A practical guide for owning outcomes, not busywork. Standards describe what good looks like for public services. Methods describe how you discover, prioritise and learn. Keep those ideas separate so you do not bury the team in process, or ship a feature factory with no evidence.
MAP-01Value maps
MAP-01
Value maps & methods
Pick the map that matches the decision in front of you.
Civil Service + Universal
Product work mixes discovery methods, prioritisation models and public-service standards. Confusing them creates either endless research or a feature factory. Every framework below answers a different question. Use the lightest one that unlocks the next honest decision.
Maps you will actually use
Map
Answers
Shape
Double Diamond / Design Thinking
Is the problem clear enough to build?
Diverge then converge: Discover, Define, Develop, Deliver
Jobs to be Done
What progress is the user hiring this for?
Job story, forces, competing solutions
OKRs
What outcome are we chasing this quarter?
Objective plus measurable Key Results
RICE / WSJF / MoSCoW / Now-Next-Later
In what order, under which constraint?
Scoring or scope classes tied to capacity
GDS Service Standard & WCAG
Is this fit for a public service?
14 points · accessibility floor AA
Green Book benefits logic
Does public money buy a defensible benefit?
Strategic to Economic to Management cases
Choose in practice
Outcome unclear: start with Double Diamond Discover before writing stories.
Many small bets: use RICE with honest Confidence scores you personally challenge.
Shared platform capacity fights: use WSJF with named cost-of-delay assumptions.
Fixed statutory date: MoSCoW with a hard arbiter (you or the SRO) and capacity on the table.
Executive roadmap talk: Now / Next / Later. Refuse fake dates on Later.
If a method never changes a prioritisation decision, stop performing it.
In DDaT terms, product roles run from Associate through Lead and Head of Product. Titles vary by department. The accountability does not: someone must own the ordered backlog and the outcome bets. If that person is "the committee", you do not have a Product Owner.
Accountability ladder (typical digital product path)
Associate / Junior PO: learning backlog craft on a contained slice with coaching.
Product Owner: accountable for one product or service backlog and Sprint Goals.
Senior / Lead PO: complex or multi-team value, coaches other POs, holds portfolio coherence.
Head of Product: owns the product profession, strategy frame and hiring bar.
What you stop and start doing as you grow
You stop doing
Writing every story yourself as the only path to clarity
Saying yes to keep the peace in steering groups
Measuring your week by tickets closed
You start doing
Coaching BAs and designers so Ready items arrive without you bottlenecking
Publishing the prioritisation method and inviting challenge on inputs
Measuring your week by outcome movement and decisions logged
Three questions to run every day
Are we solving the right user problem? Is the next bet the highest-value use of capacity? Will we learn something if this ships?
If any answer is "no" for more than a week, that becomes the priority over the loudest stakeholder request.
Features are hypotheses about value. Lead with the outcome, then the thinnest slice that can falsify or confirm it. Output without outcome is activity theatre.
Objective: the change we want. Key Results: evidence it happened. Backlog: bets that could move those results.
Weak versus strong signals
Signal
Weak version
Strong version
Roadmap
List of features by quarter
Now / Next / Later themes tied to OKRs
Story
As a user I want a button
As a … I can … so that … with measurable acceptance
Review
Demo of clicks
Demo plus metric or research learning
Success
Shipped on date
Key Result moved, or honest kill of the bet
OKR hygiene
Objectives are qualitative and memorable. Key Results are measurable, not tasks disguised as numbers.
Every major backlog theme maps to at least one Key Result. Orphans get challenged or cut.
Review OKR progress in Sprint Review at least monthly, not only at quarter end.
When a Key Result is a task ("launch portal"), rewrite it as user or operational evidence.
Run a thin discovery track alongside delivery. Timebox spikes. Put evidence next to every material bet. Discovery that never ships learning into the backlog is research theatre. Delivery that never discovers is a feature factory.
Dual-track operating rules
Track
Purpose
Red flag
Discovery
Reduce uncertainty before large build bets
Interviews with no decision attached
Delivery
Ship thin vertical slices that test value
Sprints full of foundation with no user-facing learning
Bridge
Evidence cards attached to backlog items
"We will research later" forever
Interview, analytics or support evidence attached to risky assumptions before a full Sprint of build.
Prototype or spike when uncertainty is high. Prefer falsification over polish.
Kill or reshape backlog items when evidence contradicts the bet. Celebrate the kill publicly.
Share findings in Sprint Review so stakeholders see learning, not only shipping.
In government, map discovery evidence to Service Standard points on user needs and iteration. Assessment should not be a surprise at the end of Alpha or Beta.
Ambiguity is a Product Owner failure mode, not a developer one. Ready is a shared agreement with the team, BA, UX and testers. If refinement is a monologue, you are not ready.
Definition of Ready checks
Ready check
Why it matters
User and problem clear
Stops solutioning for the wrong person
Acceptance criteria testable
Aligns PO, BA, QA and developers
Dependencies named
Feeds RAID and Sprint planning honesty
Value hypothesis stated
Lets you reorder when learning arrives
Size fits a Sprint slice
Avoids epic fog inside a Sprint
Non-functionals noted
Accessibility, performance, security do not arrive in UAT panic
Anti-patterns
Backlog as a parking lot for every stakeholder email.
Acceptance criteria written after coding starts.
Priority by whoever shouted last in the steering group.
Epics dragged into Sprints because "we need to show progress".
Opaque priority invites politics. Transparent priority invites challenge on assumptions, which is what you want. Pick one method per context and stick to it long enough to learn.
Which method, when
Method
Use when
Your job as PO
RICE
Product backlog noise, many small items
Challenge Confidence inflation
WSJF
Programme capacity fights
Facilitate cost-of-delay honesty
MoSCoW
Fixed date, negotiable scope
Hold the Must line against capacity
Now / Next / Later
Executive roadmaps
Refuse fake dates on Later
Priority is a decision. If everything is priority one, you have not decided.
Write the ranking assumptions down. Challenge is on inputs, not on your right to decide.
Revisit scores when evidence moves. Stale scores are worse than no scores.
Partner with the Delivery Manager so capacity and risk sit next to value, not after it.
Map power and interest. Manage Closely those who can stop value (SRO, finance, security). Keep Informed those who feel the change. Keep Satisfied high-power, low day-to-day interest stakeholders with short, decision-shaped updates.
Use RAG for outcome risk, not for "busy this week".
Keep a decision log: choice, why, who, date. Shared memory is not a system of record.
Escalate with situation, impact, options, recommendation, decision-by date.
Partner with Delivery Manager so RACI for value versus delivery is unambiguous.
Never let the SRO hear bad outcome news first in a board meeting.
Template · Trade-off brief
Outcome at risk: …
Options: A / B / C with trade-offs
Recommendation: …
Decision needed by: … · Owner: …
The information does not change between refinement and a board update. The altitude, the framing and the ask do.
Audience calibration
Audience
Detail level
What they want
Team
High, acceptance and edge cases
Clear intent and cover from mid-Sprint injections
Peer POs / DM
Medium, dependency and capacity
Early warning, shared ranking inputs
SRO / board
Low, outcome and decision
Recommendation and a clear ask
Users / research
Plain language, jobs and pain
To be heard, then see what changed
Template · Outcome RAG
Status: [RAG] because [single biggest outcome driver]
What changed: …
What we are doing: action, owner, date
What we need from you: specific ask, or "visibility only"
Words to drop
Drop
Use
"The business wants…"
"[Named stakeholder] asked for X. My recommendation is Y because…"
"We have to do everything"
"Given capacity, Must is A and B. C moves to Next."
"Users will love it"
"Evidence so far: … Remaining risk: …"
In UK public services, value includes accessibility, trust, operational cost and policy outcomes. Shipping tickets is not the same as meeting the Service Standard.
Align backlog themes to Service Standard user-needs evidence.
Treat WCAG 2.2 AA as a floor in acceptance criteria for public interfaces.
Connect benefits to Green Book logic when funding or benefits realisation is live.
Work with the SRO on what "good enough to ship" means for this tranche.
Prefer GOV.UK Design System patterns over inventing one-off UI that fails assessment.
Assessment readiness as continuous work
Accessibility and performance acceptance criteria are explicit, not implied.
Benefits measures have owners beyond the delivery team.
Research repositories and decision logs are findable before the assessor asks.
Private Beta and Public Beta exit criteria are written early, not invented week-of.
Definition of Done is a product quality instrument, not a tester checklist you ignore. Scope pressure that worsens DORA and support signals is not product success.
Definition of Done agreed with the team and QA, including non-functionals you own.
Sprint Review invites real feedback. Capture changes into the backlog the same week.
Watch DORA and support signals when you pressure for more scope.
Retros that change prioritisation behaviour (for example, fewer mid-Sprint injections) get your public support.
Release notes and support scripts exist when users will feel the change.
Template · Value narrative
Outcome: …
Evidence so far: …
Next bet: …
What we will stop doing if it fails: …
Under pressure, the instinct is to add more backlog items or more meetings. Diagnose first. A fix for the wrong cause costs a Sprint.
Symptom
Likely cause
First move
Everything is Must
No arbiter, or capacity never shown
Put capacity on the table today. Name the Must arbiter in writing
Feature factory, no outcome movement
OKRs absent or ignored
Rewrite the next three items as outcome bets with measures
Discovery never ends
No decision owner for "enough evidence"
Timebox discovery. Ship a falsifying slice
Discovery never starts
Date pressure eats learning
Protect a thin dual-track slice in the next Sprint
Mid-Sprint injections
You are not holding the Sprint Goal
Park asks in the backlog. Escalate pattern to SRO if needed
Stakeholders bypass you
Unclear RACI, or you are slow to decide
Publish decision rights. Speed up small calls, escalate big ones
UAT rejects "done" work
Acceptance criteria weak or late
Rewrite AC with tester and BA before next build
Roadmap dates keep slipping
Hope-based forecasts, or scope creep
Re-baseline on Now/Next/Later. Communicate once, early
Accessibility left to the end
Not in DoD or acceptance
Add WCAG checks to Ready and Done this week
Watermelon outcomes (green slides, red reality)
Reporting punishes honesty
Thank the next person who reports red outcome risk early
The one-minute checklist
Name the single outcome at risk in one sentence.
Is the pain discovery, priority, dependency or quality?
Which decision unlocks the most value, and who owns it?
Tell the SRO before they hear a distorted version.
Protect the Sprint Goal while you sort the noise.
Glossary anchors
OKR: Objectives and Key Results
RICE: Reach, Impact, Confidence, Effort
WSJF: Weighted Shortest Job First
MoSCoW: Must, Should, Could, Will not
JTBD: Jobs to be Done
DoR / DoD: Definition of Ready / Done
GDS: Government Digital Service
Service Standard: 14 points for public services
WCAG: Web Content Accessibility Guidelines
RAID: Risks, Assumptions, Issues, Dependencies
RAG: Red, Amber, Green status
SRO: Senior Responsible Owner
Companion: the cheatsheet distils every section into a one-screen field reference.