Become an Epic Product Engineer Transistor (https://transistor.fm) https://feeds.transistor.fm/become-an-epic-product-engineer Become an Epic Product Engineer is Kent C. Dodds's interview podcast about skills that stay valuable as AI takes on more implementation: product engineering - blending technical depth with product judgment, user empathy, and problem clarity. Each episode is a long-form conversation with a guest who has shipped real software and cares about building the right thing before making it right. You get full audio, transcripts, structured show notes, homework (one concrete action to try), and links from the conversation. Canonical home for the show and every episode page: https://www.epicproduct.engineer/become-an-epic-product-engineer-podcast New episodes publish on Wednesdays (America/Denver). Video is added on Transistor for supported podcast apps when available. Complements Better with Kent - Kent's solo series on durable skills for people who ship software. © 2026 Kent C. Dodds Tech LLC. All rights reserved. e5e90e53-9f1a-5bc4-9f60-143ac09116d6 yes en Thu, 28 May 2026 15:00:05 -0600 Thu, 28 May 2026 15:01:55 -0600 https://www.epicproduct.engineer/become-an-epic-product-engineer-podcast https://img.transistorcdn.com/OfJDxZnLufV9vRbkoKc4xGdHk5aFFHm5U5p7cqJSsys/rs:fill:0:0:1/w:1400/h:1400/q:60/mb:500000/aHR0cHM6Ly9pbWct/dXBsb2FkLXByb2R1/Y3Rpb24udHJhbnNp/c3Rvci5mbS9mMmRi/OGEwYjA5MDVmNTQ5/N2RlOTQ5NWYyMWYy/NDYxNy5qcGc.jpg Become an Epic Product Engineer https://www.epicproduct.engineer/become-an-epic-product-engineer-podcast episodic Kent C. Dodds Become an Epic Product Engineer is Kent C. Dodds's interview podcast about skills that stay valuable as AI takes on more implementation: product engineering - blending technical depth with product judgment, user empathy, and problem clarity. Each episode is a long-form conversation with a guest who has shipped real software and cares about building the right thing before making it right. You get full audio, transcripts, structured show notes, homework (one concrete action to try), and links from the conversation. Canonical home for the show and every episode page: https://www.epicproduct.engineer/become-an-epic-product-engineer-podcast New episodes publish on Wednesdays (America/Denver). Video is added on Transistor for supported podcast apps when available. Complements Better with Kent - Kent's solo series on durable skills for people who ship software. Become an Epic Product Engineer is Kent C. Become an Epic Product Engineer,product engineering,Kent C. Dodds,software development,product management,user empathy,AI and engineering,software architecture,product sense Kent C. Dodds No No User empathy, feedback loops, and what not to build - product engineering with Jack Ryan 12 12 User empathy, feedback loops, and what not to build - product engineering with Jack Ryan full 2f6caa30-ad16-4977-bc4e-81db407cd085 https://www.epicproduct.engineer/user-empathy-feedback-loops-and-what-not-to-build-product-engineering-with-jack-ryan~ed0b0 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.

Chapters

0:00 Introduction to Product Engineering 2:00 UK proptech startup lessons 5:24 Tying engineering work to business success 7:03 Metrics and defining success 10:13 AI agents and product judgment 15:17 Performance trade-offs at Intercom 23:39 Message to pure implementers 29:12 Product engineer vs product manager 34:46 Customer feedback channels and user empathy 50:29 Homework: wire up customer feedback

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

Guest: Jack Ryan

Host: Kent C. Dodds

See 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.

Chapters

0:00 Introduction to Product Engineering 2:00 UK proptech startup lessons 5:24 Tying engineering work to business success 7:03 Metrics and defining success 10:13 AI agents and product judgment 15:17 Performance trade-offs at Intercom 23:39 Message to pure implementers 29:12 Product engineer vs product manager 34:46 Customer feedback channels and user empathy 50:29 Homework: wire up customer feedback

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

Guest: Jack Ryan

Host: Kent C. Dodds

See on Epic Product Engineer

]]> Wed, 27 May 2026 03:00:00 -0600 Kent C. Dodds, Jack Ryan Kent C. Dodds, Jack Ryan 3203 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.

Chapters

0:00 Introduction to Product Engineering 2:00 UK proptech startup lessons 5:24 Tying engineering work to business success 7:03 Metrics and defining success 10:13 AI agents and product judgment 15:17 Performance trade-offs at Intercom 23:39 Message to pure implementers 29:12 Product engineer vs product manager 34:46 Customer feedback channels and user empathy 50:29 Homework: wire up customer feedback

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

