The Product Engineering Podcast

As AI changes the way we build software, the boundaries between product management and engineering are starting to blur. Engineers are taking on more product responsibilities, product managers are getting closer to the technology, and traditional roles are being challenged.So what does effective product leadership look like in this new world?In this episode of The Product Engineering Podcast, I'm joined by Charlotte Redding, a product leader at Pendo, to explore the evolving relationship between product management and software engineering.Charlotte shares her perspective on why the best product teams operate more like ecosystems than separate departments, how engineering teams can develop stronger product thinking, and why Walt Disney might just be the greatest product leader in history.We also discuss how AI is changing collaboration, whether the traditional Product Owner role has a future, and why engineers need to start thinking beyond shipping features and towards delivering business outcomes.In this episode, we discuss:Why product management and engineering need to work more closely together.Creating an environment where specialists can collaborate, experiment and challenge each other's thinking.What Walt Disney's Imagineering teams can teach us about product leadership.How AI is changing the boundaries between product and engineering.Why product management skills are more transferable than we might think.How engineers can develop better product taste and judgement.Getting engineers to take ownership of business outcomes, not just technical delivery.Why Charlotte believes the traditional Product Owner role could disappear.How product and engineering careers might evolve as AI becomes more capable.The importance of knowing when to step outside your specialism — and when to ask for help.Find out more:The Product Engineering Podcast: https://doproductengineering.com/If you enjoyed this conversation, subscribe to The Product Engineering Podcast for more discussions about building better software, developing product-minded engineers, and bringing product and engineering closer together.

How do you move engineering teams beyond delivering features and towards taking ownership of product outcomes?In this episode of The Product Engineering Podcast, I'm joined by Anna Dick, CTPO at Capsule, to discuss what it takes to build and lead effective product engineering teams.Anna shares how Capsule has evolved its approach to product development, breaking down silos between engineering, product and the wider business. We discuss the importance of getting engineers closer to customers, involving them earlier in discovery, and creating smaller, more autonomous teams that can take ownership of outcomes.We also explore how AI is changing the way teams work. As prototyping and writing code become faster, the real bottlenecks increasingly lie in decision-making, dependencies and ensuring that teams are building the right things in the first place.In this episode, we discuss:Moving from roadmap delivery to shared ownership of product outcomesHow to develop a product mindset across engineering teams and business leadershipInvolving engineers in customer discovery and avoiding bias in customer researchBuilding cross-functional teams without losing specialist engineering skillsHow AI is changing prototyping, engineering roles and team structuresWhy prototypes still need validation before they become production softwareMoving beyond traditional Agile ceremonies and story pointsMaking product analytics accessible so engineers can see the impact of their workThe future of product management, software engineering and Product EngineeringWhether you're an engineering leader looking to develop more product-focused teams or a software engineer wanting to move beyond writing code, this conversation offers practical insights into how Product Engineering works in a real organisation.Links and resourcesAnna Dick on LinkedIn: https://www.linkedin.com/in/anna-dick-b4bb434/Capsule CRM: https://capsulecrm.com/

Where should the line between product management and engineering sit? And in a world where AI is making it easier for anyone to build software, do we even need that boundary anymore?In this episode of The Product Engineering Podcast, James is joined by Phil Hornby, product leadership coach, founder of For Product People and host of the Talking Roadmaps podcast, to explore the increasingly blurred boundaries between product management and engineering.Drawing on Phil's experience across both engineering and product leadership, we discuss whether organisations should define responsibilities around job titles or build teams around the strengths of the people within them.We explore what it really means to be a Product Engineer, why engineers should get closer to customers and business decisions, and whether AI could eventually enable individuals to take on responsibilities that previously required entire cross-functional teams.We cover:Where the boundary between product management and engineering should sit, and whether we need one at allWhy organisations should be designed around people's individual strengths rather than rigid job descriptionsHow engineers can participate directly in product discovery without becoming product managersThe difference between understanding users and understanding the customers who actually pay for a productWhy product management is as much about business strategy, pricing and commercial viability as it is about user experienceWhether AI makes the idea of a one-person product engineering team realisticUsing AI and personal knowledge management systems to capture context, accelerate thinking and improve writingWhy storytelling is an essential skill for communicating customer problems to engineering teamsThe danger of using AI to turn feature requests directly into working software without understanding the underlying problemThe trade-offs between generalist Product Engineers and deeply specialised engineering teamsHow different organisational structures, from functional organisations to cross-functional teams, can both be successfulWhy engineers should become more curious about customers, business models and the commercial outcomes their work supportsA recurring theme is that high-performing teams aren't created by finding people who fit neatly into predefined roles. They're created by combining people with complementary strengths and giving them the freedom to contribute where they can add the most value.We finish with Phil's advice for engineers who want to become more product-focused: stop worrying so much about the terminology and start developing genuine curiosity about your customers, your users and your business.Find Phil:For Product People: Phil's product leadership coaching and trainingTalking Roadmaps: Phil's podcast exploring product roadmaps and product leadershipLinkedIn: Search for Phil Hornby

