9.1 Product Vision
Key Takeaways
- Product vision expresses the product’s purpose: the value it intends to deliver and to whom over a long horizon
- Vision is broader and longer-term than the Product Goal; the Product Goal is the current long-term objective committed in the Product Backlog
- A useful vision informs Product Goal selection, backlog ordering, stakeholder alignment, and go/no-go decisions about what not to build
- The Product Owner develops and communicates direction so the Scrum Team and stakeholders can align—vision is not a wall poster owned by marketing alone
- Vision without empiricism becomes a fantasy roadmap; vision plus inspection of outcomes keeps the product oriented while the backlog remains emergent
9.1 Product Vision
Managing products with agility starts with direction. Before the Scrum Team can maximize value Sprint by Sprint, people need a shared sense of why this product exists, who it serves, and what success looks like far enough ahead to focus investment. That is the role of product vision in Professional Scrum Product Owner practice.
The Scrum Guide 2020 does not define “Product Vision” as a formal artifact or commitment. The formal commitment of the Product Backlog is the Product Goal. PSPO I still expects you to use vision correctly: as the broader purpose that informs goals, ordering, and stakeholder alignment—not as a substitute for the Product Goal, not as a fixed multi-year feature list, and not as something only executives own while the Product Owner is a scribe.
What Product Vision Is For
| Question vision answers | Example framing |
|---|---|
| Purpose of the product | Why does this product exist in the market or organization? |
| Value delivered | What outcomes, capabilities, or results matter? |
| To whom | Which users, customers, or beneficiaries? |
| Why it is worth pursuing | What problem, opportunity, or strategic bet justifies the work? |
A strong vision is directional, not a project plan. It paints a desired future relationship between the product and the people it serves. It should be concrete enough that the Scrum Team can reject work that does not serve the direction—and inspiring enough that stakeholders understand the bet.
Purpose, value, and audience (keep them linked)
Vague slogans fail on exams and in practice:
| Weak vision signal | Stronger vision signal |
|---|---|
| “Be the best app in our category” | “Help first-time home buyers complete financing decisions with confidence without a specialist” |
| “Digitally transform the enterprise” | “Give field technicians one place to complete jobs, capture evidence, and close tickets the same day” |
| “Increase revenue 40%” (metric only) | “Become the default self-serve upgrade path for mid-market customers who currently need sales-assisted renewals” |
Metrics can support vision, but vision is not only a KPI. Vision explains value and for whom so trade-offs make sense when the Product Goal and backlog are ordered.
Vision vs. Product Goal (Exam-Critical Distinction)
| Concept | Horizon & nature | Scrum Guide status | Primary use |
|---|---|---|---|
| Product vision | Broader, longer-term purpose of the product | Common practice language; not a formal Guide artifact/commitment | Align people on purpose; guide strategy and Goal selection |
| Product Goal | Current long-term objective for the Scrum Team—a future state of the product | Commitment of the Product Backlog | Focus multi-Sprint work; rest of backlog emerges to fulfill it |
| Sprint Goal | One Sprint objective | Commitment of the Sprint Backlog | Focus a single Sprint |
Key implications:
- Vision is broader — it may outlive several Product Goals as the product learns and the market shifts.
- Product Goal is the current long-term objective in the Product Backlog — more concrete and nearer than unbounded vision; longer than a Sprint.
- You do not “commit” to five visions at once — and you also do not run multiple concurrent Product Goals. Vision guides; the Product Goal focuses.
- Ordering the Product Backlog should advance progress toward the Product Goal, which itself should be a coherent step within the vision—not a random feature dump under a slogan.
Exam trap: Treating a vision slide deck as if it were the Product Goal commitment, or treating the Product Goal as a permanent unchangeable vision statement that never gets fulfilled or abandoned.
How Vision Informs the Product Goal and Backlog Ordering
Vision does useful work when it constrains and focuses decisions:
1. Selecting or refining the Product Goal
Given a vision of “self-serve confidence for first-time buyers,” a Product Goal might be: “New applicants can complete a pre-qualification path end-to-end without calling support.” That Goal is a future state of the product the team can plan against. When fulfilled or abandoned, a new Goal can express the next coherent step under the same vision (for example, decision-ready document packages).
2. Ordering the Product Backlog
The Product Owner orders items so the sequence best advances the Product Goal and product value. Vision and the Product Goal answer: of all possible improvements, which ones move the product’s purpose forward now? Items that are popular with one stakeholder but orthogonal to the vision/Goal lose relative order—even if they are easy.
3. Saying no (or not yet)
A clear vision makes “no” a product decision rather than a personality conflict. The Product Owner remains accountable for maximizing value and for effective backlog management; vision is part of the story that justifies order and deselection.
4. Aligning stakeholders without committee ownership of the backlog
Stakeholders inspect outcomes and provide input. They do not reorder the Product Backlog by vote. Vision is a communication tool the Product Owner uses so stakeholders understand direction and can contribute insight—not a mandate for multiple unofficial Product Owners.
Product Owner: Develop and Communicate Direction
PSPO competencies emphasize that the Product Owner develops and communicates a direction stakeholders and the Scrum Team can align on. That is active work:
| PO practice | Why it matters |
|---|---|
| Craft and evolve the vision with evidence from users, market, strategy, and technology | Direction without learning becomes dogma |
| Make vision visible and discussable | Hidden direction cannot align anyone |
| Connect vision → Product Goal → top backlog items | People see the chain from purpose to next Sprint |
| Use Sprint Review evidence to check whether the direction still holds | Empiricism may refine vision or trigger Goal change |
| Protect a single product boundary | One product, one Product Backlog, one Product Owner—vision does not justify fragmented “sub-product owners” for one product |
Who “owns” vision?
In organizations, strategy and brand groups may help form vision. For Scrum accountability, the Product Owner is still accountable for maximizing the value of the product resulting from the work of the Scrum Team and for effective Product Backlog management. If vision lives only in a C-suite deck the PO cannot use, transparency and ordering collapse. If the PO is treated as a requirements clerk with no authority to communicate direction, the organization is not respecting the Product Owner accountabilities.
Vision and Empiricism (Do Not Freeze the Future)
Complex work means you cannot predict every feature years ahead. Vision must coexist with emergence:
- The Product Backlog remains emergent—it is not a frozen multi-year specification of the vision.
- Increments and Sprint Reviews provide inspectable outcomes; adapt the backlog and, when evidence warrants, adapt the Product Goal or even refine the vision.
- “We wrote the vision in 2022, so every item on that roadmap is mandatory” fights Scrum.
- “We have no vision, so every stakeholder request is equal” also fights focus.
Healthy pattern: stable enough direction to focus, adaptive enough goals and backlog to learn.
| Anti-pattern | Better |
|---|---|
| Vision = 200-item three-year roadmap treated as scope contract | Vision = purpose and audience; roadmap is a forecast that changes with evidence |
| Vision rewritten every Sprint with no continuity | Vision evolves thoughtfully; Product Goal may change when fulfilled/abandoned |
| Vision owned by marketing; PO only takes tickets | PO develops/communicates direction used for ordering and Goal |
| Multiple competing visions for one product | One product boundary, one PO, one backlog; resolve strategic conflict transparently |
Practical Vision Checklist for PSPO I Scenarios
When a scenario mentions “direction,” “strategy,” “why we build this,” or “alignment,” ask:
- Is there a clear purpose, value, and audience?
- Is vision being confused with the Product Goal commitment?
- Does the PO communicate direction so the Scrum Team can make coherent Sprint proposals?
- Does ordering of the backlog serve that direction via the current Product Goal?
- Are stakeholders aligned and informed, or are they secretly running a second backlog?
- Is the team still using empiricism rather than treating vision as unchangeable scope?
If vision is inspiring but never touches Goal or order, it is decoration. If every feature is justified as “the vision,” vision is being used as a political shield. PSPO I rewards the middle path: purpose that focuses value decisions.
Quick Self-Check
- Vision = long-horizon purpose: value, for whom, why the product exists
- Broader than Product Goal; Product Goal is the backlog’s formal long-term objective
- Vision informs Goal selection and backlog ordering; does not replace either
- PO develops and communicates direction stakeholders can align on
- Empiricism still rules: inspect outcomes; adapt Goal and backlog; do not freeze a fantasy roadmap
How should a Product Owner treat product vision relative to the Product Goal under the Scrum Guide 2020 model?
What is the Product Owner’s primary responsibility regarding product vision in Managing Products with Agility practice?
A stakeholder insists every item on a three-year vision roadmap must stay ordered exactly as written despite new user evidence. What is the best Product Owner response?