Guest: Jack Ryan

Host: Kent C. Dodds

See on Epic Product Engineer

]]> product engineering, user empathy, customer feedback, Intercom, engineering leadership, Jack Ryan No Primitives, agent UX, and Executor - product engineering with Rhys Sullivan 11 11 Primitives, agent UX, and Executor - product engineering with Rhys Sullivan full 9f40c0e4-e82d-422c-9421-db55a222ae4a https://www.epicproduct.engineer/primitives-agent-ux-and-executor-product-engineering-with-rhys-sullivan~85cun 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.

Chapters

0:00 Intro 2:51 From Vercel Domains to Executor 4:13 What Executor does 6:30 Code mode and dynamic workloads 10:04 Who Executor is for 12:09 What makes a good product primitive 15:37 How Executor's architecture evolved 19:21 Knowing when to slow down 20:23 UX work at Vercel Domains 22:37 Scale and edge cases in domain management 24:41 Why good engineering is good product 26:14 From UX to PX 29:13 Docs and APIs as product primitives 31:02 Designing for agent trust and security 35:40 Key takeaways 39:10 Homework: build a product sense library

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

Guest: Rhys Sullivan

Host: Kent C. Dodds

See 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.

Chapters

0:00 Intro 2:51 From Vercel Domains to Executor 4:13 What Executor does 6:30 Code mode and dynamic workloads 10:04 Who Executor is for 12:09 What makes a good product primitive 15:37 How Executor's architecture evolved 19:21 Knowing when to slow down 20:23 UX work at Vercel Domains 22:37 Scale and edge cases in domain management 24:41 Why good engineering is good product 26:14 From UX to PX 29:13 Docs and APIs as product primitives 31:02 Designing for agent trust and security 35:40 Key takeaways 39:10 Homework: build a product sense library

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

Guest: Rhys Sullivan

Host: Kent C. Dodds

See on Epic Product Engineer

]]> Wed, 20 May 2026 04:00:00 -0600 Kent C. Dodds, Rhys Sullivan Kent C. Dodds, Rhys Sullivan 2484 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.

Chapters

0:00 Intro 2:51 From Vercel Domains to Executor 4:13 What Executor does 6:30 Code mode and dynamic workloads 10:04 Who Executor is for 12:09 What makes a good product primitive 15:37 How Executor's architecture evolved 19:21 Knowing when to slow down 20:23 UX work at Vercel Domains 22:37 Scale and edge cases in domain management 24:41 Why good engineering is good product 26:14 From UX to PX 29:13 Docs and APIs as product primitives 31:02 Designing for agent trust and security 35:40 Key takeaways 39:10 Homework: build a product sense library

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

Guest: Rhys Sullivan

Host: Kent C. Dodds

See on Epic Product Engineer

]]> product engineering, Executor, MCP, agent experience, product primitives, developer tools No Customer research, desire, and Sales Safari - product engineering with Alex Hillman 9 9 Customer research, desire, and Sales Safari - product engineering with Alex Hillman full ede4d68b-530e-4a91-8491-288bb71be8af https://www.epicproduct.engineer/customer-research-desire-and-sales-safari-product-engineering-with-alex-hillman~hs16v 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.

Chapters

0:00 Introduction to Product Engineering 2:46 Alex Hillman and Stacking the Bricks 6:27 Finding your audience 14:44 How customers describe themselves 29:09 Identifying who you are building for 52:16 Sales Safari and observational research 1:08:41 Homework: who is this disagreement serving?

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

Guest: Alex Hillman

Host: Kent C. Dodds

See 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.

Chapters

0:00 Introduction to Product Engineering 2:46 Alex Hillman and Stacking the Bricks 6:27 Finding your audience 14:44 How customers describe themselves 29:09 Identifying who you are building for 52:16 Sales Safari and observational research 1:08:41 Homework: who is this disagreement serving?

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

Guest: Alex Hillman

Host: Kent C. Dodds

See on Epic Product Engineer

]]> Wed, 13 May 2026 03:00:00 -0600 Kent C. Dodds, Alex Hillman Kent C. Dodds, Alex Hillman 4307 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.

Chapters

0:00 Introduction to Product Engineering 2:46 Alex Hillman and Stacking the Bricks 6:27 Finding your audience 14:44 How customers describe themselves 29:09 Identifying who you are building for 52:16 Sales Safari and observational research 1:08:41 Homework: who is this disagreement serving?

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

Guest: Alex Hillman

Host: Kent C. Dodds