What does engineering management look like in a world where AI can write much of the code, and engineers are increasingly expected to think like product managers?In this episode of The Product Engineering Podcast, James is joined by Ryan Murphy, founder of EM Accelerator and Crying on the Sofa, to explore the changing role of engineering managers and what it means to lead an effective Product Engineering team.We discuss the relationship between engineering managers and product managers, why managers sometimes become unnecessary barriers between engineers and the wider business, and how to build teams that focus on outcomes rather than simply delivering features.We also explore how AI is changing engineering management, why communication and stakeholder management are becoming more important, and whether engineering managers will need to become more hands-on again.We cover:How the relationship between engineering managers and product managers affects team effectivenessWhy engineering managers shouldn't act as gatekeepers between engineers and productHow misunderstandings between product and engineering create unnecessary conflictWhy engineers should spend time with sales, marketing and customer success to develop product understandingCelebrating product outcomes and learning rather than just technical excellence and deliveryHow AI coding tools are changing the skills engineers and engineering managers needHelping introverted engineers develop their communication and stakeholder management skillsUsing AI as a management assistant, sounding board and organisational toolThe debate around AI-generated writing and preserving authenticityWhy the human side of engineering management may become more important as AI takes on more technical workSupporting employees struggling with their mental health, and the importance of active listeningOne of the central questions is whether AI will turn engineering managers back into hands-on developers, or whether the increasing importance of coaching, communication and team wellbeing will push the role further towards people leadership.We finish by discussing mental health in engineering, including Ryan's experience and his work with Crying on the Sofa, an initiative aiming to start one million conversations about mental health.Find Ryan:EM Accelerator: https://emaccelerator.comCrying on the Sofa: https://www.cryingonthesofa.org

AI can get you to something that looks finished remarkably quickly. But looking finished and being production-ready are not the same thing.In this episode of The Product Engineering Podcast, James explores the gap between an AI-built prototype and software that is actually ready to run reliably in production. A prototype might get you 80% of the visible result very quickly, while the remaining 20% — security, scalability, observability, maintainability and operational support — can require far more work than people realise. We cover: Why an impressive AI prototype isn't necessarily production-ready  The hidden engineering work users never see  Scalability, security, observability and maintainability  Why software needs to be designed for the right level of scale  The difference between code that demonstrates an idea and code you can support long term  Why prototypes are still incredibly valuable learning tools  When it's perfectly reasonable to build something you intend to throw away  The role engineers play when product managers prototype with AI  Why “production-ready” depends on the needs of your organisation  The danger of both under-engineering and over-engineering Why prototypes shouldn't be slowed down by unnecessary production requirements  Making the gap between prototype and production explicit A prototype doesn't need to answer every engineering question if its purpose is to answer a product question. If it helps you discover whether an idea is worth pursuing, it has already delivered value — even if none of its code eventually reaches production. The important distinction comes once you've decided to keep it. At that point, the team needs to understand exactly what still has to happen before the software can safely and sustainably become part of the product.

AI can write code incredibly quickly. But simply using AI to make your existing software delivery process faster misses much of the opportunity.In this episode of The Product Engineering Podcast, James looks at how AI changes Product Engineering when you treat it as a learning tool, rather than simply a faster way to turn requirements into production code. AI is excellent at implementing a well-defined plan, but human judgement is still needed to decide whether that plan represents the right thing to build. We cover: Why using AI to accelerate a legacy delivery model isn't enough  Where human product judgement still matters  Why AI changes the economics of experimentation  Moving engineers and product managers further upstream into product decisions  Using AI to explore several possible solutions rather than committing immediately to one  Creating prototypes and thin product slices that may never reach production  Why engineers can use AI to test ideas directly with users  How AI can compress the feedback loop between an idea and evidence  Why killing ideas quickly can be more valuable than shipping them quickly  Why discarded AI-generated code isn't necessarily waste  A useful diagnostic: how much of the code you're generating actually reaches production? Before AI, code was expensive enough that teams had strong incentives to decide what to build before implementation began. AI lowers that cost dramatically. That means teams can afford to build something partly to learn whether it should exist at all. The goal isn't simply to produce more code. It's to explore more possibilities, gather evidence faster and make better product decisions.

