A framework is just a named way of working. Pick the lightest one that answers the question you have today. Each card below says what it is, when to use it, how a Product Owner might apply it, what goes wrong, and where to read more.
Cards start folded. Expand one at a time. The open card fills the width and the rest move below.
Team methodology
Scrum
Lightweight agile framework with roles, events and artefacts for a usable Increment each Sprint. The Product Owner owns Product Backlog content and order.
When to use it
Stable team with a clear backlog owner
Need planning, review and retro cadence
Value emerges through thin vertical slices
Example for a Product Owner
Own Product Backlog content and ordering. Partner with the Scrum Master on Sprint Goal clarity, protect the Goal from mid-Sprint injections, and never outsource priority to whoever shouts loudest in steering.
Things that go wrong
Ceremony without Definition of Done
Daily Scrum as status theatre to the PO
Backlog as a stakeholder parking lot
Team methodology
Kanban
Visualise work, limit WIP and manage flow. Strong fit when interrupt-driven demand sits beside product bets.
When to use it
Unscheduled operational demand on the product
Flow metrics matter more than fixed Sprint commitments
Classes of service need to be explicit
Example for a Product Owner
When your product absorbs interrupt-driven demand, use classes of service so urgent BAU does not silently erase strategic outcomes. Report aging WIP next to your roadmap narrative.
Things that go wrong
Board without WIP limits
Ignoring blocked age until everything is red
No policy for expedite versus standard work
Outcomes
OKR
Objectives and Key Results align teams on outcomes with measurable evidence. They are a compass, not a task list.
When to use it
Need outcome focus over output lists
Multiple teams must share one product direction
Quarterly strategy needs a living link to the backlog
Example for a Product Owner
Translate strategy into Objectives and Key Results, then ensure every major backlog theme clearly serves those results. Review progress in Sprint Reviews so stakeholders see learning, not only demos.
Things that go wrong
Key Results that are actually tasks
OKRs written once and ignored until quarter end
Too many Objectives so nothing is priority
Prioritisation
RICE
Reach × Impact × Confidence ÷ Effort for comparing many product-style backlog items on one transparent scale.
When to use it
Many small items to compare
Need a scaffold stakeholders can challenge
Product backlog noise is high
Example for a Product Owner
Score noisy backlog items. Personally challenge Confidence scores when a favourite feature is being justified under pressure, and keep Effort owned by the people doing the work.
Things that go wrong
Confidence inflation
Using RICE for huge programme bets it cannot express
Treating scores as precision science
Prioritisation
WSJF
Cost of delay divided by job size for a defensible order when several asks compete for the same capacity.
When to use it
Competing asks for shared platform or team capacity
Sponsors need transparent ranking inputs
Programme-level trade-offs across products
Example for a Product Owner
Facilitate cost-of-delay workshops when several programmes compete for the same delivery capacity. Refuse to rank without named assumptions written down.
Things that go wrong
Garbage-in cost of delay
Political scoring sessions with no challenge
Scores never revisited when reality changes
Prioritisation
MoSCoW
Must, Should, Could, Will not for a fixed timebox. Forces scope honesty under a deadline.
When to use it
Fixed deadline with negotiable scope
Stakeholder workshops that need a shared scope line
Statutory or regulatory dates
Example for a Product Owner
Run fixed-date scope talks with capacity on the table so Must means Must, not preference. Keep a named arbiter (you or the SRO) and a visible Will-not list after the workshop.
Things that go wrong
Everything becomes Must
Will-not list disappears after the workshop
No capacity check, so Must is fantasy
Roadmapping
Now / Next / Later
Horizon roadmap that communicates sequence without fake precision on distant work.
When to use it
Executive roadmap conversations
Need direction without over-promising dates
Portfolio themes need a simple shared picture
Example for a Product Owner
Present strategy as Now / Next / Later themes tied to OKRs. Hold the line when seniors try to pin Later to a delivery date without discovery or capacity evidence.
Things that go wrong
Later becomes a dumping ground with silent commitments
Now overloaded because saying no feels hard
No link from themes back to measurable outcomes
Discovery
Double Diamond
Design Council model: Discover and Define, then Develop and Deliver, with diverge-converge cycles that separate problem and solution space.
When to use it
Problem unclear
Service design discovery
Risk of building the wrong thing is high
Example for a Product Owner
Timebox Discover and Define before committing large Develop slices when the problem is still fuzzy. Bring evidence into Sprint Review so stakeholders see the diamond, not only the build.
Things that go wrong
Skipping Discover under date pressure
Endless Discover with no decision owner
Treating the model as a waterfall gate set
Discovery
Jobs to be Done
Users hire products to make progress in a circumstance. Focuses on the job, forces and competing solutions rather than demographics alone.
When to use it
Feature requests conflict and need a deeper frame
Segmentation by persona is not explaining behaviour
You need a sharper outcome statement for OKRs
Example for a Product Owner
Rewrite noisy feature asks as job stories. Use the job and forces to challenge solutioneering in refinement and to keep acceptance criteria tied to user progress.
Things that go wrong
JTBD as jargon with no interview evidence
Ignoring competing solutions users already hire
Writing jobs so broad they cannot drive priority
Philosophy
Lean / Lean UX
Maximise learning and value, minimise waste. Small batches, fast feedback, outcomes over deliverables.
When to use it
Queues and hand-offs dominate lead time
Design and product need shared experiment loops
You need a language for waste with sponsors
Example for a Product Owner
Cut approval queues and oversized epics before asking the team to go faster. Pair hypotheses with the thinnest experiment that could change the backlog order.
Things that go wrong
Lean theatre: posters without removing a real queue
Shipping MVPs that never get measured
Cost-cutting dressed as waste reduction
Civil Service standard
GDS Service Standard
Fourteen points on meeting user needs, providing a good service, and using the right technology for UK public services.
When to use it
UK public service build or iteration
Service assessment preparation
Need a shared quality bar across product, design and delivery
Example for a Product Owner
Attach Service Standard evidence to major releases so assessment is continuous, not a cliff edge. Put relevant points into Definition of Done and Sprint Review agendas.
Things that go wrong
Paperwork-only assessment prep
Leaving accessibility and performance to the last Sprint
Treating the Standard as design-only, not product-owned
Accessibility
WCAG
Web Content Accessibility Guidelines. AA is the common public-sector floor for inclusive interfaces.
When to use it
Public-facing interfaces
Inclusive design and test evidence
Service assessment or equality duty risk
Example for a Product Owner
Put WCAG 2.2 AA checks into acceptance criteria for public interfaces and refuse to call inaccessible work Done. Partner with UX and testers so evidence exists before release, not after complaints.
Things that go wrong
Treating AA as optional polish
Relying only on automated scans
Bolting accessibility on in the final Sprint
Business case
Green Book / Five Case Model
HMT appraisal guidance and the Strategic, Economic, Commercial, Financial and Management cases for public funding decisions.
When to use it
Seeking or refreshing public funding
Benefits realisation is live
Options appraisal needs economic and strategic rationale
Example for a Product Owner
Connect backlog themes and benefits measures to Green Book logic. Bring honest outcome evidence into Economic and Management cases so optimism bias is not locked into a feature list.
Things that go wrong
Business case as fiction written once
Benefits with no owner after go-live
Product roadmap disconnected from the Management Case
Change
ADKAR
Individual change journey: Awareness, Desire, Knowledge, Ability, Reinforcement. Useful when product behaviour depends on staff or citizen adoption.
When to use it
Adoption of new ways of working or tooling
Staff-facing product change with resistance
Training alone is not moving behaviour
Example for a Product Owner
When rolling out a new product behaviour to staff users, diagnose whether resistance is Awareness, Desire or Ability before adding more training content. Partner with Change Management on Reinforcement after go-live.