Responsible AI is increasingly judged not by the policies an organisation has, but by the evidence it can produce. Here is the uncomfortable truth about responsible AI: most organisations no longer have a policy gap, they have an evidence gap.

In the UK public sector, guidance is no longer scarce. The AI Playbook asks teams to build in meaningful human control, test systems before deployment, monitor drift and hallucinations and keep assurance in place once systems are live. Central government teams using in-scope public-facing or decision-influencing algorithmic tools are expected to publish transparency records. HM Treasury has issued guidance on evaluating the impact of AI interventions. Government has also developed AI Management Essentials to help organisations assess their AI management processes.

The expectations are clear, responsible AI is no longer just a principle. But rather it is becoming something organisations are expected to evidence.

And yet a gap remains, the Public Accounts Committee has warned that transparency is still too slow, assurance of high-risk AI remains difficult to verify, learning from pilots is not being shared systematically and weak data foundations and legacy systems threaten adoption. The same pattern appears outside government, McKinsey and Deloitte both report the same gap: deployment is accelerating while governance maturity lags significantly behind. Only about a third of organisations show stronger controls and only around a fifth say they have mature governance for autonomous agents, even as close to three-quarters plan to deploy agentic AI within two years.

This is why AI evals matter. Not because they are fashionable but because evals are becoming the missing evidence layer in product governance.

What AI evals actually are

The simplest definition is this: AI evals are structured, repeatable ways of generating evidence about whether an AI system behaves acceptably for a specific purpose, risk profile and operating context.

That sounds technical, but it is really just good governance. Evals turn vague claims into evidence. Safe, accurate, fair, compliant, useful, reliable, trustworthy. These are words that are easy to write into a strategies, business cases or assurance documents but much harder to prove in the reality of a live service. Responsible AI cannot rely on intention alone, it has to be tested against behaviour.

This should feel familiar to product managers. Strong product teams are not there just to ship output, they exist to solve meaningful problems in ways that work for users, organisations and the wider system around them. Continuous discovery makes a similar argument in practical terms: teams reduce risk by testing assumptions early and often.

AI evals extend this discipline into AI governance. They ask: what assumptions are we making about this system and what evidence do we have that those assumptions remain true?

Approval is not assurance

Traditional assurance struggles with AI because AI systems are not just another form of software.

They can drift as data, prompts, models and usage patterns change. They are sensitive to wording and context and can hallucinate confidently. They also often depend on third-party models, suppliers and benchmarks whose quality may be uneven. And as systems become more agentic, they stop being tools that merely answer questions and start becoming systems that plan, call tools, trigger actions and operate across workflows.

Benchmarking has a role in understanding this, but it should not be mistaken for governance. A general benchmark might tell you something about a model’s broad capability. It cannot tell you whether a specific service is safe, useful, fair and reliable inside a particular operating context and benchmark quality varies significantly, including among those used by developers and policymakers.

This changes the governance question. As it is no longer enough to ask, “Was this system approved before release?” The better question is, “What evidence do we have that this system is still behaving acceptably now?” That shifts governance away from approval as a moment in time and towards assurance as an operating capability.

The types of evidence product teams need

A model can perform well in isolation and still fail inside a service, product teams need different kinds of evidence.

Behavioural evals ask how the system behaves across realistic scenarios, edge cases and user groups — testing for inconsistency, overconfidence, refusal patterns and failures under ambiguity. Users rarely arrive in neat test cases. They bring partial information, emotional stress, unusual circumstances and messy language.

Quality evals ask whether outputs are relevant, accurate, complete and reliable. For retrieval-based systems, this also means testing whether the system is drawing on the right source material and whether its answer is actually supported by it. A system that sounds plausible is not the same as a system that is reliable.

Safety evals test whether the system can be induced to produce harmful, insecure, misleading or deceptive outputs — through adversarial testing, red teaming, privacy testing and misuse scenarios. Safety cannot be reduced to whether the system behaves well under friendly use.

Policy evals ask whether the system operates within legal, ethical and organisational constraints: fairness, transparency, equality duties, data protection, explainability, human oversight and routes for challenge or correction. This is where AI governance often becomes too abstract, policy evals make it concrete.

Workflow evals test the end-to-end service — what happens before, during and after the AI interaction, how it routes users, when it escalates and whether decisions are recorded properly. Once systems can trigger actions across a process, the unit of evaluation has to be the workflow, not just the answer.

Outcome evals ask the question many governance discussions avoid: does this system actually improve the service in the real world? A system might improve speed but reduce trust, or help internal teams while making the public experience worse. Outcome evals force teams to ask whether the intervention has delivered meaningful value, not just technical performance.

Sustainability evals ask whether the environmental and financial costs of running the system are understood and deliberate, an estimate of what the AI will cost at scale, and an active decision about infrastructure and carbon impact. These questions are easy to defer. They are harder to retrofit once a system is in production.

Basic assurance asks whether the system passed its tests. Responsible product governance asks whether the service is still working for the people who depend on it.

What good looks like in the public sector

The UK already has useful examples of this more evidence-led approach.

GOV.UK Chat is one of the clearest. GDS has described how the service uses automated evaluation, structured manual evaluation, red teaming and live monitoring, assessing outputs against criteria such as groundedness, relevance, factual accuracy, completeness, reliability and reputational safety. Responsible governance is not a principle on a slide. It is a living system tied to explicit evaluation criteria and real user behaviour.

The Department for Transport’s Consultation Analysis Tool offers another useful model. DfT evaluated the tool against human reference datasets using both blind and non-blind designs, reported performance metrics and retained human review — because consultation analysis involves public views, policy sensitivity and judgement. This is a credible template for public-sector AI.

The Algorithmic Transparency Recording Standard points in the same direction. DVLA’s natural-language IVR record reports that the system handles around 900,000 customers a month and has reduced time spent navigating it by over 50%. HMRC’s digital assistant record explains how conversation data is reviewed to improve performance.

These systems are not governed responsibly simply because they sit in the public sector. They are governed responsibly only to the extent that they produce evidence, retain review routes and can be monitored and changed under control.

What this looks like in practice

Two examples from recent work show what applying this looks like, and what it produces.

The first came from using Claude to build an eval suite for Claude Code — Anthropic’s agentic coding tool. The starting point was this article: I gave it to Claude and asked it to derive evaluation criteria directly from the argument. If the piece claims responsible AI requires behavioural, quality, safety, policy, workflow and outcome evidence, those categories become the basis for what to test.

From there, Claude built a working test suite — sample tasks, scoring logic and a comparison tool that flags when performance drops — which I then ran.

The five questions are worth mapping against it. Evidence of intent was clearest: the test cases encode what good output looks like. Evidence of risk shaped how scoring was weighted, with automated checks supplemented by an AI judge for harder questions of quality. Evidence of behaviour came from running tasks at varying difficulty, including examples designed to fail. Evidence of oversight is built in through human-authored test cases and a tool that raises an alert when results regress.

Evidence of change over time remains the weakest link. The tooling supports switching models and comparing results over time, but whether it gets run consistently as things evolve is a governance question, not a technical one.

The second example came from an internal app. Running the eval at this stage was a deliberate test of the approach itself: the app was still a prototype, with no users, no real data and none of the underlying infrastructure built. We knew it would fail in several areas. The point was to see whether the eval could give us a useful overall picture quickly.

It did, in minutes.

The eval covered 13 areas including user value, output quality, harm and risk, accountability, data governance, failure handling, monitoring and sustainability. Each was scored 1 to 5, with five areas marked as critical — meaning they needed to score 4 or above before the app could move to a restricted pilot.

The overall average was 2.7, three critical areas failed:

• Data governance scored 2: no plan for keeping different clients’ data separate, no data retention policy, and no confirmation of how the AI provider handles data sent to it.

• Failure handling scored 2: no plan for what happens if the AI is unavailable, and no protection against users trying to manipulate the system through crafted inputs.

• Monitoring scored 1: no plan, no named owner, and no process for checking whether the system was still behaving well after changes.

The initial output was scores. When we asked what mitigations were needed and what they would look like as concrete deliverables, the eval produced a prioritised list of eight items. Some were build tasks: keeping each client’s data isolated, logging who generated what and when, protecting against attempts to extract information the user should not see. Others were decisions that had to be made before any code was written: confirm how the AI provider handles data, agree whether users would be told AI had been involved.

Sustainability, which was added as a 13th eval area after an earlier version of this article was written identified two further gaps: no estimate of what the AI would cost to run at scale, and no deliberate decision about infrastructure and its carbon impact. Neither would have come up in a standard technical review.

The learning from this example is specific: governance evals are most valuable before you build, not after. Running the eval at prototype stage meant the findings shaped the design. The oversight model, the audit log, the data separation and the protection against manipulation were all planned in from the start because the eval identified them as requirements before the build began.

The cost of running it at this stage was one conversation, the cost of discovering the same gaps after the system was built would have been significantly higher.

The lesson across both examples is the same. Evals work best when they are treated as a prompt for a governance conversation, not a gate to pass. The initial scores showed where to look, the follow-up turned that into work the team could actually act on.

Five questions leaders should ask

The future of responsible product governance is better discipline around evidence. Before signing off consequential AI systems, senior leaders and product teams should ask for five kinds:

• Evidence of intent: What is the system for, who is it for, and what must it not do?

• Evidence of risk: What harms matter most, who could be affected, and what level of failure is acceptable?

• Evidence of behaviour: How does the system perform across real tasks, edge cases, adversarial inputs and changing conditions?

• Evidence of oversight: How can humans review, challenge, override, correct and learn from the system?

• Evidence of change over time: How is the system monitored and re-evaluated as models, prompts, data, suppliers, policies and user behaviour change?