How do you give engineers the freedom to make product decisions without expecting them to become product managers? And how can product managers make technical decisions without needing to become engineers?In this episode of The Product Engineering Podcast, James explores how effective Product Engineering teams separate context from authority. The people with the most expertise shouldn’t necessarily make every decision. Instead, their job is often to transfer the context needed by the people who are actually accountable for the outcome. We cover: Why autonomy is essential if teams are going to be accountable for outcomes  The difference between asking for context and asking for approval Why relying on domain experts to make every decision creates bottlenecks  How engineers can be empowered to make product decisions  Why product managers sometimes need authority to make technical trade-offs  Using build-vs-buy decisions as an example of shared technical context  How micromanagement slows teams down and often produces worse results  The danger of the HIPPO — the Highest Paid Person’s Opinion  Why experts should educate teams without automatically taking authority away from them  Where autonomy needs clear guardrails, particularly around areas such as security  How faster decision-making creates faster experimentation, learning and iteration The central idea is simple: move context, not authority. Create mechanisms that allow expertise and organisational knowledge to flow towards the people making decisions, while keeping those decisions with the people who will ultimately be accountable for the result. Short YouTube DescriptionHow do you create autonomous Product Engineering teams without expecting everyone to become an expert in everything?In this episode, we look at why organisations should move context, not authority — giving teams access to the expertise they need while keeping decision-making with the people accountable for the outcome.We cover engineering vs product decisions, asking for context instead of approval, the dangers of HIPPO decision-making, and where teams still need clear guardrails.

How should we hold Product Engineering teams accountable when different kinds of work require completely different ways of working?In this episode, James explores why accountability needs to match the work being done, rather than being applied uniformly to an engineering team.For well-understood, roadmap-driven work, success might mean delivering an agreed scope by an agreed date. But when a team is working towards an outcome — improving adoption, reducing churn or increasing system performance — measuring them by features shipped or delivery velocity can actively work against the learning required to achieve that outcome.James covers:Why accountability is essential for both teams and the organisations investing in themThe difference between Roadmap-Driven Engineering and Outcome-Driven Engineering accountabilityWhy delivery metrics can be harmful when applied to outcome-driven workHow technical initiatives such as improving API performance can require experimentation and learningA real-world example of one team simultaneously handling predictable document-generation work and uncertain product-adoption workWhy accountability models should be attached to pieces of work, not teamsWhy an unsuccessful result should usually lead to learning and improvement rather than blameHow regular, predictable reviews give teams clarity about what they will actually be judged onThe central idea: you cannot ask a team to optimise for an outcome and then hold them accountable for output.Different work requires different definitions of success — and teams need to know those definitions before the work begins.Find out more about The Product Engineering Podcast at doproductengineering.com.Feedback or questions? Email [email protected].

What changes when you stop giving an engineering team features to deliver and instead give them an outcome to achieve?In this episode of The Product Engineering Podcast, James explores Outcome-Driven Engineering: an operating model where product managers and engineers share accountability for creating measurable product impact.Rather than starting with a predetermined solution, an outcome-driven team starts with the change it wants to see in customer behaviour or the product. The team then works together to understand the problem, decide how success will be measured, experiment with possible interventions and learn from the results.In this episodeWhat an outcome actually means in Product EngineeringThe difference between delivering a feature and delivering an outcomeExamples including basket abandonment, product engagement and feature adoptionWhy Product Engineering is a cross-functional team model, not simply a job titleHow product managers and engineers retain different skills while sharing the same measure of successWhy individual engineering metrics shouldn't replace team-level outcome accountabilityHow an outcome-driven team moves from an outcome to measurement, experimentation and deliveryWhy you should decide how you'll measure success before you buildUsing prototypes and small interventions to test ideas quicklyHow learning can cause a team to refine, change or even abandon its original outcomeWhy shipping software is only part of the job — the real question is whether anything changedThe central idea is simple: instead of asking a Product Engineering team “What did you ship?”, ask them “Did you drive the outcome?”Next episode: Accountability — how to create an accountability structure that matches the kind of work a Product Engineering team is doing.Find out more at doproductengineering.com.