Product Strategy Template for Choices You Can Review

Turn evidence into expiring strategic choices

The record moves from a bounded diagnosis to choices, capabilities, measures, and a human review without absorbing the systems that plan research, fund work, specify behavior, or schedule delivery.

1. Select one customer and problem from evidence

   Name the customer and problem narrowly enough to exclude attractive adjacent work. Link dated observations, accountable evidence owners, limitations, constraints, and open questions. Keep raw research in its authorized system and treat a small or biased sample as a gap rather than proof of demand.

   Sources: [gov-discovery], [gov-user-needs], [strategy-pack]

2. Frame positioning as a falsifiable hypothesis

   Record the category, current alternatives, advantage hypothesis, supporting evidence, and disconfirming observations. Strategy should make the proposed difference reviewable without declaring that the market agrees or that customers will adopt the product.

   Sources: [gov-discovery], [gov-product-manager], [strategy-pack]

3. Write choices together with non-choices

   Every choice should state a rationale and link to evidence, required capabilities, a defined measure, an assumption, and at least one non-choice. The non-choice records the tradeoff and the evidence that would justify reopening it instead of letting scope return through an undocumented exception.

   Sources: [gov-priorities], [gov-roadmap], [strategy-pack]

4. Define capabilities and measures before targets

   Capabilities describe what must become possible without approving a solution. Measures define the outcome, population, calculation, baseline state, expected direction, decision threshold, window, source, owner, and limitations. An unknown baseline or threshold should stay unknown until reviewed.

   Sources: [gov-measures], [gov-product-manager], [strategy-pack]

5. Review assumptions, risks, gaps, and expiry

   Record accept, revise, reject, or expire decisions with the evidence cutoff, responsible people, remaining gaps, next review, and strategy expiry. Preserve earlier decisions and return an expired record to review instead of treating it as standing approval.

   Sources: [gov-priorities], [gov-roadmap], [json-schema-2020-12], [strategy-pack]

The product strategy ownership boundary

This resource owns the decision layer between evidence and downstream product planning. It can link to adjacent records, but it cannot inherit their approval or execution authority.

Three ways to keep strategy from becoming a wish list

The same record structure can support different strategic questions when it keeps evidence limits, tradeoffs, unknowns, and downstream authority visible.

Rules for deciding whether the strategy is reviewable

Use these stop rules before a confident narrative hides missing evidence, unowned tradeoffs, or authority that belongs in another record.

1. The diagnosis names several customers or unrelated problems

   Choose: Narrow the strategy period to one selected customer and one selected problem, then record the adjacent jobs as explicit non-choices or separate strategy candidates.

   Tradeoff: The record becomes less comprehensive, but reviewers can challenge a real choice instead of approving an umbrella statement.

2. A choice has no non-choice or reopening condition

   Choose: Do not advance the review. State what will not be pursued, why, and which future evidence would justify reconsideration.

   Tradeoff: This exposes disagreement and limits flexibility, but prevents discarded scope from returning without evidence.

3. A measure lacks a population, calculation, baseline state, window, owner, or limitation

   Choose: Keep the measure incomplete and assign the definition gap. Do not replace an unknown baseline or decision threshold with a persuasive target.

   Tradeoff: The strategy may remain in review longer, but it avoids judging later work against an undefined proxy.

4. The strategy starts assigning roadmap horizons, backlog order, requirements, funding, or dates

   Choose: Move those details to their accountable roadmap, backlog, PRD, business-case, or project-plan owner and retain only stable references here.

   Tradeoff: Reviewers must follow linked records, but ownership and change history remain auditable.

5. The review date passes or material evidence changes

   Choose: Reopen the strategy, freeze the evidence cutoff, record accept, revise, reject, or expire decisions, and set the next review and expiry.

   Tradeoff: The strategy cannot remain a static presentation, but stale assumptions are less likely to become implicit policy.

What this template cannot establish

A closed record and deterministic validator improve reviewability. They cannot establish truth, authority, execution quality, or business results.

• The pack cannot prove that research is representative, evidence is correct, the selected problem matters enough, or product demand exists.
• A strategy choice cannot approve funding, procurement, staffing, architecture, security, privacy, accessibility, legal, or compliance decisions.
• Measure definitions cannot guarantee that data will be available, causal, unbiased, statistically meaningful, or interpreted correctly.
• Passing the validator cannot authorize a roadmap, prioritize a backlog, approve requirements, commit delivery, or certify readiness.
• The fictional example is deliberately unresolved and must not be reused as real customer, market, policy, or product evidence.

Sources and reproduction evidence

The primary guidance and same-release artifact below were checked on 2026-08-01. Each source supports a bounded method or record shape; none validates the fictional choices or certifies an adapted strategy.

1. [strategy-pack] Playcode:Product strategy fictional example

   Checked August 1, 2026. Supports: The exact fictional records, projections, false authority flags, and deterministic checks described by this guide.

2. [gov-discovery] Government Digital Service:How the discovery phase works

   Checked August 1, 2026. Supports: Reframing a proposed solution as a problem, understanding users and constraints, exposing assumptions, considering alternatives, and deciding whether to continue.

3. [gov-user-needs] Government Digital Service:Understand users and their needs

   Checked August 1, 2026. Supports: Understanding the wider user context, testing assumptions, and focusing on the problem rather than starting from a solution.

4. [gov-measures] Government Digital Service:Define what success looks like and publish performance data

   Checked August 1, 2026. Supports: Defining appropriate metrics, tracking whether a service addresses its intended problem, and using performance data for decisions and improvement.

5. [gov-priorities] Government Digital Service:Deciding on priorities

   Checked August 1, 2026. Supports: Making regular transparent priority decisions from performance analysis, user research, constraints, delivery stage, and stakeholder input.

6. [gov-roadmap] Government Digital Service:Developing a roadmap

   Checked August 1, 2026. Supports: Connecting roadmap work to vision and value, stating what is not being done, iterating with evidence, and keeping roadmap intent separate from backlog work.

7. [gov-product-manager] Government Digital and Data Profession Capability Framework:Product manager role

   Checked August 1, 2026. Supports: Framing problems with multidisciplinary teams, balancing user and business needs, choosing priorities, applying insights, and defining value and outcomes.

8. [json-schema-2020-12] JSON Schema:JSON Schema draft 2020-12

   Checked August 1, 2026. Supports: The published vocabulary and metaschema used for the pack closed JSON record. It does not validate strategic judgment.

Product strategy template questions