Skip to content
Back to the journal

Essay

097

Product Strategy

11 min read

097 / 141

Product Vision: Define the Future Without Pretending to Predict It

Build a product vision as a bounded, evidence-aware future state that clarifies strategic choices, exclusions, assumptions, and the conditions for revision.

Updated July 13, 2026

Topics Product strategy Roadmapping Prioritization

Share this essay

“Make work simpler for everyone” is difficult to oppose and almost impossible to use.

It does not identify whose work, which harmful condition should disappear, what kind of future the product is trying to create, or which attractive opportunities sit outside it.

A product vision is not valuable because it sounds ambitious. It is valuable when people can use the same future state to make coherent choices without treating one solution as destiny.

That requires more than a sentence. A practical vision is a bounded claim about a desirable future, the population and problem in scope, the strategic beliefs behind it, and the evidence that could force revision.

Give vision one job

Vision is often asked to carry mission, strategy, positioning, goals, roadmap, culture, and employee motivation at once. The result is language broad enough to accommodate everything.

Use a narrower distinction:

  • Mission: the enduring contribution the organisation exists to make.
  • Product vision: the future condition this product seeks to make possible for a defined population.
  • Strategy: the choices about where to play, how to create an advantage, and which capabilities or constraints matter now.
  • Goal: a bounded result that should change within a useful period.
  • Roadmap: the current sequence of bets and commitments in service of strategy.

These are working definitions, not universal terminology. An organisation may use different names. What matters is that the artefacts do different decision work.

Vision should describe a future worth pursuing without deciding every step. If it already names the platform, interface, technology, and launch sequence, the team may be protecting a solution rather than a future state.

The vision-to-roadmap guide covers the later translation into strategy, goals, opportunities, sequence, dependencies, and commitment states.

Write a vision contract before polishing the sentence

Start with a structured record. The short statement can be written last.

Population and situation

Who should experience the future, in which context? Name users, affected people, buyers, or operators when their interests differ.

“Teams” is rarely enough. A hospital department coordinating regulated work and a small creative studio may share software features while needing different futures.

Current condition

What consequential constraint, cost, risk, or exclusion exists now? Describe the state, not a missing feature.

“Customers lack an AI assistant” is a proposed solution. “Reviewers cannot identify which evidence supports a high-consequence decision” describes a condition that several solutions might change.

Desired future state

What should become reliably possible or meaningfully different? Use language observable enough that future teams can debate whether progress is real.

Avoid pretending that the vision is a guaranteed forecast. The organisation is choosing to pursue this future, not claiming privileged knowledge that it will arrive.

Strategic reason

Why is this product and organisation a credible participant? Which capability, access, trust, data, distribution, or learning advantage makes the future more than a wish?

Boundaries

Which populations, problems, business models, harms, or product roles are deliberately outside the vision? Which principles cannot be traded away to reach it?

Assumptions and review triggers

What must remain true about the problem, environment, capability, and value? Which evidence would narrow, expand, or invalidate the vision?

Ownership and horizon

Who can interpret and revise the vision? How far ahead must it guide choices, and why is that horizon appropriate to the market and product?

The record prevents a memorable sentence from carrying hidden disagreement.

Test clarity as shared interpretation

Clear language is necessary but not sufficient. Different functions can read the same words and infer incompatible products.

Lynn and Akgün first studied 13 innovations at Apple, IBM, and HP, then tested their project-vision components with 509 new-product teams.

They examined clarity, support or agreement, and stability. The associations with success varied by innovation type; no component was uniformly associated across incremental, evolutionary, and radical projects.

The study concerns project vision and self-reported team settings from its period. It does not validate a modern product-vision template or establish simple causality.

It does challenge one-size-fits-all advice. Stability can support one kind of work and become rigidity in another; clarity may matter differently when uncertainty is radical.

Test shared interpretation with decisions, not paraphrasing:

  1. Give several people the same contested product choices independently.
  2. Ask which choices the vision supports, rejects, or leaves unresolved.
  3. Ask what evidence would change their judgement.
  4. Compare the reasoning, not only the votes.

Disagreement can reveal an unclear phrase, a missing boundary, or a genuine strategy question the vision should not answer.

Do not rewrite the vision until everybody agrees with every decision. A useful vision coordinates direction; it does not delete professional judgement.

Build the vision from evidence and choice

A vision should reach beyond current requests without floating free of reality.

Use several evidence streams:

  • recurring user problems, workarounds, and excluded populations;
  • changes in technology, regulation, channels, and alternatives;
  • product behaviour and service evidence;
  • organisational capabilities and constraints;
  • strategic options the team could pursue instead;
  • material counterevidence and affected-party concerns.

Evidence does not mechanically produce a vision. Leaders still choose which future deserves commitment and which risks are acceptable.

Make that judgement visible. Record rejected alternatives and why the chosen future is preferable under current evidence.

The market-analysis guide helps examine the surrounding customer, alternative, channel, dependency, and regulatory system before the future is declared.

Keep the future separate from the mechanism

A vision can imply necessary properties without prescribing the complete product.

If the future requires people to contest automated decisions, contestability is a product property. “Build a conversational AI review screen” is one mechanism.

