The Product Engineering Podcast

James Charlesworth

0,0 (0)
Technologies
Chaque semaine

The Product Engineering Podcast explores how software teams can move beyond shipping features and start delivering measurable outcomes. Hosted by engineering leader James Charlesworth, each episode covers practical ideas for product engineering, engineering leadership, team operating models and building products that create real impact.

-5 j

Giving Product Engineers Autonomy In Decision Making

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 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.
8 sept.

Accountability For Product Engineering Teams

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

Outcome Driven Engineering Explained

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 episode What 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.
25 août

When Your Product Roadmap Works Against You

In this episode of The Product Engineering Podcast, James explores The Roadmap Shield — what happens when the mechanisms designed to protect an engineering team from disruption also prevent it from responding to new information. 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 buildCommitted estimates — the delivery forecast the team is expected to meetCommunicated timelines — dates that become promises to customers and stakeholdersDelivery pressure — the organisational and psychological pressure to complete what was promisedTogether, 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.
5 août

The Product Equivalent Of Technical Debt

Software teams are used to talking about technical debt, but products can accumulate another kind of debt too. 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 accumulatesThe similarities between outcome debt and technical debtWhy good product decisions can become outdatedHow changing customer behaviour creates outcome debtWhy measuring outcomes reveals problems that delivery metrics missThe role of sunk-cost thinking in product decisionsHow to reassess older features using current evidenceCombining product improvements with technical refactoringHow leaders can create space to address outcome debt without assigning blameWhy established products must continually revisit earlier decisionsOutcome 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.
29 juil.

Output Metrics vs Outcome Metrics

Engineering teams have access to more delivery data than ever. Jira can measure cycle time and velocity. GitHub can track pull requests and code changes. Deployment tools can show how often software reaches production and how reliably those releases perform. 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 metricsWhy delivery metrics are easier to measure and attributeWhen metrics such as cycle time, deployment frequency and story points are usefulWhy product engineering cannot be managed like a manufacturing lineHow feature factories emerge when teams are rewarded mainly for shippingThe growing importance of outcome accountability as AI makes implementation fasterWhy teams should decide how they will measure success before delivery beginsThe difference between leading and lagging indicatorsHow outcome measurements can guide iteration and product decisionsJames 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.
21 juil.

What Is Product Engineering?

What does product engineering actually mean, and how is it different from traditional software delivery? 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 meansRoadmap-driven engineering versus outcome-driven engineeringWhy engineers should help shape solutionsHow teams can test ideas before building for scaleWhy feature flags and limited releases matterWhere roadmap-driven engineering is still the right approachHow AI changes the economics of experimentationWhy delivering a feature is not the same as solving a problemThe central question is simple: after a team ships something significant, does anybody go back and find out whether it produced the intended result?

7 épisodes

The Product Engineering Podcast explores how software teams can move beyond shipping features and start delivering measurable outcomes. Hosted by engineering leader James Charlesworth, each episode covers practical ideas for product engineering, engineering leadership, team operating models and building products that create real impact.

Création

James Charlesworth
Années d’activité

2026
Épisodes

7
Classification

Tous publics
Copyright

© 2026 Train To Code
Site web de l’émission

The Product Engineering Podcast