These are technical, product and governance questions and in the public sector, they are accountability questions.

From policy to operational evidence

The question is no longer whether an organisation has an AI policy. It is whether it can produce operational evidence that its systems still deserve to be trusted.

For product managers, evals belong in delivery. For leaders, they are board-level governance evidence. For public-sector organisations, transparency records, impact evaluation, human oversight and live monitoring are not separate workstreams. Together, they are what responsible product governance looks like when AI moves from pilot to infrastructure.

Responsible AI will not be proved by the existence of a policy. It will be proved by the evidence a service can produce when someone asks: how do you know this still works?

The problem with modern organisations is not a lack of metrics, it is that they use metrics as a substitute for accountability.

Dashboards proliferate and quarterly reviews get slicker. OKRs are cascaded and service standards are published. Transformation programmes come with benefits maps, KPI packs and performance frameworks, and everyone can point to a number.

And yet, when outcomes worsen, trust falls, users struggle, staff work around broken processes, or costs migrate somewhere less visible, it is often unclear who is meant to notice, who has the authority to act and which evidence actually counts.

That is what I mean by outcome theatre. It is what happens when an organisation can prove it is measuring performance, but cannot prove it is governing performance.

This isn’t an argument against metrics, these matter. Without them, product teams drift into opinion, anecdote and stakeholder preference. Measurement gives us a way to see patterns, challenge assumptions and understand whether change is making a difference.

But metrics only become useful when they are connected to judgement, ownership and consequence.

Consider that:

• A dashboard without decision rights is theatre.

• A target without context is theatre.

• A service metric without a service owner is theatre.

• A transformation benefit without a baseline is theatre.

An outcome that nobody is accountable for changing is not really an outcome, it is just a line in a slide deck.

The dashboard is not the service

The UK public sector offers a useful version of the problem because the formal accountability machinery is arguably strong.

Ministers are accountable to Parliament, accounting officers are accountable for value for money. Departments publish annual reports and major programmes are scrutinised. Performance frameworks exist, audit bodies report and committees challenge.

And still, operational accountability often breaks down much earlier.

The Public Accounts Committee has pointed to a lack of single service owners, weak end-to-end cost visibility, and insufficient service-level performance information across government. In 2023, only 10 of government’s Top 75 services were assessed as “great”, while 45 required significant improvement.

The larger point is not the score itself, it is what sat beneath it: weak end-to-end ownership, limited cost visibility and a lack of clear accountability for whole services.

That is the first uncomfortable truth. You can have metrics and still not have a governable service. Without an accountable owner for the whole journey, the dashboard becomes a collage of partial truths.

Digital teams report the front end, operations report throughput, finance reports cost, policy reports intent, suppliers report delivery, senior leaders report confidence and so on. But the user experiences the service as a single thing. The organisation experiences it as many things.

That is where the theatre begins. Each part of the system can look defensible from where it stands, while the overall service remains difficult, expensive, slow or unfair. Nobody is necessarily lying, as the problem is more subtle than that. The metrics are true within their own boundaries, but the boundaries are wrong.

HMRC and the problem with channel success

HMRC, the UK tax authority is one of the clearest recent examples.

On one reading, the story looks like digital progress. More people are using online tax accounts, apps and digital services. HMRC reported high satisfaction among users of its digital services. From a channel perspective, that sounds positive.

But from a service perspective, the picture is much less comfortable.

The National Audit Office reported that customers and agents spent the equivalent of 798 years waiting to speak to an HMRC adviser in 2022–23. In the first 11 months of 2023–24, HMRC answered just two-thirds of attempts to speak to an adviser, against a target of 85%. Those who got through waited nearly 23 minutes on average.

The NAO also found that HMRC’s digital services were better suited to straightforward issues, that 69% of people who used both phone and online channels had phoned because they could not resolve the issue online and that HMRC did not yet know enough about whether its digital services were actually meeting customers’ needs.

That is outcome theatre in miniature. The digital channel can improve while the service gets worse for people whose needs do not fit the digital path, i.e. a satisfaction score can look strong while unresolved demand builds elsewhere. A digital-first strategy can sound efficient while quietly increasing the burden on people with complex circumstances, low confidence, poor access or a need for human explanation.

The issue is not that digital is bad, they can be faster, cheaper and better. The issue is that channel metrics can conceal service failure when they are treated as the whole truth. A product manager should always be suspicious when a metric improves in one part of the system while complaints, repeat contact, manual workarounds or user confusion rise somewhere else.

That is usually not transformation, it is displacement.

Goodhart always turns up eventually

Goodhart’s law is commonly expressed as: when a measure becomes a target, it ceases to be a good measure. It remains one of the most important ideas in product governance, the moment a metric becomes tied to funding, status, reputation, bonus, promotion or political claim, people start optimising for the metric.

Sometimes that is useful as clear targets can focus attention. But the failure mode is obvious as people begin to improve the number without improving the reality beneath it. For example, a sprint velocity metric becomes pressure to ship more, not better. A retention metric becomes pressure to make cancellation harder, not the product more valuable and so on. In the end, the measure becomes the game.

Proxy error is the quiet failure

The most dangerous metrics are not always the obviously bad ones, instead they are the ones that are almost right. Completion rate is not useless, nor are others such as cost per transaction or revenue. But none of these are the outcome by themselves.

Completion rate does not tell you whether the user understood what they were doing, cost per transaction does not tell you whether cost has been pushed into another channel and revenue does not tell you whether value was created responsibly, sustainably or fairly.

This is proxy error: the organisation mistakes a signal for the thing itself and it happens because proxies are convenient. They are standardised and they are easy to collect. They fit in a dashboard and can be compared across teams. They are legible to senior stakeholders.

Real outcomes are messier and require interpretation. They cross organisational boundaries, show up in complaints, operational workarounds, staff judgement, user research, unequal impacts, demand patterns and long-term consequences. They rarely fit neatly into a single number.

The Department for Business and Trade’s own evaluation and performance analysis strategy makes this point clearly. It says that as digital teams move beyond replacing administrative tasks into delivering public services digitally, they need to understand social impact. Standard GDS indicators such as completion rate and cost per transaction are useful, but not sufficient.

That matters because it comes from inside the public-sector measurement system itself. The problem is not measurement, but is mistaking service indicators for the whole account of public value.

Weak organisations prefer proxy certainty to outcome ambiguity. They feels safer and look more professional and can create the appearance of control. But product work lives in the gap between what is easy to measure and what actually matters.

Metrics and power

Metrics are not neutral as they decide what gets seen, what gets ignored and who gets believed. A dashboard is a political object, even when it looks technical, it can reflect choices about what counts as success, whose experience is represented, which costs are visible and which trade-offs can remain hidden.

This matters because dashboards often move upwards more easily than context does.

Senior leaders see red, amber and green, boards see trend lines, programme teams see delivery confidence and so on. But the people closest to the work often see something else. They see the manual workaround, users who cannot complete the journey, cases reopened after being marked resolved.

And such, outcome theatre thrives when the official metric is allowed to overrule lived operational evidence. This is where psychological safety and product governance meet. If teams cannot challenge the metric, the metric becomes a form of control. It stops being a tool for learning and becomes a tool for compliance.

The question is not just “what are we measuring?” but also “who is allowed to say the measure is wrong?”

The AI amplification problem

AI will make this problem worse unless organisations are careful, because it makes measurement cheaper, faster and more abundant.

AI can generate summaries, classify feedback, produce sentiment analysis, create dashboards, detect trends, score interactions and automate reporting. Used well, that could help organisations see more. Used badly, it will help them produce more convincing theatre.

More metrics do not automatically create more accountability. In fact, the opposite can happen. The organisation can become flooded with things that resemble evidence but don’t carry real accountability. A product team can already drown in metrics and without care, AI makes it easier to drown elegantly.

The future problem may not be a lack of data, it may be too much weak evidence, produced too quickly, interpreted too confidently and connected too loosely to real decisions.

That is why the discipline around metrics needs to improve now; AI does not remove the need for ownership, baselines, challenge, context and consequence. It just makes them more important.

What product managers should do

Product managers cannot fix organisational accountability alone, but they can refuse to participate in outcome theatre. This starts with treating metrics as hypotheses, not facts.

A metric says: we believe this signal tells us something important about value, quality, risk or progress. That belief should be tested.

A product manager should ask:

• What outcome is this metric meant to represent?

• What behaviour will it create if people are rewarded for improving it?

• How could this number improve while the real outcome gets worse?

• Who is missing from the measurement?

• What cost might be shifted elsewhere?

• What would contradict the dashboard?

• What decision will change if this metric moves?

• Who has the authority to act?

The last two questions matter most, as if no decision changes, the metric is decorative and if nobody has authority to act, the metric is performative.

The counter-example matters

The strongest evidence against outcome theatre is not a better dashboard, it is better management. The National Audit Office described a DWP Scotland case where leaders shifted from holding people to account for individual task output towards supporting them to achieve outcomes for customers and making the workplace better.

Staff engagement increased by 5% in the second year of the new engagement approach and by a further 4% in the third. Over the same two-year period, customers not attending appointments decreased from 23.5% to 13.7%, failure to attend work search reviews decreased from 18.6% to 11.8%, and overall customer satisfaction increased by 8%.

This example matters because it stops this argument becoming anti-management or anti-measurement. The message is not “stop measuring people.”, but “measure in a way that makes better judgement harder to avoid.”

The shift is not just from one metric to another, it is from task control to outcome ownership. From compliance to engagement, from local output pressure to service improvement. That is the difference between measurement and accountability.

A better model: accountable evidence

The better approach is not fewer metrics, but better connected evidence.

Good product governance should have five things:

• Ownership: Someone has to own the whole product or service, not just a channel, component or delivery plan.

