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

Chapters

0:00 Introduction to Product Engineering 2:00 UK proptech startup lessons 5:24 Tying engineering work to business success 7:03 Metrics and defining success 10:13 AI agents and product judgment 15:17 Performance trade-offs at Intercom 23:39 Message to pure implementers 29:12 Product engineer vs product manager 34:46 Customer feedback channels and user empathy 50:29 Homework: wire up customer feedback

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: Kent C. Dodds
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.

Chapters

0:00 Intro 2:51 From Vercel Domains to Executor 4:13 What Executor does 6:30 Code mode and dynamic workloads 10:04 Who Executor is for 12:09 What makes a good product primitive 15:37 How Executor's architecture evolved 19:21 Knowing when to slow down 20:23 UX work at Vercel Domains 22:37 Scale and edge cases in domain management 24:41 Why good engineering is good product 26:14 From UX to PX 29:13 Docs and APIs as product primitives 31:02 Designing for agent trust and security 35:40 Key takeaways 39:10 Homework: build a product sense library

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: Kent C. Dodds
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.

Chapters

0:00 Introduction to Product Engineering 2:46 Alex Hillman and Stacking the Bricks 6:27 Finding your audience 14:44 How customers describe themselves 29:09 Identifying who you are building for 52:16 Sales Safari and observational research 1:08:41 Homework: who is this disagreement serving?

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: Kent C. Dodds
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.

Chapters

0:00 Introduction to Product Engineering 0:42 Julius's Background and T3 Code 2:05 Speed as a Product Differentiator 6:21 Parallelism and the Orchestrator Shift 9:48 Deciding What Belongs in the Core Product 13:21 Pressure to Ship Fast vs. Shipping Quality 15:45 Slowing Down for Maintainability 19:22 Product Vision, Open Source, and Team Constraints 20:50 Monetization and Building What the Ecosystem Lacks 23:53 Pricing, Inference Costs, and Sustainable Products 27:34 Feature Parity, Dogfooding, and Early Priorities 30:29 Building for Users Who Aren't You 31:30 Supervising Agents and Avoiding Bad Directions 34:18 Custom Workflows, Defaults, and the Core UX 39:15 Homework: Step Back and Look at the Whole Product

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: Kent C. Dodds
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.

Chapters

0:00 Introduction to Product Engineering 6:08 The Importance of Product Engineering 9:08 Transitioning in the Tech Landscape 12:06 The Role of AI in Product Engineering 15:03 Human Element in Product Design 17:59 Future of Product Engineering and AI 25:59 The Relevance of Game Design Today 27:03 The Role of Product Engineering 28:23 Learning from Failures in Stakeholder Engagement 30:16 The Importance of Feedback in Product Development 32:05 Designing User-Friendly Interfaces 34:32 The Value of Experienced Designers 35:40 The Evolving Workflow of Product Engineering 37:32 Balancing Speed and Quality in Development 39:20 The Role of Junior Engineers in the Industry 40:45 Engaging Stakeholders for Successful Projects 44:21 Navigating Bad Requirements 46:41 Avoiding Premature Optimization 52:31 The Future of Product Engineering 54:12 Practical Homework for Improving Product Sense

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: Kent C. Dodds
Podcast: epicproduct.engineer

See on Epic Product Engineer