Skip to content
Product Lifecycle Templates

Product Strategy

beta  ·  Family strategy-docs  ·  Phase undefined  ·  Sizes lean, full  ·  Formats kernel, one-pager  ·  ~2,700 tokens

The document that says which problems this product will solve to reach its vision, and which it will not. It is judged by whether a competitor’s name could be swapped in without the document becoming false: a strategy nobody could disagree with has not chosen anything.

How to pick a format and a size, how to tell whether the draft is any good, and when to stop.

Before you start: is this the right document at all?

Section titled “Before you start: is this the right document at all?”

Write a product strategy when a team has to choose between reasonable options and the choice keeps reopening. Do not write one to satisfy a template, a planning cycle, or a request for “the strategy deck”.

Write something else if:

You actually need Because
a product vision you are arguing about the destination, not the route. Vision describes the future state; strategy is the set of choices to reach it
a product roadmap the choices are settled and the argument is about order and timing
OKRs the strategy exists and you need this period’s measurable objectives. OKRs measure execution; they do not choose
a PRD one specific thing is agreed and needs specifying
a business case the question is whether to fund it at all

Write nothing at all if the team already agrees, the agreement is holding, and nobody has asked it to justify a refusal. A document produced to have a document is the cheapest way to make a real strategy harder to write later, because the next one has to argue with this one first.

A warning worth taking seriously. No study measures whether writing this document improves product outcomes. What is measured is adjacent and mixed, and one study found managers believed planning was helping when the financial data did not agree. If you cannot say what argument this document is going to settle, writing it will feel productive and prove nothing. See product-strategy_companion.md section 1.

Picking a format and a size

Section titled “Picking a format and a size”

Format is the opening question, and it is a real choice:

  • kernel (product-strategy_template-lean.md, product-strategy_template-full.md) starts from the obstacle. Use it when the team does not agree on what is hard. This is the default.
  • one-pager (product-strategy_template-one-pager-full.md) starts from the choice. Use it when the problem is understood and the argument is about where to compete.

If you cannot fill in “Where We Will Play” because people are still arguing about what is wrong, you wanted the kernel.

Size is how much context the reader lacks:

  • lean for a team that shares the context and needs to settle what to work on.
  • full for readers who were not in the argument: a new leader, another function, a board, or your own team in six months.

A named variant worth stealing from, in either format. Ramp’s published template adds two questions this bundle does not ship as sections: right to win and risks. See product-strategy_companion.md section 9.

The one test that outranks the rest

Section titled “The one test that outranks the rest”

Swap in a competitor’s name. If the document still reads true, you have described an industry rather than made a choice.

Everything else in this guide is a way of finding out why it failed that test.

The second test is shorter and harsher: if nothing in the document made anyone uncomfortable, it is a wish list. A strategy that costs nothing to agree with has not chosen anything.

The rubric

Section titled “The rubric”

Score each 0, 1 or 2. Under 13 out of 20 and this will not survive its first real disagreement. It will be nodded at, filed, and quietly ignored while the roadmap decides what actually happens.

# Criterion 0 1 2
1 Diagnosed No obstacle named An obstacle among several challenges listed One obstacle named, and you can point at the evidence that it is the binding one
2 Falsifiable diagnosis Could not be wrong Arguably wrong, but nobody has argued Someone on the team disagreed with it, and the disagreement is recorded or resolved
3 Constraining policy Restates the goal An approach, but nothing is ruled out by it You can name a reasonable option the policy forbids, and someone wanted that option
4 Coherent action A list of unrelated work Actions that each serve the policy You can say which two actions make each other stronger, and what breaks if one is dropped
5 Refusals with a cost Nothing declined Declines things nobody asked for Declines something a named person wanted, and they have been told
6 Not a roadmap Delivery dates and feature names throughout Some named deliverables leak in No delivery commitment could be lifted from this document; sequence lives in the roadmap. A measurement deadline in row 8 and a review backstop in row 10 are not roadmap dates and do not count against this row
7 Not interchangeable A competitor’s name fits unchanged Mostly generic, one specific claim You can point at the sentence a competitor could not write, and say what they would have to give up to write it
8 Falsifiable outcome (kernel-full, one-pager) No measure A measure with no baseline or date A leading indicator with a baseline, a date, and a stated result that would make you abandon the strategy
9 Assumptions exposed (kernel-full only) None stated Risks listed generically The assumption the strategy would die without is named, with the evidence you have and the evidence you lack
10 Owned and triggered (kernel-full only) No review, no owner “Reviewed quarterly” An event that triggers review, a backstop date, and a named person

