Become an 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 — X
• Jobs to Be Done (Clay Christensen)
• The Design of Everyday Things (Don Norman)

Guest: Aaron D. Francis

• Company: Solo & Laravel education
• GitHub: @aarondfrancis
• 𝕏: @aarondfrancis

Host: Kent C. Dodds

• Website: kentcdodds.com
• 𝕏: @kentcdodds
• GitHub: @kentcdodds
• YouTube: kentcdodds-plus
• Podcast: epicproduct.engineer

See 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 — Developers
• Cloudflare Agents
• Dillon Mulroy — site
• Dillon Mulroy — GitHub

Guest: Dillon Mulroy

• Company: Cloudflare
• GitHub: @dmmulroy
• 𝕏: @dillon_mulroy

Host: Kent C. Dodds

• Website: kentcdodds.com
• 𝕏: @kentcdodds
• GitHub: @kentcdodds
• YouTube: kentcdodds-plus
• Podcast: epicproduct.engineer

See 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)
• Thoughtworks
• Wayne Allan — LinkedIn

Guest: Wayne Allan

• Company: Thoughtworks
• 𝕏: @xWayfinder

Host: Kent C. Dodds

• Website: kentcdodds.com
• 𝕏: @kentcdodds
• GitHub: @kentcdodds
• YouTube: kentcdodds-plus
• Podcast: epicproduct.engineer

See 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

• OpenCode
• OpenCode docs
• Dax Raad (site)
• Kent C. Dodds — blog

Guest: Dax Raad

• Company: OpenCode
• GitHub: @thdxr
• 𝕏: @thdxr

Host: Kent C. Dodds

• Website: kentcdodds.com
• 𝕏: @kentcdodds
• GitHub: @kentcdodds
• YouTube: kentcdodds-plus
• Podcast: epicproduct.engineer

See 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

Software 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 podcast
• The Last Software Engineer (essay)

Guest: Kent C. Dodds

• Company: Epic Product Engineer
• GitHub: @kentcdodds
• 𝕏: @kentcdodds

See on Epic Product Engineer