Become an Epic Product Engineer

If more of your users are going to show up through an agent, this episode is for you. Kent talks with Sarah Drasner - Distinguished Engineer at Google, area tech lead for AI and the web ecosystem in Chrome - about giving agents a real interface to your product instead of brittle DOM scraping.

They cover WebMCP and semantic tooling, untrusted content hints and layered defenses against prompt injection, the accessibility upside of agents, how Google is moving from "adopt agents" to levels of autonomy, and why system design is now a skill everyone needs early.

• (00:00) - Meet Sarah Drasner, Distinguished Engineer on Chrome
• (03:21) - WebMCP and fixing the web platform
• (06:04) - Semantic tooling instead of brittle DOM scraping
• (06:58) - Agents and accessibility
• (09:57) - Untrusted content and prompt injection
• (12:38) - Product decisions inside the WebMCP spec
• (14:38) - You're not building it alone
• (15:37) - Levels of autonomy and software factories
• (17:45) - Measuring agentic changes against a control
• (19:22) - Finding the right problems to solve
• (21:41) - Prototyping with agents and adversarial reports
• (26:29) - Your comprehension can't be delegated
• (28:14) - System design is the durable skill
• (31:15) - The trust diamond: agents act for people
• (33:32) - Homework: nuance, the user, and WebMCP
• (34:39) - Kent on agents that never sleep
• (37:32) - Where to follow Sarah

Sarah Drasner is a Distinguished Engineer at Google working in Chrome on AI and the web ecosystem, and she spends a lot of her time deep in WebMCP. Before that she led web, Android, iOS, observability, and reliability across Google's core infrastructure.

The through-line is that agents are not just random bots - they are often an extension of a person trying to get an outcome. WebMCP lets your site expose structured tools for coarse-grained functionality, which is more token efficient than scraping and safer because you can mark content as untrusted, read-only, or consequential. But no single protection is enough: like accessibility and security on the web, you need layered approaches.

They also talk about product decisions inside the spec itself (like keeping state across page navigations with continuation tokens), working with the people around you instead of doing it alone, measuring agentic changes against a control at Google, prototyping with agents and adversarial reports, why your comprehension can't be delegated, and why system design matters much earlier in your career now that you're making decisions with an agent in the planning loop.

Homework: keep nuance open, put the user first (even when an agent is acting for them), and go check out WebMCP.

Homework

• Keep nuance open: don't reach for one Boolean answer - plan for layered protections, because no single solution covers every case.
• Put the user first, including when an agent is acting on their behalf. Ask when they want a signal and when that signal gets tiring.
• Check out the WebMCP spec, hand it to your agent, and ask how your product can take advantage of it.

Resources

• WebMCP spec
• WebMCP on GitHub (explainer, issues, proposals)
• Chrome DevTools MCP (DevTools for agents)
• NotebookLM
• Sarah's website
• Sarah on X
• Sarah on Bluesky
• Sarah on GitHub

Guest: Sarah Drasner

• Company: Google
• GitHub: @sdras
• 𝕏: @sarah_edo

Host: Kent C. Dodds

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

See on Epic Product Engineer

If AI handed you back hours of implementation time and you're not sure where to spend it, this episode is for you. Kent talks with Jay Parikh - Executive Vice President of CoreAI at Microsoft - about putting that time into customers, ideas, and outcomes instead of more output.

