Become an Epic Product Engineer

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.

  1. 4d ago ·  Video

    Start with curiosity and talk to a customer - continuous discovery with Teresa Torres

    If your backlog is full of tickets and zero customer contact, this episode is for you. Kent talks with Teresa Torres - product discovery coach, author of Continuous Discovery Habits, and host of Just Now Possible - about why engineers belong in discovery, what "just now possible" really means, and how curiosity beats solution advocacy. They cover opportunity solution trees, confirmation bias in decision-making, the Mom Test trap of pitching your solution, and homework that starts with one real conversation (or observing one). (00:00) - Meet Teresa Torres (02:03) - Just now possible (04:14) - Why coding agents are not enough (08:07) - Engineers in the data model conversation (15:10) - Continuous discovery habits (19:01) - Prove the null hypothesis (21:22) - Where engineers should show up more (24:06) - Solving your own problem (27:27) - AI unlocks software for one (30:04) - The Mom Test trap (33:26) - Opportunity solution trees (39:19) - Confirmation bias vs status quo (42:07) - Informed opinion vs preference (43:16) - Start with curiosity (46:01) - Homework: talk to a customer Teresa Torres has spent about twenty years coaching product teams to make better decisions about what to build. She is a maker at heart: product discovery exists so makers ship useful things instead of crickets. The through-line is engineer involvement. Marty Cagan's line sticks: engineers know best what is just now possible. Teresa's Google Maps API story makes it concrete - a PM would never have invented map pins for customer connection without an engineer who saw the new API and understood the business. AI accelerates that dynamic. Her podcast Just Now Possible interviews teams building AI products for that reason. Coding agents write a lot of code; they do not replace judgment about scalability, security, maintainability, or a data model that will survive the next iteration. They dig into continuous discovery habits: weekly customer contact, opportunity solution trees that separate outcomes from solutions, and the confirmation-bias trap of comparing every idea only to the status quo. The Mom Test warning is sharp - showing someone your solution teaches you whether they are polite, not whether the problem is real. When leadership wants ticket-takers, Teresa's answer is not "quit immediately." Start with genuine curiosity: "I'm curious, can you tell me more?" Opinionated why-questions create defensiveness. Informed opinions matter after you have customer context - personal preference dressed up as technical expertise usually misses the mark. Homework: talk to someone who matches your customer segment (even casually over coffee) and ask about the last time they experienced the problem your product exists to solve. Or sit in on interviews your PM, designer, researcher, sales, or support teams already run. Homework Identify who uses your product (or who has the problem it solves) and find one person in your network who matches that segment.Have a casual conversation (coffee, LinkedIn second-degree, whatever fits) and ask: tell me about the last time you experienced [the problem your product solves]. Learn about them as a human - not about your product.If customer contact is blocked, ask to observe an interview your PM, designer, researcher, sales, or support team is already running.Resources Product TalkProduct Discovery BasicsContinuous Discovery HabitsJust Now Possible podcastTeresa on BlueskyTeresa on LinkedInTeresa on XGuest: Teresa Torres Company: Product Talk𝕏: @ttorresHost: Kent C. Dodds Website: kentcdodds.com𝕏: @kentcdoddsGitHub: @kentcdoddsYouTube: kentcdodds-plusPodcast: epicproduct.engineerSee on Epic Product Engineer

    Start with curiosity and talk to a customer - continuous discovery with Teresa Torres

  2. Sep 30 ·  Video

    Lead with empathy and listen without defense - product sense with Mark Techson

    If you still build for an audience of one and get defensive when users "use it wrong," this episode is for you. Kent talks with Mark Techson - staff developer relations engineer on Angular at Google - about empathy as a career differentiator, listening without defense, and why knowing what to build still beats vibe-coding forever. They cover internal tools as real products, a fitness-app failure that forced better questions, Google Developer Experts as a feedback loop, durable expertise in the AI era, and why attention is the scarce resource when anyone can ship. Mark Techson (legal name Mark Thompson) has spent about twenty years building software - teaching, senior engineering roles, a fitness startup, American Express fraud tooling, healthcare exchange apps, and now staff DevRel on Angular at Google. The views in this episode are his own; he notes he works for a major frontier-model provider. The through-line is empathy. Mark's number-one product-engineering skill is putting yourself in the end user's seat before you ship. Engineers who only implement tickets miss the concert of perspectives PMs, EMs, and builders bring when everyone aims at the best user experience. He compares great teams to a film set where talent still suggests a shoulder turn that makes the scene land. Listening without defense is the mechanism. Feedback means either you built it wrong or they cannot see how it works - both are actionable. Mark's hard lesson was a fitness app he built for himself: even his wife chose another app. Surveys flipped his assumption from "customize everything" to "just tell me what to do." At Google he leans on Angular GDEs and a simple reply to angry comments: tell me more. They also talk AI. Expertise is not going out of style - Mark uses a guitar-tuner analogy: auto-tune does not erase your ear. Knowing what to build, who to build for, and how to orchestrate agents matters more as code gets cheaper. Kent adds that human attention stays finite even if tokens get cheap. Mark closes against the "you're left behind" narrative: you do not have to live on the bleeding edge, but ignoring AI is the only wrong move. Homework: write a prompt for the first basic version of a product you have been postponing, run it in any AI tool, and notice what you failed to specify. Homework Pick a product idea you have postponed for lack of time or skill.Write a prompt that describes only the first basic version - not the million-dollar finished product.Run that prompt in any AI coding tool, then list what was missing from your prompt and iterate toward that first version.Resources Mark TechsonMark on XMark on GitHubMark on LinkedInAngularGoogle Developer ExpertsGuest: Mark Techson Company: GoogleGitHub: @MarkTechson𝕏: @MarkTechsonHost: Kent C. Dodds Website: kentcdodds.com𝕏: @kentcdoddsGitHub: @kentcdoddsYouTube: kentcdodds-plusPodcast: epicproduct.engineerMark's views are his own. He notes he works for a major frontier-model provider (Google).

    Lead with empathy and listen without defense - product sense with Mark Techson

  3. Sep 23 ·  Video

    Keep a friction log and read a sales book - product ownership with Joyce Er

    If execution got cheap and you still wait for someone to tell you what to build, this episode is for you. Kent talks with Joyce Er about five years owning features on VS Code, the jump to product at Cerebras, and why trust is the metric that tells you the work is working. They cover daily stand-ups that roast your feature in public, friction logs as taste practice, dogfooding when you cannot be the user, qualifying customers instead of taking every check, and why a sales book belongs on a product engineer's shelf. (00:00) - Meet Joyce Er (01:18) - A dinner-plate AI chip (02:47) - Engineering as we knew it shrunk (04:38) - Ownership on the VS Code team (07:33) - Why ownership matters more with AI (10:23) - Keep a friction log (12:18) - Judgment from lived experience (15:33) - Invalidate old priors (17:41) - VS Code's daily stand-up roast (20:35) - When you cannot dogfood (22:52) - Getting partner teams to help (29:30) - Curiosity and time-boxing AI (32:20) - Selling inference to coding tools (34:00) - Qualify the right customer (38:47) - Trust as the success metric (40:11) - Homework: friction log and a sales book Joyce Er spent five years as a software engineer on VS Code at Microsoft, with a front-row seat to GitHub Copilot and the shift from typing code to owning the why. About a year before this conversation she moved into product at Cerebras, the company behind dinner-plate wafer-scale chips for ultra-fast AI inference. The views in this episode are her own. A major theme is ownership. On VS Code, every engineer owned the end-to-end definition of what shipped, not just the implementation. That only works with trust, dogfooding, and rituals that force you to defend the experience. Joyce describes a daily stand-up where you get five minutes to walk the feature, then the team roasts padding, consistency, and whether it belongs in the product. The lighter version is a bug bash. If people inside the company will not use the feature, that is a signal. They also talk about how you grow judgment when nobody assigns the work. Joyce's first practice is a friction log: five minutes at the end of the day listing paper cuts in any software you used. Her more controversial homework is to read a sales book - she recommends The Qualified Sales Leader - so you understand how business value actually closes, especially when the product is not a credit-card checkout. Trust, she says, is the end-to-end metric: if customers and teammates trust you, you are doing the job. Homework: keep a daily friction log, and read a book about sales. Homework Spend five minutes at the end of each day writing a friction log of paper cuts in software you used.Read a sales book - Joyce recommends The Qualified Sales Leader - and notice how value gets sold at your company.Use those notes the next time you decide what is worth building. Resources Joyce Er on XJoyce on GitHubJoyce on LinkedInCerebrasVisual Studio CodeThe Qualified Sales Leader by John McMahon Guest: Joyce Er Company: CerebrasGitHub: @joyceerhl𝕏: @joyceerhl Host: Kent C. Dodds Website: kentcdodds.com𝕏: @kentcdoddsGitHub: @kentcdoddsYouTube: kentcdodds-plusPodcast: epicproduct.engineer See on Epic Product Engineer The views expressed by Joyce Er are her own and do not necessarily represent those of her employer.

    Keep a friction log and read a sales book - product ownership with Joyce Er

  4. Sep 16 ·  Video

    Use the product yourself - empathy, architecture, and PM partnership with Rita Kozlov

    If you ship a feature and never click through it yourself, this episode is for you. Kent talks with Rita Kozlov, VP of Product for Cloudflare's developer platform, about the line between product managers and product engineers, why ownership still matters when prototypes look real, and how far upstream an engineer should insert themselves. They cover holding the pager vs throwing away a prototype, sitting in customer calls until someone will not click the button, primitives vs paved paths, and what to do when your PM is running a feature factory. (00:00) - Meet Rita Kozlov (01:36) - Engineering taste in a PM role (04:05) - Where PM and product engineer blur (07:53) - You are not holding the pager (09:48) - What AI changed on both sides (13:40) - Sit in the user's seat (17:04) - The art of the possible (18:53) - Trade-offs and why not both (23:22) - Primitives vs paved cow paths (26:43) - Insert yourself upstream (29:40) - When the PM is a feature factory (33:17) - Deep-stack work still reaches users (37:58) - Homework: go use the product Rita Kozlov is VP of Product for Cloudflare's developer platform - Workers, KV, Pages, and the rest of the stack Kent uses constantly. She started as a software engineer, and that background shows up in the details: taste for developer experience, intuition for patterns that do not sit right, and a refusal to treat implementation as someone else's problem. A major theme is how AI blurred the PM and engineer line. Prototypes are worth a million words, and they create a temptation to ship the facade. Rita's reminder to her product team: you are not the one holding the pager. Accountability is not about having someone to call at 2 a.m. It is about living with the code for the next two years. Product engineers close that gap by translating implementation trade-offs, filling the holes a PRD will never list, and sitting in the user's seat - including the customer call where nobody clicks the button. They also get into Cloudflare-shaped product judgment: most doors swing both ways if you wait; early customers are worth delaying a launch for; primitives can serve many jobs, and sometimes you still pave a cow path. Rita wants PMs to define the problem, not the solution. Engineers should get closer to customers, challenge a feature-factory PM with why, and remember that even work deep in the stack - cache, TTL, the interface between systems - is user experience. Homework is basic on purpose: go use the product, including the feature you just shipped, and push it before you throw it over the fence. Homework Use the product you work on this week - not as a demo path, as a real user.After you ship a feature, try it in the different modalities and push the limits before you hand it off.Write down what you found that you would have missed from the ticket alone. Resources Rita KozlovRita on XRita on BlueskyRita on GitHubRita on LinkedInCloudflare WorkersCloudflare Guest: Rita Kozlov Company: CloudflareGitHub: @rita3ko𝕏: @ritakozlov Host: Kent C. Dodds Website: kentcdodds.com𝕏: @kentcdoddsGitHub: @kentcdoddsYouTube: kentcdodds-plusPodcast: epicproduct.engineer See on Epic Product Engineer

    Use the product yourself - empathy, architecture, and PM partnership with Rita Kozlov

  5. Sep 9 ·  Video

    Ask why in every PR - product engineering with Erin Fox

    If you are merging beautiful AI PRs without being able to say why the change exists, this episode is for you. Kent talks with Erin Fox about treating every feature like a new product, asking why before you write code, and rebuilding the trust contract that agents quietly broke. They cover circling back to metrics, using community Slack as a feedback loop, telling a stakeholder story that is not just a migration estimate, and going slower with agents so they do not rewrite your patterns. (00:00) - Meet Erin Fox (01:40) - A new feature is a new product (05:03) - Finding the why before you build (07:36) - AI PRs broke the trust contract (10:57) - Metrics, research, and circling back (14:25) - Community Slack as a feedback loop (16:17) - Tell the story stakeholders can hear (20:49) - Communications skills as an engineering edge (24:12) - Ask your boss their goals (27:22) - Go slower with your agents (37:50) - Homework: ask why on every PR Erin Fox is a full-stack engineer who has shipped a React Native MLS soccer app, creator-focused email tools, and plenty of features that felt like launching a product each time. In this conversation, she and Kent dig into what that framing changes: you do not just implement a ticket. You figure out the date, the why, and whether the real fix is a new feature or a two-hour margin change. A major theme is trust. Erin used to assume a teammate's PR already had the why baked in. AI-generated PRs look great and pass tests, but the why is often missing. Her red flag is simple: if you cannot explain why this change is needed, do not treat passing tests as permission. That same question belongs in the PR template, in stakeholder conversations, and in how you brief an agent - because "fix this bug" will happily change a million things. They also get practical about feedback loops. Look at the metrics you instrumented. Lurk in community Slack, including accessibility channels, until user pain is not abstract. Then tell the story in language stakeholders care about: not "this migration takes a quarter," but what it unlocks. Erin's communications master's degree shows up here. She asks her manager what their goals are this quarter and treats that as the job. Homework is small on purpose: on every PR you open or review, write why this change matters. Homework On the next PR you open, add a Why section that a teammate could understand without the ticket.On the next PR you review, ask why this change is needed - especially if it looks AI-generated.If you cannot answer why, stop and find out before you merge. Resources Erin Fox on XErin on BlueskyErin on GitHubErin on LinkedInKit Guest: Erin Fox GitHub: @erinfox𝕏: @erinfoox Host: Kent C. Dodds Website: kentcdodds.com𝕏: @kentcdoddsGitHub: @kentcdoddsYouTube: kentcdodds-plusPodcast: epicproduct.engineer See on Epic Product Engineer

    Ask why in every PR - product engineering with Erin Fox

  6. Sep 2 ·  Video

    AI is a tool, not a silver bullet - product discovery with Peppe Silletti

    If shipping got cheap and you are still not sure you are building the right thing, this episode is for you. Kent talks with Peppe Silletti, independent product engineer and host of The Product Engineers Podcast, about why customer discovery still comes first when AI can write the code in a day. They cover startup vs scale-up trade-offs, raising the MVP baseline without adding noise, how PostHog treats product engineers vs product managers, and the durable skills that stay valuable when agents take more of the implementation. (00:00) - Meet Peppe Silletti (01:13) - Startup exploration vs scale-up bottlenecks (04:04) - Trade-offs before you paint yourself into a corner (06:07) - AI raises the MVP baseline (09:47) - Do not add so much that the data gets noisy (11:13) - AI is a tool, not a silver bullet (13:47) - Product engineers are not just managers (16:06) - How you know you built too much (18:49) - Prioritizing after product-market fit (24:30) - PM as compass, engineer as slice owner (27:08) - What Peppe learned hosting a podcast (29:25) - Durable skills as agents take the code (33:06) - Product engineering for backend engineers (38:26) - Homework: ally with your PM Peppe Silletti is an independent product engineer and host of The Product Engineers Podcast. In this conversation, he and Kent dig into what changes when you move from a startup hunting for product-market fit to a scale-up fixing bottlenecks - and what AI does and does not change about that work. A major theme is that writing code got cheap, so the old lean-startup constraint loosened. You can ship more than a classic MVP, then sculpt features away like Instagram dropping everything but photos. The risk did not go away. It got worse. You can feel productive while running in the wrong direction, because AI will happily agree with you. Discovery, customer interviews, and a tight feedback loop still decide whether you are learning or just shipping. They also unpack the product manager vs product engineer split. Peppe points to PostHog: product engineers owned decisions for years before a PM showed up to hold the bigger picture. His model is a PM as compass, a product engineer owning one outcome end to end. For listeners who still take tickets over the wall, the durable skills are framing the problem, interviewing without jumping to solutions, and treating UX as more than pixels - including APIs and neighboring layers of the system. Peppe's homework is deliberately social: shadow customer interviews, watch session replays with your team, and get into discovery before the roadmap is locked. Homework Ask your PM if you can shadow customer interviews and listen for how people describe the pain.Set a weekly half hour to watch session replays with your team and name the friction you see.Once those two are happening, ask to join discovery earlier - when requirements and the roadmap are still being shaped. Resources Peppe SillettiThe Product Engineers PodcastPeppe on LinkedInPeppe on GitHubThe Product Engineers Podcast on YouTubeProduct management is broken. Engineers can fix it - PostHogContinuous Discovery Habits by Teresa TorresLaws of UX by Jon Yablonski Guest: Peppe Silletti Company: The Product Engineers PodcastGitHub: @peppesilletti𝕏: @peppesilletti Host: Kent C. Dodds Website: kentcdodds.com𝕏: @kentcdoddsGitHub: @kentcdoddsYouTube: kentcdodds-plusPodcast: epicproduct.engineer See on Epic Product Engineer

    AI is a tool, not a silver bullet - product discovery with Peppe Silletti

  7. Aug 19 ·  Video

    Curiosity, micro-sales, and AI as a supplement with Shaundai Person

    If you walk into cross-team asks with a prescription instead of curiosity, this episode is for you. Kent talks with Shaundai Person about privacy UX at Netflix, the micro-sales skills she brought from a decade in sales, and why AI should accelerate good engineering judgment instead of replacing it. They cover putting yourself in the user's seat before you push back, selling the conversation instead of the ticket, what happens when agents fill a repo with band-aids, and homework that gets you out of your usual domain: try a CSS animation course without AI. (00:00) - Meet Shaundai Person (00:51) - Privacy and consent at Netflix (04:30) - What privacy engineering actually involves (08:38) - Push back with user scenarios (11:10) - UX so intuitive a toddler can use it (13:43) - Working through technical constraints (18:45) - Micro-sales from a sales career (22:32) - Curiosity is not manipulation (25:47) - AI's impact on software engineering (29:42) - Agent band-aids and architecture gaps (35:40) - New criteria for senior engineers (37:35) - AI accelerates bad practices too (40:51) - AI as a supplement, not a replacement (45:09) - Homework: try animations without AI Shaundai Person is a senior software engineer at Netflix working full stack on privacy and consent for Netflix.com. In this conversation, she and Kent dig into what product engineering looks like when the work is mostly invisible when you do it right - and when your job is piping the right experience to the right person under different laws, profiles, and countries. A major theme is how she communicates across teams. After more than a decade in sales before engineering, Shaundai treats collaboration as a series of micro-sales: get someone into the conversation, then into a small piece of work, then into teaching you how they solved it. She argues smart people do not want prescriptions. They want curiosity, a clear goal, a map of where they fit, and an invitation to dissent. They also talk about AI's impact on software engineering. Shaundai sees AI elevating more engineers toward architecture and product thinking, while warning that unchecked agents create pattern-free codebases full of band-aids. Her take: humans stay in the loop because software is for humans, and AI is a supplement - not a replacement. Her homework is specific: try Josh Comeau's Whimsical Animations (or its CSS-based starter path) and do the first stretch without AI. Homework Start Josh Comeau's Whimsical Animations (or the free CSS-based starter path).Do the first stretch without AI - refresh your own problem-solving muscle.Notice how far you get on your own, then decide where a tool would actually help.Resources Shaundai PersonShaundai on BlueskyShaundai on XShaundai on GitHubShaundai on LinkedInTypeScript for JavaScript DevelopersWhimsical Animations by Josh ComeauNetflixGuest: Shaundai Person Company: NetflixGitHub: @shaundai𝕏: @shaundaiHost: Kent C. Dodds Website: kentcdodds.com𝕏: @kentcdoddsGitHub: @kentcdoddsYouTube: kentcdodds-plusPodcast: epicproduct.engineerSee on Epic Product Engineer

    Curiosity, micro-sales, and AI as a supplement with Shaundai Person

  8. Aug 12 ·  Video

    Talk to users, ship live demos, and build durable products with Michael Grinich

    If you are building something people want but still cannot grow it, this episode is for you. Kent talks with Michael Grinich, founder of WorkOS, about cold-emailing product managers, closing the feedback loop with real users, and why live demos beat polished decks. They cover the missing step after "make something people want," how durable problem spaces survive market shifts (including auth for agents), and why storytelling is part of the product. (00:00) - Meet Michael Grinich (02:00) - Choosing the enterprise-ready niche (04:31) - Building for problems that are not yours (06:34) - Cold-emailing PMs who already shipped enterprise (10:44) - Questions that get past compliments (12:52) - Patience and durable problem spaces (15:57) - Beyond make something people want (20:25) - Auth for agents and MCP (23:57) - Talk to users, not just customers (28:42) - Live demos as tech marketing (31:39) - Test your story like Comedy Cellar material (39:10) - Monkey see, monkey do and Julia Child (43:03) - Homework: build GPT from scratch (46:10) - Where to follow Michael Michael Grinich founded WorkOS to help software companies become enterprise-ready - SSO, directory sync, permissions, audit logging, and the rest of the stack that unlocks bigger customers. In this conversation, he and Kent dig into how that idea came from lived pain at a previous startup, and how he validated the market by cold-emailing and meeting PMs at companies like Dropbox, Slack, Asana, and Airtable. A major theme is that "make something people want" is incomplete. Michael argues you also need an economic engine: who pays, why they pay continuously, and how the business model stays in harmony with the product. He ties that to picking durable problem spaces - WorkOS started in classic B2B auth, and the same foundation now matters even more for agents, MCP, and agent registration via auth.md. They also get practical about product discovery. Talk to users, not only customers and dollar signs. Use live demos as the pinnacle of tech marketing. Treat small meetups like a Comedy Cellar set where you test material before the big stage. And when you show people how something works, you put yourself on the same side of the table - the Julia Child model of teaching by doing. Michael's homework is concrete: spend an afternoon with Andrej Karpathy's "Let's build GPT from scratch" video so you understand the underpinnings of the systems you are building on. Homework Watch Andrej Karpathy's "Let's build GPT from scratch" video (a few hours, one afternoon is enough).Hack along enough to rebuild a simple ChatGPT-like interface on top of a transformer you understand.Notice how that deeper mental model changes how you talk about agents, models, and product bets at work.Resources Michael Grinich on XMichael on GitHubMichael on LinkedInMichael on BlueskyWorkOSauth.mdauth.md on GitHubWorkOS events on LumaLet's build GPT from scratch (Andrej Karpathy)The Mom TestGuest: Michael Grinich Company: WorkOSGitHub: @grinich𝕏: @grinichHost: Kent C. Dodds Website: kentcdodds.com𝕏: @kentcdoddsGitHub: @kentcdoddsYouTube: kentcdodds-plusPodcast: epicproduct.engineerSee on Epic Product Engineer

    Talk to users, ship live demos, and build durable products with Michael Grinich
See All (30)

Trailer

About

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.

Information

  • Creator
    Kent C. Dodds
  • Years Active
    2026
  • Episodes
    30
  • Rating
    Explicit
  • Copyright
    © 2026 Kent C. Dodds Tech LLC. All rights reserved.
  • Show Website
    Become an Epic Product Engineer

You Might Also Like