See on Epic Product Engineer

]]> product engineering, customer research, Sales Safari, audience research, Stacking the Bricks, product marketing No Speed, prioritization, and maintainability — product engineering with Julius Marminge 8 8 Speed, prioritization, and maintainability — product engineering with Julius Marminge full 0c17a893-4095-4ba0-a325-e3e8ea730fcc https://www.epicproduct.engineer/speed-prioritization-and-maintainability-product-engineering-with-julius-marminge~jihuq 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.

Chapters

0:00 Introduction to Product Engineering 0:42 Julius's Background and T3 Code 2:05 Speed as a Product Differentiator 6:21 Parallelism and the Orchestrator Shift 9:48 Deciding What Belongs in the Core Product 13:21 Pressure to Ship Fast vs. Shipping Quality 15:45 Slowing Down for Maintainability 19:22 Product Vision, Open Source, and Team Constraints 20:50 Monetization and Building What the Ecosystem Lacks 23:53 Pricing, Inference Costs, and Sustainable Products 27:34 Feature Parity, Dogfooding, and Early Priorities 30:29 Building for Users Who Aren't You 31:30 Supervising Agents and Avoiding Bad Directions 34:18 Custom Workflows, Defaults, and the Core UX 39:15 Homework: Step Back and Look at the Whole Product

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

Guest: Julius Marminge

Host: Kent C. Dodds

See 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.

Chapters

0:00 Introduction to Product Engineering 0:42 Julius's Background and T3 Code 2:05 Speed as a Product Differentiator 6:21 Parallelism and the Orchestrator Shift 9:48 Deciding What Belongs in the Core Product 13:21 Pressure to Ship Fast vs. Shipping Quality 15:45 Slowing Down for Maintainability 19:22 Product Vision, Open Source, and Team Constraints 20:50 Monetization and Building What the Ecosystem Lacks 23:53 Pricing, Inference Costs, and Sustainable Products 27:34 Feature Parity, Dogfooding, and Early Priorities 30:29 Building for Users Who Aren't You 31:30 Supervising Agents and Avoiding Bad Directions 34:18 Custom Workflows, Defaults, and the Core UX 39:15 Homework: Step Back and Look at the Whole Product

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

Guest: Julius Marminge

Host: Kent C. Dodds

See on Epic Product Engineer

]]> Wed, 06 May 2026 04:00:00 -0600 Kent C. Dodds, Julius Marminge Kent C. Dodds, Julius Marminge 2529 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.

Chapters

0:00 Introduction to Product Engineering 0:42 Julius's Background and T3 Code 2:05 Speed as a Product Differentiator 6:21 Parallelism and the Orchestrator Shift 9:48 Deciding What Belongs in the Core Product 13:21 Pressure to Ship Fast vs. Shipping Quality 15:45 Slowing Down for Maintainability 19:22 Product Vision, Open Source, and Team Constraints 20:50 Monetization and Building What the Ecosystem Lacks 23:53 Pricing, Inference Costs, and Sustainable Products 27:34 Feature Parity, Dogfooding, and Early Priorities 30:29 Building for Users Who Aren't You 31:30 Supervising Agents and Avoiding Bad Directions 34:18 Custom Workflows, Defaults, and the Core UX 39:15 Homework: Step Back and Look at the Whole Product

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

Guest: Julius Marminge

Host: Kent C. Dodds

See on Epic Product Engineer

]]> product engineering, agent orchestrators, maintainability, T3 Code, AI workflows, developer tools No Stakeholder empathy, UX, and durable product skills — product engineering with Jamon Holmgren 7 7 Stakeholder empathy, UX, and durable product skills — product engineering with Jamon Holmgren full d1193505-037f-40cd-b409-d8c08b54ed2d https://www.epicproduct.engineer/stakeholder-empathy-ux-and-durable-product-skills-jamon-holmgren~r856r 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.

Chapters

0:00 Introduction to Product Engineering 6:08 The Importance of Product Engineering 9:08 Transitioning in the Tech Landscape 12:06 The Role of AI in Product Engineering 15:03 Human Element in Product Design 17:59 Future of Product Engineering and AI 25:59 The Relevance of Game Design Today 27:03 The Role of Product Engineering 28:23 Learning from Failures in Stakeholder Engagement 30:16 The Importance of Feedback in Product Development 32:05 Designing User-Friendly Interfaces 34:32 The Value of Experienced Designers 35:40 The Evolving Workflow of Product Engineering 37:32 Balancing Speed and Quality in Development 39:20 The Role of Junior Engineers in the Industry 40:45 Engaging Stakeholders for Successful Projects 44:21 Navigating Bad Requirements 46:41 Avoiding Premature Optimization 52:31 The Future of Product Engineering 54:12 Practical Homework for Improving Product Sense

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