Which rows apply to what. The rubric is written for the kernel, which is the default format. Scope, in full:

Document Rows that apply Maximum Score against
kernel, full all 10 20 13
kernel, lean 1-7 (it has no measure, assumptions or trigger section) 14 9
one-pager 3-8 (it starts from the choice, so rows 1-2 have no diagnosis to grade, and it carries no assumptions or review-trigger section) 12 8

Every threshold is the same proportion of the available points. Rows 1 and 2 do not apply to the one-pager on purpose, not by oversight: that format deliberately opens from the choice rather than the obstacle, which is exactly why the guide tells you to use the kernel instead when the team is still arguing about what is wrong. Row 8 does apply to it, because the one-pager carries its own “How We Will Know We Have Won” section.

Format-specific checks

Section titled “Format-specific checks”

Kernel. Read the diagnosis and the guiding policy alone, in that order. Does the policy obviously answer the diagnosis? If a reader could not tell which obstacle the policy is for, the two sections were written independently, which is the failure this format is most prone to.

One-pager. Read “Where We Will Play” and “How We Will Win” alone. Does the second explain why you win in the first, against alternatives that exist there? A “how we will win” that would be true anywhere means the cascade broke at the second step.

Failure signals to look for in the draft

Section titled “Failure signals to look for in the draft”
  • The goal has replaced the diagnosis. “We need to grow self-serve revenue” is a target. The diagnosis is why that has not already happened.
  • Fluff. Elevated language that survives any edit because it asserts nothing.
  • Rah-rah. “World-class”, “delightful”, “best-in-class”. Nobody could disagree, so nothing was chosen.
  • The roadmap in disguise. Dated features under strategy headings; the hard question was skipped.
  • The OKR substitute. Objectives and numbers, with no reasoning for why those objectives.
  • Straddling. Two incompatible positions held at once. Porter’s worked case is Continental Lite, which “lost hundreds of millions of dollars, and the CEO lost his job”.
  • Everything survives. Every option that was on the table before the document still is.
  • Nobody is uncomfortable. The clearest signal of all.

When it is good enough

Section titled “When it is good enough”

When someone can use it to refuse a plausible, senior, well-argued request, and when the person whose work it declines has read it and knows why. A strategy that has never been cited in a decision is not finished, however well it reads.

Then delete every HTML comment, and put the review trigger in a calendar with a name attached.

The artifacts

Section titled “The artifacts”

product-strategy_template-lean.md · ~2,700 tokens

---
title: "{{product_name}} Product Strategy"
product: "{{product_name}}"
owner: "{{who_owns_this_strategy}}"
period: "{{period_this_covers}}"
status: "{{draft_or_agreed}}"
last_updated: "{{date}}"
doc_type: product-strategy
size: lean
format: kernel
source_template: product-strategy
source_template_version: 0.1.0
---


<!--
LEAN PRODUCT STRATEGY (kernel format). The smallest strategy that can still do a strategy's job: the
obstacle you have diagnosed, the approach you are taking to it, the action that follows, and what that rules
out. Four sections, one page. To grow it into a strategy that has to survive people who were not in the room
(see product-strategy_template-full.md), ADD sections; never rename or reorder the ones below, because the
full variant is a strict superset of this one.


THE TEST THIS DOCUMENT HAS TO PASS. Swap in a competitor's name. If it still reads true, you have described
an industry rather than made a choice. The second test is shorter: if nothing in it made anyone
uncomfortable, it is a wish list. Both come from practitioners, not from theory, and they are the reason
"What We Are Not Doing" is in the LEAN variant and not an optional extra.


