Become an 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

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

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

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

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

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

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

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

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

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

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