Guest: Jamon Holmgren

Host: Kent C. Dodds

See 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.

Chapters

0:00 Introduction to Product Engineering 6:08 The Importance of Product Engineering 9:08 Transitioning in the Tech Landscape 12:06 The Role of AI in Product Engineering 15:03 Human Element in Product Design 17:59 Future of Product Engineering and AI 25:59 The Relevance of Game Design Today 27:03 The Role of Product Engineering 28:23 Learning from Failures in Stakeholder Engagement 30:16 The Importance of Feedback in Product Development 32:05 Designing User-Friendly Interfaces 34:32 The Value of Experienced Designers 35:40 The Evolving Workflow of Product Engineering 37:32 Balancing Speed and Quality in Development 39:20 The Role of Junior Engineers in the Industry 40:45 Engaging Stakeholders for Successful Projects 44:21 Navigating Bad Requirements 46:41 Avoiding Premature Optimization 52:31 The Future of Product Engineering 54:12 Practical Homework for Improving Product Sense

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

Guest: Jamon Holmgren

Host: Kent C. Dodds

See on Epic Product Engineer

]]> Wed, 29 Apr 2026 04:00:00 -0600 Kent C. Dodds, Jamon Holmgren Kent C. Dodds, Jamon Holmgren 3385 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.

Chapters

0:00 Introduction to Product Engineering 6:08 The Importance of Product Engineering 9:08 Transitioning in the Tech Landscape 12:06 The Role of AI in Product Engineering 15:03 Human Element in Product Design 17:59 Future of Product Engineering and AI 25:59 The Relevance of Game Design Today 27:03 The Role of Product Engineering 28:23 Learning from Failures in Stakeholder Engagement 30:16 The Importance of Feedback in Product Development 32:05 Designing User-Friendly Interfaces 34:32 The Value of Experienced Designers 35:40 The Evolving Workflow of Product Engineering 37:32 Balancing Speed and Quality in Development 39:20 The Role of Junior Engineers in the Industry 40:45 Engaging Stakeholders for Successful Projects 44:21 Navigating Bad Requirements 46:41 Avoiding Premature Optimization 52:31 The Future of Product Engineering 54:12 Practical Homework for Improving Product Sense

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

Guest: Jamon Holmgren

Host: Kent C. Dodds

See on Epic Product Engineer

]]> product engineering, stakeholder feedback, UX, React Native, AI agents, Jamon Holmgren No Watch users, fix systems, and design for humanity — product engineering with Don Norman 6 6 Watch users, fix systems, and design for humanity — product engineering with Don Norman full c7034fb0-e838-4e75-acdb-54ac9394c02f https://www.epicproduct.engineer/watch-users-fix-systems-and-design-for-humanity-product-engineering-with-don-norman-3l2t5 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.

Chapters

0:00 Introduction to Product Engineering and Design 1:13 Don Norman's Journey in Engineering and Psychology 5:53 The Intersection of Human Error and Design 10:39 The Evolution of Technology and User Experience 16:53 Lessons from Apple and Product Development 22:59 The Importance of Failure and Learning 24:23 Cognitive Science and Its Impact on Design 26:17 The Evolution of Neural Networks 30:09 Challenges of Change and Innovation 34:10 The Role of Early Adopters 37:05 Learning from Failure 40:19 Vision and Long-Term Impact 47:34 Empowering Engineers for Societal Good 49:41 Navigating Technological Change and Advocacy 51:30 Understanding the Role of Advisors and Consultants 54:41 The Impact of AI on Software Development 59:47 The Future of Programming in an AI-Driven World 1:06:35 Designing for Humanity and Sustainability

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

Guest: Don Norman

Host: Kent C. Dodds

See 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.

Chapters

0:00 Introduction to Product Engineering and Design 1:13 Don Norman's Journey in Engineering and Psychology 5:53 The Intersection of Human Error and Design 10:39 The Evolution of Technology and User Experience 16:53 Lessons from Apple and Product Development 22:59 The Importance of Failure and Learning 24:23 Cognitive Science and Its Impact on Design 26:17 The Evolution of Neural Networks 30:09 Challenges of Change and Innovation 34:10 The Role of Early Adopters 37:05 Learning from Failure 40:19 Vision and Long-Term Impact 47:34 Empowering Engineers for Societal Good 49:41 Navigating Technological Change and Advocacy 51:30 Understanding the Role of Advisors and Consultants 54:41 The Impact of AI on Software Development 59:47 The Future of Programming in an AI-Driven World 1:06:35 Designing for Humanity and Sustainability

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

