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. 1d ago ·  Video

    Architecture, AI agents, and product empathy with Robert C. Martin

    Kent talks with Robert C. Martin - Uncle Bob - about what AI agents change, what they do not change, and why software architecture, design sense, and customer empathy still matter. They cover why engineers may need to "walk away from the code" while still caring about structure, how agents can be guided with quality tools, why beginners still need to learn the material agents manipulate, and what product engineering looks like when implementation gets cheaper. (00:00) - Meet Robert C. Martin (02:53) - What has changed and what has not (05:41) - The rising abstraction line (08:00) - Walking away from the code (11:15) - Agents and larger systems (14:16) - Clean code when agents write code (20:09) - Design sense and agent judgment (22:36) - Why beginners still need code (34:57) - What product engineering means (41:18) - Homework: try SwarmForge Robert C. Martin has watched software move through layers of abstraction for decades: binary, assembly, high-level languages, frameworks, and now AI agents. In this conversation, he and Kent talk about the next layer up and the durable engineering judgment that still belongs to humans. A major theme is that the low-level work keeps changing while the high-level rules of design and architecture stay remarkably stable. Bob argues that if engineers want the real benefit of agents, they will eventually need to stop treating code as the primary surface and start reviewing module structure, dependencies, data flow, and system behavior. But that does not mean code quality stops mattering. It means humans need better feedback loops, better tools, and enough design sense to know what to ask the agents to improve. They also talk about new engineers, education, and the danger of skipping the code too early. Agents are power tools, and Bob's advice is that engineers still need to understand the material those tools are shaping. The episode lands on product engineering as the marriage of deep technical skill and deep customer understanding: the product engineer lives partly in the technology and partly in the customer's world. Homework Try Robert C. Martin's SwarmForge project locally and follow the setup instructions far enough to run it.Use it to experiment with coordinated agents passing tasks or information to each other.If you find a problem or a useful improvement, leave an issue on the GitHub repo so the product feedback loop closes.Resources Robert C. MartinClean CodersSwarmForgeAgile ManifestoClean CodeGuest: Robert C. Martin Company: Uncle Bob Consulting LLCGitHub: @unclebob𝕏: @unclebobmartinHost: Kent C. Dodds Website: kentcdodds.com𝕏: @kentcdoddsGitHub: @kentcdoddsYouTube: kentcdodds-plusPodcast: epicproduct.engineerSee on Epic Product Engineer

    Architecture, AI agents, and product empathy with Robert C. Martin

  2. Jul 15 ·  Video

    Curiosity, UX, and durable engineering skills with Annie Sexton

    Kent talks with Annie Sexton, developer educator at ngrok, about the durable skills engineers need as AI changes the shape of software work. They cover how to teach complex technical ideas without assuming too much, why curiosity keeps engineers from becoming button pushers, how pacing and storytelling make educational content work, and why UX and product judgment are becoming harder to ignore. (00:00) - Meet Annie Sexton (02:15) - Teaching for the mid-level developer (05:48) - Jobs to be done for technical education (08:19) - Which fundamentals still matter with AI? (12:13) - Tricking people into learning (18:27) - Measuring educational content (23:13) - Pacing, hooks, and retention (30:12) - Education as trust-building (35:23) - Curiosity and engineering joy in the AI era (40:11) - UX as a differentiator (43:40) - Homework: make users awesome and audit a product Annie Sexton is a developer educator, software engineer, and technical video creator whose work has focused on making difficult infrastructure and software concepts feel approachable. In this conversation, she and Kent talk about teaching developers in an AI-heavy world, where syntax and implementation details are cheaper but curiosity, taste, pacing, and user empathy matter more. A major thread in the episode is education as product work. Annie describes writing for the mid-level JavaScript developer, using curiosity to pull people into topics they did not expect to care about, and treating comments, retention, and repeated confusion as feedback loops. Kent connects that to jobs to be done, teaching with agents enabled, and the need to understand what learners actually need now instead of preserving old rituals just because they were once necessary. They also dig into the emotional and practical shift AI has created for engineers. Annie talks honestly about losing some of the old joy of hands-on coding while finding a new place for that energy in product thinking, UX, and education. The episode closes with two concrete pieces of homework: read Badass: Making Users Awesome, and practice noticing every little point of friction in a product you almost chose but did not. Homework Read Badass: Making Users Awesome by Kathy Sierra and pay attention to the shift from making an impressive product to making users feel capable.Pick a product you considered using but rejected, then go through its onboarding or core flow again.Write down every specific point of friction, confusion, hidden error, awkward field, or moment where your eyes glaze over.Resources Annie SextonngrokFly.ioBadass: Making Users AwesomeWebcomic StudioGuest: Annie Sexton Company: ngrokGitHub: @anniebabannieHost: Kent C. Dodds Website: kentcdodds.com𝕏: @kentcdoddsGitHub: @kentcdoddsYouTube: kentcdodds-plusPodcast: epicproduct.engineerSee on Epic Product Engineer

    Curiosity, UX, and durable engineering skills with Annie Sexton

  3. Jul 8 ·  Video

    Taste, simplicity, and AI-era product judgment with Michael Shimeles

    Kent talks with Michael Shimeles - Rasmic - about building products in the AI era without losing the engineering judgment that makes software useful. They cover AI consulting, why clients often ask for the wrong thing, how to push conversations back to the real problem, why simplicity is a product advantage, and why developers are more valuable when they combine technical skill with taste, domain knowledge, and user empathy. (00:00) - Meet Michael Shimeles (01:16) - Product studios and AI consulting (04:35) - Training teams and building custom agents (07:37) - Uncovering the real problem (12:33) - Questions that cut through AI hype (16:47) - Do it the hard way first (19:01) - Finding ideas in products you use (21:03) - Taste, quality, and care (24:10) - Simplicity beyond design (28:04) - Domain knowledge and feedback (31:11) - Developers are expected to own more (35:35) - Do not fall in love with the solution (39:14) - Homework: read an old engineering book Michael Shimeles is a full-stack engineer, DevX engineer at Convex, creator, and the person behind a product studio and AI consultancy. In this conversation, he and Kent talk about what happens when every company suddenly wants agents, automation, and custom AI tools - and why the right answer is sometimes "you do not need AI yet." A major thread in the episode is problem discovery. Michael describes clients who come in excited about subagents, custom harnesses, or the newest tool from a YouTube video, while the real job is to slow down, ask what problem they are trying to solve, and decide whether a simple workflow, an off-the-shelf tool, or a custom product is actually warranted. Kent connects that to The Mom Test and the value of doing things the hard way first so you know where existing solutions fall short. They also dig into taste and simplicity. Michael argues that AI has made it easier to ship software, but not easier to care. Taste comes from shipping, noticing products you wish you had made, learning from feedback, and making the path from a user's problem to a solved problem as short as possible. The episode closes with a practical challenge for engineers using agents: go back to the old engineering books. Syntax is cheaper now, but engineering, architecture, first-principles thinking, and simplicity make you better at directing AI. Homework Pick one classic engineering book you have ignored or dismissed and read it with AI-assisted development in mind.Notice how the engineering principles from that book change the way you prompt, review, and steer coding agents.Treat agents as code-writing accelerators, not replacements for architecture, simplicity, and first-principles thinking.Resources Ras Mic - Michael ShimelesConvexFabrikaThe Mom TestClean CodeGuest: Michael Shimeles Company: ConvexGitHub: @michaelshimeles𝕏: @rasmicHost: Kent C. Dodds Website: kentcdodds.com𝕏: @kentcdoddsGitHub: @kentcdoddsYouTube: kentcdodds-plusPodcast: epicproduct.engineer

    Taste, simplicity, and AI-era product judgment with Michael Shimeles

  4. Jul 1 ·  Video

    Know your customer better than your code - product engineering with Lucas Wargha

    Kent talks with Lucas Wargha, engineering manager at FamilySearch, about turning software engineers into product engineers: understanding mission and business outcomes, talking to real users across cultures, and stopping the assembly line of JIRA handoffs. They cover customer personas at global scale, the Gmail password-loading story as product-engineering thinking, owning epics end-to-end, creators vs consumers, and a hopeful take on historic days in our industry. (00:00) - Introduction to Product Engineering (02:12) - FamilySearch and product outcomes (07:36) - Customer personas at global scale (12:07) - Know your customer better than your code (15:01) - Product engineer vs product manager (17:33) - Turning engineers into product engineers (22:38) - The Gmail password-loading story (27:01) - Stopping the JIRA assembly line (31:19) - Prioritizing customer needs (42:28) - Homework: talk to three users Lucas leads engineers building FamilySearch Memories - tools for photos, audio, and stories that help people connect with family beyond names and dates. He describes a shift away from engineers as expensive task-takers toward people who understand company vision, product outcomes, and why a rewrite or maintenance project is worth doing. A thread through the episode is customer literacy: mapping personas, interviewing users in Brazil and discovering translation nuances you would never see in analytics alone, and balancing qualitative insight with data when the customer base is literally global. Lucas and Kent compare product engineers and product managers, why role sprawl happened, and what changes when engineers own milestones across web and mobile instead of finishing isolated stories. They also talk about practical culture moves - engineers delivering food like DoorDash did, using your own product, the Gmail team preloading after you type your email, and why fulfillment comes from creating value for people rather than optimizing reducers. Lucas closes with homework grounded in his motto: know your customer better than your code, and talk to three users before you implement your next story. Homework Know your customer better than you know your code - measure whether you get as passionate about product outcomes as you do about architecture debates.Take the first story on your board (or next assigned work) and talk to three different potential users across personas before you implement it.Resist finishing the story in isolation - what you learn from those conversations should change what you build.Resources FamilySearchLucas Wargha (site)Competing Against Luck (Jobs to Be Done)UtahJSGuest: Lucas Wargha Company: FamilySearchGitHub: @lucaswargha𝕏: @lucaswarghaHost: Kent C. Dodds Website: kentcdodds.com𝕏: @kentcdoddsGitHub: @kentcdoddsYouTube: Kent C. DoddsPodcast: epicproduct.engineerSee on Epic Product Engineer

    Know your customer better than your code - product engineering with Lucas Wargha

  5. Jun 24 ·  Video

    Demos, feedback loops, and AI-era product judgment with Ruben Casas

    Kent talks with Ruben Casas about building products again in the AI-agent era: why experienced engineers can now stay close to customers and code, how demos turn vague ideas into something people can react to, and why product judgment matters more as implementation gets cheaper. They cover Postman, MCP, agent-driven UI, prototypes, early user feedback, feature product-market fit, and the engineering guardrails that help teams ship quickly without turning the product into a pile of disconnected features. (00:00) - Introduction to Product Engineering (00:48) - Ruben Casas and Postman (07:36) - Building products again in the AI era (19:38) - Finding customer pain points (22:32) - Demos and prototypes (28:53) - Getting people to care about your ideas (31:41) - Prioritizing product problems (41:25) - Homework: build a prototype demo Ruben brings a practical perspective from building developer tooling, platform work, and AI-agent products at Postman. The conversation starts with a shift many experienced engineers are feeling right now: agents make it possible to stay involved in higher-level product decisions while also getting hands-on with implementation again. That is exciting, but it also raises the bar for deciding what is worth building in the first place. A recurring theme in the episode is that demos and prototypes are not just engineering exercises. They are product tools. Ruben and Kent talk about starting from a real pain point, building just enough to show the opportunity, putting it in front of users quickly, and using that feedback to decide whether the idea deserves more investment. They also dig into the risk of shipping too many mildly useful features, and why product engineers still need architecture, testing, taste, and guardrails as more people use AI to touch production code. Homework Find a real problem that is bothering you.Use an agent to build a quick prototype for it, especially if you have not tried AI coding tools seriously yet.Record a short demo, send it to someone, and ask for feedback.Resources Ruben CasasPostmanRethinking UI in Agent-Driven SystemsMCP AppsGuest: Ruben Casas Company: PostmanGitHub: @infoxicator𝕏: @infoxicadorHost: Kent C. Dodds Website: kentcdodds.com𝕏: @kentcdoddsGitHub: @kentcdoddsYouTube: Kent C. DoddsPodcast: epicproduct.engineerSee on Epic Product Engineer

    Demos, feedback loops, and AI-era product judgment with Ruben Casas

  6. Jun 17 ·  Video

    The technical person in the room - product engineering with Sean Roberts

    Kent talks with Sean Roberts, engineer at PhotoShelter, about product engineering shaped by agency work and small teams: being the technical person in sales conversations early, planning with product judgment, and knowing when to speak up (and when to listen). They discuss why implementation skill still matters in the AI era, how to avoid "vibes-only" product calls, budgeting and sequencing work with business context, and why striking up real conversations (with customers or anyone) is a trainable muscle. (00:00) - Introduction to Product Engineering (02:11) - Agency work and customer conversations (08:47) - The technical person in the room (16:54) - Determining business goals (26:48) - Planning and the dark forest (35:10) - Relationships and positive feedback (40:21) - Homework: talk to someone new Sean's path is a familiar pattern for this season: years of agency and startup work where engineers sit close to customers, budgets are real, and the person writing code is often in the room when the problem gets defined. He describes learning to ask questions on sales calls as a junior developer, sometimes literally driving the founder to the meeting, and translating needs into feasible software on the spot. The middle of the episode turns toward planning inside a product company: helping teams separate solved problems from "dark forest" work, pushing back on specs that underestimate legacy complexity, and bringing beginner's mind even when you are senior. Sean is honest that much of his product sense today is still conversation-driven, and he wants better analytics to complement that, not replace it. Kent and Sean also touch the emotional side of the job: positive feedback when you save someone tedium, the risk of changing UX too often because *you* are bored, and why relationships matter if you want to hear "you made my life easier." The homework is deliberately low ceremony: talk to someone you do not normally talk to and practice curiosity. Homework Ask someone you do not normally talk to at work for 15 minutes: a salesperson, PM, support lead, or another engineer on a different team.Ask about their job, challenges, and customers; practice translating what you hear into software constraints without jumping to solutions too fast.If work feels awkward, practice the same muscle outside work (cashier, server, neighbor) - the goal is conversation comfort, not a formal interview.Resources PhotoShelterSean Roberts - GitHubGuest: Sean Roberts Company: PhotoShelterGitHub: @seanroberts𝕏: @sean_j_robertsHost: Kent C. Dodds Website: kentcdodds.com𝕏: @kentcdoddsGitHub: @kentcdoddsYouTube: Kent C. DoddsPodcast: epicproduct.engineerSee on Epic Product Engineer

    The technical person in the room - product engineering with Sean Roberts

  7. Jun 10 ·  Video

    Software architecture, human judgment, and AI's limits with Grady Booch

    Kent talks with Grady Booch about what software engineering still means in the age of AI agents, why implementation is only one part of the work, and why human judgment remains central to building durable systems. They discuss software architecture, the limits of large language models, computable minds, product engineering across different risk and complexity levels, and the kind of curiosity that helps engineers grow beyond a narrow slice of the field. (00:00) - Introduction to Product Engineering (01:00) - Grady Booch background (06:47) - The Last Software Engineer (09:00) - Will the software industry end? (10:04) - Consciousness and the computable mind (20:13) - What is software engineering? (27:45) - Software architecture and agents (35:30) - The ceiling for LLMs on implementation (39:33) - Durable skills and human judgment (41:39) - Curiosity beyond your domain (45:47) - Homework: read foreign source code Grady brings a rare long-view perspective to the AI and software engineering conversation: early computing, Rational Software, UML, IBM Research, NASA work, software architecture, and current research into computing and the human experience. That background gives this episode a useful tension. Kent and Grady do not agree on every framing, especially around whether the software development industry could eventually "end," but they find common ground around judgment, curiosity, and the responsibility engineers have for what they build. A major theme is that implementation is not the whole of software engineering. Grady breaks the work into a broader journey from imagination to executable artifacts, with computer science, algorithms, architecture, organizational forces, economics, risk, and ethics all shaping the result. Agents and LLMs can help with some of that work, but Grady argues they remain unreliable narrators: useful, fast, and sometimes impressive, while still needing experienced humans who can smell when the work is going off the rails. The episode closes with a practical challenge for engineers: broaden your judgment by studying systems and ideas outside your usual domain. Read unfamiliar source code. Read books outside your lane. Build the curiosity that gives your technical decisions more context. Homework Read the source code for a system that is completely foreign to your usual work.Use historical or open source systems like MacPaint, MediaWiki, or the Linux kernel to study different constraints and architectures.Read a book outside your domain, such as The Sciences of the Artificial, Systemantics, or The Society of Mind. Resources Grady BoochComputing: The Human ExperienceThe Last Software EngineerThe End of History and the Last ManAnil Seth: Why AI is unlikely to become consciousKlugeThe Society of MindWorld ModelsGlobal Workspace TheoryA Robust Layered Control System for a Mobile RobotI Am a Strange LoopThe C++ Programming LanguageD3Victorian Engineering ConnectionsComputer History Museum Software History CenterMacPaint and QuickDraw Source CodeMediaWiki Source CodeLinux Kernel ArchivesThe Sciences of the ArtificialSystemantics Guest: Grady Booch Company: Computing: The Human ExperienceGitHub: @gradybooch𝕏: @grady_booch Host: Kent C. Dodds Website: kentcdodds.com𝕏: @kentcdoddsGitHub: @kentcdoddsYouTube: kentcdodds-plusPodcast: epicproduct.engineer See on Epic Product Engineer

    Software architecture, human judgment, and AI's limits with Grady Booch

  8. Jun 3

    User outcomes, workflow design, and biotech software - product engineering with Swizec Teller

    Kent talks with Swizec Teller about product engineering for software that serves real businesses and non-developer users: how to learn a domain you did not grow up in, how to spot hidden friction by watching people work, and why the best product work focuses on outcomes, not engineering puzzles. They talk through biotech, internal tooling, habits users build around buggy software, feature placement, success metrics, and how to widen the pit of success for people who are just trying to do their jobs. (00:00) - Intro (01:04) - Swizec's path from startups to biotech (02:18) - Learning a domain you didn't grow up in (05:14) - Widening the pit of success (09:46) - Introducing workflow changes without friction (12:11) - Feature flags and early feedback loops (16:11) - How to find real user needs (20:02) - What support tickets tell you about users (22:55) - Reading friction as a product signal (24:51) - Automation and what it changes for users (26:58) - Where to place new capabilities (29:26) - Breaking big ideas into shippable pieces (33:31) - Defining success before you ship (37:27) - Software is valuable for what users can now do Swizec brings a perspective that broadens the season in a useful way. Instead of developer-facing tools, he has spent years building software that supports biotech, healthcare, and other real-world businesses where the user is trying to get work done, not admire your architecture. That makes the conversation very grounded in observation: shadowing experts, noticing workaround behavior, understanding existing habits, and putting new capabilities exactly where people already look. The second half of the episode turns that into a practical product loop. Swizec and Kent talk about defining success before you ship, measuring whether a workflow actually improved, and balancing long-range vision with the adjacent possible of what today's technology can support. The result is a strong reminder that software is valuable because of the user's new "superpower," not because the implementation was clever. Homework Spend one hour watching users use your software.If you do not have direct access to users, ask your manager or PM to connect you with someone internally, or watch a partner or friend try a real workflow while you take notes.Treat every workaround or confusing step you see as a potential product opportunity. Resources Swizec TellerSwizec newsletterSwizec Teller - GitHub Guest: Swizec Teller GitHub: @Swizec𝕏: @swizec Host: Kent C. Dodds Website: kentcdodds.com𝕏: @kentcdoddsGitHub: @kentcdoddsYouTube: kentcdodds-plusPodcast: epicproduct.engineer See on Epic Product Engineer

    User outcomes, workflow design, and biotech software - product engineering with Swizec Teller
See All (20)

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
    20
  • Rating
    Clean
  • Copyright
    © 2026 Kent C. Dodds Tech LLC. All rights reserved.
  • Show Website
    Become an Epic Product Engineer

You Might Also Like