In this episode of The Product Engineering Podcast, I'm joined by Richard Oliver Bray, Developer Experience Engineer at Firecrawl, to explore how AI is changing software development, what engineers need to learn, and where the technology might take us next.

We discuss whether traditional programming skills are becoming less important, the risks of shipping AI-generated code without understanding how it works, and whether AI could allow small engineering teams to tackle problems that previously required enormous R&D departments.

We also get into some more speculative territory. Could React be the last JavaScript framework? Will AI eventually bypass programming languages altogether? And could AI-generated games fundamentally change the gaming industry?

In this episode, we discuss:

• How AI is changing the role of software engineers.
• Whether learning to code still matters in an AI-first world.
• The challenges of maintaining and supporting AI-generated software.
• Why building a prototype is very different from shipping production software.
• Whether AI could make new programming languages and frameworks less likely to succeed.
• How AI could enable smaller teams to solve increasingly complex problems.
• The future of AI agents, recursive self-improvement and software development.
• What AI-generated games might mean for the future of gaming consoles.

Links mentioned:

• Richard Oliver Bray: https://robray.dev/
• Richard on LinkedIn: https://www.linkedin.com/in/richbray/
• Firecrawl: https://www.firecrawl.dev/
• Better Stack YouTube: https://www.youtube.com/@betterstack

The Product Engineering Podcast

Website: https://doproductengineering.com/

YouTube: https://www.youtube.com/@doproductengineering

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 outcomes
• How to develop a product mindset across engineering teams and business leadership
• Involving engineers in customer discovery and avoiding bias in customer research
• Building cross-functional teams without losing specialist engineering skills
• How AI is changing prototyping, engineering roles and team structures
• Why prototypes still need validation before they become production software
• Moving beyond traditional Agile ceremonies and story points
• Making product analytics accessible so engineers can see the impact of their work
• The future of product management, software engineering and Product Engineering

Whether 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 resources

• Anna Dick on LinkedIn: https://www.linkedin.com/in/anna-dick-b4bb434/
• Capsule CRM: https://capsulecrm.com/

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 all
• Why organisations should be designed around people's individual strengths rather than rigid job descriptions
• How engineers can participate directly in product discovery without becoming product managers
• The difference between understanding users and understanding the customers who actually pay for a product
• Why product management is as much about business strategy, pricing and commercial viability as it is about user experience
• Whether AI makes the idea of a one-person product engineering team realistic
• Using AI and personal knowledge management systems to capture context, accelerate thinking and improve writing
• Why storytelling is an essential skill for communicating customer problems to engineering teams
• The danger of using AI to turn feature requests directly into working software without understanding the underlying problem
• The trade-offs between generalist Product Engineers and deeply specialised engineering teams
• How different organisational structures, from functional organisations to cross-functional teams, can both be successful
• Why engineers should become more curious about customers, business models and the commercial outcomes their work supports

A 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 training
• Talking Roadmaps: Phil's podcast exploring product roadmaps and product leadership
• LinkedIn: Search for Phil Hornby

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 effectiveness
• Why engineering managers shouldn't act as gatekeepers between engineers and product
• How misunderstandings between product and engineering create unnecessary conflict
• Why engineers should spend time with sales, marketing and customer success to develop product understanding
• Celebrating product outcomes and learning rather than just technical excellence and delivery
• How AI coding tools are changing the skills engineers and engineering managers need
• Helping introverted engineers develop their communication and stakeholder management skills
• Using AI as a management assistant, sounding board and organisational tool
• The debate around AI-generated writing and preserving authenticity
• Why the human side of engineering management may become more important as AI takes on more technical work
• Supporting employees struggling with their mental health, and the importance of active listening

One 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.com
• Crying on the Sofa: https://www.cryingonthesofa.org

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.

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.

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 Description

How 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.

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 them
• The difference between Roadmap-Driven Engineering and Outcome-Driven Engineering accountability
• Why delivery metrics can be harmful when applied to outcome-driven work
• How technical initiatives such as improving API performance can require experimentation and learning
• A real-world example of one team simultaneously handling predictable document-generation work and uncertain product-adoption work
• Why accountability models should be attached to pieces of work, not teams
• Why an unsuccessful result should usually lead to learning and improvement rather than blame
• How regular, predictable reviews give teams clarity about what they will actually be judged on

The 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 james@doproductengineering.com.

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 episode

• What an outcome actually means in Product Engineering
• The difference between delivering a feature and delivering an outcome
• Examples including basket abandonment, product engagement and feature adoption
• Why Product Engineering is a cross-functional team model, not simply a job title
• How product managers and engineers retain different skills while sharing the same measure of success
• Why individual engineering metrics shouldn't replace team-level outcome accountability
• How an outcome-driven team moves from an outcome to measurement, experimentation and delivery
• Why you should decide how you'll measure success before you build
• Using prototypes and small interventions to test ideas quickly
• How learning can cause a team to refine, change or even abandon its original outcome
• Why shipping software is only part of the job — the real question is whether anything changed

The 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.