WHAT THE EVIDENCE ACTUALLY SAYS, SO YOU ARE NOT MISLED. No study measures whether writing a product strategy
document improves product outcomes. There is a mixed literature on whether strategic PLANNING as a process
correlates with firm performance, and one study of listed firms found no correlation with objective
financial results while finding one with what managers BELIEVED. So "everyone felt it helped" is not
evidence. This template earns its place by making choices explicit, not by a proven effect. See
product-strategy_companion.md section 1.


THE KERNEL IS NOT THIS LIBRARY'S INVENTION. Diagnosis, guiding policy and coherent action come from Richard
Rumelt's Good Strategy Bad Strategy (2011). The headings are his; the guidance below is this bundle's.


THIS IS ONE OF TWO FORMATS, AND THE CHOICE IS REAL.
- This kernel starts from the obstacle. Reach for it when the hard part is that nobody agrees what the
  problem is.
- product-strategy_template-one-pager-full.md is a choice cascade (winning aspiration, where we will play,
  how we will win). Reach for it when the problem is understood and the hard part is choosing between
  places to compete.
They are different opening questions, not two sizes of one document. See product-strategy_companion.md
section 4.


WHAT A PRODUCT STRATEGY IS, AND IS NOT
It is the set of choices that gets you from where you are to the vision. It is NOT a vision (that is the
destination), NOT a roadmap (that is sequence and timing), NOT OKRs (those measure a period's execution),
and NOT a business strategy (that decides where the company invests). The strategy/roadmap boundary is the one this
bundle's sources return to most often: the moment dates and feature names appear, you are writing the next document
down. See product-strategy_companion.md section 8.


HOW TO FILL THIS IN
1. Read the comment under each heading: WHAT it wants, WHY it matters (with a pointer into
   product-strategy_companion.md), guiding questions to ASK, a GOOD and a WEAK example, and the TRAP to
   avoid.
2. Replace each {{placeholder}} with your content.
3. Write the diagnosis first and do not move on until it names ONE obstacle. Every other section depends on
   it, and a strategy with a vague diagnosis fails quietly rather than loudly.
4. If a section does not apply, write "N/A" and one line of why, rather than deleting it.
5. Before you share it: self-grade against product-strategy_guide.md, then DELETE every HTML comment. They
   are guidance, not content.
-->


# {{product_name}} Product Strategy


## Diagnosis


<!-- WHAT  The one thing that makes the goal hard. Not a summary of the market, not a list of challenges:
           the single obstacle that, if it went away, would make the rest straightforward. Two or three
           sentences.
     WHY   This is the section that separates a strategy from a wish. Rumelt's test is that if you fail to
           identify and analyse the obstacle you do not have a strategy, you have "either a stretch goal, a
           budget, or a list of things you wish would happen". Everything downstream is an answer to this
           paragraph, so a vague diagnosis produces a document that cannot be wrong and therefore cannot be
           useful. Deep dive: product-strategy_companion.md section 3 (Diagnosis).
     ASK   What is actually stopping us? If this obstacle disappeared overnight, would the goal become easy?
           Is this a cause or a symptom? Would a competitor recognise this as their obstacle too, and if so,
           have we named ours?
     GOOD  "Dispatchers build a route in under a minute, but only once someone has told them which jobs are
           genuinely urgent. Urgency lives in the free-text notes field: in the 200 jobs we sampled, three of
           every five emergencies were caught by a human reading it. Our scheduling engine is fast and it is
           scheduling the wrong things first."
           (one obstacle, evidenced, and it rules some responses out)
     WEAK  "The market is increasingly competitive and customers expect more from field-service software.
           We need to keep innovating to stay ahead."
           (true of every company in the category; names nothing that could be wrong)
     TRAP  Writing the goal here instead of the obstacle. "We need to grow self-serve revenue" is a target.
           The diagnosis is why that has not already happened. -->


{{the_diagnosis}}


## Guiding Policy


<!-- WHAT  The approach you are taking to the obstacle above. One paragraph. It should constrain: a reader
           should be able to name a reasonable option it rules out.
     WHY   A guiding policy is a direction, not a plan. Rumelt's image is guardrails: it directs and
           constrains action without fully defining it. If every option that was on the table last month
           still survives this paragraph, it is not a policy, it is a preamble. Deep dive:
           product-strategy_companion.md section 3 (Guiding Policy).
     ASK   What does this rule out? Which team's current plan changes because of this? If someone disagreed
           with us, what would they be arguing for instead? Is this an approach, or a restatement of the
           goal?
     GOOD  "We will infer urgency from the job record rather than asking dispatchers to encode it. Given a
           choice between a better form for entering priority and a model that reads what is already
           written, we read what is already written."
           (an approach with a real alternative it rejects: redesigning the intake form)
     WEAK  "We will focus on delivering an excellent dispatcher experience and driving scheduling
           efficiency."
           (names no alternative, so it forbids nothing)
     TRAP  Listing several policies. If you have three, you have not chosen; you have deferred the choice to
           whoever reads this next, and they will pick the one that suits them. -->


{{the_guiding_policy}}


## Coherent Action


<!-- WHAT  The moves that carry out the policy, and how they reinforce each other. Three to five, as prose
           or a short list. Each should be a kind of work, not a dated deliverable.
     WHY   The word doing the work is "coherent". Porter's argument is that fit is what makes a position
           durable, because it "locks out imitators by creating a chain that is as strong as its strongest
           link": actions that each make sense alone but do not reinforce each other are a list, not a
           strategy. Deep dive: product-strategy_companion.md section 3 (Coherent Action).
     ASK   Does each action serve the policy, or just seem generally good? Which two of these make each
           other stronger? If we dropped one, would the others still work? Are these kinds of work, or
           are they release dates wearing a disguise?
     GOOD  "1. Extract urgency signals from the notes field at ingest, so priority exists before a human
           reads anything. 2. Show the inferred priority beside the dispatcher's own, so disagreement is
           visible rather than silent. 3. Track the override rate as our leading indicator. The first two
           make the inference usable; the third is how we learn whether it is any good."
           (each serves the policy, and they compound)
     WEAK  "Launch AI assistant in Q3. Redesign the intake form. Hire two data scientists. Improve the
           mobile app."
           (a dated to-do list; nothing here reinforces anything else)
     TRAP  Writing the roadmap. If a reader could build a Gantt chart directly from this section, it has
           stopped being strategy. Sequence and timing belong in the roadmap, which is downstream of this
           document. -->


{{the_coherent_action}}


## What We Are Not Doing


<!-- WHAT  The things you are explicitly declining this period, and one line each on why. Two to five. Name
           real options, not straw ones.
     WHY   This is the section that makes the other three usable, and the one every quality
           test in this bundle's research turns on. The test
           practitioners actually apply is whether the team can say "this is a really great idea... but
           we're not going to build it" and mean it. A strategy that makes nobody uncomfortable is a wish
           list. Deep dive: product-strategy_companion.md section 3 (What We Are Not Doing) and section 7.
     ASK   What has been asked for repeatedly that we are now refusing? Which of these would a competitor
           happily do? Who will be unhappy when they read this, and have we told them? If nothing here
           costs us anything, have we actually chosen?
     GOOD  "1. We are not shipping the customer-facing arrival-window feature this year. It is the most
           requested item in our backlog and it depends on scheduling accuracy we do not yet have. 2. We are
           not taking on national facilities-management contractors. They are winnable and they buy on
           compliance reporting, which pulls us back toward the forms-and-fields product."
           (both were live options; both have a named cost)
     WEAK  "We are not going to compromise on quality or lose focus on the customer."
           (nobody was proposing either; refusing nothing)
     TRAP  Listing only things nobody wanted. A refusal that costs nothing proves nothing. If every item
           here is uncontroversial, the hard choice is still hiding somewhere else in the document. -->


{{what_we_are_not_doing}}

Provenance

Section titled “Provenance”

The reasoning, the history and every source, in the repository:

  • Companion - the long-form argument: why these sections, where the sources disagree, and what the bundle refuses to claim
  • History - what changed in this bundle, and when
  • Research log - every source consulted, with what each one actually supports
  • Catalog metadata - the machine-readable record this page is generated from

Catalog record: 15 sections across 2 format(s), methodology methodology-agnostic; OKR-friendly, typically owned by Product Manager / CPO.