Product vision and strategy: give your team a shared direction
Product vision describes the change you want to create for customers. Strategy explains who you will serve, how you will help them and what takes priority. Their value becomes clear when the team faces competing requests. This guide shows how to establish a clear direction, turn it into decisions you can test and keep it useful in everyday work.
Sales wants a new integration, support wants an easier ordering process and leadership wants another customer segment. Every request may have a reasonable basis. Without a shared direction, the latest meeting or loudest voice wins. A completed task list does not explain why the company should invest in this particular combination of changes.
Throughout this guide, we use a fictional ordering product for small businesses. The examples are illustrative, not results from a client project. The working approach can be adapted to your team. It is neither a mandatory template from one methodology nor a promise that a document alone will deliver commercial success.
01Distinguish vision, strategy, goals and the work plan
Vision describes a desirable future for the customer. Strategy contains the choices intended to reach it within the company’s circumstances. Goals define the progress you want to assess. A roadmap shows the sequence of work and expected outcomes. A backlog holds more detailed items. Mixing these levels makes every button change look like a change to the entire strategy.
Marty Cagan of SVPG distinguishes choosing problems strategically from discovering their solutions. A brief should therefore explain the reason for a priority before listing features. “Improve repeat ordering” leaves room to find a suitable solution. “Add three screens” describes an output without explaining its value.
| Level | Question | Illustrative example |
|---|---|---|
| Vision | How should the customer’s work change? | A small business replenishes the right stock without lengthy searches. |
| Strategy | Which situations will we focus on? | Start with repeat orders from existing customers. |
| Goal | How will we recognise useful progress? | Check completion of a correct order without additional correction. |
| Roadmap | What must precede what? | First data availability, then journey validation and a pilot. |
| Backlog | What specific work will we do? | Add missing states, prototype the flow and check data. |
02Gather evidence before defining the direction
Start with customer situations you can substantiate. Review interviews, real task completion, recurring support questions, reasons for lost business and operational constraints. Record where each finding came from and whom it concerns. One strongly expressed request from a major client does not automatically represent the whole market.
Separate observation from interpretation. “The customer called to confirm availability” is an observation. “We need a chatbot” is already a proposed solution. First establish whether information was missing, untrustworthy or difficult to find. The same symptom may call for different changes to data, content or the business process.
Alongside customer needs, map the company’s capabilities. The product requires available inputs, operational support and a financially sustainable way of delivering the service. Document existing commitments too. A strategy relying on immediate contract changes, an unavailable partner interface or nonexistent capacity must first address those assumptions.
03Express the vision as a clear change
Try writing the vision in everyday language: whose important situation will change, and how will it improve? “Become an innovative leader in the digital market” gives a team little guidance. For our example, the vision could be: “Help small businesses replenish stock with confidence that they are ordering what they actually need.”
That sentence does not yet require a mobile app, AI or a particular subscription model. It leaves room to explore solutions. At the same time, it is specific enough to discuss whether a new request helps the intended customer. Add a short account of the current and future situation if the sentence alone feels too abstract.
Check whether the vision is credible and meaningful to real people. The team must be able to explain the problem in its own words. A vision is neither an advertising promise of guaranteed results nor a substitute for validating demand. For initial validation, see our guide from idea to MVP.
04Make real choices in your strategy
Choose an initial customer group, a specific problem and a reason your company can offer a suitable solution. For the ordering product, existing relationships and reliable order history could be advantages. The strategy might therefore prioritise repeat replenishment, while acquiring entirely new customers receives a different priority.
State what you will leave out during the current period. A deferred segment or feature is not forbidden forever. You do need a clear reason for keeping attention focused now. Record the consequence and the condition for reconsidering each choice. An unexplained “not yet” can easily become a promise at the next sales meeting.
Check alignment with the business model. The user, decision-maker and payer may be different people. If a member of staff places an order but the owner approves the budget, the strategy must address both roles. Making one role’s work easier should not quietly add work for another.
05Name the assumptions behind the direction
For every important choice, state what must be true for it to work. Our fictional product assumes customers want to repeat previous orders and that historical data can identify the right goods. The first claim concerns behaviour; the second concerns data availability and quality. Testing only the easier assumption is insufficient.
Rank assumptions by uncertainty and the consequences of being wrong. Choose a suitable test for the key uncertainty: an interview about a specific situation, observation, a prototype, a manual pilot or a technical experiment. A clickable prototype can reveal a confusing journey, but cannot prove supplier reliability or willingness to pay over time.
Decide in advance how the findings will affect your choices. If a failed test can never change a priority, it is not providing meaningful decision evidence. Record what was supported, what remains uncertain and what needs to change. Explicit uncertainty is more useful than a confident estimate with no documented basis.
06Turn direction into outcomes you can assess
Choose an outcome that reflects the customer’s task and connect it to a business need. In our example, a correctly accepted order requiring no subsequent correction is more useful than the number of screens opened. Define the baseline, population, time period and data source. Set a target only once those conditions are understood.
Add a balancing measure alongside the main indicator. Faster ordering is unhelpful if errors, returns or support enquiries increase. Fewer calls do not automatically mean success if customers have simply stopped ordering. Assess value together with quality and any costs you may have shifted to another part of the company.
If the team uses Scrum, the Scrum Guide makes the Product Owner accountable for communicating the Product Goal. This goal describes a future state of the product. Do not automatically equate it with the company’s long-term vision. This article proposes a general working approach that can also be used outside Scrum.
07Use the roadmap to show dependencies and confidence
A roadmap helps people agree on sequencing, dependencies and expected outcomes. Near-term steps may have a specific scope and date; more distant intentions need explicit assumptions. If partner data availability remains unknown, presenting the subsequent automation as equally certain as an already validated form repair is not credible.
Separate a firm external commitment from a working estimate. A mandatory system migration deadline may require a smaller scope. A new feature without a validated need requires room to change the solution. Both sales and development must understand what can be promised to customers and what is still for internal planning.
For each significant initiative, explain its contribution to the strategy. This does not mean excluding maintenance, security or technical prerequisites for future development. Those activities have their own justification and capacity needs. Make them visible so the product plan does not assume people are free when they are already responsible for operations.
08Create a concise document people can act on
A shared reference can be short if it contains the decisive information and links to evidence. A sentence on a poster cannot settle a priority dispute. A lengthy presentation is equally unhelpful if nobody can locate the current decision. Maintain one findable version with an owner, date and history of significant changes.
| Document section | Illustrative content | What the team must add |
|---|---|---|
| Customer and situation | Small businesses repeatedly order supplies. | The business types, roles and occasions included. |
| Value | Correct replenishment with less searching. | How the task works today and where errors occur. |
| Strategic choice | Start with repeat orders from existing clients. | Why this segment and which alternatives are deferred. |
| Uncertainty | Past orders may not reflect current needs. | How to test the assumption and who decides whether to continue. |
| Outcome and checks | Correct order completion, errors and support demand. | Definitions, baselines and evaluation conditions. |
| Ownership | One decision owner, with sales and operations involved. | Names, authority, capacity and the next review. |
09Use a workshop to make choices, not polish a slogan
Send participants the evidence and proposed questions before the meeting. Include people who understand customers, operations, economics and technical constraints. They do not all need joint authority over every detail. You do need to identify obstacles before a proposal becomes a public commitment.
First establish a shared understanding of the problem. Then compare genuine alternatives and their consequences. In our example, these could be existing customers versus a new segment, or self-service versus assisted ordering. If the discussion only adjusts the wording of one preselected option, the fundamental choice has been left outside the conversation.
End with a record of decisions, open questions and owners of further validation. Do not hide disagreement behind a broader sentence that everyone appears to accept. Sometimes the right outcome is a short investigation before the final choice. Specify who will then decide and on what basis.
10Test communication through concrete dilemmas
Explain the problem, chosen direction, reasons and boundaries. Give an example of work that will happen sooner because of the strategy, and a request that will be deferred. Sales, customer support and any external supplier also need that explanation. Each influences the promises customers hear.
Instead of asking “Is that clear to everyone?”, present a real dilemma. Should the team expand the catalogue, improve repeat ordering or add another approval step first? Ask colleagues to explain their choice and the evidence they lack. Different conclusions may reveal an unclear priority rather than an unwillingness to cooperate.
Bring the direction into routine decisions: initiative briefs, outcome reviews, onboarding and scope discussions. A single presentation rarely resolves later questions. Keep recording explanations and rejected alternatives so newcomers do not have to reconstruct the same arguments from scratch.
11Clarify ownership and decision-making authority
Name an owner for the product’s direction and explain their authority. Also define which questions the team can resolve independently and when leadership must decide. Choosing a particular interface may belong to the team; a major change in target customers or pricing may require a broader decision. The boundaries should fit your organisation.
With several teams, identify shared outcomes and dependencies. One team must not improve its metric by passing errors to another. If teams use different definitions of an accepted order, a shared vision will not resolve conflicting reports. For the organisational aspect, see scaling a product team.
Give an external supplier access to context and a way to raise risks. A list of screens without their purpose can encourage precise delivery of a brief that no longer addresses the problem. Distinguish consultation, approval of a change and a binding order for work. Strategy alone does not amend the parties’ commercial agreement.
12Review the direction and explain changes
Choose a review rhythm that reflects product uncertainty and the availability of results. A new pilot may need more frequent decisions than an established service. Alongside scheduled reviews, define triggering events: a substantial change in needs, an invalidated key assumption, changed economics or an unavailable dependency.
During a review, separate changes to the solution from changes to the strategy and vision. One unsuccessful screen is not, by itself, a reason to abandon the customer’s problem. Conversely, a need that remains unsupported over time requires more than a new design. Customer journey mapping can help identify obstacles across related steps.
- The team can name the customer, problem and expected change.
- The strategy includes priorities and justified deferrals.
- Key assumptions have a validation method and an owner.
- Outcomes have definitions, baselines and balancing measures.
- The roadmap distinguishes commitments, estimates and untested possibilities.
- The current document is findable and changes are explained.
- New decisions reach the work, communication and responsibilities.
13Common questions about product vision and strategy
Does a small team need a vision?
Yes. Small teams also have to choose between competing requests. The supporting document can be brief. What matters is a shared understanding of customers, value and priorities, rather than page count or a dedicated strategy department.
How long should a product vision be?
Try expressing the main idea in one clear sentence, supported by a short story. There is no universal word count. If the team needs more context to make decisions, keep it alongside the strategy and supporting evidence.
Is strategy the same as a roadmap?
No. Strategy explains the choice of customers, problems and approach. A roadmap helps sequence the work. A feature plan can exist without a clear strategy, but it then becomes difficult to explain why that particular work takes priority.
Do we need OKRs or Scrum?
Not to define a shared direction. Choose an approach that fits the team. If you use a framework, respect its terminology and accountabilities. Renaming an ordinary task list as OKRs does not create a measurable customer outcome.
Who should approve the strategy?
Choose an accountable owner according to the company’s structure and the significance of the decision. Involve leadership and people who understand customers, operations and technology. Collaborative preparation does not require a unanimous vote on every detail.
How do we know the team understands the direction?
Ask colleagues to explain the reason for a priority and resolve a concrete dilemma. Check whether they can identify missing information and a reason to defer a request. Simply repeating the same slogan is insufficient evidence of understanding.
When should the strategy change?
When new evidence challenges a fundamental assumption or circumstances change substantially. Record what changed and how it affects priorities. Avoid deciding solely on one unsuccessful iteration, but do not retain an old plan only because work has already been invested in it.
14Sources and the scope of this working approach
The distinction between vision and strategic approach draws on Marty Cagan’s Vision vs. Strategy and Product Strategy Overview. Product Goal terminology and Product Owner accountability follow the Scrum Guide 2020.
The ordering product, working tables, review questions and communication scenarios are original illustrations for this article. They contain neither client-specific data nor measured improvements. Adapt these principles to the business model, team size and evidence actually available.