Guest: Don Norman

Host: Kent C. Dodds

See on Epic Product Engineer

]]> Wed, 22 Apr 2026 04:00:00 -0600 Kent C. Dodds, Don Norman Kent C. Dodds, Don Norman 4589 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.

Chapters

0:00 Introduction to Product Engineering and Design 1:13 Don Norman's Journey in Engineering and Psychology 5:53 The Intersection of Human Error and Design 10:39 The Evolution of Technology and User Experience 16:53 Lessons from Apple and Product Development 22:59 The Importance of Failure and Learning 24:23 Cognitive Science and Its Impact on Design 26:17 The Evolution of Neural Networks 30:09 Challenges of Change and Innovation 34:10 The Role of Early Adopters 37:05 Learning from Failure 40:19 Vision and Long-Term Impact 47:34 Empowering Engineers for Societal Good 49:41 Navigating Technological Change and Advocacy 51:30 Understanding the Role of Advisors and Consultants 54:41 The Impact of AI on Software Development 59:47 The Future of Programming in an AI-Driven World 1:06:35 Designing for Humanity and Sustainability

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

Guest: Don Norman

Host: Kent C. Dodds

See on Epic Product Engineer

]]> product engineering, Don Norman, human factors, user observation, design, AI No Human factors, product debt, and industrial design — product engineering with Will King 6 6 Human factors, product debt, and industrial design — product engineering with Will King full f913540b-aab6-4ef6-a3f8-d8e03af4a7ea https://www.epicproduct.engineer/human-factors-product-debt-and-industrial-design-product-engineering-with-will-king-6y0o3 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.

Chapters

0:00 Introduction to Product Engineering 2:12 The Transition from Industrial Design to Software 6:58 Human Factors in Software Design 9:41 Understanding User Demographics 13:40 Observing User Behavior 18:45 The Importance of User Feedback 26:20 The Role of Problem Solving in Product Engineering 31:43 Understanding Product Debt 34:26 The Importance of Pruning Features 38:43 Balancing User Experience and Product Changes 43:27 Navigating User Feedback 46:57 The Future of Software Development 53:27 The Role of Product Engineers vs. Product Managers 56:57 Actionable Steps for Product Engineers

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

Guest: Will King

Host: Kent C. Dodds

See 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.

Chapters

0:00 Introduction to Product Engineering 2:12 The Transition from Industrial Design to Software 6:58 Human Factors in Software Design 9:41 Understanding User Demographics 13:40 Observing User Behavior 18:45 The Importance of User Feedback 26:20 The Role of Problem Solving in Product Engineering 31:43 Understanding Product Debt 34:26 The Importance of Pruning Features 38:43 Balancing User Experience and Product Changes 43:27 Navigating User Feedback 46:57 The Future of Software Development 53:27 The Role of Product Engineers vs. Product Managers 56:57 Actionable Steps for Product Engineers

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

Guest: Will King

Host: Kent C. Dodds

See on Epic Product Engineer

]]> Wed, 15 Apr 2026 04:00:00 -0600 Kent C. Dodds, Will King Kent C. Dodds, Will King 3716 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.

Chapters

0:00 Introduction to Product Engineering 2:12 The Transition from Industrial Design to Software 6:58 Human Factors in Software Design 9:41 Understanding User Demographics 13:40 Observing User Behavior 18:45 The Importance of User Feedback 26:20 The Role of Problem Solving in Product Engineering 31:43 Understanding Product Debt 34:26 The Importance of Pruning Features 38:43 Balancing User Experience and Product Changes 43:27 Navigating User Feedback 46:57 The Future of Software Development 53:27 The Role of Product Engineers vs. Product Managers 56:57 Actionable Steps for Product Engineers

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

Guest: Will King

Host: Kent C. Dodds

See on Epic Product Engineer

]]> product engineering, human factors, industrial design, product debt, user research, AI agents No Vertical slices, Solo, and empathy — product engineering with Aaron D. Francis 5 5 Vertical slices, Solo, and empathy — product engineering with Aaron D. Francis full 6b717a20-95a3-4b32-9005-87854a0cc2e8 https://www.epicproduct.engineer/vertical-slices-solo-and-empathy-product-engineering-with-aaron-d-francis-kadx7 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.

Chapters