Product roadmaps provide valuable stability. They protect teams from scope creep, create predictable timelines and allow the wider organisation to coordinate around upcoming work. But as commitments build around a proposed solution, changing direction can become increasingly difficult — even when the evidence says you should.

James breaks the Roadmap Shield into four reinforcing layers:

• Committed scope — the agreed definition of what the team will build
• Committed estimates — the delivery forecast the team is expected to meet
• Communicated timelines — dates that become promises to customers and stakeholders
• Delivery pressure — the organisational and psychological pressure to complete what was promised

Together, these layers can subtly change the question from “Is this still the right thing to build?” to “Are we successfully delivering the thing we committed to?”

Using an example involving an AI integration and MCP, James shows how quickly a sensible technical decision can become outdated — and why teams often continue delivering the original solution anyway.

The answer isn't to abandon roadmaps. Instead, teams need explicit exit ramps that allow credible new information to challenge existing commitments.

That might mean working in smaller roadmap increments, identifying which deadlines genuinely cannot move, adding caveats to commitments where appropriate, and creating enough trust for a team to say: we've learned something important, so we're changing direction.

The goal is to find the balance between predictability and adaptability — protecting teams from noise without protecting their solutions from evidence.

Outcome debt builds up when features are shipped without confirming whether they achieved the result they were intended to produce. Over time, products become filled with decisions, assumptions and features that may once have made sense, but are no longer delivering enough value.

In this episode, James explains how outcome debt compares with technical debt, why it does not necessarily mean that anyone made a bad decision, and how changes in customer behaviour, technology and the wider market can cause previously successful features to lose their effectiveness.

The episode also explores how outcome measurement helps teams identify outcome debt, why sunk costs make weak features difficult to remove, and how teams can address technical debt and outcome debt together.

In this episode

• What outcome debt is and how it accumulates
• The similarities between outcome debt and technical debt
• Why good product decisions can become outdated
• How changing customer behaviour creates outcome debt
• Why measuring outcomes reveals problems that delivery metrics miss
• The role of sunk-cost thinking in product decisions
• How to reassess older features using current evidence
• Combining product improvements with technical refactoring
• How leaders can create space to address outcome debt without assigning blame
• Why established products must continually revisit earlier decisions

Outcome debt is not evidence that a team failed. It is a natural consequence of building products in a changing environment. The important question is whether teams regularly return to previous decisions, measure their continued impact and improve or remove the features that no longer serve the product.

The Product Engineering Podcast explores how software teams can move beyond shipping features and take greater responsibility for measurable product outcomes.

These metrics are useful, but they only tell us how efficiently a team produces software. They do not tell us whether that software made the product better.

In this episode of The Product Engineering Podcast, James explores the difference between output and outcome metrics, and why engineering leaders need both.

The episode begins with the McNamara fallacy: the tendency to focus on what is easy to measure while overlooking information that may be more important. Engineering organisations can fall into the same trap when they treat delivery activity as the primary measure of success.

James explains why output metrics work well for predictable work such as migrations and platform upgrades, where the intended destination is already understood. Product development is different. Teams are often working with uncertain assumptions about customers, behaviour and business impact. Efficient delivery cannot compensate for building the wrong thing.

The episode also covers:

• The difference between output and outcome metrics
• Why delivery metrics are easier to measure and attribute
• When metrics such as cycle time, deployment frequency and story points are useful
• Why product engineering cannot be managed like a manufacturing line
• How feature factories emerge when teams are rewarded mainly for shipping
• The growing importance of outcome accountability as AI makes implementation faster
• Why teams should decide how they will measure success before delivery begins
• The difference between leading and lagging indicators
• How outcome measurements can guide iteration and product decisions

James shares an example involving two engineering teams. One completed a predictable React migration, while the other delivered a navigation redesign that users disliked. Both teams delivered their planned work successfully, but only one produced the intended result.

The example demonstrates why delivery success and product success are not the same thing.

The question engineering teams should ultimately be able to answer is simple:

Did the product get better?

Learn more about The Product Engineering Podcast at doproductengineering.com.

In this first episode, James Charlesworth explores the shift from roadmap-driven engineering to an approach where engineers share responsibility for product outcomes, not just delivering requirements.

Using an example from an email marketing platform, the episode compares two ways of working. In a roadmap-driven model, product managers define a feature and engineers are responsible for building it predictably. In a product engineering model, the whole team starts with the outcome they want to create, explores different solutions and uses evidence to decide what to build next.

The episode also examines how product engineering changes the way teams think about prototypes, scalability, experimentation and technical quality. It explains why the first version of a feature does not always need to support the entire customer base, provided it is safe, measurable and capable of testing the underlying idea.

James also discusses how AI is accelerating this shift by making it cheaper and faster to turn an idea into something that can be tested with real users.

In this episode

• What product engineering means
• Roadmap-driven engineering versus outcome-driven engineering
• Why engineers should help shape solutions
• How teams can test ideas before building for scale
• Why feature flags and limited releases matter
• Where roadmap-driven engineering is still the right approach
• How AI changes the economics of experimentation
• Why delivering a feature is not the same as solving a problem

The central question is simple: after a team ships something significant, does anybody go back and find out whether it produced the intended result?