• A baseline: Teams need to know what they are comparing against. Better than what? Better for whom? Better over what period?

• A balanced measure set: Every efficiency metric should be paired with quality, trust and equity measures. If speed improves but quality falls or digital take-up rises while vulnerable users lose access then that is not a clean success.

• Shadow metrics: These are measures that help detect gaming and hidden harm but are not tied directly to reward. e.g. repeat contact, complaint, reopened cases, etc. These often tell you what the official dashboard cannot.

• Consequence: There must be an agreed point at which the evidence triggers a decision.

Without consequence, measurement is observation, with it: measurement becomes governance.

The real test

Every organisation says it cares about outcomes, they use statements like: Outcome-led, evidence-based, user-centred. But the real test is not whether an organisation uses outcome language. The real test is what happens when the outcome evidence is inconvenient.

• Does the roadmap change?

• Does funding move?

• Does the dashboard get corrected?

• Does anyone with authority make a different decision?

If not, the organisation may have metrics, but it does not have accountability. This is the danger of outcome theatre. It lets organisations look mature while avoiding the harder work of ownership, judgement and consequence.

The point of metrics is not to make performance visible, but to make better decisions unavoidable.

Everyone says they want evidence-led prioritisation until the evidence asks them to change something they have already committed to. That is where the comfortable version of product management starts to break down.

On paper, prioritisation should be straightforward. Understand the user need, look at the evidence, consider value, risk, effort, confidence, urgency and strategic fit, then compare the options and make the best decision available.

In practice, it is rarely that simple.

Teams can produce user research, service data, operational insight, cost analysis, risk assessments and discovery findings. They can make a reasonable case, show where the current plan is weak and identify where work could reduce risk or improve outcomes.

And still, the roadmap barely moves.

The evidence is acknowledged, but not acted on. It becomes “useful context”, gets added to the appendix, or is parked for a later phase.

Better evidence does not automatically lead to better priorities.

Not necessarily because people dislike evidence, or because the organisation is irrational. Often, it is because the decision environment is not set up to respond to the evidence being presented.

That distinction matters.

Evidence-led prioritisation is not just about producing better evidence. It is about understanding whether the organisation can change course when the evidence suggests it should.

The myth of rational prioritisation

A lot of product practice carries an implicit assumption that if the evidence is good enough, the right priority will become obvious.

That is the logic behind many prioritisation frameworks: score the options, rank the backlog, compare value against effort, make confidence visible and create a more structured conversation.

These tools are useful. They help teams move beyond opinion, expose trade-offs and reduce the chance of everything being decided by whoever speaks loudest or holds the most senior title. But they can also make prioritisation look simpler than it is.

Prioritisation is not just a sorting exercise. It is a decision made inside an organisation, shaped by timing, funding, governance, reputation, accountability, delivery pressure, legal constraints, supplier arrangements, senior commitments and inherited plans.

A backlog does not exist outside the system that funds it, governs it and judges it.

This is why evidence-led prioritisation struggles when it is treated as a purely analytical problem. The product team may be asking: “What does the evidence show?”

The organisation may be asking: “What can we safely change, delay or admit without creating wider consequences?”

These are not the same questions.

Why evidence does not always move the roadmap

When evidence fails to change priorities, it is easy to assume the organisation does not care about evidence. Sometimes that may be true. But often, evidence is resisted because it threatens something the organisation is trying to protect.

It may challenge a senior commitment, weaken confidence in a preferred solution or show that delivery started before enough was understood. It may suggest that the most valuable work is not the most visible work.

It may also arrive too late. By the time evidence is presented, the real prioritisation may already have happened through funding decisions, delivery plans, supplier commitments, governance papers, policy commitments or public promises.

The roadmap may appear open, but the wider system may already have narrowed the room for manoeuvre.

This is particularly visible in public sector digital delivery, where priorities are shaped by policy commitments, spending controls, legal duties, assurance, governance and reputational risk. The private sector has its own version of this pattern, shaped by commercial targets, investor expectations, sales commitments and quarterly revenue pressure.

The point is not that evidence is irrelevant. The point is that evidence rarely enters a neutral space.

Insight is not the same as decision evidence

One common mistake is assuming that insight automatically creates movement.

A research finding can be valid. A data pattern can be clear. A discovery recommendation can be well supported. But if the evidence is not connected to a decision the organisation can actually make, it often remains interesting rather than influential.

This is the difference between insight-shaped evidence and decision-shaped evidence.

Insight-shaped evidence shows what has been learned. Decision-shaped evidence shows what the learning changes.

That distinction matters because organisations rarely change direction simply because new information exists. They change direction when the implications are clear, material and actionable enough to affect a decision.

So evidence should not only show that users are struggling with a journey, that a feature has limited demand or that uncertainty exists. It should make the consequence clear: continuing with a known failure point, delaying work with stronger evidence, or committing further investment before a key assumption has been tested.

In environments that resist evidence, describing reality is not enough. Evidence has to clarify the consequence of continuing as planned.

That does not mean being dramatic or adversarial. It means making the trade-off visible, so the organisation cannot treat the evidence as useful background while carrying on as before.

Evidence does not remove organisational reality

A more mature view of prioritisation recognises that evidence does not remove politics from decision-making.

Prioritisation is political in the broadest sense because it allocates attention, money, people, time and legitimacy. Every priority creates a deprioritisation somewhere else. Every roadmap protects some interests and disappoints others.

Evidence can improve this process, but it does not make it neutral.

We talk about “letting the data decide” as if data has authority on its own. It does not. People decide, governance decides, budgets decide. Evidence only matters if there is a route for it to affect those decisions.

If nobody has permission to change the plan, more evidence will not solve the problem. If the funding model rewards new delivery but not maintenance, evidence about operational waste or resilience will struggle to land. If a roadmap has become a reassurance mechanism, evidence that introduces uncertainty may be treated as a problem rather than a contribution.

Evidence-led prioritisation therefore requires organisational literacy. Product managers need to understand not only what the evidence says, but what kind of system the evidence is entering.

When evidence is welcomed but cannot alter direction, sequence, scope or investment, it starts to become performative: product theatre with better artefacts.

Prioritisation as risk reduction

In these environments, it can be more useful to frame prioritisation less as value ranking and more as risk reduction.

The question is not only what is most valuable to build. It is what uncertainty needs to be reduced before the organisation commits further. This changes the conversation.

Discovery becomes a way of protecting decision quality, not just an upfront phase. Alpha work becomes a structured attempt to test assumptions before locking into scale. Operational improvement becomes a way of reducing failure demand, cost and friction, not just tidying up the edges.

This matters because evidence does not always need to justify a complete change in direction. Sometimes its job is to stop the organisation committing too early, too heavily or too confidently to something it does not yet understand.

That is often where evidence-led prioritisation becomes most useful: not as a way to produce the perfect ranked list, but as a way to sequence work so the organisation avoids expensive mistakes.

Small moves are still moves

In environments that resist evidence, the choice is not always between full reprioritisation and failure. Sometimes the work is to create enough movement for the evidence to stay alive.

An organisation may not accept a major change in direction, but it may accept a time-boxed experiment, a staged investment decision or further validation before scaling.

This is not about settling for tokenism. It is about understanding the amount of change the system can currently tolerate, then using that movement to create better evidence, stronger confidence and a more defensible next decision.

A useful product stance is not simply: “The evidence says no.” It is more often: “The evidence suggests we should not fully commit yet. Here is the smallest responsible step that reduces uncertainty, protects delivery and gives us a better decision point.”

In complex systems, changing direction safely can be more important than pushing for a complete reversal.

The real test

Weak evidence-led prioritisation says: “Here is the evidence, therefore this should be the priority.”

Stronger evidence-led prioritisation says: “Here is what the evidence changes, what remains uncertain, what is at risk, and what the lowest-risk next decision should be.”

The first assumes the organisation is ready to act rationally. The second recognises that organisations often need help to change their mind safely.

The real test is not whether a team can produce a prioritised backlog, apply a framework, conduct research, review analytics or score options.

The real test is whether evidence has permission to affect the plan.

That does not mean changing direction constantly, treating every new insight as disruption, or ignoring strategy, governance and commitments. It means being honest about whether priorities can change when the evidence says they should.

Because if priorities are fixed regardless of what is learned, the organisation is not prioritising. It is sequencing pre-agreed commitments.

And if evidence is only welcome when it confirms the existing direction, it is not evidence-led. It is evidence-decorated.

The best product teams do not simply bring more data into resistant environments. They understand why the resistance exists and they shape evidence around decisions, expose trade-offs, reduce uncertainty and create safer routes for change.

They do not pretend that evidence removes organisational reality. They use it to improve the quality of decisions made within it. That is the harder and more useful version of evidence-led prioritisation.

Not a clean framework, ranked list or ritual of confidence. But the disciplined, often uncomfortable act of helping organisations make better choices when their own systems make those choices difficult.

Large-scale transformation programmes are often described as technology challenges, funding challenges or delivery challenges. Increasingly, they are becoming something else entirely: stability challenges.

Modern governments want long-term transformation delivered inside increasingly short-term political environments.

• Ministers change.

• Priorities shift.

• Electroral pressure arrives early.

• Public expectations move rapidly.

• Leadership speculation begins before major programmes have had time to mature.

The technology may remain consistent for years, the political logic surrounding it may change every few months.

This creates a growing mismatch between the lifespan of transformation programmes and the lifespan of political stability.

Most meaningful transformation is inherently multi-year. Modernising healthcare systems, replacing legacy infrastructure, introducing AI safely into public services, reforming planning systems or building interoperable platforms across government all require sustained organisational alignment over long periods of time.

These are not six-month initiatives. Many require years of operational learning, procurement alignment, institutional adaptation and incremental delivery before outcomes become fully visible.

