The Product Engineers Podcast

What happens to engineering when AI makes software easier to build? Marty Cagan, founder of Silicon Valley Product Group and coauthor of "EMPOWERED: Ordinary People, Extraordinary Products", argues that engineers' role in shaping the product becomes even more important. Their knowledge of technology helps them see new possibilities, challenge proposed solutions and decide what is worth building.We explore engineers' contribution to product innovation, what discovery looks like in an engineer's day, and why handing over an AI-generated prototype to be made production-ready can recreate the feature factory. Marty also distinguishes empowerment from autonomy, discusses how AI could help smaller teams own more of the product, and shares practical ways engineers can start changing how their teams work.In our conversation, we discuss:1. Why engineers can be your strongest source of product innovation2. Why using AI to speed up a feature factory can deliver failed products faster3. How engineers can make time for discovery and help shape prototypes before a solution is decided4. How empowerment differs from autonomy, and why smaller AI-assisted teams could reduce dependencies5. How to start changing a feature factory from within through customer contact, usage data and small experimentsWhere to find Marty Cagan:• LinkedIn: https://www.linkedin.com/in/cagan/• SVPG: https://www.svpg.com/team/marty-cagan/Where to find Peppe:• LinkedIn: https://www.linkedin.com/in/peppesilletti/• X: https://x.com/peppesilletti• Website: https://peppesilletti.ioWhere to find The Product Engineers Podcast:• Website: https://productengineers.comIn this episode, we cover:(00:00) Introduction(00:56) Feature factories and empowered engineers(07:30) The product model and owning the problem(12:31) Four product risks and why engineers should push back(20:46) How AI changes product teams, discovery and delivery(26:25) The AI productivity paradox(31:53) Daily discovery and the prototype handoff trap(37:08) Developer tools and understanding your customers(42:58) Smaller teams, empowerment and autonomy(46:53) How engineers can start changing a feature factoryReferenced:• EMPOWERED: Ordinary People, Extraordinary Products, by Marty Cagan and Chris Jones: https://www.svpg.com/books/empowered-ordinary-people-extraordinary-products/• The AI Productivity Paradox, by Marty Cagan: https://www.svpg.com/the-ai-productivity-paradox/• A Fresh Definition of the Product Role, by Marty Cagan: https://www.svpg.com/a-fresh-definition-of-the-product-role/• Benedict Evans on Another Podcast: Most people and companies aren’t tool-builders: https://open.spotify.com/episode/4NkYXMBNyXqxihujGGSytc• Atlassian: The State of Teams 2026 (source of the 89%/6% figures): https://www.atlassian.com/blog/state-of-teams-2026• Earlier episode with Meikel Ratz at PostHog: Why "Just Coding" Isn’t Enough Anymore: https://productengineers.com/episodes/season2/why-just-coding-isnt-enough-anymore/• Product Therapy, hosted by Christian Idiodi (SVPG): https://podcasts.apple.com/us/podcast/product-therapy/id1738373011• Claude Code: https://claude.com/product/claude-code• Cursor: https://cursor.com/• OpenAI Codex: https://openai.com/codex/• Lovable: https://lovable.dev/