They cover where the line between engineer and product manager is (and isn't), why small teams win the learning loop, activity metrics vs outcome metrics, tracking focus time and toil, capacity planning at GitHub scale, and why Copilot Fusion means you shouldn't have to pick a model.

• (00:00) - Meet Jay Parikh and Microsoft CoreAI
• (01:16) - Where software engineers fit now
• (03:33) - Spend saved time on outcomes and customers
• (05:12) - Product engineer vs product manager
• (06:47) - Small teams, faster learning loops
• (08:30) - Capacity planning at GitHub scale
• (11:41) - Activity metrics vs outcome metrics
• (14:38) - Tracking focus time and toil
• (15:44) - Copilot Fusion: stop picking models
• (18:32) - Agents that manage the project
• (19:00) - Homework: raise your ambition, measure outcomes

Jay Parikh leads CoreAI at Microsoft, the organization building the tools, platform, and infrastructure for AI-native developers, including GitHub. Kent caught up with him the day of his GitHub Universe keynote.

The through-line is outcomes over output. When agents take on more of the implementation and verification, Jay wants that time to go into ideation, creation, collaboration, and "picking right" - and then into checking whether the feature actually moved the business. The line between software engineer and product manager is situational, not fixed, but getting closer to the customer is all upside for engineers.

They talk about small teams that traverse a faster learning loop than competitors, why activity metrics (lines of code, PR counts) were useful for getting people moving but aren't the goal, dividing PR velocity by incident rate, measuring focus time vs unfocused time and toil across CoreAI, capacity planning when volume per person keeps climbing, and Copilot Fusion and Copilot projects: express your intent and budget, and let the system orchestrate the models and agents.

Homework: whatever level of ambition you have, raise it. Then define explicit outcome metrics (leading and lagging) and wire them into your dashboards and your agents.

Homework

• Whatever level of ambition you have with these tools, raise it: try something bigger, bolder, and faster than you think you're ready for.
• Try different tools and different ways of doing the work to find the edge.
• Define explicit outcome metrics for what you're building, and know which are leading and which are lagging.
• Wire those outcome metrics into your dashboards and your agents so the whole learning loop runs faster.

Resources

• GitHub Universe 2026: Evolving every layer of the stack (Jay Parikh)
• Copilot Fusion docs
• Copilot projects docs
• Jay on GitHub
• Jay on LinkedIn

Guest: Jay Parikh

• Company: Microsoft
• GitHub: @jayparikh

Host: Kent C. Dodds

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

If you jump straight to implementation before you can explain the user journey, this episode is for you. Kent talks with Drew Hoskins - author of The Product-Minded Engineer, Senior Staff engineer at Stripe - about the otter metaphor, avoiding the Cthulhu effect in user interviews, and reviewing systems instead of diffs.

They cover Facebook product-hybrid archetypes, Temporal and Stripe loops, the rule of three for generalization, and homework: sketch one feature's journey and hunt for plot holes.

• (00:00) - Meet Drew Hoskins
• (00:33) - The Product-Minded Engineer
• (03:21) - Stripe and developer products
• (06:11) - From compilers to product hybrid
• (08:34) - Facebook archetypes and career turn
• (10:57) - Temporal PM, then back to Stripe
• (13:51) - Sketch the user journey
• (16:13) - Balancing systems and users
• (21:05) - Fire-and-forget codegen risks
• (25:00) - Avoiding the Cthulhu effect
• (30:43) - Puzzle approach to empathy
• (33:28) - Rule of three
• (39:43) - Review systems, not only diffs
• (46:03) - Homework: sketch one journey

Drew Hoskins (he also goes by Andrew) is the author of The Product-Minded Engineer. He started as a compiler engineer at Microsoft, built deep systems at Facebook and Oculus, founded Workflow Engine at Stripe, spent two years as a PM at Temporal, then returned to Stripe engineering after the book shipped - living the product-hybrid path he writes about.

The through-line is product-minded engineering as a career shape, not a side hobby. At Facebook, Kent Beck's staff archetypes named "product hybrid" as a real mode. Drew doubled down instead of managing. The otter metaphor from the book frames engineers who play across product and systems. User interviews go wrong when you summon the Cthulhu effect - leading people into agreeing with your idea. Sketching the journey (discovery, understanding, usability, safe usability) exposes plot holes before you ship.

They talk balancing systems thinking with user empathy, reviewing systems not diffs as agents write more code, deferred trust and conditional approvals, and the rule of three for when to generalize.

Homework: take a feature you are working on, sketch its user journey in detail, and look for plot holes - how users find it, how they understand what it means, where the story breaks.

Homework

• Pick a feature you are working on.
• Sketch the user journey in detail (discovery, understanding, usability / safe usability).
• Look for plot holes: how does the user find it, understand what it means, and get through without getting stuck?

Resources

• The Product-Minded Engineer (O'Reilly)
• The Product-Minded Engineer (Substack)
• Drew on LinkedIn
• Temporal
• Stripe

Guest: Drew Hoskins

• Company: Stripe

Host: Kent C. Dodds

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

See on Epic Product Engineer

If you only get asked about feasibility, this episode is for you. Kent talks with Sam Julien - Director of Product at CopilotKit, author of Agentic GraphRAG - about moving past ticket-taking, collaborative product-engineering dialogue, and frameworks that help you push back with vocabulary.

They cover leverage / neutral / overhead triage, Kagan's four big risks, communicating intent with AI agents, and why engineers need product models even when they have a PM.

• (00:00) - Meet Sam Julien
• (01:26) - Dev to DevRel to product
• (03:37) - Product, design, and engineering overlap
• (06:00) - Durable skills as agents write code
• (12:01) - Get closer to customers
• (15:34) - Building a product-minded engineering team
• (18:46) - When technical work was the whole job
• (25:28) - Talk through the problem first
• (33:26) - Sales-driven development and gatekeeping
• (36:26) - Beyond feasibility
• (39:35) - LNO, RICE, and friends
• (42:42) - Continuous discovery and agents
• (46:44) - Communicating intent to AI
• (51:27) - Homework: triage your backlog

Sam Julien went from self-taught web developer to developer relations to product. He is Director of Product at CopilotKit (generative UI across front ends, Slack, Teams) and author of the O'Reilly book Agentic GraphRAG.

The through-line is product-minded engineering as a durable skill. Implementation-only careers are getting thinner as agents take more code work. Sam's article on building a product-minded engineering team name-drops jobs-to-be-done, Kagan's four big risks, continuous delivery, LNO (leverage / neutral / overhead), DHM, RICE, and North Star - and he lands on LNO as especially practical for backlog triage.

Leverage work: small effort, outsized outcome. Neutral: necessary, so scope it. Overhead: automate or drop - often a fit for AI. Engineers need these models so they can push back with shared vocabulary, especially when the PM is checked out. Feasibility alone is not enough; value, usability, and business viability belong in the dialogue.

They also talk collaborative product-engineering conversations, gatekeeping sales-driven development, and communicating intent clearly when agents execute.

Homework: spend ten minutes on your backlog and apply at least one triage framework (LNO or similar). Extra credit: watch something recent from Teresa Torres.

Homework

• Open your backlog once this week.
• Spend about ten minutes sorting items with a triage lens (LNO - leverage, neutral, overhead - or another framework from the episode).
• For each item, ask why you are doing it, what the effort is, and what the value or impact is.

Resources

• Sam Julien
• Building a Product-Minded Engineering Team
• CopilotKit
• Sam on X
• Sam on GitHub
• Sam on LinkedIn
• Agentic GraphRAG (O'Reilly)

Guest: Sam Julien

• Company: CopilotKit
• GitHub: @samjulien
• 𝕏: @samjulien

Host: Kent C. Dodds

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

See on Epic Product Engineer

If you ship features and never hear what users actually said, this episode is for you. Kent talks with Ben Vinegar - co-founder of Modem, formerly founding engineer and VPE at Sentry - about aggregating feedback, eliminating adoption barriers, and keeping human judgment in the loop as AI speeds up shipping.

They cover FreshBooks-era product engineering, Modem's approach to capturing feedback across Slack, Discord, GitHub, and support tools, and why five real conversations beat a median LLM opinion.

• (00:00) - Meet Ben Vinegar
• (01:29) - Career startup guy
• (03:48) - What Modem is for
• (06:59) - Building products for builders
• (12:58) - Aggregating feedback at scale
• (15:26) - FreshBooks and early product loops
• (21:34) - Onboarding and getting users unstuck
• (25:06) - Emerging technology at Sentry
• (27:59) - Buy a laundromat - go deep on users
• (33:56) - Support culture and intentionality
• (39:35) - Human connection in the feedback loop
• (42:27) - Hunk and accelerating taste with AI
• (45:12) - Human judgment vs median products
• (49:43) - Homework: five people talking

Ben Vinegar calls himself a career startup guy - early at FreshBooks, Disqus, and Sentry (first five people through ~400 employees), then head of product engineering, VPE, and VP of emerging technology. He founded Modem (modem.dev) to give product engineers faster access to what users are saying so they can iterate.

The through-line is closed-loop feedback. Successful products Ben has worked on followed make-a-change, get-it-in-front-of-users, adjust, repeat. Modem aggregates signals from Slack Connect, Discord, GitHub issues, Intercom, Zendesk, and similar channels so teams are not hunting screenshots in five tools.

They talk adoption barriers, FreshBooks' support culture, and why human judgment still differentiates when agents can ship median products. Ben's Hunk terminal diff tool story shows taste accelerating with AI: he built what he needed as a "norm core" Mac user who wanted agents running while he closed the laptop. Extreme product bets rarely come from averaged LLM taste.

Homework from Ben, sharpened by Kent: get five people to try your software - and talk with them about their experience using it.

Homework

• Pick something you shipped (or are about to ship).
• Get five people to try it.
• Talk with those five people about their experience using your software - not just whether they clicked install.

Resources

• Modem
• Ben Vinegar
• Ben on X
• Ben on Bluesky
• Ben on GitHub
• Ben on LinkedIn
• Hunk

Guest: Ben Vinegar

• Company: Modem
• GitHub: @benvinegar
• 𝕏: @bentlegen

Host: Kent C. Dodds

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

See on Epic Product Engineer

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 Talk
• Product Discovery Basics
• Continuous Discovery Habits
• Just Now Possible podcast
• Teresa on Bluesky
• Teresa on LinkedIn
• Teresa on X

Guest: Teresa Torres

• Company: Product Talk
• 𝕏: @ttorres

Host: Kent C. Dodds

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

See on Epic Product Engineer

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 Techson
• Mark on X
• Mark on GitHub
• Mark on LinkedIn
• Angular
• Google Developer Experts

Guest: Mark Techson

• Company: Google
• GitHub: @MarkTechson
• 𝕏: @MarkTechson

Host: Kent C. Dodds

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

Mark's views are his own. He notes he works for a major frontier-model provider (Google).

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 X
• Joyce on GitHub
• Joyce on LinkedIn
• Cerebras
• Visual Studio Code
• The Qualified Sales Leader by John McMahon

Guest: Joyce Er

• Company: Cerebras
• GitHub: @joyceerhl
• 𝕏: @joyceerhl

Host: Kent C. Dodds

• Website: kentcdodds.com
• 𝕏: @kentcdodds
• GitHub: @kentcdodds
• YouTube: kentcdodds-plus
• Podcast: 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.

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 Kozlov
• Rita on X
• Rita on Bluesky
• Rita on GitHub
• Rita on LinkedIn
• Cloudflare Workers
• Cloudflare

Guest: Rita Kozlov

• Company: Cloudflare
• GitHub: @rita3ko
• 𝕏: @ritakozlov

Host: Kent C. Dodds

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

See on Epic Product Engineer

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 X
• Erin on Bluesky
• Erin on GitHub
• Erin on LinkedIn
• Kit

Guest: Erin Fox

• GitHub: @erinfox
• 𝕏: @erinfoox

Host: Kent C. Dodds

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

See on Epic Product Engineer

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 Silletti
• The Product Engineers Podcast
• Peppe on LinkedIn
• Peppe on GitHub
• The Product Engineers Podcast on YouTube
• Product management is broken. Engineers can fix it - PostHog
• Continuous Discovery Habits by Teresa Torres
• Laws of UX by Jon Yablonski

Guest: Peppe Silletti

• Company: The Product Engineers Podcast
• GitHub: @peppesilletti
• 𝕏: @peppesilletti

Host: Kent C. Dodds

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

See on Epic Product Engineer

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 Person
• Shaundai on Bluesky
• Shaundai on X
• Shaundai on GitHub
• Shaundai on LinkedIn
• TypeScript for JavaScript Developers
• Whimsical Animations by Josh Comeau
• Netflix

Guest: Shaundai Person

• Company: Netflix
• GitHub: @shaundai
• 𝕏: @shaundai

Host: Kent C. Dodds

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

See on Epic Product Engineer

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 X
• Michael on GitHub
• Michael on LinkedIn
• Michael on Bluesky
• WorkOS
• auth.md
• auth.md on GitHub
• WorkOS events on Luma
• Let's build GPT from scratch (Andrej Karpathy)
• The Mom Test

Guest: Michael Grinich

• Company: WorkOS
• GitHub: @grinich
• 𝕏: @grinich

Host: Kent C. Dodds

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

See on Epic Product Engineer

If you ship features before you can explain the process, this episode is for you. Kent talks with Ronan Berder about building consumer products at Nike, Hilton, and Burberry scale in China, why engineers need to leave the IDE, and why a process you have not written down is not a process.

They cover aligning teams on product vision, benchmarking competitors before you invent, design boundaries that unlock creativity, consulting failures from expectation gaps, and the homework that sounds too simple: write down what you are struggling with.

• (00:00) - Meet Ronan Berder
• (01:53) - Shipping at China consumer scale
• (03:42) - Partner vs vendor: strategy before build
• (09:02) - Aligning engineers on product vision
• (15:56) - Benchmark competitors before you invent
• (17:35) - Design systems, boundaries, and process
• (22:42) - If it is not written down, you do not have a process
• (28:40) - Process scale: five people vs 160
• (33:21) - Horizontal skills beyond the IDE
• (34:15) - Abstraction layers in the business
• (39:44) - Talking with VPs and C-suite
• (44:49) - Consulting failures and expectation gaps
• (50:48) - When clients insist on bad bets
• (53:39) - Large companies lack creativity
• (58:23) - Homework: write down your struggles

Ronan Berder founded Wiredcraft in Shanghai, grew it past 160 people, and sold it after years of shipping localized consumer apps for brands like Nike, Hilton, Burberry, and Adidas - often to tens of millions of users on day one. In this conversation, he and Kent dig into what product engineering looks like when you are a partner to VPs and C-suite, not a ticket-taking vendor.

A major theme is process as a creative constraint. Ronan argues designers and engineers need boundaries, shared definitions, and written playbooks - not because bureaucracy is fun, but because you cannot improve what you never articulated. He is blunt about engineers who never benchmark competitors, teams that chase cool campaigns over boring work that moves sales, and consulting failures that come from expectation gaps more often than from bad code.

They also talk about AI making pure implementation more replaceable, why understanding one layer above and below your work still matters, and how large companies rarely invent the creative bets that startups do. Ronan's homework is simple: whatever you are struggling with right now, write it down and organize your thoughts.

Homework

• Pick one thing you are struggling with in your work right now.
• Write it down and organize your thoughts until the gaps are visible.
• Share the written version with a teammate and use it to align on what 'done' means.

Resources

• Ronan Berder
• Ronan on X
• Ronan on GitHub
• Ronan on LinkedIn
• Rotsu
• Wiredcraft

Guest: Ronan Berder

• Company: Rotsu
• GitHub: @hunvreus
• 𝕏: @hunvreus

Host: Kent C. Dodds

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

See on Epic Product Engineer

If you build internal tools, AI enablement, or platform work, this episode is for you. Kent talks with Ben Ilegbodu about treating developers as customers, measuring success without a checkout funnel, and the durable skills that still matter when agents write more of the code.

They cover agentic workflows and skills at Netflix, closing the agent loop for TV UI development, verification and harness engineering, and why deciding what to build beats shipping three times more features.

• (00:00) - Meet Ben Ilegbodu
• (01:06) - From React speaking to Netflix AI enablement
• (02:56) - Training engineers for agentic workflows
• (04:17) - Skills, context, and insulating teams from churn
• (08:41) - Product engineering for internal tools
• (10:06) - How to measure success without a checkout funnel
• (12:07) - Closing the agent loop for TV UI
• (18:34) - Durable skills: what to build, specs, verification
• (23:45) - Harness builders and agent experience
• (26:33) - Agent-to-agent PR review
• (28:21) - Intent docs and harness engineering
• (29:36) - Do users want 3x more features?
• (32:00) - Retrospective skills that improve the system
• (36:56) - AI is here to stay
• (39:11) - Homework: turn repeated prompts into skills

Ben Ilegbodu has spent years helping other engineers move faster - first through React education and UI tooling, and now on Netflix's TV UI productivity team focused on AI enablement. In this conversation, he and Kent talk about what product engineering looks like when your customers are other developers, not the people paying for Netflix.

A major theme is that internal tooling still needs product judgment. Ben argues the product is what you deliver to developers, and that feedback can be even more direct than consumer product work because your users Slack you when something breaks. Measuring success means observability, usage, and silence that is not always golden. On the AI side, they dig into skills as reusable context for agents, the hard problem of closing agent loops for TV apps that are not web browsers, and why durable skills like deciding what to build, writing specs, and verification will outlast any particular harness.

They also talk about agent-to-agent workflows, retrospective skills that improve the system from real usage, and the temptation to turn 3x throughput into 3x feature spam. Ben's homework is practical: notice the prompts and workflows you repeat while developing with an agent, and turn those into skills so you stop retyping the same guidance every session.

Homework

• While you develop with an agent, notice the prompts or workflows you repeat over and over.
• Turn one of those repeated instructions into a skill (or part of a larger skill) so the agent can reuse it.
• Run with that skill on your next task and notice what details you can stop retyping every session.

Resources

• Ben Ilegbodu
• Ben on X
• Ben on GitHub
• Netflix

Guest: Ben Ilegbodu

• Company: Netflix
• GitHub: @benmvp
• 𝕏: @benmvp

Host: Kent C. Dodds

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

See on Epic Product Engineer

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. Martin
• Clean Coders
• SwarmForge
• Agile Manifesto
• Clean Code

Guest: Robert C. Martin

• Company: Uncle Bob Consulting LLC
• GitHub: @unclebob
• 𝕏: @unclebobmartin

Host: Kent C. Dodds

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

See on Epic Product Engineer

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 Sexton
• ngrok
• Fly.io
• Badass: Making Users Awesome
• Webcomic Studio

Guest: Annie Sexton

• Company: ngrok
• GitHub: @anniebabannie

Host: Kent C. Dodds

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

See on Epic Product Engineer

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 Shimeles
• Convex
• Fabrika
• The Mom Test
• Clean Code

Guest: Michael Shimeles

• Company: Convex
• GitHub: @michaelshimeles
• 𝕏: @rasmic

Host: Kent C. Dodds

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

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

• FamilySearch
• Lucas Wargha (site)
• Competing Against Luck (Jobs to Be Done)
• UtahJS

Guest: Lucas Wargha

• Company: FamilySearch
• GitHub: @lucaswargha
• 𝕏: @lucaswargha

Host: Kent C. Dodds

• Website: kentcdodds.com
• 𝕏: @kentcdodds
• GitHub: @kentcdodds
• YouTube: Kent C. Dodds
• Podcast: epicproduct.engineer

See on Epic Product Engineer

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 Casas
• Postman
• Rethinking UI in Agent-Driven Systems
• MCP Apps

Guest: Ruben Casas

• Company: Postman
• GitHub: @infoxicator
• 𝕏: @infoxicador

Host: Kent C. Dodds

• Website: kentcdodds.com
• 𝕏: @kentcdodds
• GitHub: @kentcdodds
• YouTube: Kent C. Dodds
• Podcast: epicproduct.engineer

See on Epic Product Engineer

Kent talks with Sean Roberts, engineer at PhotoShelter, about product engineering shaped by agency work and small teams: being the technical person in sales conversations early, planning with product judgment, and knowing when to speak up (and when to listen).

They discuss why implementation skill still matters in the AI era, how to avoid "vibes-only" product calls, budgeting and sequencing work with business context, and why striking up real conversations (with customers or anyone) is a trainable muscle.

• (00:00) - Introduction to Product Engineering
• (02:11) - Agency work and customer conversations
• (08:47) - The technical person in the room
• (16:54) - Determining business goals
• (26:48) - Planning and the dark forest
• (35:10) - Relationships and positive feedback
• (40:21) - Homework: talk to someone 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

• PhotoShelter
• Sean Roberts - GitHub

Guest: Sean Roberts

• Company: PhotoShelter
• GitHub: @seanroberts
• 𝕏: @sean_j_roberts

Host: Kent C. Dodds

• Website: kentcdodds.com
• 𝕏: @kentcdodds
• GitHub: @kentcdodds
• YouTube: Kent C. Dodds
• Podcast: epicproduct.engineer

See on Epic Product Engineer

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 Booch
• Computing: The Human Experience
• The Last Software Engineer
• The End of History and the Last Man
• Anil Seth: Why AI is unlikely to become conscious
• Kluge
• The Society of Mind
• World Models
• Global Workspace Theory
• A Robust Layered Control System for a Mobile Robot
• I Am a Strange Loop
• The C++ Programming Language
• D3
• Victorian Engineering Connections
• Computer History Museum Software History Center
• MacPaint and QuickDraw Source Code
• MediaWiki Source Code
• Linux Kernel Archives
• The Sciences of the Artificial
• Systemantics

Guest: Grady Booch

• Company: Computing: The Human Experience
• GitHub: @gradybooch
• 𝕏: @grady_booch

Host: Kent C. Dodds

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

See on Epic Product Engineer

Kent talks with Swizec Teller about product engineering for software that serves real businesses and non-developer users: how to learn a domain you did not grow up in, how to spot hidden friction by watching people work, and why the best product work focuses on outcomes, not engineering puzzles.

They talk through biotech, internal tooling, habits users build around buggy software, feature placement, success metrics, and how to widen the pit of success for people who are just trying to do their jobs.

• (00:00) - Intro
• (01:04) - Swizec's path from startups to biotech
• (02:18) - Learning a domain you didn't grow up in
• (05:14) - Widening the pit of success
• (09:46) - Introducing workflow changes without friction
• (12:11) - Feature flags and early feedback loops
• (16:11) - How to find real user needs
• (20:02) - What support tickets tell you about users
• (22:55) - Reading friction as a product signal
• (24:51) - Automation and what it changes for users
• (26:58) - Where to place new capabilities
• (29:26) - Breaking big ideas into shippable pieces
• (33:31) - Defining success before you ship
• (37:27) - Software is valuable for what users can now 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 Teller
• Swizec newsletter
• Swizec Teller - GitHub

Guest: Swizec Teller

• GitHub: @Swizec
• 𝕏: @swizec

Host: Kent C. Dodds

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

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.

Jack brings a useful split perspective: early UK proptech startup experience where engineering success and company success were basically the same thing, followed by years of technical leadership at Intercom without people management. That combination shows up throughout the episode in how he talks about responsibility, ambiguity, and what still matters when agents can generate more code faster.

A big theme is reframing success. Instead of celebrating "I shipped the ticket on time," Jack argues product engineers look back at whether the thing they shipped is being used, whether customers are happy, and whether the work connected to business outcomes. Metrics help start those conversations, but he is skeptical of sweating small week-to-week movements on a single number when qualitative signals and customer conversations often tell you more.

The close is especially practical: engineers can use their craft to improve product judgment, not only implementation - by wiring up real customer feedback channels (Slack feeds, sales-call snippets, forward-deployed engineer patterns) and learning to ask *why* people want something before deciding what to build.

Homework

• Find good sources of customer feedback in your org (support, sales, success, research, or forward-deployed engineers).
• Use engineering to put that feedback somewhere you will actually see it regularly - wire up a Slack channel, dashboard, or digest so the signal can "wash over you" the way Jack describes.
• Practice asking *why* a customer wants something before treating their feature request as the spec.

Resources

• Jack Ryan - Intercom Blog
• Intercom
• requisite (Intercom open source)

Guest: Jack Ryan

• Company: Intercom
• GitHub: @jmfryan
• 𝕏: @jmfryan

Host: Kent C. Dodds

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

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.

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

• Executor
• Rhys Sullivan - site
• Executor - GitHub
• OpenCode

Guest: Rhys Sullivan

• Company: Executor
• GitHub: @RhysSullivan
• 𝕏: @RhysSullivan

Host: Kent C. Dodds

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

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.

Alex brings a product and marketing lens that fits this season perfectly: great products do not just solve technical problems, they help the right people recognize that you understand their world. The conversation starts with finding an audience and quickly turns into a practical way to build product sense inside a company: learn how customers describe themselves, observe where they gather, listen for the language they use, and speak from their priorities instead of your own taste.

The second half gets into Sales Safari, Stacking the Bricks' observational research practice. Alex explains why surveys and interviews can miss important signal, what to look for in real conversations, and how notes on jargon, pain, worldview, and recommendations can turn scattered internet conversations into useful product understanding. The through-line is simple and demanding: reduce the distance between you and the people you serve so your software, messaging, and decisions feel anticipated rather than manipulative.

Homework

• The next time coworkers or product teammates disagree about direction, step back and observe the conversation.
• Ask: who is this disagreement in service of? Is it serving the customer, the decision maker, the loudest person, or someone else?
• Practice this once a day or once a week, then use the patterns you notice to decide what you should contribute.

Resources

• Stacking the Bricks
• 30x500
• The Tiny MBA
• The Mom Test
• Alex Hillman on X

Guest: Alex Hillman

• Company: Stacking the Bricks
• GitHub: @alexknowshtml
• 𝕏: @alexhillman

Host: Kent C. Dodds

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

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.

Julius is building right in the middle of one of the fastest-moving product categories in software, and that gives this episode a useful tension: everything feels possible, but that does not mean everything belongs in the product. The conversation covers the shift from one-agent-at-a-time coding to orchestration, why T3 Code focuses so much on a fast app layer, and how Julius thinks about what should live in the core product versus forks, plugins, or future work.

The deeper lesson is about judgment under speed. Julius and Kent keep returning to the same idea from different angles: when agents can generate a lot of implementation quickly, the real work is deciding what is worth building, what will age well, and what future decisions you might accidentally box yourself out of.

Homework

• Take a step back and look at your product from the whole picture, not just the slice you currently touch.
• Before prioritizing a feature, ask whether it keeps the product maintainable long-term and whether it fits the job to be done for your users.

Resources

• T3 Code
• T3 Chat
• Julius Marminge — GitHub
• OpenCode

Guest: Julius Marminge

• GitHub: @juliusmarminge
• 𝕏: @jullerino

Host: Kent C. Dodds

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

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.

Jamon brings a useful mix to this conversation: founder of Infinite Red, longtime consultant, React Native specialist, and now indie game developer. That perspective makes the episode unusually practical. He has spent years watching where projects go wrong when product thinking is weak: bad requirements, unclear stakeholder alignment, UX details nobody owned, and engineers optimizing the wrong thing too early.

The thread through the whole episode is durability. Product engineering is not just about shipping faster with agents or getting better at a specific tool. It is about understanding people, shaping better requirements, recognizing when the human side of the workflow matters more than the code, and making decisions that keep paying off as the technology changes around you.

Homework

• Sit down with a non-technical person and watch them try to use a feature you built.
• Write down every hesitation, workaround, double-click, or confusing step you notice, then use that list to reprioritize what you fix next.

Resources

• Infinite Red
• Jamon Holmgren — site
• Night Shift Agentic Workflow
• Gunship Origins on Steam

Guest: Jamon Holmgren

• Company: Infinite Red
• GitHub: @jamonholmgren
• 𝕏: @jamonholmgren

Host: Kent C. Dodds

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

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.

Don's career makes this episode unusually wide-ranging: early computing, human error, aviation safety, Unix, Apple product decisions, digital cameras, color TV, and the long arc from usable products to systems that shape society. The through-line is straightforward but demanding: if you want better products, watch what people actually do, notice the workarounds they no longer complain about, and treat clusters of small usability problems like real product debt.

The second half brings that thinking into the present. Don and Kent talk about AI coding tools as force multipliers that still need direction, architecture, and supervision, then zoom out to Design for a Better World and the Don Norman Design Award. The result is a conversation about product sense that spans decades without feeling dated: the tools change, but the responsibility to understand people, systems, and consequences does not.

Homework

• Spend time watching people do real work before you ask them for solutions; observation reveals the hidden setup, workarounds, and friction they now assume are just "how it works."
• After a release, step back and fix clusters of small usability issues as a system instead of waiting for one confusing bug to become catastrophic.
• Treat AI as a force multiplier you must instruct and supervise; stay responsible for the problem definition, architecture, and review.

Resources

• Don Norman Design Award (DNDA)
• Design for a Better World
• The Design of Everyday Things
• Nielsen Norman Group — Don Norman
• United Nations Sustainable Development Goals

Guest: Don Norman

• Company: Don Norman Design Award (DNDA)

Host: Kent C. Dodds

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

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.

Will's path runs from designing bucket trucks to self-taught software engineering, education products, and database tooling, and that background gives this episode a distinctive lens: software is still a product people use with bodies, habits, emotions, and mental models. The conversation makes product sense concrete through examples like onboarding timing, course complexity, support workflows, and the small confidence signals that separate stable-feeling products from merely functional ones.

You'll hear why watching users work keeps surfacing across this series, how to tell broken experiences from merely unpopular ones, why user feedback usually improves polish more than strategy, and how product engineers can stay valuable in an agent-heavy future by understanding both the user and the constraints of the software medium.

Homework

• Use AI agents more for gathering than executing: explore multiple solution paths, adjacent domains, and missing context before you ship.
• Give agents richer context like user demographics, constraints, and likely mental models, then use your own judgment to evaluate what comes back.
• Slow down long enough to question assumptions before implementation; use AI as a creativity and critique tool, not just a code accelerator.

Resources

• Will King - site
• Deploy Empathy (Michele Hansen)
• The Mom Test (Rob Fitzpatrick)
• Interface Craft (Josh Puckett)

Guest: Will King

• Company: Crunchy Data
• GitHub: @wking-io
• 𝕏: @willking

Host: Kent C. Dodds

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

See on Epic Product Engineer