Meanwhile, political systems increasingly operate at a very different speed.

Continuous campaigning, fragmented voter coalitions, short media cycles, economic pressure and declining public trust all compress the amount of time governments feel they have to demonstrate visible progress.

Transformation may require ten years, whilst political patience may now last less than two.

Cognitive instability

One of the least discussed challenges in large-scale delivery is that programmes are rarely judged under the same political conditions in which they were created.

A transformation initiative may begin during a period of optimism and reform, only to mature during a period dominated by scrutiny, financial pressure, electoral anxiety, or institutional defensiveness.

The programme itself may not fundamentally change, but the logic through which it is evaluated does.

Transformation programmes increasingly operate within conditions of cognitive instability: environments where the criteria used to define success shift faster than the systems themselves.

This echoes the work of Karl Weick, who observed that organisations continuously reinterpret reality through changing narratives and sense-making processes. In transformation programmes, the surrounding political narrative often changes before delivery outcomes become visible.

A useful way to think about this is through the lens of Edward de Bono’s Six Thinking Hats framework. Not as a workshop exercise, but as a way of understanding how political systems change the evaluative model surrounding delivery. A programme launched under one political “hat” may eventually find itself judged under another.

An ambitious reform programme created during a period of Yellow Hat optimism may initially be celebrated for ambition, experimentation and pace. Delivery teams are encouraged to move quickly, demonstrate innovation and signal transformation.

But if political pressure increases before outcomes emerge, the environment often shifts.

The same programme may later encounter Black Hat conditions dominated by scrutiny, caution, affordability concerns and institutional risk management. Governance expands, decision-making slows and political tolerance for uncertainty collapses.

What was previously framed as ambition may now be reframed as recklessness. The programme has not necessarily changed, the surrounding political cognition has.

This is particularly visible in large public-sector digital programmes where optimism around innovation often collides later with demands for assurance, cost control and demonstrable public value.

The same pattern appears elsewhere. Platforms justified through White Hat logic: efficiency, productivity, measurable operational improvement, may later encounter Red Hat criticism driven by public frustration, emotional dissatisfaction or political symbolism.

A service may technically perform better while simultaneously being perceived as failing. Likewise, decentralised Green Hat reform agendas often recentralise once pressure intensifies. Periods of experimentation and distributed decision-making give way to stronger governance, central control and operational standardisation.

Again, the underlying transformation may remain broadly consistent. But the model through which success is judged changes around it.

In stable environments, programmes may operate under one dominant political logic for years. In volatile environments, the governing “hat” can rotate every few months.

The shrinking window for transformation

This creates another problem. Foundational work is politically difficult because its benefits are delayed, but its disruption is immediate.

The deepest layers of transformation are often the least visible: architecture redesign, migration work, interoperability, governance restructuring, procurement reform, technical debt reduction and operational integration.

These activities are frequently essential to future outcomes while producing very little short-term political reward. The visible costs, however, appear immediately.

Budgets increase before efficiencies emerge. Delivery friction becomes visible before operational improvements materialise. Migration pain arrives long before stability does. This creates enormous pressure for governments to prioritise visible outputs over long-term systemic health.

The result is what might be described as perpetual transformation instability: an environment where programmes continuously restart, reposition, restructure and redefine success before underlying systems have had time to mature.

From the outside, this can look like delivery failure. In reality, it may reflect a deeper systems problem. The surrounding political environment changes faster than the transformation itself.

When leadership itself becomes uncertain, delivery organisations begin adapting long before formal policy changes occur.

Roadmaps quietly shift, governance expands, risk tolerance contracts. Visible wins become prioritised over foundational investment. Teams begin optimising for political survivability rather than long-term systemic optimisation.

Modern political systems increasingly expect startup-speed transformation built on top of decades-old institutional infrastructure while simultaneously operating inside compressed political cycles. That combination creates a uniquely difficult delivery environment.

Transformation as a continuity problem

Historically, transformation failure was often framed as a delivery problem. Increasingly, it may be more accurate to frame it as a continuity problem.

Digital transformation depends upon conditions that modern political environments struggle to sustain: long-term architectural consistency, institutional memory, operational alignment and tolerance for delayed outcomes.

As Peter Senge observed, complex systems separate cause and effect through both time and structure. The deepest benefits of transformation often emerge long after the most politically difficult work has taken place.

But political systems increasingly reward immediacy.

Visible outputs are prioritised over foundational change. Short-term coherence overrides long-term adaptability. Programmes are expected to maintain strategic consistency inside environments that no longer remain stable themselves.

The danger is not simply failed transformation, it is perpetual transformation instability: programmes continuously restarting, restructuring and redefining success before underlying systems have had time to mature.

The challenge is no longer simply building systems that scale, it is building systems capable of surviving cognitive instability long enough for their value to emerge.

Complex systems rarely fail because change takes too long, they fail because the surrounding environment changes how success is defined before the work is complete.

The problem we think we have

The public sector doesn’t have a talent problem, it has an incentive problem.

That’s not a criticism of the people working in it. If anything, it’s the opposite. Across government and public services, I’ve consistently seen capable product managers, thoughtful engineers and committed delivery teams — people who understand what good looks like.

And yet delivery still feels slow, decisions still take too long and teams still struggle to make meaningful progress.

So the question isn’t why people aren’t good enough. It’s why capable people consistently produce constrained outcomes.

The problem we actually have

When delivery struggles, the explanations are familiar. We talk about capability, leadership and the need to adopt better practice. These are comforting answers because they suggest the problem can be solved by improving people.

But they miss something more fundamental: the environment those people are operating in.

In complex organisations, behaviour is shaped less by intent and more by incentives. Not just financial incentives, but the broader system of funding cycles, governance structures, accountability models and risk exposure. These define what is safe to do, what is rewarded, and what is quietly avoided.

Over time they shape how teams behave.

This is a systems problem. Outcomes are not just shaped by individual decisions, but by the structure those decisions sit within.

Why risk aversion is rational

“Risk aversion” is often framed as a cultural issue in the public sector. In practice, it is usually a rational response to the system.

If decisions are highly scrutinised, failure is visible and success is rarely attributed, then the safest path is not to make bold product decisions. It is to avoid decisions that could go wrong.

That doesn’t mean people don’t want to do better work, it means the system doesn’t consistently support it.

How the system shapes delivery

Once you start looking through this lens, familiar patterns become easier to explain. Roadmaps are driven by funding cycles rather than user need. Delivery is shaped by governance gates rather than learning loops. Teams optimise for approval rather than outcomes.

None of this requires bad intent, it is what happens when the system rewards compliance more than effectiveness.

Why best practice struggles to land

This is also why so many well intentioned improvements struggle to take hold.

Product practices such as outcome-based thinking, product operating models and continuous discovery are designed to improve how teams work. But when success is still measured through milestones, reporting and approvals, those practices tend to become overlays rather than drivers of behaviour.

Similarly, approaches that rely on learning and iteration assume space to adapt. Where scope is fixed upfront and funding is tied to delivery commitments, that space becomes limited.

Concepts like incremental delivery are intended to reduce risk. In high-scrutiny environments, even small changes can feel disproportionately risky. The result is often a preference for larger, more certain deliveries, even when they carry greater long-term risk.

These ideas are not new. What is less understood is how difficult they are to apply in constrained environments.

What can actually be done

Understanding the system doesn’t automatically give you the ability to change it and most product managers don’t have the authority to redesign the incentives they’re operating within.

But that doesn’t mean you’re powerless. The most useful shift I’ve seen is simply making the incentives visible. Teams often feel the constraints they are under, but rarely articulate them. In practice, this means being explicit about what is actually driving decisions, i.e. what is being rewarded, what is being avoided and where the real risk sits.

When those dynamics are surfaced, conversations change. The focus moves away from whether the team is “doing the right thing” and towards what the system is encouraging them to do.

The second shift is learning to work with constraints rather than around them. In most public sector environments, governance, funding and approval processes are not going away. Trying to bypass them usually creates more friction, not less.

What tends to work better is shaping work to fit within those constraints while still moving things forward. That might mean breaking work into smaller, lower-risk increments that can pass through existing approval structures, or reframing decisions in terms that align with how the organisation already measures success.

This is less about applying best practice perfectly and more about adapting it so it can survive in the system it sits within.

And perhaps most importantly, it requires recognising the limits of your influence. You can improve how your team works. You can create space for better decisions. You can shift how conversations happen.

But you are unlikely to change funding cycles or governance models on your own.

The goal is not to fix the system in one move. It is to create small shifts in how it behaves, which over time can lead to more meaningful change.

The constraint we need to engage with

Public sector delivery does not struggle because people lack capability. It struggles because the system they are operating in does not consistently support good outcomes.

Until incentives change, behaviour will not change.

And that leaves product managers with a different challenge than the one they are often given.

Not just to deliver better outcomes but to understand the system they are operating in and find ways to make it work differently.

A well-written PRD can be completely wrong and still move a team forward. It can define a clear problem, a plausible user, coherent success metrics and a structured solution. It can pass review, align stakeholders and create momentum. And yet, it can still fail to improve anything that matters.

This is not because the document is poorly written, it is because it is convincing enough.

The clarity it presents can justify action even when the underlying understanding is incomplete, that is where the risk sits.

The PRD was never the decision

At their best, PRDs were not intended to be deliverables. They were thinking tools, ways of forcing articulation of the problem, the value and the trade-offs involved. The document itself mattered far less than the decisions required to produce it.

A more accurate framing is that a PRD should clarify or record decisions, not replace the discovery and judgement needed to make them.

A good PRD reflects decisions that have already been made, often through challenge, disagreement and iteration, rather than acting as a substitute for that process. The issue is not the existence of the document, but the role it begins to play.