0:00 Introduction to Product Engineering 0:54 What Product Engineering Means in an AI World 4:42 Building Solo From a Painful Real Problem 8:33 Solving the Underlying Problem, Not the Requested Feature 11:37 Questions That Reveal What Users Actually Need 15:21 Product Vision and Having a Point of View 20:41 Worktrees, Feature Requests, and the Real Problem 24:59 Building for Domains You Actually Understand 28:24 AI, Bespoke SaaS, and Underserved Niches 31:00 Finding Painful Problems in Real Businesses 38:17 Empathy Over Technically Correct 41:45 Cow Paths, Affordances, and Following Real User Behavior 42:55 Optimism, Adaptation, and the Future of Product Craft

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

Guest: Aaron D. Francis

Host: Kent C. Dodds

See 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.

Chapters

0:00 Introduction to Product Engineering 0:54 What Product Engineering Means in an AI World 4:42 Building Solo From a Painful Real Problem 8:33 Solving the Underlying Problem, Not the Requested Feature 11:37 Questions That Reveal What Users Actually Need 15:21 Product Vision and Having a Point of View 20:41 Worktrees, Feature Requests, and the Real Problem 24:59 Building for Domains You Actually Understand 28:24 AI, Bespoke SaaS, and Underserved Niches 31:00 Finding Painful Problems in Real Businesses 38:17 Empathy Over Technically Correct 41:45 Cow Paths, Affordances, and Following Real User Behavior 42:55 Optimism, Adaptation, and the Future of Product Craft

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

Guest: Aaron D. Francis

Host: Kent C. Dodds

See on Epic Product Engineer

]]> Wed, 08 Apr 2026 05:00:00 -0600 Kent C. Dodds, Aaron D. Francis Kent C. Dodds, Aaron D. Francis 2740 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.

Chapters

0:00 Introduction to Product Engineering 0:54 What Product Engineering Means in an AI World 4:42 Building Solo From a Painful Real Problem 8:33 Solving the Underlying Problem, Not the Requested Feature 11:37 Questions That Reveal What Users Actually Need 15:21 Product Vision and Having a Point of View 20:41 Worktrees, Feature Requests, and the Real Problem 24:59 Building for Domains You Actually Understand 28:24 AI, Bespoke SaaS, and Underserved Niches 31:00 Finding Painful Problems in Real Businesses 38:17 Empathy Over Technically Correct 41:45 Cow Paths, Affordances, and Following Real User Behavior 42:55 Optimism, Adaptation, and the Future of Product Craft

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

Guest: Aaron D. Francis

Host: Kent C. Dodds

See on Epic Product Engineer

]]> product engineering, vertical slice, developer tools, empathy, agents, Solo No Foundations, feedback, and agents — Dillon Mulroy on product at Cloudflare 4 4 Foundations, feedback, and agents — Dillon Mulroy on product at Cloudflare full ecabc762-fb62-4d05-80fc-ea8ff2bcd4ce https://www.epicproduct.engineer/foundations-feedback-and-agents-dillon-mulroy-on-product-at-cloudflare-7fhnr 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.

Chapters

0:00 Introduction to Product Engineering 0:53 Dillon's Role at Cloudflare and Agent Experience 2:04 Preparing Cloudflare for Agent Users 5:29 Product Taste and Building What You'd Want to Use 7:09 Building Great Products for Non-Developer Users 10:03 Pushing Back on Pressure to Ship Fast 12:07 Getting Direct Feedback From Users 14:34 Watching Users Work 17:34 Support Teams as a Gold Mine of Product Signal 18:42 Observability, Metrics, and Customer Escalations 20:46 Rebuilding Vercel Domains 22:40 Making User Pain Painful 23:54 Discipline, Small Scope, and Reviewing AI-Written Code 27:52 Observability as Product Engineering 31:00 Delighters and Going Beyond the Basics 37:04 Onboarding Friction and Feedback Loops 40:36 Rewrites, Pain Reduction, and Fixing the Right Problems 44:20 Cross-Functional Relationships Beyond End Users 45:30 Learning Product Sense by Sitting With Support 47:01 Homework: Care Deeply and Build Better Feedback Systems

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

Guest: Dillon Mulroy

Host: Kent C. Dodds

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.

Chapters