How can engineers get involved in product work when they usually receive a roadmap, finished designs, and a ticket to implement? Teresa Torres, product discovery coach and author of Continuous Discovery Habits, explains how engineers can participate while the team is still learning about customer problems and deciding what to build.In our conversation, we discuss:1. Why getting involved before sprint planning gives engineers more room to contribute2. How to build relationships and ask for customer and business context3. How to find people with the problem your product solves and collect specific stories4. Why AI coding agents still need product, design, and engineering expertise5. How to bring what you learn to the team and influence change through your own habitsEpisode transcript: https://productengineers.com/episodes/season2/how-engineers-can-get-involved-in-product-work-teresa-torres-continuous-discovery-habits-author/Where to find Teresa Torres:• Product Talk: https://www.producttalk.org/• LinkedIn: https://www.linkedin.com/in/teresatorres/• X: https://x.com/ttorresWhere to find Peppe:• LinkedIn: https://www.linkedin.com/in/peppesilletti/• X: https://x.com/peppesilletti• Website: https://peppesilletti.ioWhere to find The Product Engineers Podcast:• Website: https://productengineers.comIn this episode, we cover:(01:05) Why engineers need a say in what gets built(04:09) Getting involved before sprint planning(06:38) Building trust and asking for product context(14:38) AI coding agents and the product trio(24:39) Why tiny product teams may not stay tiny(27:32) Finding people with the problem your product solves(30:33) Learning from specific stories and spotting product gaps(39:14) Bringing what you learn back to the team(41:47) Changing your habits, humility, and where to find TeresaReferenced:• Continuous Discovery Habits: https://www.producttalk.org/continuous-discovery-habits/• Product trios: https://www.producttalk.org/product-trios/• Customer interviews: https://www.producttalk.org/customer-interviews/• Product Talk Podcast: https://www.youtube.com/@ProductTalkVideos• All Things Product Podcast: https://www.youtube.com/@AllThingsProductPodcast

What does business sense for engineers look like in practice? Arnon Cavaeiro joins me to talk about product engineering, product discovery and choosing which customer problems to solve. We get into revenue, costs and product strategy, and how understanding them helps you decide what to build next.The conversation moves from discovery to delivery, with practical questions engineers can bring to their next project. Why can a feature go unused even when a customer requested it? What is the smallest experiment that would test your riskiest assumption? Arnon shares how to use early signals before revenue catches up, make the business case for technical debt, and navigate the growing overlap between engineering and product management.In our conversation, we discuss:1. Why understanding revenue and costs changes what engineers choose to build2. How to judge customer problems by reach, pain and relative priority3. Why customer requests need small experiments and clear product positioning4. How leading metrics help you change direction before revenue catches up5. How to connect technical debt and engineering decisions to business outcomesWhere to find Arnon Cavaeiro:• LinkedIn: https://www.linkedin.com/in/acavaeiro/Where to find Peppe:• LinkedIn: https://www.linkedin.com/in/peppesilletti/• X: https://x.com/peppesilletti• Website: https://peppesilletti.ioWhere to find The Product Engineers Podcast:• Website: https://productengineers.comIn this episode, we cover:(00:00) Introduction(03:23) Why engineers need to understand the business(07:15) Choosing problems worth solving(09:56) Small experiments and risky assumptions(13:16) Unused features, customer requests and positioning(16:57) Building as thinking, prototypes and taste(26:05) Outcomes, experiments and leading metrics(35:33) Making the business case for technical debt(41:40) Who owns product decisions?(47:08) Closing thoughts and where to find ArnonReferenced:• Taste Labs: https://tastelabs.com/ • Linear: https://linear.app/

Robert C. Martin, also known as Uncle Bob, joins The Product Engineers Podcast to discuss why technical expertise still matters when AI writes the code. The author of Clean Code and Clean Architecture explains how those principles help engineers steer AI coding agents towards better software.We get into Robert's use of static analysis, complexity and coverage metrics, dependency checks and mutation testing. He shares how he stays technically involved while reading less code, and why understanding customers is essential to choosing the right technical constraints.In our conversation, we discuss:1. Why clean code and clean architecture still matter when AI writes the code2. How static analysis and dependency checks help steer agents towards better software3. How Robert combines acceptance tests, QA tests and mutation testing to check AI-written code4. How engineers can stay technically in control without reading every line of code5. Why understanding customers leads to better technical decisionsEpisode transcript: https://productengineers.com/episodes/season2/why-hardcore-technical-focus-still-matters-big-timeWhere to find Robert C. Martin:• X: https://x.com/unclebobmartin• Website: https://cleancoder.com/• Videos: https://cleancoders.com/Where to find Peppe:• LinkedIn: https://www.linkedin.com/in/peppesilletti/• X: https://x.com/peppesilletti• Website: https://peppesilletti.ioWhere to find The Product Engineers Podcast:• Website: https://productengineers.comIn this episode, we cover:(00:00) Why technical expertise still matters with AI(05:27) Agile, customer contact and organisational change(08:39) Learning from customers without losing technical depth(13:19) Connecting technical requirements to customer needs(18:00) Clean code, static analysis and quality metrics for agents(23:48) Enforcing architecture and checking behaviour with tests(28:26) TDD, reading less code and staying technically in control(34:27) Where deep specialists matter and who can build with AI(40:30) Where to find RobertReferenced:• Clean Code: https://www.informit.com/store/clean-code-a-handbook-of-agile-software-craftsmanship-9780135398579• Clean Architecture: https://www.informit.com/store/clean-architecture-a-craftsmans-guide-to-software-structure-9780134494166• Agile Manifesto: https://agilemanifesto.org/• CRAP4J: the complexity-and-coverage metric discussed in the episode• Gherkin: the acceptance-test language used in Robert's workflow