In some organisations, the PRD becomes the centre of gravity, with conversations orbiting the document rather than the problem it is meant to represent. Clarity becomes something that is presented, rather than something that has been earned through understanding.

When clarity becomes theatre

A structured PRD creates a powerful sense of confidence. It suggests that the problem is understood, that the solution is appropriate, that the risks are known and that the path forward is coherent. The structure itself implies rigour, which makes the document persuasive.

However, none of these things are guaranteed. A document can be internally consistent and still be fundamentally wrong. It can describe the wrong problem with precision, define success using metrics that do not matter, or outline a solution that ignores the system it sits within. Because it is well written, it often becomes harder to challenge rather than easier.

This is where clarity becomes theatre. Not because anyone is intentionally misleading, but because the document performs the role of understanding. It creates a shared sense that the work has been thought through, even when important uncertainties remain unresolved. Karl Weick’s work helps explain why this is so effective: organisations rely on coherent narratives to coordinate action, even when those narratives are incomplete.

In complex delivery environments, this pattern becomes visible. I have seen this in public sector work, where a problem is documented cleanly with agreed success metrics and a clear solution path, while the real drivers sit outside the document in policy constraints, operational pressures and organisational risk tolerance. The PRD is coherent, but the system it describes is not. The result is predictable: the solution addresses what is written down, rather than what is actually happening.

This is what product theatre can look like. The artefact appears complete, the logic is sound and the presentation is convincing, but the underlying understanding remains partial and fragile.

Static documents in dynamic systems

PRDs capture a moment in time. They represent a snapshot of what is believed to be true about a problem, a solution and a path forward. At the point of writing, that snapshot can feel accurate and aligned.

However, product environments are not static. Assumptions change, constraints shift and new information emerges as teams learn more about users, systems and outcomes. In many teams, the PRD does not evolve at the same pace as the team’s understanding. Sometimes it becomes a historical artefact that is still referenced despite no longer reflecting reality. More often, it is updated just enough to remain credible, without reopening the decisions it was built on.

This creates divergence. The document reflects past thinking, while the team operates on current understanding. The gap between the two is rarely explicit, but it is where misalignment begins. This is not simply a process issue; it reflects a deeper mismatch between static artefacts and dynamic environments. Henry Mintzberg argued that strategy often emerges through action rather than being fully defined upfront, and product work behaves in much the same way. A document that assumes completeness at the start will always struggle to accommodate learning as it unfolds.

What AI risks doing

AI does not just make PRDs easier to write, it changes what they signal. For a long time, a clear and well-structured PRD implied that decisions had been made through analysis, discussion and trade-offs. That implication is now weaker.

AI tools are highly effective at producing structured, coherent documents. They can generate plausible problem statements, user needs that appear credible and well-formed success metrics. What they cannot do is determine whether any of these are grounded in reality. The risk is not poor quality, but unearned credibility.

This matters because it changes how PRDs are interpreted. A polished document used to suggest that someone had done the work required to reach that level of clarity. Now, that same level of clarity can be produced with far less underlying effort. This does not make the document wrong, but it does make it harder to read.

Herbert Simon’s idea of bounded rationality is useful here. People already make decisions with simplified models of reality due to limited information and cognitive constraints. AI does not remove this limitation, it can reinforce it by making those simplified models appear more complete than they actually are.

The implication is practical, PRDs can no longer be read as reliable signals of rigour. They need to be treated as hypotheses about reality, rather than representations of it. This shifts how they should be challenged. Instead of asking whether the document is clear, teams need to ask what evidence supports the problem, what assumptions are being made, what constraints are being excluded and what would change their mind. The document itself cannot answer these questions, but it can obscure the need to ask them.

A well-written PRD is now a much weaker signal than it once was. It tells us less than it used to about whether sound decisions have been made.

What this means

The PRD is not the decision. A clear document is not evidence of a good decision, it is evidence that something has been articulated well. This distinction matters more as the cost of producing clarity continues to fall.

The implication is not that PRDs are useless, but that their role is often misunderstood. The value of product management lies less in producing structured artefacts and more in making decisions under uncertainty, understanding systems rather than isolated features, navigating competing incentives and defining value rather than simply describing it. These activities are harder to document and far harder to replicate or generate convincingly.

Take home

PRDs persist because they are organisationally useful. They create a sense of control, provide something tangible to review, and support governance. But that usefulness comes with risk. When the document becomes the signal, it becomes easier to believe that clarity exists when it does not. And now that clarity can be generated quickly and convincingly, that illusion is stronger than ever.

A well-written PRD is now a much weaker signal than it once was.

The question is no longer whether it is clear.

It is whether it is true.

The framing problem we keep ignoring

Sustainability has a positioning problem, not a science problem, tooling or even a capability problem. A framing problem.

Say “sustainability” in most organisations and you trigger a predictable set of reactions: cost, compliance, trade-offs, slower delivery, “nice to have.” It gets mentally filed somewhere between the CSR report and next year’s strategy offsite.

Now replace the word.

Say “we need to become more efficient” and the reaction flips: cost reduction, performance improvement, competitive advantage, faster delivery, immediate action.

Same underlying behaviours, completely different response. That’s not semantics, its incentive alignment.

Sustainability doesn’t fail because it’s wrong. It fails because it’s mis-sold.

Most sustainability efforts are positioned as: do this because it’s good for the planet.

Which is true, but in most delivery environments, that’s not how decisions get made. Decisions are shaped by cost pressure, delivery timelines, risk and measurable outcomes. So sustainability gets treated as an additional constraint rather than a better way of operating.

Efficiency doesn’t have this problem. It’s already embedded in lean, Six Sigma, cost optimisation, performance engineering and product thinking. Nobody questions whether reducing waste is valuable, nobody challenges improving resource use.

Here’s the shift that matters:

Most sustainability practices are just efficiency practices viewed through a wider lens.

The examples are everywhere:

• Reducing compute usage lowers cost and carbon.

• Eliminating rework speeds delivery and reduces waste.

• Extending device lifespan cuts spend and emissions.

• Removing unnecessary features improves UX and reduces processing overhead.

This isn’t theoretical, for example:

• Google reduced data centre energy consumption by focusing on efficiency, using AI to cut cooling energy by around 40%, with carbon reduction following as a consequence rather than the goal.

• Cloud platforms like Amazon Web Services achieve lower emissions per workload not by leading with sustainability, but by maximising infrastructure utilisation and efficiency at scale.

You don’t need a new discipline, you need a different entry point.

The uncomfortable truth

Sustainability on its own often loses, efficiency almost always wins. Not because organisations don’t care, but because efficiency fits the system they operate in. Sustainability often doesn’t. So when you lead with sustainability, you create friction. When you lead with efficiency, you create momentum.

There’s a temptation to read this as reframing or manipulation, it isn’t. It’s recognising that organisations optimise for what they measure, language shapes what gets prioritised and incentives determine what actually happens.

If your goal is real-world impact, not just intent. Then you have to work with the system, not against it. That’s not greenwashing, that’s systems thinking.

What this means in practice

If you’re trying to embed sustainability into delivery, stop leading with it.

Reframe sustainability decisions as efficiency gains. Not “reduce environmental impact” but “reduce waste in the system.” The goal is the same, but the reception is different.

Quantify in business terms first. Cost per transaction, processing time, infrastructure usage, rework rates. Carbon becomes a secondary validation, not the primary pitch. Lead with the number that gets attention, then connect it to the broader outcome.

Design for less, not more. A lot of product work still operates on the assumption that more features equal more value, they often don’t. Less is frequently faster, cheaper, cleaner and better and this is where sustainability and product excellence align most naturally.

Challenge whether the work should exist at all. The most sustainable and most efficient outcome is often not doing the work. Unnecessary services, duplicated journeys, over-engineered solutions. This is where real impact sits and where most organisations struggle to go.

The shift

The goal isn’t to stop talking about sustainability, it’s to earn the right to talk about it by first delivering efficiency.

Once teams see the cost savings, the performance gains, the delivery improvements, then

sustainability stops being a constraint and becomes something credible, tangible and scalable. It earns a seat at the table rather than being invited to stand in the corridor.

One-line takeaway

If you want organisations to act sustainably, don’t ask them to be sustainable. Ask them to be efficient.

Final thought

Sustainability isn’t actually a dirty word, but in many organisations it behaves like one. Efficiency doesn’t. If both roads lead to the same destination, the only question worth asking is: which one actually gets travelled?

The shift we’re missing

AI isn’t replacing product managers, it’s exposing them.

The dominant narrative is that AI will automate large parts of the role. Such as writing requirements, summarising research and proposing solutions. In many ways, that’s already happening. But the more important shift isn’t about what AI can do. It’s about what it reveals when those things are no longer where the value sits.

The illusion of control

Product management has always occupied an ambiguous space between ownership and coordination. We talk about outcomes but measure output. We talk about responsibility but distribute it across teams, processes and artefacts.

In practice, it has been possible to appear effective, maintaining a well-structured backlog, facilitating delivery, keeping stakeholders aligned, etc. Without ever being fully accountable for what happens once the work is released into the world.

In more complex settings, particularly the public sector, this pattern becomes pronounced. I’ve worked in programmes producing vast amounts of documentation, detailed, carefully structured, well-intentioned, that in practice said very little. Quickly outdated, rarely revisited, loosely connected to the decisions being made day to day. The system keeps moving, but responsibility stays diffuse.

When the work becomes trivial

AI doesn’t disrupt product management by replacing it. It disrupts it by making much of it trivial.

When requirements, summaries and solution options can be generated instantly, the activities that once signalled “Product Management” lose their weight. They become easier, faster and ultimately less valuable.

The role no longer centres on producing clarity. It centres on deciding what that clarity should lead to.

