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