Everyone tells engineers to talk to users. But what should you ask, and how do you turn the answers into better product decisions? Sara Iacozza is a Senior UX Researcher and Product Strategist with 7+ years of experience helping teams understand user behaviour and decide what to build.In our conversation, we discuss:1. How understanding users helps engineers make trade-offs and find simpler solutions2. How to practise user interviews with colleagues, an AI coach, and a researcher’s feedback3. How to avoid leading questions, use plain language, and ask about real experiences4. How to turn interview notes into shared insights and check AI analysis against the evidence5. How to get closer to users by shadowing interviews, watching recordings, and talking to colleaguesEpisode transcript: Where to find Sara Iacozza:• LinkedIn: https://it.linkedin.com/in/sara-iacozza/Where to find Peppe:• LinkedIn: https://www.linkedin.com/in/peppesilletti/• X: https://x.com/peppesilletti• Website: https://peppesilletti.ioWhere to find The Product Engineers Podcast:• Website: https://productengineers.comIn this episode, we cover:(00:00) Introduction and what UX research involves(06:35) Why user research matters for engineers(12:33) Learning to interview users, with practice and AI(24:19) Avoiding leading questions and polite answers(28:39) Using language your users understand(33:08) Turning conversations into insights and checking AI analysis(42:00) Making research part of the team’s work(45:20) Getting closer to users when access is limited(51:35) Where to find SaraReferenced:• Sara’s User Interview Coach (announcement and access link): https://www.linkedin.com/posts/sara-iacozza_chatgpt-user-interview-coach-activity-7296141061372993536-pWZQ• Continuous Discovery Habits by Teresa Torres: https://www.producttalk.org/continuous-discovery-habits/

Jon Yablonski is a senior product designer at Mixpanel and the author of Laws of UX. In this episode, we explore how software engineers can get better at UX design through observation, practice, and collaboration, starting with the products they already use and love.In our conversation, we discuss:✦ Why engineers may already have more design skills than they realise✦ How to train your design eye by studying products you use and love✦ How engineering decisions shift complexity between your code and your users✦ When familiar interface patterns help, and where novelty makes sense✦ How Jon uses AI for prototypes while working through design ideas with pen and paperEpisode transcript: [ADD EPISODE URL]Where to find Jon Yablonski:• Website: https://jonyablonski.com/• LinkedIn: https://www.linkedin.com/in/jon-yablonski-b4269115/Where to find Peppe:• LinkedIn: https://www.linkedin.com/in/peppesilletti/• X: https://x.com/peppesilletti• Website: https://peppesilletti.ioWhere to find The Product Engineers Podcast:• Website: https://productengineers.comIn this episode, we cover:(00:00) Introduction: what UX design really means(07:01) Why engineers aren’t “bad at design”(10:22) Bridging design and engineering(17:45) How to train your design eye(20:16) Laws of UX: complexity and trade-offs(27:29) Familiar patterns and when to break them(31:57) Designing better AI experiences(37:37) Using AI without outsourcing your thinking(41:49) Figma, AI prototypes, and design systems(47:31) Design is a skill you can practiceReferenced:• Laws of UX: https://jonyablonski.com/work/laws-of-ux/• Laws of UX, 2nd Edition: https://www.oreilly.com/library/view/laws-of-ux/9781098146955/• Tesler’s Law• Jakob’s Law• Figma• Claude Code• Storybook