As Gibson Biddle has described, the leverage in product work comes from a small number of high-quality decisions. When the number of possible options expands, as AI ensures it will, then the quality of those decisions becomes the only differentiator.

From translation to judgement

Much of product work has historically been translation: taking inputs from users, stakeholders, policy and technology and turning them into something a team can act on. That required effort, e.g. synthesis, structure, clarity. It was the visible centre of the role.

AI compresses that effort. Translation becomes quicker, lighter, more accessible. And as a result, the centre of gravity shifts away from producing representations of work and towards something less tangible but more consequential: deciding between possibilities.

In environments where decision-making is already constrained, where governance is layered and authority is distributed, this shift becomes even more visible. The challenge is no longer producing the right artefacts. It’s creating the conditions where meaningful decisions can actually be made. That is not something AI can solve.

Systems, not stories

Answering those decisions well requires a perspective that extends beyond individual features or user stories. Product decisions exist within systems, combinations of user behaviour, technical constraints, organisational incentives and external forces like policy and regulation.

These systems are dynamic. Outcomes emerge from their interactions, not from any single action.

Donella Meadows made this point clearly: interventions in a system cannot be understood in isolation. A change in one part creates effects elsewhere, often in ways that aren’t immediately visible. The artefact may be correct, but the system response is not.

Where AI stops

AI can help explore these systems. It can surface patterns, generate hypotheses, propose interventions.

But it doesn’t exist within the system the way a product team does. It doesn’t experience constraints directly, or bear the consequences of decisions as they unfold. It doesn’t navigate bureaucratic structures or work in the space between policy and delivery, where decisions are shaped as much by context as by logic. It doesn’t sit in a room where authority is limited and influence has to be built over time.

It produces outputs that are plausible and often useful. But it carries no responsibility for what happens when those outputs are acted upon.

What remains

As the activities that once defined the role become easier to automate, what remains is the moment a decision is made and the responsibility for that decision becomes real.

This is less visible than a roadmap or a set of requirements. But it is where the actual impact of product management lives.

In practice, it means working within constraints that cannot be removed, only navigated. Making decisions with incomplete authority and still being accountable for outcomes. Recognising that the system you operate within shapes what’s possible, without letting that become an excuse to abdicate responsibility.

What this means in practice

• The artefacts no longer carry the weight. If AI reduces the cost of producing them, product management cannot continue to define itself by them. A clear requirement or a well-structured backlog will no longer be enough to signal value.

• The problem matters more than the solution. When multiple solutions can be generated quickly, the real leverage is in identifying the right problem. A poorly framed problem just means faster production of the wrong outcomes.

• Trade-offs become unavoidable. More options don’t remove constraints, they sharpen them. Decisions between speed and sustainability, short-term delivery and long-term system health, become more explicit and harder to defer.

• Systems thinking becomes essential. Without understanding how decisions interact with organisational, technical and policy constraints, even well-reasoned choices produce unintended consequences.

• Accountability becomes visible. As artefacts become easier to produce, they can no longer absorb responsibility. The link between decision and outcome becomes harder to distance yourself from.

The uncomfortable truth

Part of what AI is revealing is that some elements of product management have been more performative than we might like to admit. Well-structured artefacts can give the impression of clarity. Well-run processes can give the impression of progress. Even when the underlying decisions haven’t been resolved. AI removes some of that cover.

The question that matters

The future of product management isn’t defined by how well we use AI tools. It’s defined by how clearly we understand the part of the role that can’t be delegated.

It’s a shift away from production and towards accountability, from describing work to taking responsibility for its consequences. The question is no longer how to incorporate AI into product management. It’s what we are prepared to be responsible for when the tools can do much of the rest.

Subscribe now

Product management is often described as the intersection of business, technology and user need. The familiar Venn diagram is neat, reassuring and misleading.

It implies boundaries.

In practice, product management has no clean edges. It is not a discipline that simply sits between others. It is a synthesis discipline, one that borrows, adapts and recombines expertise from across an organisation. That is also why product management cannot be separated from strategy. Strategy is not something product merely executes, it is something product continually shapes through choices made under constraint.

Marty Cagan and SVPG position empowered product teams as accountable for outcomes, for ensuring what is built is valuable and viable, not merely delivered. That framing places product squarely inside strategy, not downstream of it.

And yet, as organisations mature, a subtle fragmentation tends to emerge. Discovery becomes something research does. Requirements become something business analysis does. Sustainability becomes something a specialist network does. Delivery becomes something programme management does. Strategy becomes something leadership workshops produce.

Product risks narrowing into coordination.

The synthesis problem in practice

This tension becomes especially visible in public sector transformation.

In one programme, we began discovery with almost no validated evidence base. There was a strong assumption that digitisation would generate cost savings, but limited data to support it. The task was not to prioritise features, it was to interrogate an economic hypothesis without bias.

That work required economic reasoning about marginal cost and long-term savings, business analysis to map current-state processes and regulatory dependencies, systems thinking to anticipate knock-on effects across the wider ecosystem and political literacy to understand institutional incentives.

Kanban boards and collaborative tools helped structure the work, but the real challenge was integration. Had we treated economics as “finance’s job”, modelling as “analysis’ job” and strategy as “policy’s job”, product would have reduced itself to delivery administration. Instead, it operated in the uncomfortable space of synthesis, i.e. validating or invalidating cost assumptions and enabling better strategic decisions.

The same pattern surfaces in central government digital identity work. On the surface, transaction monitoring and fraud detection look like technical challenges. But deeper questions quickly emerge: what false positive rate is acceptable in a public identity system? How much friction can users tolerate? How do you balance fraud prevention with accessibility and trust?

These are statistical, ethical and strategic questions that are intertwined. Data science alone cannot resolve them. Nor can policy alone. Product decisions must integrate risk appetite, user impact, operational feasibility and public accountability simultaneously.

Even in retail environments, the dynamic holds. Revenue optimisation intersects with behavioural psychology, operational constraints and brand positioning. A change that improves short-term conversion but increases returns, customer service costs or erodes trust is not a strategic win. Product choices become strategy expressed in increments.

Strategy is not handed down - it is refined through learning

Melissa Perri’s framing of product strategy as an evolving system of aligned outcomes is instructive. Strategy is not a static directive, it is refined through learning. Roadmaps composed of outcomes and hypotheses rather than feature lists are strategic instruments. In practice, especially where evidence is initially weak, product-level learning can materially reshape what is considered viable or desirable at portfolio level.

Business analysis sits directly within this synthesis too. The International Institute of Business Analysis defines it as enabling change by defining needs and recommending solutions that deliver value. In both regulatory and service-delivery contexts, modelling current-state processes, identifying constraints and exposing hidden assumptions were not adjacent to product work, they were integral to it. If product abdicates that literacy entirely, it loses the ability to interrogate scope and value effectively.

The danger of clean separation

The risk of separating disciplines too neatly is local optimisation.

Delivery optimises for throughput. Data optimises for rigour. Policy optimises for compliance. Sustainability optimises for carbon reduction. Commercial teams optimise for revenue. Each is rational within its own boundary. Systemic optimisation rarely happens without integration across those boundaries.

Product management, at its best, is that integrative function. Recognising this does not mean inflating the role. It does not mean claiming to be an economist, a data scientist or a policy expert. It means accepting that product judgement depends on borrowed literacies: enough economic fluency to question cost assumptions, enough analytical rigour to model change, enough strategic awareness to understand organisational incentives and enough systems thinking to anticipate second-order effects.

Product cannot be cleanly extracted from strategy, because strategy is expressed through product decisions. Nor can it be cleanly extracted from business analysis, because defining needs and navigating constraints are not optional extras, they are core to determining what is worth building.

The more we attempt to separate product from the disciplines it synthesises, the more we hollow it out into process.

The work is not to draw sharper boundaries. It is to recognise that product management is inherently multidisciplinary and that its value lies precisely in the integrative space between expertise.

Digital carries a dangerous illusion. We talk about “the cloud”, frictionless services, instant AI, seamless transformation. The language implies immateriality. But the Government Digital Sustainability Alliance summit made one thing unmistakably clear to me: digital has weight.

It has carbon.
It has water use.
It has supply chains.
It has social consequences.

And it sits squarely inside the climate and nature crisis.

The 4% that is already outdated

The summit opened with a familiar statistic: ICT accounts for roughly 4 percent of global greenhouse gas emissions. That estimate originates from lifecycle analyses by researchers such as Malmodin and Lundén and was widely cited around 2018–2019, including by The Shift Project. Later in the day, Mike Berners-Lee presented a breakdown from that period showing:

• User devices ~37 per cent

• Televisions and consumer electronics ~34 per cent

• Networks ~14 per cent

• Data centres ~10 per cent

• Cryptocurrencies ~5 per cent

Two things matter here:

1. This was a pre-AI estimate. It largely excluded the explosion of generative AI, and much of IoT. In other words, the baseline is already dated.

2. The dominant impact is not simply hyperscale data centres. It is billions of manufactured devices. Peer-reviewed work by Belkhir and Elmeligi demonstrates that for many digital products, the majority of emissions occur during manufacturing rather than use.

Digital is not clean. It is embodied.

Circularity is structural, not cosmetic

The Minister for Nature and Circular Economy referenced replacing devices based on performance rather than arbitrary time cycles.

It sounds operational. It is systemic.

Circular economy research from the Ellen MacArthur Foundation shows that extending product life materially reduces embodied carbon and raw material extraction. Servers and digital hardware contain more than twenty critical raw materials, many with low recycling rates according to European Commission data.

If manufacturing dominates impact, extending lifespan is one of the most powerful levers available. Design decisions lock in emissions long before reporting frameworks ever see them.