If the vision depends on cross-organisation trust, evidence provenance may be essential. A specific ledger technology is not automatically part of the vision.

For each proposed capability, ask:

  • Which part of the desired future requires it?
  • Is the requirement about an outcome, property, or chosen solution?
  • Which alternatives could satisfy the same need?
  • Which assumption makes this mechanism preferable now?
  • Can the mechanism change while the vision remains intact?

This is how vision guides architecture and product choices without freezing them.

Make exclusions do real work

A vision that excludes nothing is an umbrella for opportunism.

Write non-goals at the same level as the future. Examples might include becoming the system of record, serving individual consumers, automating final authority, or replacing specialist judgement.

Then test incoming opportunities against those exclusions.

An opportunity outside the vision is not automatically bad. It may belong to another product, require a deliberate vision change, or expose that the current boundary is wrong.

What should not happen is silent expansion: one profitable exception at a time until the product serves a future nobody consciously chose.

The boundary-setting guide explains how to expose the displaced commitment, authority, and reopen condition when an adjacent request appears.

Do not measure vision with one proxy

Vision operates over a longer horizon than most product metrics. A single number will usually capture only one signal or one stage in the mechanism.

Build an evidence portfolio:

  • outcome evidence for the population in scope;
  • mechanism evidence showing whether the expected change is occurring;
  • reach and exclusion evidence showing who benefits or remains outside;
  • business and capability evidence showing whether the model can endure;
  • counter-signals for harms and strategic drift;
  • assumption evidence for the beliefs most likely to fail.

Do not invent a “vision score.” The evidence may conflict, mature at different rates, and support revision rather than a pass or fail.

The important question is whether the organisation is learning enough to continue pursuing this future responsibly.

Share ownership without erasing authority

People execute a vision more coherently when they have contributed evidence, interpretation, and objections. That does not mean every word needs consensus or that authority should be hidden.

Pearce and Ensley studied 71 product and process innovation teams longitudinally. They found reciprocal relationships among shared vision, innovation effectiveness, and team dynamics over time.

The design does not establish a one-way intervention: “create shared vision and innovation will improve.” The reciprocal result suggests that shared vision can be both an influence on and a product of team experience.

Invite affected functions and users to challenge the proposed future. Ask them where the statement hides conflict, shifts cost, assumes capability, or excludes a legitimate need.

Then name the decision owner. Participation without a visible point of authority can produce a compromise sentence that nobody is accountable for defending or revising.

Review on evidence, not ritual

Quarterly rewriting makes a vision behave like a goal. Permanent language turns it into doctrine.

Review when a material assumption changes:

  • the problem weakens or appears in a different population;
  • technology changes what is possible or safe;
  • regulation, channel, or market structure moves;
  • the organisation gains or loses a required capability;
  • progress repeatedly contradicts the expected mechanism;
  • harms or exclusions become unacceptable;
  • the desired future is substantially achieved.

Distinguish a wording correction from a boundary change. A material revision should record the new evidence, affected strategy and commitments, dissent, and transition implications.

Benassi, Amaral, and Ferreira used exploratory and systematic literature reviews to propose a product-vision framework with textual and visual elements plus concise, challenging, strategy-aligned, and collectively obtained properties.

The authors explicitly state that the construct needs further practical validation. Treat those properties as research-informed prompts, not a certified checklist.

A fictional vision under pressure

Consider a fictional product used by regulated service teams to review evidence before approving high-consequence work.

The first draft says: “Make approvals effortless with intelligent automation.” It hides the affected population, treats less effort as the only value, and assumes automation is the future.

The vision contract produces a different direction:

People responsible for consequential approvals can reach and explain a decision without reconstructing evidence across disconnected systems, while final authority remains contestable and human-owned.

The population, current condition, desired future, and authority boundary are visible. The statement still does not determine whether the solution uses search, workflow redesign, structured evidence, automation, or several mechanisms.

One assumption is that explanation and provenance remain important to buyers and affected people. A review trigger covers regulation or evidence that a different authority model is required.

No adoption result, performance improvement, or commercial outcome is invented. The example shows how a vision can guide choices while leaving the strategy and solution open to evidence.

Audit whether the vision is alive

Take recent roadmap, architecture, sales, and exception decisions. For each one, ask:

  • Which part of the vision changed the reasoning?
  • Did two teams infer incompatible futures?
  • Was an exclusion applied or bypassed?
  • Which assumption was tested?
  • Did a short-term commitment narrow the future accidentally?
  • Is the evidence portfolio showing progress, harm, or drift?
  • Does the organisation know who can revise the vision?

If the vision appears only in presentations, improve the operating links before rewriting the prose.

A product vision should not predict the future with confidence. It should make one desirable future, its boundaries, and the organisation’s current beliefs clear enough to choose—and clear enough to challenge.

Sources

Related books

If you want to go further on this topic, these are two good places to start.

02

leadership

An Elegant Puzzle

by Will Larson

A human-centric guide to solving complex problems in engineering management, from sizing teams to handling technical debt to managing organizational growth.

Some outbound links are affiliate links and support independent bookstores.