0:00 Introduction to Product Engineering 0:53 Dillon's Role at Cloudflare and Agent Experience 2:04 Preparing Cloudflare for Agent Users 5:29 Product Taste and Building What You'd Want to Use 7:09 Building Great Products for Non-Developer Users 10:03 Pushing Back on Pressure to Ship Fast 12:07 Getting Direct Feedback From Users 14:34 Watching Users Work 17:34 Support Teams as a Gold Mine of Product Signal 18:42 Observability, Metrics, and Customer Escalations 20:46 Rebuilding Vercel Domains 22:40 Making User Pain Painful 23:54 Discipline, Small Scope, and Reviewing AI-Written Code 27:52 Observability as Product Engineering 31:00 Delighters and Going Beyond the Basics 37:04 Onboarding Friction and Feedback Loops 40:36 Rewrites, Pain Reduction, and Fixing the Right Problems 44:20 Cross-Functional Relationships Beyond End Users 45:30 Learning Product Sense by Sitting With Support 47:01 Homework: Care Deeply and Build Better Feedback Systems

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

Guest: Dillon Mulroy

Host: Kent C. Dodds

See on Epic Product Engineer

]]> Tue, 31 Mar 2026 20:13:30 -0600 Kent C. Dodds, Dillon Mulroy Kent C. Dodds, Dillon Mulroy 2943 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.

Chapters

0:00 Introduction to Product Engineering 0:53 Dillon's Role at Cloudflare and Agent Experience 2:04 Preparing Cloudflare for Agent Users 5:29 Product Taste and Building What You'd Want to Use 7:09 Building Great Products for Non-Developer Users 10:03 Pushing Back on Pressure to Ship Fast 12:07 Getting Direct Feedback From Users 14:34 Watching Users Work 17:34 Support Teams as a Gold Mine of Product Signal 18:42 Observability, Metrics, and Customer Escalations 20:46 Rebuilding Vercel Domains 22:40 Making User Pain Painful 23:54 Discipline, Small Scope, and Reviewing AI-Written Code 27:52 Observability as Product Engineering 31:00 Delighters and Going Beyond the Basics 37:04 Onboarding Friction and Feedback Loops 40:36 Rewrites, Pain Reduction, and Fixing the Right Problems 44:20 Cross-Functional Relationships Beyond End Users 45:30 Learning Product Sense by Sitting With Support 47:01 Homework: Care Deeply and Build Better Feedback Systems

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

Guest: Dillon Mulroy

Host: Kent C. Dodds

See on Epic Product Engineer

]]> product engineering, Cloudflare, observability, developer tools, user feedback, coding agents No The right thing before the thing right — product engineering with Wayne Allan 3 3 The right thing before the thing right — product engineering with Wayne Allan full 536ae530-6c1d-4631-ad7b-dab01dcb600d https://www.epicproduct.engineer/the-right-thing-before-the-thing-right-product-engineering-with-wayne-allan~g8g0r 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.

Chapters

0:00 Introduction to Product Engineering 6:01 The Role of Communication in Product Development 12:13 Maintaining Excitement in Product Development 18:06 The Challenge of Validating Ideas 27:08 The Importance of Market Analysis 32:39 The Kano Model: Features That Matter 40:38 The Future of Systems of Record and Transactions 47:23 The Power of Listening and Asking Questions

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

Guest: Wayne Allan

Host: Kent C. Dodds

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.

Chapters

0:00 Introduction to Product Engineering 6:01 The Role of Communication in Product Development 12:13 Maintaining Excitement in Product Development 18:06 The Challenge of Validating Ideas 27:08 The Importance of Market Analysis 32:39 The Kano Model: Features That Matter 40:38 The Future of Systems of Record and Transactions 47:23 The Power of Listening and Asking Questions

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

Guest: Wayne Allan

Host: Kent C. Dodds

See on Epic Product Engineer

]]> Tue, 31 Mar 2026 20:13:11 -0600 Kent C. Dodds, Wayne Allan Kent C. Dodds, Wayne Allan 3032 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.

Chapters

0:00 Introduction to Product Engineering 6:01 The Role of Communication in Product Development 12:13 Maintaining Excitement in Product Development 18:06 The Challenge of Validating Ideas 27:08 The Importance of Market Analysis 32:39 The Kano Model: Features That Matter 40:38 The Future of Systems of Record and Transactions 47:23 The Power of Listening and Asking Questions

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

Guest: Wayne Allan

Host: Kent C. Dodds

See on Epic Product Engineer

]]> product engineering, user research, feedback loops, The Mom Test, Kano model, Crossing the Chasm No Product sense, restraint, and OpenCode with Dax Raad 1 1 Product sense, restraint, and OpenCode with Dax Raad full 46a22c34-7ffc-4f7f-a446-4cdef53528d8 https://www.epicproduct.engineer/product-sense-restraint-and-open-code-with-dax-raad-9qoje 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.