Are we digitising demand or just digitising?

One tension that surfaced repeatedly was uncomfortable but necessary. Government sometimes digitises services or processes without asking a more fundamental question. Should this service exist in this way at all?

And more fundamentally:

• Does it have real users?

• Is there genuine demand?

• Or are we digitising because digitisation itself is assumed to be progress?

Digital government scholarship has warned for years about “paving the cow paths”, i.e. automating inefficient systems rather than redesigning them. Scaling a weak service digitally does not create value, it scales waste.

With the Carbon Budget and Growth Delivery Plan now formalised, digital can no longer be neutral to delivery. If a service has low uptake, unclear demand or marginal value, digitising it faster does not make it sustainable.

This was not explicitly framed this way by every speaker, but it was my clear takeaway from the discussions.

AI: between productivity and paradox

AI was a theme almost through every panel. There were examples of structured governance. Defra’s 25 internal questions before deploying AI. DWP’s experimentation with sustainable prompting, consciously reducing token use and computational demand.

Research supports this caution. Studies by Patterson et al. and Luccioni et al. show that training and inference energy demand can vary dramatically by model scale and architecture, larger models consume substantially more energy.

Mike Berners-Lee then introduced a slide that, crystallised the risk. Four potential trajectories for ICT. One quadrant was circled: Efficiency gains leading to rising overall impact.

This is Jevons paradox, first described in 1865. When efficiency improves, cost falls. When cost falls, usage increases. Overall consumption rises. Berners-Lee argued that, as a society, we have defaulted to that route.

We have defaulted to Jevons paradox.

The better route, the one he implicitly advocated is absolute reduction through sufficiency and constraint. Efficiency combined with limits. Efficiency combined with demand management. Efficiency combined with systemic restraint.

In other words: using ICT to reduce total energy and material throughput, not simply to expand digital activity more cheaply.

At present, we are not on that route.

Beyond carbon

One of the strongest sessions of the day challenged the reduction of sustainability to carbon alone. Carbon accounting is essential, but it is incomplete.

The planetary boundaries framework developed by Rockström and colleagues identifies nine Earth system processes, several of which are already beyond safe limits. Freshwater depletion, biodiversity loss and chemical pollution are not captured by CO₂ metrics.

Lifecycle assessment standards exist precisely because upstream mining and downstream disposal matter. Servers require rare materials. Data centres consume water. E-waste is one of the fastest-growing waste streams globally.

Reducing sustainability to carbon simplifies measurement. But it does not reflect planetary reality.

Social value and material reality

Around 1.6 million people in the UK remain completely offline, according to Good Things Foundation and Ofcom. Digital exclusion is not a marginal issue, it is structural. Citizens Advice research shows that households without reliable digital access often pay more for utilities, insurance and financial services because they cannot access online tariffs or comparison markets.

At the same time, millions of usable devices sit dormant in homes and corporate estates. Refurbishment charities demonstrate a simple but powerful truth: circular economy and social value are not competing agendas. Extending device life can reduce embodied carbon while narrowing the digital divide.

Yet the material reality remains uncomfortable. A smartphone’s components may travel tens of thousands of miles before assembly. Downstream, waste and recycling sectors account for a disproportionate share of modern slavery prosecutions. Digital infrastructure carries social risk at both ends of its lifecycle.

Embedding social value into procurement from the outset, as required under the UK Social Value Model is not compliance theatre. It is one of the few structural levers government holds to influence supply chains, reduce inequality and shape environmental outcomes simultaneously.

Thirty COP conferences later

Berners-Lee displayed a slide tracing 30 COP conferences.

Decades of negotiation. Emissions still rising. Political economy research has documented fossil fuel lobbying’s influence on climate negotiations. The gap between ambition and delivery remains wide.

He framed the climate and nature crisis as a national security issue. Increasingly, defence institutions agree. The ICT footprint slide, highlighting approximately 2 billion tonnes CO₂e in 2020 was a reminder that digital is already material at planetary scale.

And that was before AI scaled.

Secure by design. Green by design.

A resilience session focused on oversized estates, blanket disaster recovery requirements and legacy systems embedded within critical infrastructure.

“Secure by design” is well understood in cyber security. There was a proposal to mirror it with green by design. This could involve:

• Embedding environmental thinking at architecture stage.

• Including climate risk in risk registers.

• Mapping dependencies across regulators and infrastructure.

The Credo project was referenced as an example of attempting to understand systemic digital dependencies across government.

My overall reflection

The summit did not introduce radically new science.

The evidence has existed for decades:

• Jevons paradox

• Rebound effect literature

• Planetary boundaries

• Lifecycle assessment standards

• Circular economy research

• Digital exclusion data

What felt different was alignment. Public sector digital leaders are beginning to speak explicitly in the language of limits, lifecycle and systems.

The illusion of digital weightlessness is fading. The real question is not whether digital can become more efficient. It is whether we are willing to combine efficiency with sufficiency.

Because without constraint, efficiency expands impact. And right now, if Berners-Lee is correct and the evidence suggests he may be, we have defaulted to the wrong quadrant. The opportunity is still there, but only if we choose a different route.

Subscribe now

If you believe public sector product management is slow because people do not care about outcomes, you have misunderstood the system.

And if you believe private sector product management is inherently more rigorous because it chases revenue, you have misunderstood that system too.

The difference between public and private product management is not capability, it is incentives.

Product management is shaped less by stand-ups and roadmaps and more by what the organisation is optimised for. Change the accountability structure, the funding model or the consequences of failure and the behaviour shifts too. The underlying craft remains largely the same, e.g. problem framing, prioritisation, stakeholder alignment, evidence-led decision making. What changes is what the system rewards and what it punishes.

In commercial environments, success is comparatively legible. Such a revenue, margin, growth, retention. Even when teams speak in terms of customer value, a financial signal sits somewhere beneath it.

In public services, value is rarely reducible to revenue. Success may mean reducing processing times for statutory applications, improving access for vulnerable users, increasing regulatory compliance or delivering a ministerial commitment without legal challenge. The causal chain between product change and measurable impact is often longer, more politically exposed and more complex to quantify.

Marty Cagan argues that strong product organisations focus on outcomes rather than outputs. That principle applies equally in government. The difference is that outcomes are frequently social or policy-driven, rather than commercial. They are harder to measure and slower to validate, but no less important.

The misconception that public sector teams are indifferent to outcomes misunderstands the nature of public value. The challenge is rarely intent, it is measurability within constraint.

Risk and accountability

Risk tolerance is another structural difference. In private organisations, experimentation is often tolerated or encouraged where there is potential upside.

In public delivery, failure carries additional aspects, such as audit scrutiny, media coverage, parliamentary oversight and legal challenge. Experimentation is possible but must coexist with transparency and legitimacy.

Melissa Perri writes about the importance of aligning product strategy with organisational context. In government, that context includes democratic accountability. Speed is valuable, but it cannot override fairness, compliance or value for money.

From the outside, that can look like slowness. In reality, it is constraint management.

Funding and planning

Funding models reinforce differences. Commercial organisations can often reallocate capital dynamically and investment follows performance.

However public sector funding typically operates within annual or multi-year cycles governed by spending reviews and procurement regulation. Supplier relationships are formalised through contract frameworks and budgets are fixed.

This can reduce agility, but it also introduces stability. Core public services do not disappear because they underperform one quarter, they continue because they are socially necessary.

A public sector product manager therefore spends more time navigating commercial governance and procurement constraints. It is not administrative overhead but rather part of the system within which delivery must operate.

Stakeholders and authority

Stakeholder complexity exists in both sectors but authority is structured differently.

In private organisations, stakeholders may include executives, sales, marketing and customers. In public delivery, the map can extend to ministers, policy teams, operational agencies, regulators, legal advisers and citizens. Each carries a distinct mandate.

Ken Norton once described the product manager as a “CEO of the product” without formal authority. In government contexts, that informal leadership must operate across political and operational domains simultaneously. Communication becomes translation, e.g. between policy intent and delivery feasibility, between user need and ministerial briefing.

The complexity is not necessarily greater, it is configured differently.

Pace and legitimacy

Private sector organisations are structurally incentivised to move quickly and market competition creates urgency. Public institutions are structurally incentivised to justify decisions and withstand scrutiny and process exists to protect fairness and public trust.

Speed without legitimacy erodes confidence in public services. Legitimacy without pace erodes service quality. Navigating that tension defines much of public sector product leadership.

Shreyas Doshi often emphasises understanding incentives before judging behaviour. Many perceived inefficiencies are rational responses to systemic constraints. A procurement checkpoint may slow iteration, but it exists to protect value for money. An assurance review may feel heavy, but it exists to protect trust.

What remains constant

Despite these structural differences, the fundamentals remain. Clear problem framing, disciplined prioritisation, user insight, stakeholder alignment and delivery coordination are required in both environments.

Strong product managers understand the system they operate within. They recognise what is rewarded, what is penalised and where risk accumulates and adapt practice accordingly.

Public and private sector product management are not opposites. They are variants operating under different conditions. The craft is shared, but the constraints are not.

Why should PMs care?

Economically: wasted clicks, retries, heavy pages, unnecessary “real-time”, and data hoarding inflate cloud spend, supplier cost, support demand, and operational risk (UK Government, 2025).

Environmentally: the same waste consumes energy through compute, storage, and data transfer. UK government guidance now explicitly expects teams to minimise environmental impact and design services to reduce impacts across their lifecycle (UK Government, 2019; UK Government, 2025).

Below are ten steps you can take this month. Each one is PM-owned and easy to translate into backlog language.

The 10 steps

1) Add a “non-build” option to every decision

Do: ask if the need can be met via content, policy, process, reuse or removal.
Why: not building avoids ongoing run cost and footprint.

