write-vision-strategy git:20260919.72235e0A

Immutable. This exact content is served forever at /api/v1/blob/f7f1a85058775d7b.

---
name: write-vision-strategy
description: Write the product vision, the destination, which may be unfalsifiable, and the product strategy, the route, which must be falsifiable this year: a diagnosis, a guiding policy stated as a constraint, coherent bets that each name what they refuse, and the one alternative rejected in favor of the one chosen. Use when a vision reads like a poster or nobody can find one, when a strategy is a roadmap retyped in prose or a goals slide with adjectives, before annual planning copies last year's document forward, or when roadmap bets cannot be traced to any stated policy. Takes the diagnosis evidence, the competitive read, and a costed option if one exists; returns the vision and the product strategy, handed to strategy-critic for the attack pass and to roadmap-builder for sequencing.
---

# Vision and Strategy: a wish list is not a strategy

Ask a team for their strategy and what usually comes back is a roadmap wearing adjectives, or a vision doing two jobs badly because nobody separated them. The vision names a destination nobody can disprove this quarter; the strategy commits to a route a bad quarter can disprove, and merging them produces a document that cannot be planned against or be wrong either. This skill writes them as two documents, forces the strategy to name what it refuses and the alternative it rejected, and stops at the edge of positioning and the north star, which belong to other skills.

## Files this skill drives

- [../../templates/planning/vision.md](../../templates/planning/vision.md), the destination: future state, who it is for, why now, non-goals
- [../../templates/planning/product-strategy.md](../../templates/planning/product-strategy.md), the route: diagnosis, bets, differentiation, sequencing, success metrics, risks
- Worksheets: [../../frameworks/strategy/strategy-kernel.md](../../frameworks/strategy/strategy-kernel.md) (Rumelt, 2011), [../../frameworks/strategy/playing-to-win.md](../../frameworks/strategy/playing-to-win.md) (Lafley and Martin, 2013)
- Reads: [../../templates/discovery/competitive-analysis.md](../../templates/discovery/competitive-analysis.md), the alternative the strategy has to beat, and [../../templates/planning/business-case.md](../../templates/planning/business-case.md), a costed option when one exists
- See also [../../frameworks/assessment/product-operating-model-assessment.md](../../frameworks/assessment/product-operating-model-assessment.md) (Cagan and colleagues, 2024) once the bets are drafted and before they are committed. A strategy describes intended behavior; that sheet scores the behavior the company actually shows, dimension by dimension, and a deficit is what turns the commitment argument into a choice between changing the organization, cutting the plan, and writing the risk down for a named signature
- Hands the draft to [../strategy-critic/SKILL.md](../strategy-critic/SKILL.md) for the kernel, cascade, and durability attack, then to [../roadmap-builder/SKILL.md](../roadmap-builder/SKILL.md) for sequencing
- Boundary, not owned here: positioning is [../competitive-intel/SKILL.md](../competitive-intel/SKILL.md)'s file, [../../templates/planning/positioning.md](../../templates/planning/positioning.md); the north star is [../metrics-tree/SKILL.md](../metrics-tree/SKILL.md)'s file, [../../templates/planning/north-star-metric.md](../../templates/planning/north-star-metric.md)
- Method background: [../../knowledge/cagan-product-teams.md](../../knowledge/cagan-product-teams.md) for the vision, the kernel and Playing to Win entries in [../../knowledge/INDEX.md](../../knowledge/INDEX.md) for the strategy

## When to use

- A vision reads like a poster: nothing in it would fail to describe a competitor, or nobody can locate one at all
- A strategy is a roadmap retyped in prose, or a goals slide with adjectives standing in for a diagnosis
- Annual planning is about to copy last year's strategy forward with only the dates changed
- Roadmap bets exist that trace to no stated policy, or a stated policy has no bet funding it
- A new leader asks what the strategy is, and the honest answer is a list of features

## Inputs

The diagnosis evidence: the discovery document, evidence notes, and any win-loss or metrics review describing what is actually going on. The competitive analysis's so-what, naming the alternative the strategy has to beat. The business case's recommended option, when one has already been costed. The previous period's strategy, scored honestly against what happened. The team's stated capacity and constraints.

Ask for what is missing. No diagnosis evidence: stop; a diagnosis written from opinion describes the org chart, and no worksheet rescues it afterward. No named alternative: use the competitive analysis's do-nothing or manual-workaround row, since the customer's real alternative is rarely a product. No previous strategy to score: say so, rather than implying a continuity that is not there.

## Workflow

### 1. Separate the vision from the strategy, on paper

Decide, before writing a sentence, which document it belongs to. The vision states the destination and may be unfalsifiable this year; the strategy states this year's route and must be falsifiable, a specific bet, on named evidence, that a bad quarter can prove wrong. Decision rule: a sentence that would sit unchanged in either document has not been placed yet.

### 2. Write the diagnosis before the policy

Fill the strategy's diagnosis (section 1) from the strategy kernel worksheet: the situation, every claim linked to evidence, and the crux, the one obstacle that unlocks the rest if it falls. Apply the kernel's tests: a diagnosis with no sentence that would surprise a new hire summarizes the org chart, and a claim that could describe any company in the category fails. Write what changed since the last period, or say plainly that nothing did.

### 3. Name the guiding policy as a constraint, not an aspiration

Section 1b of the strategy template holds this. State how the diagnosis gets beaten, in a sentence that refuses something a reasonable competitor might choose instead. Test it the kernel's way: write the opposite policy. An absurd opposite, "be worse at onboarding", means the original is a platitude; an opposite a sane rival might actually choose means the policy is real. "Grow the business" and "invest in innovation" both fail this test; keep writing until the sentence would make a rival's product lead wince.