Drew Hoskins is the author of The Product-Minded Engineer and has spent more than 20 years building products and platforms at Microsoft, Meta, Stripe, and Temporal. His work and writing focus on helping engineers develop a product mindset by understanding their users, deciding what’s worth building, and turning technical expertise into better products.In our conversation, we discuss:1. Why great code can fail to win adoption, and how product thinking helps engineers increase their impact2. How to learn from users through support records, sales calls, GitHub issues, and product metrics3. How user scenarios reveal “plot holes,” guide prioritisation, and become tests that reflect real usage4. What Drew learned as a PM at Temporal, and how tools help make product-minded habits last5. Why AI may create software generalists, how to review AI-generated tests, and practical exercises to start tomorrowEpisode transcript: https://productengineers.com/episodes/season2/how-to-become-a-product-minded-engineer-in-the-ai-eraWhere to find Drew Hoskins:• LinkedIn: https://www.linkedin.com/in/drewhoskins2/• Substack: https://drewhoskins.substack.com/Where to find Peppe:• LinkedIn: https://www.linkedin.com/in/peppesilletti/• X: https://x.com/peppesilletti• Website: https://peppesilletti.ioWhere to find The Product Engineers Podcast:• Website: https://productengineers.comIn this episode, we cover:(00:00) Introduction and what product-minded engineering means(05:39) Developer experience, adoption, and engineering career impact(10:47) Getting closer to users through conversations and data(15:25) User scenarios, plot holes, and meaningful tests(22:01) Lessons from Temporal and building a product-minded culture(28:21) AI coding, reviewing tests, and the software generalist(33:57) Collaboration, daily habits, and exercises to get startedReferenced:• The Product-Minded Engineer: https://www.oreilly.com/library/view/the-product-minded-engineer/9781098173722/

Meikel Ratz is a product engineer at PostHog, where he leads the messaging team. In this episode, we unpack the product thinking behind that role and what it takes to become a product-minded engineer: understanding customers, making product decisions, thinking about revenue, and deciding what to build instead of simply working through tickets.In our conversation, we discuss:1. Why solving problems, not writing code, has always been the real job of software engineers2. “Snacking work”: the small, satisfying tasks that consume time without creating much impact3. How PostHog gives engineers ownership over customers, product decisions, reliability, and revenue4. How engineers can develop product and business sense, even if they’ve spent their career being handed tickets5. Why data should drive product decisions, when gut feeling is still useful, and how AI changes the economics of experimentationEpisode transcript: https://productengineers.com/episodes/season2/why-just-coding-isnt-enough-anymore/Where to find Meikel Ratz:• LinkedIn: https://www.linkedin.com/in/meikelratz/Where to find Peppe:• LinkedIn: https://www.linkedin.com/in/peppesilletti/• X: https://x.com/peppesilletti• Website: https://peppesilletti.ioWhere to find The Product Engineers Podcast:• Website: https://productengineers.comIn this episode, we cover:(01:29) What is the role of a software engineer in the AI era?(07:09) Snacking work, hard problems, and engineering impact(14:01) Product engineers, product managers, and company culture(23:21) What it means to be a product-minded engineer(29:31) How to develop business and product sense(34:13) Start with users, then business, pricing, and product vision(39:03) How PostHog uses data to make product decisions(43:02) Data, gut feeling, and experimenting cheaply with AI(44:50) What to do when engineers are just handed tickets(48:53) Where to find MeikelReferenced:• PostHog: https://posthog.com

