Skip to content

Product Vision

At a glance

  • Purpose: State why the product exists, for whom, and how you will know it worked — before a backlog turns that into features.
  • Use it when: Before building a product backlog, and whenever the team cannot explain what it is delivering in business terms. Revisit it when scope debates become emotional.
  • Owner: The product owner, agreed with the sponsor and key users.
  • Related: Module 04 · Lab 14

How to use this template

  1. Write the outcome statement first, in one sentence. If you cannot, the product's purpose is not agreed yet and no backlog will fix that.
  2. Name the target users specifically. "Everyone" produces a product for nobody.
  3. Define how success will be measured with a baseline and a target. "Improve satisfaction" is not a measure; "reduce average form completion errors from an observed baseline of 12% to under 5%" is.
  4. List what you will deliberately not do in this release — the vision's most useful section when someone proposes a well-argued feature.
  5. Re-read it at each release boundary. A vision that never changes is either very stable or ignored.

Field descriptions

Field What goes in it Watch out for
Outcome statement What changes for the user, in one sentence A feature list wearing a sentence's clothes
Target users The primary users, and their context Secondary beneficiaries listed as primary
Problem The current situation and its cost Assuming the problem without evidence
Success measures Baseline, target, and how it is captured Measures with no baseline, so no target can be judged
Non-goals What this release deliberately excludes A non-goals list nobody proposed
Constraints Time, budget, regulatory, technical Constraints invented by the team
Assumptions What the vision depends on being true Assertions disguised as vision statements

Blank template

# Product Vision — [Product name]

| | |
| --- | --- |
| **Version** | [1.0] |
| **Date** | [YYYY-MM-DD] |
| **Owner** | [Product owner] |
| **Reviewed with** | [Sponsor, key users] |

## 1. Outcome statement

For [target users], who [situation or problem], [product] will [the change it creates],
so that [the benefit]. Unlike [current alternative], it [the distinguishing difference].

## 2. Target users

| User group | Context | What they need |
| --- | --- | --- |
| [Group] | [Where and how they work] | [Need, not feature] |

## 3. The problem today

[The current situation, how it costs time, money, or quality, and the evidence you have for it.
State clearly which parts are evidence and which are assumptions.]

## 4. Success measures

| Measure | Baseline | Target | How it is captured | When |
| --- | --- | --- | --- | --- |
| [Measure] | [Current value, or "unknown — to be established"] | [Target] | [Method] | [Date] |

## 5. What this release will not do

- [Non-goal, with the reason it is excluded now]

## 6. Constraints and assumptions

| Type | Statement | If it turns out untrue |
| --- | --- | --- |
| Constraint | [Limit] | [Consequence] |
| Assumption | [Belief] | [Consequence] |

## 7. Review record

| Date | Change | Reason |
| --- | --- | --- |

Worked example

From Lab 14, on the e-commerce platform — illustrative, with invented baselines:

For returning customers who abandoned a basket, who currently have no way to tell whether an item is orderable, the stock visibility feature will show expected availability on the product page, so that they can decide before investing time in checkout. Unlike the current practice of surfacing a stock error at the final step, it answers the question before the customer commits.

Measure Baseline Target How captured
Checkout abandonment attributed to stock errors Unknown — no instrumented baseline exists Establish baseline in the first two weeks Event logging added in the first increment
Support tickets asking whether an item is in stock 40 per week (observed) Under 15 per week Ticket category count

Note that the first measure honestly records that no baseline exists. Inventing "20%" for a project that has never measured it is the most common integrity failure in a vision document — and it is why the first increment here is instrumentation, not the feature.

Common mistakes

  • A feature list in disguise. "A modern, mobile-first shop with search, reviews, and a loyalty programme" describes a build, not an outcome.
  • No baseline. A target without a baseline cannot be evaluated, so nobody can tell whether the product worked.
  • Everyone as the target user. Designing for everyone is designing for no one.
  • Vision treated as a substitute for a backlog. The vision sets direction; it does not sequence work.
  • Written once, filed away. If the team cannot recite the outcome statement, it has not been communicated.
  • Solution specified before the problem is agreed. When a vision names a technology, the problem is usually still unstated.