Line to use: “What is the lowest-impact way to meet this need?”

2) Make “real-time” an explicit requirement (not a default)

Do: set refresh rates and background job frequency as a product decision.
Why: constant polling and always-on processing silently drives cost and emissions.

Acceptance criteria: “No polling more than every 15 minutes unless user-critical.”

3) Put a page-weight budget on your top journeys

Do: pick your 3 highest-traffic pages and set a max transfer size.
Why: lighter pages reduce data transfer, improve performance and cut retries.

Acceptance criteria: “Top journey pages stay under X MB on first load.”

4) Design out retries and “check status” behaviour

Do: add clear status, timestamps, reference numbers, and “what happens next”.
Measures: duplicate submissions; repeat visits; contact rate per 1,000 users.

5) Default to “smaller” unless the user truly needs bigger

Do: compress images, cap uploads, offer high-res as an option.
Why: smaller payloads reduce bandwidth, storage, failures and cost.

Acceptance criteria: “Uploads are compressed by default; max size X unless exempt.”

6) Make data minimisation a product rule

Do: only collect fields and analytics events you can link to decisions.
Why: every extra datum adds long-term storage, backup, security and retention overhead.

Line to use: “If we will not use it, we will not collect it.”

7) Make retention a product decision (not a technical default)

Do: define retention for logs, uploads, exports, and audit data.
Why: “keep forever” becomes permanent spend and permanent risk.

Acceptance criteria: “Logs retained X days; exports deleted after X days; uploads archived or deleted after X months.”

8) Treat third-party scripts as a costed choice

Do: require a value case and a review date for any new third party.
Why: third parties often add weight, requests, privacy/security overhead, and hidden costs.

Acceptance criteria: “No new third-party scripts without documented user value and a removal plan.”

9) Reuse first, build second

Do: add a “reuse check” in refinement: existing components, patterns, platforms, shared services.
Why: reuse reduces duplicated systems and duplicated run cost.

10) Pick two measures and report them every fortnight

Do: choose two “waste signals” you can keep up forever.
Why: what you measure is what survives delivery pressure and government guidance explicitly expects teams to measure and reduce impacts (UK Government, 2025).

Good starters:

• page weight on top journeys

• duplicate submissions / repeat contacts

• polling frequency on key endpoints

• storage growth and retention compliance

The 10-minute habit that makes it stick

At the end of refinement, ask:

1. What demand does this create? (and how do we prevent repeats?)

2. What data does this create? (and how long do we keep it?)

3. How often will this run? (and can it run less?)

References

• UK Government (2019) Government Design Principles. Available at: GOV.UK. https://www.gov.uk/guidance/government-design-principles

• UK Government (2025) Environmentally sustainable services. Available at: GOV.UK Service Manual. https://www.gov.uk/service-manual/design/environmentally-sustainable-services

Public sector Product Management is not simply evolving by choice. The changes in 2026 are the result of accumulated pressure: financial constraint, operational risk, public scrutiny, technological acceleration and regulatory response. Due to demand, the role is shifting from digital delivery towards to strategic stewardship.

This article sets out what is changing in public-sector product management and why these changes are happening now.

From “digital transformation” to service stewardship: why the focus has shifted

Over the past decade, much of government’s digital effort was spent proving that digital delivery could work at all. By the mid-2020s that argument has largely been won and the challenge has moved on. Three forces explain this shift:

1. Legacy risk has become unavoidable
   The National Audit Office (NAO) reporting over several years has shown that ageing systems are no longer just inefficient, but are operationally dangerous: vulnerable to cyber-attack, difficult to change and costly to run. Temporary fixes and front-end digitisation have deferred rather than removed these risks.

2. Services need to operate continuously under pressure
   Public services are facing higher demand, fewer staff and tighter budgets. That makes service reliability, integration and operability more important than launching new functionality.

3. Central standards have matured
   The Government Service Standard and Service Manual increasingly emphasise solving whole problems, measuring performance and operating services over time. This pushes accountability away from projects and towards long-lived services.

These factors explain why product management in 2026 is less about delivery phases and more about owning outcomes over time.

Why AI has moved from experimentation to governed use

The explosion of generative AI in 2023–24 created a wave of experimentation across the Public Sector. By 2026, that phase is necessarily ending. The reasons are structural:

• Risk and scale
  Early pilots demonstrated that AI can deliver value, but also that errors, bias or misuse can scale quickly in public services. This has triggered a shift from “try it and see” to formal governance.

• Regulatory and central guidance response
  UK government guidance such as the Generative AI Framework and AI Playbook explicitly frames AI as a capability that must be deployed with controls, transparency and assurance. This reflects both legal risk and reputational risk.

• Operational reality
  The most credible use cases are not headline-grabbing automation, but quieter augmentation of staff work: summarisation, drafting, triage and search. These require close integration into services, not isolated tools.

As a result, AI has become a wider ‘product concern’ in 2026 not due to fashion or trend, but because it is now too consequential to sit outside product accountability.

Why trust, security and privacy have become product outcomes

Security and privacy have always mattered in government, but they are now shaping product work more directly. This is happening because:

• The attack opportunities have expanded
  More digital services, more APIs and more data sharing mean more points of failure and legacy systems exacerbate this risk.

• Cyber incidents now have wider visible service impact
  Disruptions are no longer abstract, they are mroe consequential and directly affect citizen access to services. That shifts responsibility upstream into product decision-making.

• Public expectations have changed
  Citizens increasingly expect transparency about how their data is used, especially where AI is involved, trust can no longer be assumed.

Guidance such as Secure by Design reinforces this by placing lifecycle responsibility on delivery teams. In 2026, treating security as “technical debt” is no longer credible.

Why legacy modernisation is now unavoidable

Legacy modernisation has been discussed for years. What changed is the cost of not acting. By 2026:

• The skills required to maintain older systems are scarcer

• Integration costs rise with every new service dependency

• Cyber vulnerabilities accumulate faster than they can be mitigated

• Policy and service change cycles outpace system adaptability.

This explains why modernisation is no longer seen as a transformation programme, but as a continuous product strategy focused on risk reduction and sustainability. Therefore Product managers are becoming increasingly expected to articulate trade-offs, not just aspirations.

Why user-centred design is becoming more data-driven

User-centred design is not being replaced but it is being sharpened. The driver here is accountability. In an environment of constrained funding, teams must justify prioritisation decisions more clearly. Qualitative insight remains essential, but it is no longer sufficient on its own. Guidance now explicitly expects teams to:

• Measure service performance

• Understand demand and failure

• Demonstrate improvement over time.

In 2026, evidence-led prioritisation is less about demonstrating maturity and more about justifying difficult decisions in constrained conditions.

Why procurement is shaping product work more directly

Procurement has always influenced delivery, but AI and platform dependency have increased the stakes. Cabinet Office guidance reflects concern about:

• Hidden AI usage within supplier solutions

• Ongoing vendor dependency

• Accountability gaps when services fail.

This explains the move towards greater transparency, optional AI-specific procurement questions and outcome-based expectations. Product managers are brought into this because procurement decisions increasingly determine what is possible at a service level.

What this means overall: why product judgement matters more in 2026

The broader reason behind these changes is constraint. Public sector product management in 2026 is shaped by:

• Financial pressure

• Operational risk

• Regulatory response

• Technological acceleration

• Public accountability.

As a result, Product Management will reward judgement more than process. The most effective product leaders will be those who can make trade-offs explicit, balance innovation with responsibility and sustain services that people rely on every day.

Quality management has been addressing similar challenges for decades. How to deliver consistently. How to reduce waste. How to manage risk. How to improve outcomes over time without exhausting teams or relying on heroic effort.

Despite its manufacturing roots, quality management has clear lessons for modern product teams, particularly those working in complex, regulated or high-stakes environments.

Quality is about reliability, not perfection

In product management, quality is often equated with polish or the absence of bugs. In quality management, it means something more practical: the ability to meet user needs reliably over time.

A high-quality product behaves predictably, fails safely and improves through evidence rather than opinion. It delivers value consistently rather than occasionally. For internal platforms and public-sector services, reliability and trust often matter more than novelty.

Kaizen fits product work naturally

Kaizen, or continuous improvement, aligns closely with how effective product teams operate.

Rather than relying on large redesigns or periodic roadmap resets, Kaizen encourages small changes, frequent learning and steady progress. In practice, this means using user insight and service data to make regular, low-risk improvements. Refining flows, simplifying journeys, reducing operational friction and removing unnecessary process.

None of these changes are dramatic in isolation, but together they compound.

Process matters as much as features

Quality management places as much emphasis on how work happens as on what is delivered. This is a useful for product teams that focus heavily on roadmaps while ignoring flow, bottlenecks and decision-making friction.

For product managers, this means improving prioritisation, reducing hand-offs, strengthening cross-functional collaboration and spotting waste such as excessive meetings, rework or unclear ownership. Better processes improve both delivery speed and decision quality.

Measure what helps you learn

Quality management is data-driven without being metric-obsessed. Measures exist to understand whether the system is working, not to perform for dashboards.

For product teams, this means asking whether users are succeeding, where work stalls, which issues repeat and how demand changes over time. Metrics should support learning and decision-making, not create noise.

Quality is ultimately a leadership choice

Quality does not emerge from tools or frameworks alone. It is a leadership stance.

Product leaders who take quality seriously prioritise long-term outcomes, treat risk as something to manage rather than ignore, invest in team capability and create space for continuous improvement. This does not slow teams down, it helps them move with confidence and sustainability.

Final thought

You do not need formal quality certifications to benefit from quality management thinking. The value lies in the mindset of continuous improvement. Evidence over opinion and systems over silos.

In a product world focused on speed, quality management offers something more valuable, momentum without chaos.