Skip to content

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.
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.


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.


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.


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.


  • 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 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.

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-vision
size: lean
format: canvas
source_template: product-vision
source_template_version: 0.1.0
---
<!--
LEAN PRODUCT VISION (canvas format). The smallest vision that can still do a vision's job: the future you
intend to create, who it is for and what they need, why this team is the one to build it, and what it rules
out. 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 full
variant 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 anyone
can use it to refuse something. If it cannot be cited to kill a plausible feature request from someone
senior, it is decoration, however well written. That is why "What This Rules Out" is in the LEAN variant and
not 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 product
visions is that they are written once, stored somewhere, and never consulted again. Nothing in a template
can prevent that. What a template can do is make the vision short enough to remember and specific enough to
argue 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 cited
authority on product vision argues that a canvas alone cannot do what the narrative does. The library ships
all three rather than pretending that disagreement is settled. See product-vision_companion.md section 4.
WHAT A PRODUCT VISION IS, AND IS NOT
It describes a future state. It is NOT a mission (that describes present purpose), NOT a strategy (that is
the set of choices for getting there), NOT a roadmap (that is sequence and timing), and NOT a positioning
statement (that is how you stand against alternatives for a customer today). The vision/mission boundary is
the one practitioners get wrong most often. See product-vision_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-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}}

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).