Product Vision
beta · Family strategy-docs · Phase undefined · Sizes lean, full · Formats canvas, narrative, prfaq · ~2,450 tokens
The document that says what future this product is trying to create, for whom, and why this team is the one to build it. It is judged not by how it reads but by whether it can be used to refuse something: a vision nobody has ever cited to say no is decoration.
Self-grade against this before circulating a draft. It takes about ten minutes and it is the last cheap moment to fix anything.
Use it for all three formats. The criteria are about what the document does, not how it is laid out, so they apply equally to a canvas, a narrative and a PR/FAQ. Where a format changes how a criterion is met, the row says so.
Deep background for every criterion is in product-vision_companion.md; a
worked pass is product-vision_example.md.
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 vision when the team faces choices that a roadmap cannot settle, when people who were not in the founding conversation need to make decisions consistent with it, when you are hiring or raising against a future rather than a feature set, or when prioritisation arguments keep reopening the same question.
Do not write one when any of these is true:
- You cannot name a single thing it would rule out. Then you do not yet have a destination, you have a direction, and writing it down will produce the wallpaper described in the companion’s section 7.
- What you actually need is a strategy. If the question is “which problems do we solve first”, that is strategy, and the vision is upstream of it. Companion section 8.
- What you actually need is a roadmap. If the question is “what ships when”, writing a vision will delay the answer without improving it.
- Nothing has changed and the last one still works. A strategy change is not a reason to rewrite a vision. If you are rewriting yearly, you are maintaining a roadmap under the wrong title.
- Honest caveat: no source found addresses whether a vision is worth writing for a very small team or a solo product. The practitioner literature assumes medium-to-large organisations. At small scale, judge it by the refusal test below rather than by alignment benefits that only appear at scale.
Picking a format and a size
Section titled “Picking a format and a size”| If the job is… | Use |
|---|---|
| Orient a team fast, and be quotable in a prioritisation argument | canvas, lean (4 sections) |
| The above, plus survive readers who were not in the room: funders, a board, an incoming leader | canvas, full (8 sections) |
| Make someone want this future: hiring, a founding team, a team that has lost the thread | narrative |
| Argue that the future is worth having at all, and surface objections early | PR/FAQ |
They are not tiers. A narrative is not a better canvas, and the canvas is not a summary of the narrative; they are different documents serving the same purpose. Companion section 4 explains why the library ships three rather than picking one.
The one test that outranks the rest
Section titled “The one test that outranks the rest”Can this document be used to refuse something?
Find a real request from the last year that somebody senior wanted and that this vision says no to. Point at the sentence that does the refusing.
If you cannot, stop grading and fix that first. Everything below improves a document that is already doing its job; this decides whether it is doing its job at all. A vision nobody has ever cited to decline anything is decoration, however good the prose. See companion section 1.
The rubric
Section titled “The rubric”Score each 0, 1 or 2. Under 17 out of 24 and this will not be cited in an argument. It will be pasted into an onboarding deck, admired once, and never opened again, which is the documented failure mode for this document type.
Rows 9 and 10 do not apply to the lean canvas, which omits Horizon and Review and Leaps of Faith by design. Grade the other ten and score against 14 out of 20.
| # | Criterion | 0 | 1 | 2 |
|---|---|---|---|---|
| 1 | It refuses something | Nothing is declined | Exclusions named, all uncontroversial | An exclusion someone actually proposed, and you can say who and when |
| 2 | It is picturable | No person, no scene | A generic user doing a generic thing | A named person in a specific hour, doing what they cannot do today |
| 3 | Imagery outweighs values | Value words only | Concrete detail present but buried under abstractions | Concrete detail dominates; the abstract value words fit on one hand |
| 4 | It excludes someone | “Business users”, “our customers” | A segment named, but nobody is ruled out | A real reader would read it and conclude “not me” |
| 5 | It gives a reason to believe | Credentials or ambition | An asset named that a competitor could also claim | Something a well-funded competitor could not copy next quarter, and it says why |
| 6 | It is not a mission | Would read identically after ten years of no progress | Future-facing, but describes the company rather than a changed world | Describes a state of the world that is currently untrue and would be visibly true if reached |
| 7 | It is not a roadmap | Named features or delivery dates | No features, but the horizon reads as a plan | Destination and horizon only; no sequence, no capability list |
| 8 | It is not a positioning statement | Compares the product to alternatives for a customer today | Mixes future state with present competitive claims | States the future; competitive material sits separately as context |
| 9 | It has a horizon and a trigger (canvas full only) | No date, no review | A date, but no trigger and no owner | A date, a named review point, and what would prompt a rewrite as distinct from a strategy change |
| 10 | Its assumptions are named (canvas full and narrative) | “Risks will be managed” | Assumptions listed, all comfortable | The assumption the author is most worried about, with the earliest signal that would disprove it |
| 11 | It is short enough to recall | Needs re-reading to summarise | Summarisable, but not from memory | Someone who read it once can state the destination without opening it |
| 12 | It survives its own authors | Only makes sense with verbal context | Understandable, but a new reader could not act on it | An incoming leader could use it to decline something without asking anyone |
Which rows apply to what. This bundle ships four variants and two rows grade a section that only some
of them contain, so scoring every variant against all twelve would penalise the choice of format rather
than the quality of the document. Row 9 needs a Horizon and Review section, which only the canvas full
variant has. Row 10 needs a place where assumptions are named: Leaps of Faith in canvas full, What Has to Be True in the narrative. The PR/FAQ has neither, by design.
| Document | Rows that apply | Maximum | Score against |
|---|---|---|---|
| canvas, full | all 12 | 24 | 17 |
| canvas, lean | 1-8, 11-12 (it carries no horizon or assumptions section) | 20 | 14 |
| narrative, full | 1-8, 10-12 (it names assumptions but sets no dated horizon) | 22 | 16 |
| prfaq, full | 1-8, 11-12 (its horizon and its assumptions live inside the FAQ answers, not as sections) | 20 | 14 |
Every threshold above is the same proportion of the available points as the headline 17 of 24.
Every cell above describes evidence, not a count. That is deliberate: a threshold you can clear by adding
items will be cleared by adding items. This library’s own bug-report research documents the mechanism for
defect counts, and a rubric row is the same kind of target. If you can satisfy a cell without improving the
document, the cell is written wrong.
Rows 6, 7 and 8 exist because these are the three artifacts a product vision is most often confused with, and each confusion has a different tell. Companion section 8 has the boundaries.
Format-specific checks
Section titled “Format-specific checks”Canvas. Is every cell doing work, or is one of them restating another? “Who it is for” and “what they need” collapsing into one thought is the usual sign the target group is not specific enough.
Narrative. Read it aloud. Any sentence that is hard to say aloud will be skimmed. Is it in the present tense throughout, from inside the future? Did a bullet list creep in? A list means you have started writing a canvas with worse formatting.
PR/FAQ. Would a customer recognise the headline as being about them? Is there a single word in the press release a customer would not use? Does the Internal FAQ contain a question you are actually afraid of, or only ones with comfortable answers? An easy FAQ is the tell that this document is marketing.
Failure signals to look for in the draft
Section titled “Failure signals to look for in the draft”- Every exclusion is comfortable. Section is theatre. Find one that costs something.
- The vision names a feature. It will be stale within two quarters, and readers will argue about the feature instead of the future.
- The business goal is a number with a date. That is a key result. It will age faster than the vision and make the vision look stale by association.
- Each team has its own version. Companion section 7; this is a documented failure, not a scaling strategy.
- You are rewriting it because the strategy changed. The strategy is supposed to change. If the destination moves every time the route does, it was never a destination.
- A quotation you did not check. This subject has an unusually bad attribution record, including one very famous line that its supposed author never wrote. Companion section 6.
When it is good enough
Section titled “When it is good enough”When someone who was not in the room can read it, tell you what the product is for, name a thing it rules out, and disagree with you about something specific.
Disagreement is the signal. A vision nobody can argue with has not said anything.
The artifacts
Section titled “The artifacts”product-vision_template-lean.md · ~2,450 tokens
---title: "{{product_name}} Product Vision"product: "{{product_name}}"owner: "{{who_owns_this_vision}}"horizon: "{{target_year_or_range}}"status: "{{draft_or_agreed}}"last_updated: "{{date}}"doc_type: product-visionsize: leanformat: canvassource_template: product-visionsource_template_version: 0.1.0---
<!--LEAN PRODUCT VISION (canvas format). The smallest vision that can still do a vision's job: the future youintend to create, who it is for and what they need, why this team is the one to build it, and what it rulesout. Four sections, one page. To grow it into a vision that has to survive people who were not in the room(see product-vision_template-full.md), ADD sections; never rename or reorder the ones below, because the fullvariant is a strict superset of this one.
THE TEST THIS DOCUMENT HAS TO PASS. A vision is not judged by how it reads. It is judged by whether anyonecan use it to refuse something. If it cannot be cited to kill a plausible feature request from someonesenior, it is decoration, however well written. That is why "What This Rules Out" is in the LEAN variant andnot an optional extra: it is the section that makes the other three usable.
THE FAILURE MODE TO EXPECT IS NOT BAD WRITING, IT IS DISUSE. The most commonly reported failure of productvisions is that they are written once, stored somewhere, and never consulted again. Nothing in a templatecan prevent that. What a template can do is make the vision short enough to remember and specific enough toargue with. See product-vision_companion.md section 7.
THIS IS ONE OF THREE FORMATS, AND THE CHOICE IS REAL.- This canvas orients people fast and gives them something citable.- product-vision_template-narrative-full.md is prose, for when the vision has to persuade rather than orient.- product-vision_template-prfaq-full.md is a launch announcement dated years out, for when the argument is whether this future is worth having at all.They are not sizes of one document; they are different documents serving one purpose, and the most citedauthority on product vision argues that a canvas alone cannot do what the narrative does. The library shipsall three rather than pretending that disagreement is settled. See product-vision_companion.md section 4.
WHAT A PRODUCT VISION IS, AND IS NOTIt describes a future state. It is NOT a mission (that describes present purpose), NOT a strategy (that isthe set of choices for getting there), NOT a roadmap (that is sequence and timing), and NOT a positioningstatement (that is how you stand against alternatives for a customer today). The vision/mission boundary isthe one practitioners get wrong most often. See product-vision_companion.md section 8.
HOW TO FILL THIS IN1. Read the comment under each heading: WHAT it wants, WHY it matters (with a pointer into product-vision_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 it with someone, not for them. The alignment argument is most of the value; the document is the residue of it.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-vision_guide.md, then DELETE every HTML comment. They are guidance, not content.-->
# {{product_name}} Product Vision
## The Vision
<!-- WHAT The future you intend to create, described as a state of the world rather than as a plan. Two or three sentences, or one memorable line plus a short paragraph. Write it so someone can picture it. WHY The one piece of evidence-backed advice in this whole subject is about this section: vision statements that carry a lot of concrete imagery and only a small number of abstract values are associated with better performance, and leaders in practice tend to do the opposite. Concrete picture, few abstractions. That finding studied leader RHETORIC rather than written documents and only its experimental half is causal, so treat it as a strong steer, not a law. Deep dive: product-vision_companion.md section 3 (The Vision) and section 6. ASK What is different about the world once this works? Who is doing what, that they cannot do today? If a stranger read only this paragraph, what would they picture? Which single word here is doing the most work, and is it a picture or an abstraction? GOOD "Anyone at Acme who has a question about the business can answer it themselves, in the time it takes to ask it out loud. The people who own the numbers stop being a queue in front of them." (a state of the world, in customer terms, picturable, no feature named) WEAK "To be the leading provider of best-in-class analytics solutions that delight our customers and drive value." (abstractions stacked on abstractions; nothing to picture, nothing to disagree with) TRAP Writing your mission here by mistake. A mission says what you do now and why you exist; a vision says what the world looks like when you have succeeded. If your sentence would still be true and unchanged in ten years of no progress, it is a mission. -->
{{the_vision}}
## Who It Is For, and What They Need
<!-- WHAT The specific people this future is for, and the need or problem it addresses for them. Name a group narrow enough to exclude someone. WHY A vision for everyone constrains nothing, and a vision that constrains nothing cannot be used to decline anything. Naming who this is NOT for is what gives the next section something to bite on. Deep dive: product-vision_companion.md section 3 (Who It Is For, and What They Need). ASK Who exactly? What do they do today instead, and what does that cost them? Who is explicitly not the target, even though they might use it? What need is durable enough to still exist in five years? GOOD "Operations and finance managers at mid-market companies who currently wait on a two-person analytics team. They need answers within a working session, not within a sprint. Not for professional analysts, who are better served by the query tools they already have." WEAK "Business users who need data." (excludes nobody, so it permits everything) TRAP Describing a market segment instead of a person with a problem. "Mid-market SaaS" is a place to sell, not a need to serve. -->
{{who_it_is_for_and_what_they_need}}
## Why Us
<!-- WHAT What makes this team or product the one that reaches this future, when others have not. An insight, an asset, a capability, or a bet about where the world is going. WHY This is what separates a vision from a wish. Without it, the document describes a future anyone could pursue, which gives a reader no reason to believe this one. Deep dive: product-vision_companion.md section 3 (Why Us). ASK What do we know, have, or believe that others do not? What has changed recently that makes this possible now when it was not before? If a well-funded competitor read this, what could they not simply copy next quarter? GOOD "We already sit inside the systems where the questions get asked, so we can answer them in context rather than in a separate tool. Every general-purpose analytics product has to import the data first; we do not." WEAK "Our team is world-class and deeply committed to customer success." (true of everyone who would ever write this sentence, and therefore evidence of nothing) TRAP Listing current features. Features are what you have built toward the vision, not the reason you will reach it. A feature list here dates the document within two quarters. -->
{{why_us}}
## What This Rules Out
<!-- WHAT The work this vision makes it correct to decline: directions, customer segments, or categories of feature that would serve someone else's future rather than this one. Two to five concrete examples, ideally ones somebody has actually proposed. WHY THIS IS THE SECTION THAT DECIDES WHETHER THE DOCUMENT IS REAL. The sharpest available test of a product vision is whether it can be used to refuse a feature request from an influential stakeholder. A vision that has never been cited to say no is not guiding anything, whatever else it is doing. Deep dive: product-vision_companion.md section 3 (What This Rules Out) and section 7. ASK What has been proposed in the last year that this future says no to? Which adjacent market are we deliberately not entering? What would we refuse even if a large customer paid for it? If nothing comes to mind, is the vision specific enough to rule anything out at all? GOOD "We are not building a general-purpose query builder; that serves analysts, and analysts are not who this is for. We are not pursuing the enterprise compliance-reporting market, which needs audit guarantees this future does not require. We would decline a bespoke data warehouse integration for a single large account, because it moves us toward being a services business." WEAK "We will stay focused and avoid distractions." (names nothing, refuses nothing, and will never be quoted in a real argument) TRAP Listing only things nobody wanted to do anyway. If every exclusion is uncontroversial, the section is theatre. At least one entry should be something a reasonable colleague would argue for. -->
{{what_this_rules_out}}product-vision_template-full.md · ~4,000 tokens
---title: "{{product_name}} Product Vision"product: "{{product_name}}"owner: "{{who_owns_this_vision}}"horizon: "{{target_year_or_range}}"status: "{{draft_or_agreed}}"last_updated: "{{date}}"next_review: "{{date_or_trigger}}"doc_type: product-visionsize: fullformat: canvassource_template: product-visionsource_template_version: 0.1.0---
<!--FULL PRODUCT VISION (canvas format). The lean vision plus everything needed for it to survive contact withpeople who were not in the room: the competitive context that explains why this future is not alreadysomeone else's, the business goals that stop it being borrowed grandeur, an explicit horizon with a reviewtrigger, and the assumptions it rests on. This is a strict superset of product-vision_template-lean.md;every lean section appears here unchanged and in the same order.
USE FULL WHEN the vision will be handed to an incoming leader, cited in a funding conversation, read by aboard, or used to justify declining something expensive. Use lean when a small team needs a shareddestination it can cite in a prioritisation argument. See product-vision_companion.md section 4.
THE TEST THIS DOCUMENT HAS TO PASS is the same at either size: can it be used to refuse something? If itcannot be cited to kill a plausible request from someone senior, it is decoration, however well written.
THIS IS ONE OF THREE FORMATS. The canvas orients and is citable;product-vision_template-narrative-full.md persuades; product-vision_template-prfaq-full.md argues that thefuture is worth having. They are different documents serving one purpose, not sizes of one document, andthe library ships all three because the two most-cited authorities on product vision genuinely disagreeabout whether a canvas can do this job. See product-vision_companion.md section 4.
HOW TO FILL THIS IN1. Read the comment under each heading: WHAT it wants, WHY it matters (with a pointer into product-vision_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 it with the people who will have to live by it. The alignment argument is most of the value.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-vision_guide.md, then DELETE every HTML comment.-->
# {{product_name}} Product Vision
## The Vision
<!-- WHAT The future you intend to create, described as a state of the world rather than as a plan. Two or three sentences, or one memorable line plus a short paragraph. Write it so someone can picture it. WHY The one piece of evidence-backed advice in this whole subject is about this section: vision statements that carry a lot of concrete imagery and only a small number of abstract values are associated with better performance, and leaders in practice tend to do the opposite. Concrete picture, few abstractions. That finding studied leader RHETORIC rather than written documents and only its experimental half is causal, so treat it as a strong steer, not a law. Deep dive: product-vision_companion.md section 3 (The Vision) and section 6. ASK What is different about the world once this works? Who is doing what, that they cannot do today? If a stranger read only this paragraph, what would they picture? Which single word here is doing the most work, and is it a picture or an abstraction? GOOD "Anyone at Acme who has a question about the business can answer it themselves, in the time it takes to ask it out loud. The people who own the numbers stop being a queue in front of them." WEAK "To be the leading provider of best-in-class analytics solutions that delight our customers and drive value." (abstractions stacked on abstractions; nothing to picture, nothing to disagree with) TRAP Writing your mission here by mistake. A mission says what you do now and why you exist; a vision says what the world looks like when you have succeeded. If your sentence would still be true and unchanged in ten years of no progress, it is a mission. -->
{{the_vision}}
## Who It Is For, and What They Need
<!-- WHAT The specific people this future is for, and the need or problem it addresses for them. Name a group narrow enough to exclude someone. WHY A vision for everyone constrains nothing, and a vision that constrains nothing cannot be used to decline anything. Naming who this is NOT for is what gives "What This Rules Out" something to bite on. Deep dive: product-vision_companion.md section 3 (Who It Is For, and What They Need). ASK Who exactly? What do they do today instead, and what does that cost them? Who is explicitly not the target, even though they might use it? What need is durable enough to still exist in five years? GOOD "Operations and finance managers at mid-market companies who currently wait on a two-person analytics team. They need answers within a working session, not within a sprint. Not for professional analysts, who are better served by the query tools they already have." WEAK "Business users who need data." (excludes nobody, so it permits everything) TRAP Describing a market segment instead of a person with a problem. "Mid-market SaaS" is a place to sell, not a need to serve. -->
{{who_it_is_for_and_what_they_need}}
## Why Us
<!-- WHAT What makes this team or product the one that reaches this future, when others have not. An insight, an asset, a capability, or a bet about where the world is going. WHY This is what separates a vision from a wish. Without it, the document describes a future anyone could pursue, which gives a reader no reason to believe this one. Deep dive: product-vision_companion.md section 3 (Why Us). ASK What do we know, have, or believe that others do not? What has changed recently that makes this possible now when it was not before? If a well-funded competitor read this, what could they not simply copy next quarter? GOOD "We already sit inside the systems where the questions get asked, so we can answer them in context rather than in a separate tool. Every general-purpose analytics product has to import the data first; we do not." WEAK "Our team is world-class and deeply committed to customer success." (true of everyone who would ever write this sentence, and therefore evidence of nothing) TRAP Listing current features. Features are what you have built toward the vision, not the reason you will reach it. A feature list here dates the document within two quarters. -->
{{why_us}}
## Market and Competitive Context
<!-- WHAT What exists today that people use instead, why those alternatives do not reach this future, and what is changing in the market that makes now the moment. Include the honest option of "they do nothing" or "they use a spreadsheet", which is usually the real incumbent. WHY A vision written without this reads as though the future is unoccupied. It almost never is, and a reader who knows the market will discount the whole document if it pretends otherwise. This is also the section that stops a vision quietly describing a future a competitor has already reached. Deep dive: product-vision_companion.md section 3 (Market and Competitive Context). ASK What do our target users do today instead? Which alternatives are structurally unable to get where we are going, and why? What shift (technical, regulatory, behavioural) opens this window, and could it close? Who else is aiming at this same future? GOOD "Today these questions go to a shared analytics inbox, or into a spreadsheet that is copied and diverges. General-purpose BI tools can answer them but require modelling work our users cannot do, so adoption stalls at the analyst. The shift we are riding is that operational systems now expose usable APIs, which is what makes answering in context possible at all." WEAK "The analytics market is large and growing, with several established players." (market sizing, not competitive reasoning; tells the reader nothing about why this future is reachable by us) TRAP Naming competitors and asserting they are worse. State what their approach structurally cannot do. "Slower and clunkier" is an opinion that ages badly; "requires a modelling step our users cannot perform" is a claim with a mechanism. -->
{{market_and_competitive_context}}
## What This Rules Out
<!-- WHAT The work this vision makes it correct to decline: directions, customer segments, or categories of feature that would serve someone else's future rather than this one. Two to five concrete examples, ideally ones somebody has actually proposed. WHY THIS IS THE SECTION THAT DECIDES WHETHER THE DOCUMENT IS REAL. The sharpest available test of a product vision is whether it can be used to refuse a feature request from an influential stakeholder. A vision that has never been cited to say no is not guiding anything, whatever else it is doing. Deep dive: product-vision_companion.md section 3 (What This Rules Out) and section 7. ASK What has been proposed in the last year that this future says no to? Which adjacent market are we deliberately not entering? What would we refuse even if a large customer paid for it? If nothing comes to mind, is the vision specific enough to rule anything out at all? GOOD "We are not building a general-purpose query builder; that serves analysts, and analysts are not who this is for. We are not pursuing the enterprise compliance-reporting market, which needs audit guarantees this future does not require. We would decline a bespoke data warehouse integration for a single large account, because it moves us toward being a services business." WEAK "We will stay focused and avoid distractions." (names nothing, refuses nothing, and will never be quoted in a real argument) TRAP Listing only things nobody wanted to do anyway. If every exclusion is uncontroversial, the section is theatre. At least one entry should be something a reasonable colleague would argue for. -->
{{what_this_rules_out}}
## Business Goals
<!-- WHAT What reaching this future is worth to the organisation, in the organisation's own terms: revenue, retention, market position, cost, strategic option. Not metrics with targets, which belong to strategy and OKRs; the outcome the business is buying. WHY This is the section that catches borrowed grandeur, the named failure mode where a team writes a vision far larger than its actual ambition or resources. Stating the business outcome forces the vision to be one the company would actually fund. It is also the honest place to admit that the vision serves the company and not only the customer. Deep dive: product-vision_companion.md section 3 (Business Goals). ASK Why would the company invest years in this rather than something else? What does it unlock that is hard to get another way? If we reach this future, what is measurably different about the business? Would the company fund this at the scale the vision implies? GOOD "Self-service answers remove the analytics team as a bottleneck on every other product decision, which is the constraint on how fast the rest of the portfolio can move. Commercially, it changes us from a reporting add-on into the system of record for operational questions, which is a renewal argument rather than a feature argument." WEAK "Increase revenue and improve customer satisfaction." (true of every product ever funded) TRAP Putting KPI targets here. A number with a date is a key result and belongs in the OKR set; it will be stale long before the vision is, and its staleness will make the vision look stale too. -->
{{business_goals}}
## Horizon and Review
<!-- WHAT How far out this future sits, and the explicit trigger for revisiting it. A date, plus the kinds of learning that would justify a rewrite. WHY The dominant failure of product visions is not that they are wrong, it is that they are written once and never read again. A named review trigger is the cheapest available defence. On horizon, practitioner guidance clusters around a few years out for software and longer for hardware, but there is no evidence behind those numbers and the two most-cited authorities disagree; the useful framing is that a one-year vision is a roadmap and a ten-year one drifts from reality. Deep dive: product-vision_companion.md section 3 (Horizon and Review) and section 6. ASK By when do we expect this to be true? What would have to happen for this vision to be wrong rather than merely behind schedule? Who reviews it, and when is the next one? What learning would change it, as opposed to changing the strategy underneath it? GOOD "Horizon: 2029, roughly three years out. Reviewed each October alongside annual planning, and immediately if either of the leaps of faith below is disproven. A strategy change does not trigger a rewrite; the strategy is expected to change several times on the way here." WEAK "This is a long-term vision that we will revisit periodically." (no date, no trigger, no owner, so nobody will) TRAP Treating every strategy change as a reason to rewrite the vision. If the destination moves every time the route does, it was never a destination. -->
{{horizon_and_review}}
## Leaps of Faith
<!-- WHAT The assumptions this vision rests on that you cannot yet prove, stated plainly, with what would tell you each one is wrong. WHY An ambitious multi-year vision cannot be validated before you commit to it; if it could, it would not be ambitious. Naming the unproven parts is what separates a considered bet from wishful thinking, and it is what makes the review trigger above actionable. It also protects the document: a vision that turns out to be wrong for a stated reason is a good decision that did not work, while one that was never examined is just a mistake. Deep dive: product-vision_companion.md section 3 (Leaps of Faith) and section 6. ASK What must be true about our users for this future to matter to them? What must be true about the technology or the market? Which of these is most likely to be wrong? What is the cheapest signal that would tell us early? GOOD "We assume non-analysts will trust an answer they did not derive themselves, which is the biggest unknown; the early signal is whether pilot users act on answers or re-check them with the analytics team. We assume operational APIs stay open enough to read in context; the signal is vendor rate-limit and licensing changes." WEAK "Some risks exist and we will monitor them." (no assumption named, so nothing can be disproven) TRAP Listing only comfortable assumptions. If none of them frightens anyone, the real bet is still unstated and the section has made the vision look examined without examining it. -->
{{leaps_of_faith}}product-vision_template-narrative-full.md · ~2,900 tokens
---title: "{{product_name}} Product Vision"product: "{{product_name}}"owner: "{{who_owns_this_vision}}"horizon: "{{target_year_or_range}}"status: "{{draft_or_agreed}}"last_updated: "{{date}}"doc_type: product-visionsize: fullformat: narrativesource_template: product-visionsource_template_version: 0.1.0---
<!--PRODUCT VISION, NARRATIVE FORMAT. Prose, two to four pages, written to be read start to finish rather thanscanned. This is a DIFFERENT DOCUMENT from product-vision_template-full.md, not a longer one: it shares noneof the canvas headings, and the gate deliberately asserts no nesting relationship between the two formats.
WHY THIS FORMAT EXISTS. The practitioner who has written most directly about the product vision, MartyCagan, argues explicitly against filling in a canvas for this job, on the grounds that a strong vision is awork of persuasion closer to storytelling than to form-filling. The library ships the canvas anyway, becausea canvas is teachable and a canvas can be cited in an argument. It ships this too, because his objection isa real one and the reader deserves the option he is actually advocating. See product-vision_companion.mdsection 4 for the disagreement, stated in both parties' own words.
WHEN TO REACH FOR IT. When the vision has to make someone WANT the future rather than merely understand it:a hiring conversation, a founding team, a board that has to fund years of work, a team that has lost thethread. A canvas states a future. Prose can make someone believe it is worth their next three years.
RULES THAT MAKE THIS FORMAT WORK, AND THAT THE CANVAS DOES NOT NEED1. WRITE IT IN THE PRESENT TENSE, FROM INSIDE THE FUTURE. Not "users will be able to", but "Priya opens the dashboard and sees". The tense is the technique; it forces concrete detail and exposes vagueness fast.2. NAME A PERSON AND FOLLOW THEM. One named user living one specific hour is worth more than a paragraph about "customers". The single piece of evidence-backed advice in this subject is that vision language rich in concrete imagery is associated with better performance than language rich in abstract values, and that leaders tend to do the opposite. That finding studied leader RHETORIC rather than written documents and only its experimental half is causal, so treat it as a strong steer rather than a law; companion section 6.3. NO BULLET LISTS, NO TABLES, NO HEADINGS BEYOND THE FIVE BELOW. The moment it becomes scannable it becomes a canvas with worse formatting. If you find yourself wanting a list, you are writing the other format.4. NO FEATURE NAMES. A feature dates the document in two quarters and invites the reader to argue about the feature instead of the future.5. IT MUST STILL BE ABLE TO REFUSE SOMETHING. Persuasion is not a licence for vagueness; the fourth section is not optional and is the test the canvas is also judged by.
HOW TO FILL THIS IN1. Draft the first section in one sitting without stopping to edit. This form rewards a voice.2. Read it aloud. Every sentence that is hard to say aloud is a sentence a reader will skim.3. Replace each {{placeholder}} with your prose.4. Before you share it: self-grade against product-vision_guide.md, then DELETE every HTML comment.-->
# {{product_name}}: {{short_evocative_line}}
## Open in the Future
<!-- WHAT Two or three paragraphs describing an ordinary hour in the world once this has worked, in the present tense, following one named person. Start in the middle of their day, not with context. WHY This is the whole reason to choose this format. A reader who can picture the future argues about whether it is worth reaching; a reader given abstractions argues about the abstractions. The imagery-over-values finding applies most sharply here. Deep dive: product-vision_companion.md section 3 (The Vision) and section 4 (narrative format). ASK What hour of whose day am I describing? What are they doing in the first sentence? What is present in this scene that does not exist today, and what is absent that exists today? Would a reader who knows nothing about us still picture it? GOOD "It is a Tuesday and Priya, who runs fulfilment, wants to know why the north-east region slipped last week. She asks, in the same window where she noticed the problem, and has an answer before the thought has gone. She does not file a request. Nobody is waiting on Dev, who used to be the only person who could have told her, and who is now doing something harder and more interesting." WEAK "In the future, our platform will empower business users to access insights seamlessly and drive data-informed decisions across the enterprise." (no person, no hour, nothing to picture, and it could describe any analytics product written in the last fifteen years) TRAP Opening with the problem statement or the market. Those belong later. The scene has to land first, or the reader reads the rest as a pitch rather than a place. -->
{{open_in_the_future}}
## The People There
<!-- WHAT Who this future is for, widened out from the one person in the opening scene, and what they need badly enough that they would change their habits for it. One or two paragraphs. Say plainly who it is not for. WHY The scene establishes that the future is desirable; this establishes that it is desirable to a specific, findable group rather than to everyone in principle. A vision for everyone constrains nothing. Deep dive: product-vision_companion.md section 3 (Who It Is For, and What They Need). ASK How many Priyas are there, and where do they work? What do they do today instead, and what does it cost them in time or in decisions not made? Who would read the opening scene and correctly conclude this is not for them? GOOD "There are a few dozen Priyas in a company like hers and a few hundred thousand across the mid-market: people who own an operational number, are measured on it weekly, and cannot get at it without asking someone. This is not for professional analysts. They already have better tools than we will ever build, and they are not waiting on anyone." WEAK "Our target users are business decision-makers who value data." (excludes nobody) TRAP Sliding into persona documentation. This is a paragraph about people, not a spec sheet about segments; the persona document is a different artifact and lives elsewhere. -->
{{the_people_there}}
## Why This Falls to Us
<!-- WHAT Why this team reaches that future when others have not, and why now rather than five years ago. One or two paragraphs of argument, not of credentials. WHY Without this the narrative is a nice story about a future anyone could build, which gives the reader nothing to believe in beyond the writing. This is the section that turns a story into a bet. Deep dive: product-vision_companion.md section 3 (Why Us). ASK What do we know or have that others do not? What changed recently that opens this? What could a well-funded competitor not simply copy next quarter? Why has nobody done it already, and is that reason going away? GOOD "The reason nobody has done this is that answering a question in context requires already being in the context, and analytics tools have always started by copying the data somewhere else. We start from inside the operational systems, which is an accident of where we came from and the one thing a general-purpose competitor cannot adopt without becoming a different company." WEAK "We have a world-class team, deep domain expertise, and a track record of execution." (a sentence available to anyone, and therefore evidence of nothing) TRAP Reciting credentials instead of making an argument. Nobody has ever been persuaded of a future by a team's CVs; they are persuaded by a reason the future is reachable from here. -->
{{why_this_falls_to_us}}
## What We Are Not Doing
<!-- WHAT The futures this one excludes, in prose. Two to four concrete refusals, at least one of which a reasonable colleague would argue for. WHY THE NARRATIVE FORMAT IS JUDGED BY THE SAME TEST AS THE CANVAS: can this be used to refuse something? Prose makes it easier to be moving and easier to be vague, and this section is the guard against the second. A vision nobody has ever cited to say no is decoration in any format. Deep dive: product-vision_companion.md section 3 (What This Rules Out) and section 7. ASK What has been proposed in the last year that this future says no to? What would we decline even if a large customer paid for it? If the answer is nothing, is the future above specific enough to be a destination at all? GOOD "We are not building a query builder. Every conversation about this eventually produces someone asking for one, and every time we build one we are building for the analysts we just said this is not for. We are also not going after compliance reporting, which needs guarantees this future does not, and which would quietly turn us into an audit vendor over about two years." WEAK "We will remain focused on our core mission and resist the temptation to do everything." (refuses nothing in particular and will never be quoted in a real argument) TRAP Refusing only things nobody wanted. If every exclusion is comfortable, this section has made the document look disciplined without costing anything. -->
{{what_we_are_not_doing}}
## What Has to Be True
<!-- WHAT The assumptions this future rests on that cannot yet be proven, and the horizon you are working to. One or two paragraphs, plainly stated, including the one that worries you most. WHY Buying into an ambitious vision is unavoidably an act of faith: if it could be validated in advance it would not be ambitious. Saying so, and naming what would disprove it, is what makes this a considered bet rather than optimism, and it is what lets the vision be revisited honestly instead of defended. Deep dive: product-vision_companion.md section 3 (Leaps of Faith). ASK What must be true about these people for this to matter to them? About the technology? About the market? Which of those is most likely to be wrong, and what would be the earliest cheap signal? By when do we expect this to be real? GOOD "The bet that keeps me up is whether someone who did not derive an answer will act on it. Every part of this depends on that, and we will know early: if pilot users take the answer to Dev to check it, we have built a faster way to generate work for the analytics team. We are working to about three years, and reviewing this each October or sooner if that signal turns." WEAK "There are of course risks and uncertainties, which we will manage as they arise." (names no assumption, so nothing can ever be shown to be wrong) TRAP Listing only assumptions you are confident about. The section exists to expose the fragile one; a comfortable list makes the vision look examined without examining it. -->
{{what_has_to_be_true}}product-vision_template-prfaq-full.md · ~2,100 tokens
---title: "{{product_name}} Product Vision"product: "{{product_name}}"owner: "{{who_owns_this_vision}}"dateline: "{{future_date_two_to_three_years_out}}"status: "{{draft_or_agreed}}"last_updated: "{{date}}"doc_type: product-visionsize: fullformat: prfaqsource_template: product-visionsource_template_version: 0.1.0---
<!--PRODUCT VISION, PR/FAQ FORMAT. A launch announcement written as though the future has already happened,dated years ahead, followed by the questions it provokes. This is a DIFFERENT DOCUMENT from the canvas andthe narrative, not a longer one, and the gate asserts no nesting relationship between formats.
WHERE THIS COMES FROM, STATED CAREFULLY. The working-backwards PR/FAQ is an Amazon practice, described atbook length by Colin Bryar and Bill Carr in Working Backwards (2021). No source this library could read namesan individual as its originator, and the practice is best described as one that emerged at Amazon rather thanone that was invented by a named person. It also predates any of the product-vision literature and was notdesigned as a vision format: it defines a specific launch. Using it for a multi-year vision is a practitionerextension, and a good one, but the library says so rather than implying Amazon prescribed it. Seeproduct-vision_companion.md sections 2 and 4.
WHEN TO REACH FOR IT. When the live question is whether this future is worth having at all. Writing theannouncement first forces the benefit into customer language before any engineering path exists, and the FAQforces the objections out while they are still cheap. It is the most uncomfortable of the three formats towrite, which is the point: a future that cannot be announced in plain language usually is not a future, it isa roadmap with ambition.
RULES THAT MAKE THIS FORMAT WORK1. DATE IT IN THE FUTURE AND WRITE IN THE PAST AND PRESENT TENSE. The launch has happened. No "will".2. THE HEADLINE MUST BE ABOUT THE CUSTOMER, NOT THE PRODUCT. If it names a feature, start again.3. NO INTERNAL VOCABULARY. If a phrase would need explaining to a customer, it fails here, and its presence usually means the benefit has not been found yet.4. THE FAQ IS WHERE THE DOCUMENT EARNS ITS KEEP. A press release with an easy FAQ is marketing. Put the questions you are afraid of in it.5. IT MUST STILL BE ABLE TO REFUSE SOMETHING. The Internal FAQ carries that job here.
HOW IT IS READ. This format is conventionally reviewed by having the room read it in silence first, thendiscuss. If you are writing one, plan for that: it has to stand on its own for twenty minutes without younarrating it.
HOW TO FILL THIS IN1. Write the headline and the first paragraph twenty times before writing anything else. That is the work.2. Replace each {{placeholder}} with your content.3. Before you share it: self-grade against product-vision_guide.md, then DELETE every HTML comment.-->
# {{product_name}}: {{customer_benefit_headline}}
## Press Release
<!-- WHAT A one-page announcement dated {{future_date}}, written as though the future described has shipped. Headline, one-line subhead naming who it is for, a first paragraph stating the benefit, two or three paragraphs on the problem and how the world is different now, a quote from a customer, a quote from you, and how to get started. WHY Writing the announcement first is the entire mechanism of this format: it makes you state the benefit in the customer's language before you have permission to talk about how it is built, and an unwritable press release is an early and cheap signal that the future is not compelling. Deep dive: product-vision_companion.md section 4 (PR/FAQ format). ASK What is the headline a customer would actually care about? Who is the subhead naming? If a reader stopped after the first paragraph, would they know what changed and for whom? Is there a single word here a customer would not use? GOOD Headline: "Acme customers now answer their own operational questions in under a minute." Subhead: "For the operations and finance managers who used to wait on an analytics queue." First paragraph: "Starting today, anyone at a company using Acme can ask a question about their own numbers in the tool where they noticed the problem, and get an answer while they are still thinking about it." WEAK Headline: "Acme launches next-generation AI-powered analytics platform." (about the product and its technology, not about anyone's day; and it would have been written the same way in any of the last five years) TRAP A customer quote that no customer would say. If your quote contains "leveraging" or a product name used as a verb, it is you talking. Write what Priya would say to a colleague. -->
{{press_release}}
## Customer FAQ
<!-- WHAT The questions a customer or user asks after reading the release. Six to ten, with real answers. Include the awkward ones: what it costs, what it does not do, what happens to their existing way of working, whether they can trust the answers. WHY The press release states the benefit; this establishes it is a benefit under scrutiny rather than in a brochure. It is also where the vision's boundaries first become visible to an outsider. Deep dive: product-vision_companion.md section 4 (PR/FAQ format). ASK What would a sceptical user ask in the first two minutes? What does this NOT do that they might assume it does? What do they have to give up or change? Why should they believe the answers are right? GOOD "Q: How do I know the answer is correct? A: Every answer shows the rows behind it and the filter that produced it, and you can open them. We expect people to check the first few and then stop; the point is that checking is possible, not that it is required." WEAK "Q: Is it easy to use? A: Yes, extremely." (a question nobody asks and an answer nobody believes) TRAP Only asking questions you have good answers to. The FAQ that is comfortable to write is the one that was not worth writing. -->
{{customer_faq}}
## Internal FAQ
<!-- WHAT The questions the organisation asks: why this and not something else, what it rules out, what has to be true, what it costs, what happens if the central assumption is wrong, and how far out this is. Six to twelve, with honest answers including the ones that are "we do not know yet". WHY THIS IS WHERE THIS FORMAT MEETS THE TEST THE OTHER TWO ALSO FACE: can the document be used to refuse something? The Internal FAQ is also the only part of a PR/FAQ that carries the business case, the horizon, and the leaps of faith, all of which the canvas format gives dedicated sections. If you skip it, you have written marketing rather than a vision. Deep dive: product-vision_companion.md section 3 (What This Rules Out, Business Goals, Leaps of Faith). ASK What are we deliberately NOT building, and what has been proposed that this says no to? Why is this worth years rather than the alternative use of the same people? What must be true that we cannot prove? What would tell us early that we are wrong? By when do we expect this to be real, and when do we next review it? GOOD "Q: Are we building a query builder? A: No, and we will keep being asked. A query builder serves analysts, and the release above is explicitly not for analysts. Q: What is the biggest thing we are assuming? A: That someone who did not derive an answer will act on it. If pilot users take answers to the analytics team to verify, we have built a faster way to create work for that team, and the vision is wrong rather than early." WEAK "Q: What are the risks? A: As with any ambitious initiative, there are execution risks that we will manage carefully." (names nothing, refuses nothing, disproves nothing) TRAP Letting this section become a project plan. Resourcing and sequencing belong to the strategy and the roadmap; what belongs here is why the destination is worth the journey and what would change our minds about it. -->
{{internal_faq}}---title: "Acme Analytics Product Vision"product: "Acme Analytics"owner: "Dana Okoro, VP Product"horizon: "2029 (about three years)"status: "agreed"last_updated: "2026-01-14"next_review: "October 2026, or immediately if either leap of faith below is disproven"doc_type: product-visionsize: fullformat: canvassource_template: product-visionsource_template_version: 0.1.0---
> **Worked example.** A filled `product-vision`, full variant, canvas format, for the same Acme Analytics> product used by the `prd`, `test-plan`, `test-case` and `bug-report` examples. **This document is the top of> that chain:** the FY26 "Time to Insight" company goal those examples cite descends from the vision below,> so the library now holds one continuous thread from a product vision down to a defect report and the> regression that guards it.>> Read it alongside [`product-vision_guide.md`](product-vision_guide.md), which is the rubric it was graded> against. Notice what it does **not** contain: no feature names, no dates other than the horizon, and no> numeric targets. Those belong to the strategy, the roadmap and the OKR set.
# Acme Analytics Product Vision
## The Vision
By 2029, anyone at a company running Acme can answer a question about their own operations in the time ittakes to ask it out loud, in the place where the question occurred to them.
Priya runs fulfilment. She notices that the north-east region slipped last week, asks why in the same screenwhere she noticed it, and has an answer before the thought has gone. She does not file a request, does notwait for a sprint, and does not learn a query language. Dev, who is currently the only person who could haveanswered her, is no longer a queue. He is doing the harder work of deciding what the company should measureat all.
The change we are trying to create is not faster reporting. It is the end of the waiting period betweennoticing something and understanding it.
## Who It Is For, and What They Need
Operations, fulfilment and finance managers at mid-market companies: people who **own a number**, are measuredon it weekly, and today cannot get at it without asking someone else. There are a few dozen of them in acompany the size of Priya's and a few hundred thousand across our market.
What they need is an answer inside the working session in which they had the question. Not within a sprint,not by Thursday. The cost of the current gap is not the analyst's time, it is the decisions that never getmade because the question was not worth the wait.
**This is not for professional analysts**, meaning people whose job is analysis and who already havededicated query tools. They are not blocked on anyone, and building for them is how products like thisquietly become something else. We will keep saying this, because the request to serve them arrives abouttwice a year and always from someone senior.
*A note for readers following the sibling examples:* the Saved Views PRD serves a **Recurring Analyst**persona, which is a different group and is not the exclusion above. A Recurring Analyst returns to the samedashboards on a cadence and is exactly who this vision is for; a professional analyst writes queries onother people's behalf and is not.
## Why Us
The reason nobody has solved this is structural. Answering a question in context requires already being inthe context, and every general-purpose analytics product begins by copying the data somewhere else. By thetime the data has arrived in the analytics tool, the context in which the question was asked is gone, and sois the person who asked it.
We start from inside the operational systems, because that is where Acme began and where our integrationsalready live. That is an accident of history rather than a strategy, but it is the one thing ageneral-purpose competitor cannot adopt without becoming a different company.
The window opened because operational systems now expose APIs rich enough to read in context. That was nottrue five years ago.
## Market and Competitive Context
Today the question goes to a shared analytics inbox, or into a spreadsheet that gets copied and thendiverges. **The real incumbent is the spreadsheet and the favour**, not a product.
General-purpose BI tools can answer these questions and are better at the hard ones. They require a modellingstep our users cannot perform, so adoption reliably stalls at the analyst, which is the same bottleneck in amore expensive form. Embedded-analytics vendors are closer to us, but they sell to the software vendor ratherthan to the operator, so the questions they answer are the ones the vendor anticipated.
Two things could close this window: operational vendors restricting API access, or a general-purpose toolsolving the modelling problem well enough that non-analysts can use it directly. We watch both.
## What This Rules Out
- **We are not building a general-purpose query builder.** Every roadmap conversation eventually produces a request for one. It serves analysts, and we have just said analysts are not who this is for.- **We are not entering enterprise compliance reporting.** It needs audit and retention guarantees this future does not require, and pursuing it would reshape the product around a different buyer within two years.- **We would decline a bespoke warehouse integration for a single large account**, even at a price that looks good in a quarter, because each one moves us toward being a services business.- **We are not building a mobile app** while the questions we serve are asked at a desk, in a working session, with the operational system already open.
The first of these has been argued for twice by the sales leadership, most recently in November, and declinedon the strength of this section. That is the only evidence that matters for whether this document works.
## Business Goals
Removing the analytics team as a bottleneck is the constraint on how fast the rest of the portfolio can move.Every other product decision at Acme currently queues behind the same two people.
Commercially, this changes what we are. A reporting add-on is a feature that competes on price at renewal. Asystem where the operational questions get asked and answered is where the work happens, and that is adifferent conversation with a different person at a different point in the contract.
The strategic option we are buying is the right to be the place operators go first. We do not need to own thewarehouse to be that.
## Horizon and Review
**Horizon: 2029, about three years out.** Long enough that we cannot see the whole path, short enough thatthe people reading this expect to still be here.
Reviewed each October alongside annual planning, and immediately if either leap of faith below is disproven.
**A strategy change does not trigger a rewrite.** We expect the strategy to change several times on the wayhere, and it already has once: the FY26 plan pivoted from breadth of integrations to depth in two verticalswithout changing a word of this document. If we find ourselves rewriting the vision every planning cycle, theproblem is that it was a roadmap.
## Leaps of Faith
**The one that keeps me up: that someone who did not derive an answer will act on it.** Everything abovedepends on it, and we cannot know in advance. The early signal is cheap and we are watching it in the pilot:if users take our answers to Dev to check them, we have not removed a bottleneck, we have built a faster wayto create work for it. Three of eleven pilot users currently do this. We need to understand whether thatnumber falls with familiarity or is a floor.
**That operational APIs stay open enough to read in context.** Signal: vendor rate-limit and licensingchanges, reviewed quarterly. Two vendors tightened limits in 2025 and both were negotiable, which isreassuring but not evidence.
**That the mid-market will not simply hire the analyst.** If the cost of analytical headcount falls farenough, the problem we are solving becomes cheaper to solve with people. We think this is unlikely within thehorizon and we are not currently monitoring it, which is a gap worth naming.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: 16 sections across 3 format(s), methodology methodology-agnostic, typically owned by Product Manager (contrib: exec, design, eng).