If you're freelancing as a software engineer, you've probably noticed something a bit weird: your freelance pricing is now working against you. The faster you go, the less you bill. This episode is a conversation with Judith Bohlert — a freelance software engineer based in Germany, self-employed for 3 years, building greenfield MVPs and prototypes for early-stage startups — about how freelancing with AI tools affects the job, pricing, and the identity of an independent engineer. We get into the case for moving from time-seller to product engineer-consultant, why a productized service or a value-based offer is now the obvious response to AI freelancing economics, and why your personal brand — not your stack — is the only moat left when average code becomes a commodity. TIMESTAMP 0:00 — How AI changed a Monday morning for a freelance dev 4:15 — Tools that actually work: Claude Code, Cursor, GitHub Copilot 5:41 — Repricing your work: hourly vs fixed vs productized vs value-based 17:46 — Use AI to work less, not more: the case for the four-day week 22:04 — Personal brand as the only moat when code is a commodity 35:00 — The freelancer label is dying, the consultant role is rising 38:54 — Advice if you want to start freelancing now GUEST Judith Bohlert is a freelance software engineer based in Germany, with around 3 years of self-employment experience, focused on greenfield MVPs and prototypes for early-stage startups. She writes the low noise newsletter — a calmer take on working in tech, without hustle culture or the productivity-hack treadmill. Website:https://www.judithboehlert.com/ Newsletter (low noise newsletter):https://www.lownoiseclub.com/ LinkedIn:https://www.linkedin.com/in/jboehlert/ CONNECT WITH PRODUCT ENGINEERS Host: Peppe Silletti LinkedIn:https://www.linkedin.com/in/peppesilletti/ Peppe's website:https://peppesilletti.io Product Engineers Community:https://discord.gg/4sMtRNSgU4 Share this episode with a freelance developer friend who's billing hourly and starting to feel it. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit podcast.productengineers.com

If you’re a product engineer, engineering manager or PM, we all know how it goes: you go through tons of meetings every day, and only when they end is when real work starts. PRDs, tickets, specs, follow-ups — all the artefact work nobody sees you do. And by the time you’re done, the next meeting is already starting. One of today’s guests has a name for it: the infinite workday. And that’s exactly the problem today’s guests set out to fix. Mark Barbir and Sanden Gocka are the founders of Earmark — an AI meeting note taker that turns live conversations into shippable work in real time. We get into how they actually use it day to day, how it helps product teams, where the new bottleneck of product work has moved, and what it looks like when an idea you just said out loud turns into a working prototype before the call ends. If you’ve been hunting for AI tools for product managers that go beyond generic summaries, I’m walking you through them, and you can decide if it’s worth trying. GUESTS Mark Barbir and Sanden Gocka are the co-founders of Earmark. They previously worked together at Mindbody, a large enterprise SaaS company with a 400-person delivery organisation, and later crossed paths again at ProductPlan, where Sanden was an engineering manager and director. After years of watching product and engineering leaders drown in meetings and artefact work, they set out to build the tool they wished they had: an AI meeting assistant that generates the artefacts a conversation implies, in real time, while the meeting is still happening. Mark’s LinkedIn: https://www.linkedin.com/in/markbarbir/Sanden LinkedIn: https://www.linkedin.com/in/sandengocka Earmark: https://www.tryearmark.com TIMESTAMPS 00:00 The Invisible Second Shift: PM Meetings Problem 01:49 The Infinite Workday: Why PMs Work After Hours 07:49 Vision Pro Pivot: From Presentation Coach to Meeting AI 11:35 Why Vision Pro Failed (and What They Learned) 14:13 Engineering Translator Card: Understanding Technical Talk 16:00 Specs, PRDs & Code in Real-Time During Meetings 19:00 Make Me Look Smart: AI for Shy PMs 28:32 PMs Are Now The New Bottleneck 31:56 Dog Food Success: How Earmark Built Earmark 40:09 How to Get Started with Earmark REFERENCES Cursor: https://cursor.com Linear: https://linear.app MacWhisper — the local speech-to-text tool Sanden used in his early hacked workflow AssemblyAI (referenced in the co-marketing case study story): https://www.assemblyai.com CONNECT WITH PRODUCT ENGINEERS Host: Peppe Silletti LinkedIn: https://www.linkedin.com/in/peppesilletti/ Product Engineers: Website: https://productengineers.com Discord Channel: https://discord.gg/4sMtRNSgU4 Share this episode with a teammate who is still writing their PRDs at 10pm. This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit podcast.productengineers.com