Chapters

0:00 Introduction to Product Engineering 3:00 Understanding Developer Workflows 5:24 Introspection on Product Processes 8:45 The Invisible Skill of Product Management 11:36 Onboarding and User Experience 14:34 Product Restraint and Feature Overload 17:37 User Feedback and Feature Requests 20:26 Clarity on Problems and Solutions 23:42 The Role of AI in Product Development 27:19 Augmenting Human Capabilities with AI 29:59 Navigating the Challenges of AI in Product Development 33:16 The Future of Skills in an AI-Driven World 36:30 Understanding AI's Impact on Development Practices 40:36 Balancing Speed and Quality in Software Development 45:38 The Human Element in AI-Enhanced Workflows 52:18 The Importance of Believing in Product Quality

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

Guest: Dax Raad

Host: Kent C. Dodds

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.

Chapters

0:00 Introduction to Product Engineering 3:00 Understanding Developer Workflows 5:24 Introspection on Product Processes 8:45 The Invisible Skill of Product Management 11:36 Onboarding and User Experience 14:34 Product Restraint and Feature Overload 17:37 User Feedback and Feature Requests 20:26 Clarity on Problems and Solutions 23:42 The Role of AI in Product Development 27:19 Augmenting Human Capabilities with AI 29:59 Navigating the Challenges of AI in Product Development 33:16 The Future of Skills in an AI-Driven World 36:30 Understanding AI's Impact on Development Practices 40:36 Balancing Speed and Quality in Software Development 45:38 The Human Element in AI-Enhanced Workflows 52:18 The Importance of Believing in Product Quality

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

Guest: Dax Raad

Host: Kent C. Dodds

See on Epic Product Engineer

]]> Tue, 31 Mar 2026 20:12:23 -0600 Kent C. Dodds, Dax Raad Kent C. Dodds, Dax Raad 3240 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.

Chapters

0:00 Introduction to Product Engineering 3:00 Understanding Developer Workflows 5:24 Introspection on Product Processes 8:45 The Invisible Skill of Product Management 11:36 Onboarding and User Experience 14:34 Product Restraint and Feature Overload 17:37 User Feedback and Feature Requests 20:26 Clarity on Problems and Solutions 23:42 The Role of AI in Product Development 27:19 Augmenting Human Capabilities with AI 29:59 Navigating the Challenges of AI in Product Development 33:16 The Future of Skills in an AI-Driven World 36:30 Understanding AI's Impact on Development Practices 40:36 Balancing Speed and Quality in Software Development 45:38 The Human Element in AI-Enhanced Workflows 52:18 The Importance of Believing in Product Quality

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

Guest: Dax Raad

Host: Kent C. Dodds

See on Epic Product Engineer

]]> product sense, coding agents, OpenCode, developer tools, onboarding, progressive disclosure No Introducing Become an Epic Product Engineer 1 1 Introducing Become an Epic Product Engineer full a736546c-5535-4d6c-8e88-25f540c83385 https://www.epicproduct.engineer/introducing-become-an-epic-product-engineer~frxeb 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.

Chapters

0:00 Introducing Become an Epic Product Engineer 0:38 The archer metaphor 0:52 Knowing what to build 1:05 Learning out loud with guests 1:18 Product engineers vs product managers 1:35 Homework on every episode 1:55 Episode highlights 2:15 Better with Kent companion series 2:30 Homework: subscribe and pick an episode

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

Guest: Kent C. Dodds

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.

Chapters

0:00 Introducing Become an Epic Product Engineer 0:38 The archer metaphor 0:52 Knowing what to build 1:05 Learning out loud with guests 1:18 Product engineers vs product managers 1:35 Homework on every episode 1:55 Episode highlights 2:15 Better with Kent companion series 2:30 Homework: subscribe and pick an episode

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

Guest: Kent C. Dodds

See on Epic Product Engineer

]]> Tue, 31 Mar 2026 20:11:35 -0600 Kent C. Dodds, Kent C. Dodds Kent C. Dodds, Kent C. Dodds 689 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.

Chapters

0:00 Introducing Become an Epic Product Engineer 0:38 The archer metaphor 0:52 Knowing what to build 1:05 Learning out loud with guests 1:18 Product engineers vs product managers 1:35 Homework on every episode 1:55 Episode highlights 2:15 Better with Kent companion series 2:30 Homework: subscribe and pick an episode

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

Guest: Kent C. Dodds

See on Epic Product Engineer

]]> Become an Epic Product Engineer, product engineering, product management, software development, AI and engineering, durable skills No