Avsnitt
-
Kent talks with Ruben Casas about building products again in the AI-agent era: why experienced engineers can now stay close to customers and code, how demos turn vague ideas into something people can react to, and why product judgment matters more as implementation gets cheaper.
They cover Postman, MCP, agent-driven UI, prototypes, early user feedback, feature product-market fit, and the engineering guardrails that help teams ship quickly without turning the product into a pile of disconnected features.
(00:00) - Introduction to Product Engineering(00:48) - Ruben Casas and Postman(07:36) - Building products again in the AI era(19:38) - Finding customer pain points(22:32) - Demos and prototypes(28:53) - Getting people to care about your ideas(31:41) - Prioritizing product problems(41:25) - Homework: build a prototype demoRuben brings a practical perspective from building developer tooling, platform work, and AI-agent products at Postman. The conversation starts with a shift many experienced engineers are feeling right now: agents make it possible to stay involved in higher-level product decisions while also getting hands-on with implementation again. That is exciting, but it also raises the bar for deciding what is worth building in the first place.
A recurring theme in the episode is that demos and prototypes are not just engineering exercises. They are product tools. Ruben and Kent talk about starting from a real pain point, building just enough to show the opportunity, putting it in front of users quickly, and using that feedback to decide whether the idea deserves more investment. They also dig into the risk of shipping too many mildly useful features, and why product engineers still need architecture, testing, taste, and guardrails as more people use AI to touch production code.
Homework
Find a real problem that is bothering you.Use an agent to build a quick prototype for it, especially if you have not tried AI coding tools seriously yet.Record a short demo, send it to someone, and ask for feedback.Resources
Ruben CasasPostmanRethinking UI in Agent-Driven SystemsMCP AppsGuest: Ruben Casas
Company: PostmanGitHub: @infoxicatorđ: @infoxicadorHost: Kent C. Dodds
Website: kentcdodds.comđ: @kentcdoddsGitHub: @kentcdoddsYouTube: Kent C. DoddsPodcast: epicproduct.engineerSee on Epic Product Engineer
-
Kent talks with Sean Roberts, engineer at PhotoShelter, about product engineering shaped by agency work and small teams: being the technical person in sales conversations early, planning with product judgment, and knowing when to speak up (and when to listen).
They discuss why implementation skill still matters in the AI era, how to avoid "vibes-only" product calls, budgeting and sequencing work with business context, and why striking up real conversations (with customers or anyone) is a trainable muscle.
(00:00) - Introduction to Product Engineering(02:11) - Agency work and customer conversations(08:47) - The technical person in the room(16:54) - Determining business goals(26:48) - Planning and the dark forest(35:10) - Relationships and positive feedback(40:21) - Homework: talk to someone newSean's path is a familiar pattern for this season: years of agency and startup work where engineers sit close to customers, budgets are real, and the person writing code is often in the room when the problem gets defined. He describes learning to ask questions on sales calls as a junior developer, sometimes literally driving the founder to the meeting, and translating needs into feasible software on the spot.
The middle of the episode turns toward planning inside a product company: helping teams separate solved problems from "dark forest" work, pushing back on specs that underestimate legacy complexity, and bringing beginner's mind even when you are senior. Sean is honest that much of his product sense today is still conversation-driven, and he wants better analytics to complement that, not replace it.
Kent and Sean also touch the emotional side of the job: positive feedback when you save someone tedium, the risk of changing UX too often because *you* are bored, and why relationships matter if you want to hear "you made my life easier." The homework is deliberately low ceremony: talk to someone you do not normally talk to and practice curiosity.
Homework
Ask someone you do not normally talk to at work for 15 minutes: a salesperson, PM, support lead, or another engineer on a different team.Ask about their job, challenges, and customers; practice translating what you hear into software constraints without jumping to solutions too fast.If work feels awkward, practice the same muscle outside work (cashier, server, neighbor) - the goal is conversation comfort, not a formal interview.Resources
PhotoShelterSean Roberts - GitHubGuest: Sean Roberts
Company: PhotoShelterGitHub: @seanrobertsđ: @sean_j_robertsHost: Kent C. Dodds
Website: kentcdodds.comđ: @kentcdoddsGitHub: @kentcdoddsYouTube: Kent C. DoddsPodcast: epicproduct.engineerSee on Epic Product Engineer
-
Saknas det avsnitt?
-
Kent talks with Grady Booch about what software engineering still means in the age of AI agents, why implementation is only one part of the work, and why human judgment remains central to building durable systems.
They discuss software architecture, the limits of large language models, computable minds, product engineering across different risk and complexity levels, and the kind of curiosity that helps engineers grow beyond a narrow slice of the field.
(00:00) - Introduction to Product Engineering(01:00) - Grady Booch background(06:47) - The Last Software Engineer(09:00) - Will the software industry end?(10:04) - Consciousness and the computable mind(20:13) - What is software engineering?(27:45) - Software architecture and agents(35:30) - The ceiling for LLMs on implementation(39:33) - Durable skills and human judgment(41:39) - Curiosity beyond your domain(45:47) - Homework: read foreign source codeGrady brings a rare long-view perspective to the AI and software engineering conversation: early computing, Rational Software, UML, IBM Research, NASA work, software architecture, and current research into computing and the human experience. That background gives this episode a useful tension. Kent and Grady do not agree on every framing, especially around whether the software development industry could eventually "end," but they find common ground around judgment, curiosity, and the responsibility engineers have for what they build.
A major theme is that implementation is not the whole of software engineering. Grady breaks the work into a broader journey from imagination to executable artifacts, with computer science, algorithms, architecture, organizational forces, economics, risk, and ethics all shaping the result. Agents and LLMs can help with some of that work, but Grady argues they remain unreliable narrators: useful, fast, and sometimes impressive, while still needing experienced humans who can smell when the work is going off the rails.
The episode closes with a practical challenge for engineers: broaden your judgment by studying systems and ideas outside your usual domain. Read unfamiliar source code. Read books outside your lane. Build the curiosity that gives your technical decisions more context.
Homework
Read the source code for a system that is completely foreign to your usual work.Use historical or open source systems like MacPaint, MediaWiki, or the Linux kernel to study different constraints and architectures.Read a book outside your domain, such as The Sciences of the Artificial, Systemantics, or The Society of Mind.Resources
Grady BoochComputing: The Human ExperienceThe Last Software EngineerThe End of History and the Last ManAnil Seth: Why AI is unlikely to become consciousKlugeThe Society of MindWorld ModelsGlobal Workspace TheoryA Robust Layered Control System for a Mobile RobotI Am a Strange LoopThe C++ Programming LanguageD3Victorian Engineering ConnectionsComputer History Museum Software History CenterMacPaint and QuickDraw Source CodeMediaWiki Source CodeLinux Kernel ArchivesThe Sciences of the ArtificialSystemanticsGuest: Grady Booch
Company: Computing: The Human ExperienceGitHub: @gradyboochđ: @grady_boochHost: Kent C. Dodds
Website: kentcdodds.comđ: @kentcdoddsGitHub: @kentcdoddsYouTube: kentcdodds-plusPodcast: epicproduct.engineerSee on Epic Product Engineer
-
Kent talks with Swizec Teller about product engineering for software that serves real businesses and non-developer users: how to learn a domain you did not grow up in, how to spot hidden friction by watching people work, and why the best product work focuses on outcomes, not engineering puzzles.
They talk through biotech, internal tooling, habits users build around buggy software, feature placement, success metrics, and how to widen the pit of success for people who are just trying to do their jobs.
(00:00) - Intro(01:04) - Swizec's path from startups to biotech(02:18) - Learning a domain you didn't grow up in(05:14) - Widening the pit of success(09:46) - Introducing workflow changes without friction(12:11) - Feature flags and early feedback loops(16:11) - How to find real user needs(20:02) - What support tickets tell you about users(22:55) - Reading friction as a product signal(24:51) - Automation and what it changes for users(26:58) - Where to place new capabilities(29:26) - Breaking big ideas into shippable pieces(33:31) - Defining success before you ship(37:27) - Software is valuable for what users can now doSwizec brings a perspective that broadens the season in a useful way. Instead of developer-facing tools, he has spent years building software that supports biotech, healthcare, and other real-world businesses where the user is trying to get work done, not admire your architecture. That makes the conversation very grounded in observation: shadowing experts, noticing workaround behavior, understanding existing habits, and putting new capabilities exactly where people already look.
The second half of the episode turns that into a practical product loop. Swizec and Kent talk about defining success before you ship, measuring whether a workflow actually improved, and balancing long-range vision with the adjacent possible of what today's technology can support. The result is a strong reminder that software is valuable because of the user's new "superpower," not because the implementation was clever.
Homework
Spend one hour watching users use your software.If you do not have direct access to users, ask your manager or PM to connect you with someone internally, or watch a partner or friend try a real workflow while you take notes.Treat every workaround or confusing step you see as a potential product opportunity.Resources
Swizec TellerSwizec newsletterSwizec Teller - GitHubGuest: Swizec Teller
GitHub: @Swizecđ: @swizecHost: Kent C. Dodds
Website: kentcdodds.comđ: @kentcdoddsGitHub: @kentcdoddsYouTube: kentcdodds-plusPodcast: epicproduct.engineerSee on Epic Product Engineer
-
Kent talks with Jack Ryan, Principal Engineer at Intercom, about product engineering at scale: why implementation is only part of the job, how to broaden what you measure as success beyond shipping tickets, and why customer feedback is an input, not a product roadmap.
They cover startup lessons from property tech, metrics vs. conversation, AI-era decision-making, performance trade-offs, PM/engineering overlap, and practical ways engineers can tighten feedback loops without outsourcing judgment to users.
Jack brings a useful split perspective: early UK proptech startup experience where engineering success and company success were basically the same thing, followed by years of technical leadership at Intercom without people management. That combination shows up throughout the episode in how he talks about responsibility, ambiguity, and what still matters when agents can generate more code faster.
A big theme is reframing success. Instead of celebrating "I shipped the ticket on time," Jack argues product engineers look back at whether the thing they shipped is being used, whether customers are happy, and whether the work connected to business outcomes. Metrics help start those conversations, but he is skeptical of sweating small week-to-week movements on a single number when qualitative signals and customer conversations often tell you more.
The close is especially practical: engineers can use their craft to improve product judgment, not only implementation - by wiring up real customer feedback channels (Slack feeds, sales-call snippets, forward-deployed engineer patterns) and learning to ask *why* people want something before deciding what to build.
Homework
Find good sources of customer feedback in your org (support, sales, success, research, or forward-deployed engineers).Use engineering to put that feedback somewhere you will actually see it regularly - wire up a Slack channel, dashboard, or digest so the signal can "wash over you" the way Jack describes.Practice asking *why* a customer wants something before treating their feature request as the spec.Resources
Jack Ryan - Intercom BlogIntercomrequisite (Intercom open source)Guest: Jack Ryan
Company: IntercomGitHub: @jmfryanđ: @jmfryanHost: Kent C. Dodds
Website: kentcdodds.comđ: @kentcdoddsGitHub: @kentcdoddsYouTube: kentcdodds-plusPodcast: epicproduct.engineerSee on Epic Product Engineer
-
Kent talks with Rhys Sullivan about building Executor and thinking like a product engineer in the AI-agent era: how to design the right primitives, why agent experience is becoming its own product surface, and how to keep quality high when shipping has never been easier.
They cover MCP, code mode, approvals, workspace scoping, docs and APIs as user experience, and why slowing down can still be the right move even when agents make speed feel free.
Rhys has an unusually current perspective on product engineering because he is working right at the edge of the agent tooling shift. The conversation starts with his recent work on Vercel Domains and then moves into Executor, where the challenge is no longer just implementing integrations, but choosing the abstractions that make a system composable, safe, and pleasant to use over time.
What makes the episode strong is how often it comes back to product judgment instead of novelty. Rhys and Kent talk about finding the right primitives, observing how other products solve hard UX problems, resisting the urge to ship every request immediately, and building systems that help agents without letting them become dangerously "helpful."
Homework
Create a dedicated notes channel or system where you save examples of products doing something well.Use those notes as reusable product input: when you need to build a flow later, pull the examples back up instead of starting from scratch.Resources
ExecutorRhys Sullivan - siteExecutor - GitHubOpenCodeGuest: Rhys Sullivan
Company: ExecutorGitHub: @RhysSullivanđ: @RhysSullivanHost: Kent C. Dodds
Website: kentcdodds.comđ: @kentcdoddsGitHub: @kentcdoddsYouTube: kentcdodds-plusPodcast: epicproduct.engineerSee on Epic Product Engineer
-
Kent talks with Alex Hillman of Stacking the Bricks about customer research, product fit, and the kind of product engineering that starts before implementation: understanding who you are serving, what they already believe, and how to make people feel understood instead of sold to.
They cover audience selection, observational research, helping in public, aligning your work with customer and business priorities, and why AI makes human judgment, trust, and synthesis more important rather than less.
Alex brings a product and marketing lens that fits this season perfectly: great products do not just solve technical problems, they help the right people recognize that you understand their world. The conversation starts with finding an audience and quickly turns into a practical way to build product sense inside a company: learn how customers describe themselves, observe where they gather, listen for the language they use, and speak from their priorities instead of your own taste.
The second half gets into Sales Safari, Stacking the Bricks' observational research practice. Alex explains why surveys and interviews can miss important signal, what to look for in real conversations, and how notes on jargon, pain, worldview, and recommendations can turn scattered internet conversations into useful product understanding. The through-line is simple and demanding: reduce the distance between you and the people you serve so your software, messaging, and decisions feel anticipated rather than manipulative.
Homework
The next time coworkers or product teammates disagree about direction, step back and observe the conversation.Ask: who is this disagreement in service of? Is it serving the customer, the decision maker, the loudest person, or someone else?Practice this once a day or once a week, then use the patterns you notice to decide what you should contribute.Resources
Stacking the Bricks30x500The Tiny MBAThe Mom TestAlex Hillman on XGuest: Alex Hillman
Company: Stacking the BricksGitHub: @alexknowshtmlđ: @alexhillmanHost: Kent C. Dodds
Website: kentcdodds.comđ: @kentcdoddsGitHub: @kentcdoddsYouTube: kentcdodds-plusPodcast: epicproduct.engineerSee on Epic Product Engineer
-
Kent talks with Julius Marminge about building T3 Code in the agent-orchestrator wave: why speed still matters, why fast shipping does not mean shipping every possible feature, and how product judgment becomes more important as parallel AI workflows make implementation cheap.
They dig into dogfooding, core-product trade-offs, monetization pressure, customization vs defaults, and how to keep agent-built software maintainable over time.
Julius is building right in the middle of one of the fastest-moving product categories in software, and that gives this episode a useful tension: everything feels possible, but that does not mean everything belongs in the product. The conversation covers the shift from one-agent-at-a-time coding to orchestration, why T3 Code focuses so much on a fast app layer, and how Julius thinks about what should live in the core product versus forks, plugins, or future work.
The deeper lesson is about judgment under speed. Julius and Kent keep returning to the same idea from different angles: when agents can generate a lot of implementation quickly, the real work is deciding what is worth building, what will age well, and what future decisions you might accidentally box yourself out of.
Homework
Take a step back and look at your product from the whole picture, not just the slice you currently touch.Before prioritizing a feature, ask whether it keeps the product maintainable long-term and whether it fits the job to be done for your users.Resources
T3 CodeT3 ChatJulius Marminge â GitHubOpenCodeGuest: Julius Marminge
GitHub: @juliusmarmingeđ: @jullerinoHost: Kent C. Dodds
Website: kentcdodds.comđ: @kentcdoddsGitHub: @kentcdoddsYouTube: kentcdodds-plusPodcast: epicproduct.engineerSee on Epic Product Engineer
-
Kent talks with Jamon Holmgren about product engineering from a long-running consultancy lens: how working with clients, stakeholders, and non-technical users sharpens your product sense, and why those skills matter even more as implementation gets cheaper with AI.
They cover React Native, consulting, game design, stakeholder failures, feedback loops, and what software builders need to keep learning as the job shifts up the stack.
Jamon brings a useful mix to this conversation: founder of Infinite Red, longtime consultant, React Native specialist, and now indie game developer. That perspective makes the episode unusually practical. He has spent years watching where projects go wrong when product thinking is weak: bad requirements, unclear stakeholder alignment, UX details nobody owned, and engineers optimizing the wrong thing too early.
The thread through the whole episode is durability. Product engineering is not just about shipping faster with agents or getting better at a specific tool. It is about understanding people, shaping better requirements, recognizing when the human side of the workflow matters more than the code, and making decisions that keep paying off as the technology changes around you.
Homework
Sit down with a non-technical person and watch them try to use a feature you built.Write down every hesitation, workaround, double-click, or confusing step you notice, then use that list to reprioritize what you fix next.Resources
Infinite RedJamon Holmgren â siteNight Shift Agentic WorkflowGunship Origins on SteamGuest: Jamon Holmgren
Company: Infinite RedGitHub: @jamonholmgrenđ: @jamonholmgrenHost: Kent C. Dodds
Website: kentcdodds.comđ: @kentcdoddsGitHub: @kentcdoddsYouTube: kentcdodds-plusPodcast: epicproduct.engineerSee on Epic Product Engineer
-
Kent talks with Don Norman about why the core work of product engineering has not changed: watch people work, treat so-called user error as a design problem, and fix root causes instead of blaming symptoms.
Don walks through a remarkable arc from electrical engineering and cognitive psychology to Three Mile Island, Xerox PARC, Apple, and the first use of user experience in a job title. They talk about timing and failed products, cross-functional product teams, what AI changes for software builders, and why Don now cares most about designing for humanity, not only usability.
Don's career makes this episode unusually wide-ranging: early computing, human error, aviation safety, Unix, Apple product decisions, digital cameras, color TV, and the long arc from usable products to systems that shape society. The through-line is straightforward but demanding: if you want better products, watch what people actually do, notice the workarounds they no longer complain about, and treat clusters of small usability problems like real product debt.
The second half brings that thinking into the present. Don and Kent talk about AI coding tools as force multipliers that still need direction, architecture, and supervision, then zoom out to Design for a Better World and the Don Norman Design Award. The result is a conversation about product sense that spans decades without feeling dated: the tools change, but the responsibility to understand people, systems, and consequences does not.
Homework
Spend time watching people do real work before you ask them for solutions; observation reveals the hidden setup, workarounds, and friction they now assume are just "how it works."After a release, step back and fix clusters of small usability issues as a system instead of waiting for one confusing bug to become catastrophic.Treat AI as a force multiplier you must instruct and supervise; stay responsible for the problem definition, architecture, and review.Resources
Don Norman Design Award (DNDA)Design for a Better WorldThe Design of Everyday ThingsNielsen Norman Group â Don NormanUnited Nations Sustainable Development GoalsGuest: Don Norman
Company: Don Norman Design Award (DNDA)Host: Kent C. Dodds
Website: kentcdodds.comđ: @kentcdoddsGitHub: @kentcdoddsYouTube: kentcdodds-plusPodcast: epicproduct.engineerSee on Epic Product Engineer
-
Kent talks with Will King about bringing an industrial design mindset into software: human factors, observing real users, and why good product engineering starts with caring enough to notice what frustrates people.
They dig into product debt, support as a product superpower, pruning features without breaking trust, and how to use AI agents for exploration and critique instead of only faster implementation.
Will's path runs from designing bucket trucks to self-taught software engineering, education products, and database tooling, and that background gives this episode a distinctive lens: software is still a product people use with bodies, habits, emotions, and mental models. The conversation makes product sense concrete through examples like onboarding timing, course complexity, support workflows, and the small confidence signals that separate stable-feeling products from merely functional ones.
You'll hear why watching users work keeps surfacing across this series, how to tell broken experiences from merely unpopular ones, why user feedback usually improves polish more than strategy, and how product engineers can stay valuable in an agent-heavy future by understanding both the user and the constraints of the software medium.
Homework
Use AI agents more for gathering than executing: explore multiple solution paths, adjacent domains, and missing context before you ship.Give agents richer context like user demographics, constraints, and likely mental models, then use your own judgment to evaluate what comes back.Slow down long enough to question assumptions before implementation; use AI as a creativity and critique tool, not just a code accelerator.Resources
Will King - siteDeploy Empathy (Michele Hansen)The Mom Test (Rob Fitzpatrick)Interface Craft (Josh Puckett)Guest: Will King
Company: Crunchy DataGitHub: @wking-iođ: @willkingHost: Kent C. Dodds
Website: kentcdodds.comđ: @kentcdoddsGitHub: @kentcdoddsYouTube: kentcdodds-plusPodcast: epicproduct.engineerSee on Epic Product Engineer
-
Kent talks with Aaron D. Francis about product engineering: why ticket-taking implementation is losing ground to agents, what a vertical slice from UI to database really means, and how Aaronâs desktop app Solo came from a painful problemânot a feature spec.
They go deep on scratch-your-own-itch products, separating agents from dev stacks, Jobs to Be Done, why users bring you solutions instead of problems, and how empathy (and letting go of âtechnically correctâ) changes what you ship.
Aaron builds in publicâLaravel roots, education, and now Solo, a terminal multiplexerâstyle desktop app for organizing agents and dev stacks. This episode is a practical tour of product sense for developers: watching people work, reading support email with empathy, cow paths vs. fences, and why the ârightâ architecture can still lose if humans go home furious.
Youâll hear how Aaron reasons from problem â solution when users ask for worktrees, when to duplicate UI affordances even when the model is âone,â and how introverts can still do discovery by treating outreach like an optimization missionâplus niche opportunities outside the Cursor clone gold rush.
Homework
When someone asks for a solution (e.g. a feature), slow down and ask what problem theyâre really trying to solveâusers often lead with implementations.Practice user empathy: imagine someone stressed, trying to finish work; question âtechnically correctâ UX that blames the user instead of protecting them (confirmations, back-button data loss, etc.).If talking to people is hard, reframe discovery as a systematic search (spreadsheet energy, trusted partners, or domain friends)âor pair with someone who loves conversations.Resources
Aaron D. Francis â XJobs to Be Done (Clay Christensen)The Design of Everyday Things (Don Norman)Guest: Aaron D. Francis
Company: Solo & Laravel educationGitHub: @aarondfrancisđ: @aarondfrancisHost: Kent C. Dodds
Website: kentcdodds.comđ: @kentcdoddsGitHub: @kentcdoddsYouTube: kentcdodds-plusPodcast: epicproduct.engineerSee on Epic Product Engineer
-
Kent talks with Dillon Mulroy, Principal Engineer at Cloudflare, about Agent Experience and dogfooding AI platform work: how Cloudflare closes the loop between builders and customers, why observability and support are product superpowers, and how to stay disciplined when agents tempt you to ship huge diffs overnight.
They go deep on watching users work, firehose social feedback, partnering with support, and why âmake pain painfulâ aligns incentives for better software.
Dillonâs path runs from internal insurance tools to Vercel Domains to Cloudflareâs agent and dashboard workâalways with the same through-line: care about the user, get real feedback, and invest in primitives so delighters donât collapse under bad foundations. This episode covers metrics and paging as a product habit, learning from customer escalations, scoping small when AI speeds up coding, and building cross-functional relationships (support, sales, finance) as part of engineering judgment.
Youâll hear practical parallels with episodes on delighters and onboarding tension, plus why reviewing agent-written code still matters for system intuition when things break at 2 a.m.
Homework
Try hard and care a lot; more practically, focus on foundations and primitives.Put good feedback systems in place so you know whatâs going on with your product and where it doesnât feel goodâalerting and metrics, customer journey signals, or customer interviews.If you have a customer support team, sit with them and watch them triage cases for your product; get to know supportâtheyâre sitting on a gold mine of product signalâand empathize with them like you do with users.Kentâs shorthand for the mindset Dillon agreed with: make pain painfulâif your users are hurting, you should feel it too.Resources
Cloudflare â DevelopersCloudflare AgentsDillon Mulroy â siteDillon Mulroy â GitHubGuest: Dillon Mulroy
Company: CloudflareGitHub: @dmmulroyđ: @dillon_mulroyHost: Kent C. Dodds
Website: kentcdodds.comđ: @kentcdoddsGitHub: @kentcdoddsYouTube: kentcdodds-plusPodcast: epicproduct.engineerSee on Epic Product Engineer
-
Kent talks with Wayne Allan (engineer, PM, and consultant) about product engineering in practice: why âbuilding the thing rightâ only matters after youâre building the right thing, how to shorten feedback loops without six-month research theater, and why falling in love with the problem beats falling in love with your solution.
They cover scrappy validation, talking to sales and support, the Kano model, *Crossing the Chasm*, and what changes when shipping gets faster than learning.
Wayne blends delivery and product leadershipâhis stories range from a flagship-adjacent launch that nobody used to the everyday discipline of listening to customers without waiting two weeks for a meeting. This episode connects feedback-loop thinking (familiar from CI) to product discovery, yes-and conversations when someone is married to a feature idea, and the difference between hygiene features, performance features, and delighters when teams ship faster than users can absorb.
Youâll also hear grounded takes on when âmove fastâ breaks trust, how AI may reshape search-and-listing UIs, and a concrete reading list: *The Mom Test* and *Crossing the Chasm*.
Homework
Talk to people, ask good questions, and listenâWayne says thatâs the biggest hack thatâs worked in his career.Read *The Mom Test*: ask how people solved this problem in the past instead of whether they like your idea or would use itâyou get far more useful insight (Wayne ties this to caring about the problem, not your solution).Resources
*The Mom Test* (Rob Fitzpatrick)*Crossing the Chasm* (Geoffrey Moore)ThoughtworksWayne Allan â LinkedInGuest: Wayne Allan
Company: Thoughtworksđ: @xWayfinderHost: Kent C. Dodds
Website: kentcdodds.comđ: @kentcdoddsGitHub: @kentcdoddsYouTube: kentcdodds-plusPodcast: epicproduct.engineerSee on Epic Product Engineer
-
Kent talks with Dax Raad about building OpenCode in a crowded coding-agent market: why dev tools are still a consumer-style product, how fast shipping can make good products feel worse, and what âproduct skillâ actually looks like when agents remove friction from implementation.
They dig into onboarding, progressive disclosure, listening across many user requests for the real pattern, and why slowing down can be the right moveâeven when competitors ship faster.
Dax has spent years building tools developers actually use; on OpenCode heâs thinking hard about product process while the space moves at breakneck speed. This episode is a practical look at product deterioration (not just code rot), bottom-up adoption for dev tools, and how coding agents change who decides what gets builtâwithout replacing the need for taste, restraint, and clarity about what problem youâre solving.
Youâll hear concrete examples from OpenCodeâs terminal UI and onboarding, parallels to Kentâs Epic Workshop app, and a grounded take on inference pricing, hype, and when âship messy and fix laterâ does and doesnât hold up.
Homework
Convince yourself that getting good at product really mattersâDax says thereâs a lot in the culture that tries to tell you it doesnât, and you need that commitment because the belief will be challenged.If you donât already believe it, figure out how to make yourself believe it matters (Kentâs recap of the guestâs action).Resources
OpenCodeOpenCode docsDax Raad (site)Kent C. Dodds â blogGuest: Dax Raad
Company: OpenCodeGitHub: @thdxrđ: @thdxrHost: Kent C. Dodds
Website: kentcdodds.comđ: @kentcdoddsGitHub: @kentcdoddsYouTube: kentcdodds-plusPodcast: epicproduct.engineerSee on Epic Product Engineer
-
Kent opens Become an Epic Product Engineer: why product engineering is the durable skill as AI takes on more implementation, what to expect from guest conversations and homework, and where to start in the catalog.
(00:00) - Introducing Become an Epic Product Engineer(00:38) - The archer metaphor(00:52) - Knowing what to build(01:05) - Learning out loud with guests(01:18) - Product engineers vs product managers(01:35) - Homework on every episode(01:55) - Episode highlights(02:15) - Better with Kent companion series(02:30) - Homework: subscribe and pick an episodeSoftware keeps changing, and AI is accelerating something that was already true: implementation is getting cheaper while knowing what to build matters more.
In this intro Kent frames the show - learning out loud with people who blend technical depth and product judgment - and why developers need product thinking without becoming product managers. He walks through the archer metaphor (better arrows, same need to pick the target), how homework works at the end of every episode, and highlights conversations to start with.
Also: Better with Kent, Kent's solo companion series on the same durable skills.
Homework
Subscribe to Become an Epic Product Engineer in your favorite podcast app.Pick one episode to listen to first - if it wins you over, come back for the rest.Resources
Become an Epic Product Engineer podcastThe Last Software Engineer (essay)Guest: Kent C. Dodds
Company: Epic Product EngineerGitHub: @kentcdoddsđ: @kentcdoddsSee on Epic Product Engineer