### 4. State the coherent actions, and what each one gives up

Two or three bets (section 2), never seven, each naming what it chooses and, in the refused column, what it gives up. Run the Playing to Win cascade per bet: where to play, how the chosen customer picks this over the alternative in the competitive analysis, and the capability required that the team does not cheaply have today. An action tracing to no policy clause is a pet project; cut it, or write the missing clause.

### 5. Name the one bet the strategy leans on, and what would show it wrong

Among the bets, name the one whose failure forces a rewrite, not just a delay. Write its load-bearing condition as a "what would have to be true" statement, per the cascade worksheet, and mark it evidenced, cheaply testable with an owner and a date, or untestable. An untestable condition is not disqualifying; an unmarked one is. This is the sentence [../strategy-critic/SKILL.md](../strategy-critic/SKILL.md) attacks first, so write it as though it already had.

### 6. State what you are deliberately not doing, at both grains

At the vision's grain: the segments, geographies, or use cases deferred, each with a reason and a revisit condition, not a date (section 5). At the strategy's grain: the approaches this year's bets refuse, in the bets table itself, and the capability or campaign left unfunded because of it. Name who will be unhappy about each refusal by role, not by euphemism; a non-goal nobody minds losing was never a real option.

### 7. Date both documents and tie them to a number

Give the vision a horizon and the north star metric it implies; a candidate label is fine when metrics-tree has not built the sheet yet, and positioning itself stays with competitive-intel rather than getting drafted here. Give the strategy a period, success metrics traced to the north star tree, and key risks with an early signal and a named watcher. Set the review date before circulating either document; an undated strategy gets copied forward next year, unread.

### 8. Hand off before anyone else reads it

Send the strategy to [../strategy-critic/SKILL.md](../strategy-critic/SKILL.md) for the kernel, cascade, and durability attack before a wider room sees it; an unattacked strategy gets attacked live, in the meeting, by whoever is least invested in it. Once it passes, hand the bets to [../roadmap-builder/SKILL.md](../roadmap-builder/SKILL.md) for sequencing into quarters.

## Output format

1. The vision: future state in the customer's terms, one primary customer, why now with linked evidence, the implied north star metric, non-goals with reasons and revisit conditions
2. The strategy: diagnosis with the crux, two or three bets each with a refused column, the differentiation mechanism and the alternative it beats, sequencing with evidence preconditions, success metrics, key risks with signals and owners
3. The one load-bearing bet, named, with its falsification condition and evidence status
4. Both documents dated, with a review date set
5. The handoff line to strategy-critic and, once passed, to roadmap-builder

## Failure modes this skill guards against

- The strategy that is a roadmap in prose: dates and features with a diagnosis bolted on afterward
- Goals presented as strategy: "be the leading platform for X", excluding nothing, guiding nothing
- The diagnosis that flatters the team: no fact that would surprise a new hire, no obstacle a competitor would recognize
- A strategy with no rejected alternative, so the recommendation reads as the only option ever considered
- The vision refreshed annually by a workshop and never referenced again between refreshes
- Vision and strategy merged into one document, so neither can be planned against nor proven wrong
- A strategy no single team could act on differently tomorrow, whatever it says about next year

## Exit gate

The vision and then the strategy open DEFINE in [../../os/OPERATING-LOOP.md](../../os/OPERATING-LOOP.md) and are approved at Gate 2 in [../../os/STAGE-GATES.md](../../os/STAGE-GATES.md), the vision by the business sponsor and the strategy by the product owner and the business sponsor; the strategy explains the bets that fill [../../templates/planning/roadmap.md](../../templates/planning/roadmap.md). Do not report either done until the vision's non-goals carry reasons and revisit conditions, the strategy names at most three bets each with a refused column, the one load-bearing bet has a stated falsification condition, both documents carry a date and a review date, and [../strategy-critic/SKILL.md](../strategy-critic/SKILL.md) has run its attack pass.

## What checks this

Some checks on this skill run automatically and some depend on a person. This section says which is which. It is generated by `python3 tools/what_checks.py` from the declarations it links to, and CI fails when it falls out of date.

- **Checked by CI on every commit.** This file must carry the seven sections every prose skill carries: `python3 tools/skill_rubric.py --min 7` fails the `skill-rubric` gate in `python3 tools/ci_gate.py` when one is missing. That checks structure, not whether the advice is right.
- **Checked by the runtime.** This skill is declared against Gate 1 in [SKILL.graph.yml](SKILL.graph.yml). Gate 1 is recorded with `pmos gate --bank-id discover`, which refuses the proof unless every question in that bank has been accepted and the bank is the current one, requires the proof to name its `source`, `source_sha256`, `actor_id`, `requester_id`, `decision` and `approved_at`, and rejects self-approval and any approver the bank does not pin. Approver ids are typed, not authenticated, so a recorded approval is a local attestation, not proof of who signed. If the proof's source changes after approval the gate goes stale and nothing later completes until it is proved again. [The journey run](../../examples/journey-run.md) shows all six gates and a stale gate being proved again.
- **Checked by a person.** The runtime checks who approved and that the evidence has not changed. It does not check whether the reasoning in this skill's Workflow was followed well; that judgment belongs to the people who sign the gate. Gate 1 is signed by the product owner and the sponsor or lead who can stop this, per the sign-off tables in [os/STAGE-GATES.md](../../os/STAGE-GATES.md).