Product Strategy vs Roadmap vs Vision: What Each One Decides

Ask five product people to define vision, strategy and roadmap, and you will get five answers that overlap just enough to be dangerous. In one company the “roadmap” is a list of features with dates. In the next it is a slide of themes. In a third the “strategy” is the roadmap with a nicer title. These are not harmless differences in vocabulary. When the three collapse into one document, a team loses the ability to ask the questions each one exists to answer, and the cost shows up as misaligned work, endless prioritization debates and a roadmap that changes every time a senior person has an idea.

I have written and been handed all three in many shapes across ten years in strategy consulting, market intelligence and product. The clearest mental model I have found is simple: the vision says where and why, the strategy says how we will win, and the roadmap says what and when. The rest of this post makes that sentence usable, with the questions each document answers, who owns it, how long it lasts, what breaks when it is missing, and a worked example you can copy.

If you want the full method for writing the middle layer, how to write a product strategy that actually gets implemented is the companion to this post.

The one-paragraph version

Product vision describes the future you are trying to create for customers and why it matters. It is a destination and a reason. It changes rarely, perhaps every few years.

Product strategy is the set of choices that will get you toward the vision given your market, your customers and your resources: where you will play, how you will win, and what you will not do. It changes when the evidence changes, usually reviewed every quarter and rewritten every six to twelve months.

Product roadmap is the sequence of work that carries out the strategy: what you will tackle, in what order, with what confidence. It changes continuously, reviewed monthly or even more often.

Each layer depends on the one above it and tests it from below. A roadmap with no strategy is a list. A strategy with no vision can be internally coherent and pointless. A vision with no strategy is a poster.

The questions each one answers

I find it easier to define documents by the questions they must answer than by their format.

Vision answers: where are we going, and why does it matter?

A good vision lets a new employee explain, in a sentence, what the company exists to change in customers’ lives. It should be ambitious, specific enough to exclude things, and stable enough to survive a bad quarter. Test: could two teams use it to disagree productively about a decision? If everyone nods and nothing follows, it is too vague.

Vision is also where you state the customer and the change. “Small businesses spend hours a week on financial admin; we want them to spend none” is a vision. “Be the leader in financial software” is a ranking.

Strategy answers: how will we win, given what is true today?

Strategy begins from a diagnosis of the situation and ends with a guiding policy and coherent actions. It answers where to play, how to win, what the sources of advantage are, and what is explicitly out of scope. The test of a strategy is whether it forces a trade-off. If a competitor would never choose the opposite, you have written a value, not a strategy.

Strategy is the layer that connects the abstract to the practical, which is why it is also where most organizations have a gap. They have a vision on a wall and a roadmap in a tool, and nothing in between to explain why those roadmap items and not others.

Roadmap answers: what will we do, in what order, and how sure are we?

A roadmap turns the strategy into sequenced work. A useful one makes the sequence legible, shows dependencies, and is honest about confidence. It tells engineers what is coming, tells sales what they can and cannot promise, and tells leadership how the strategy is progressing.

The best roadmaps I have worked with are not feature lists. They are organized around outcomes, with the solutions underneath them treated as hypotheses. I describe how to build one that survives contact with reality in building a growth roadmap.

Who owns each one

Ownership is where the confusion becomes political.

Vision is usually owned by the CEO or founder, with product leadership shaping the product expression of it. It is a leadership statement. A product manager who invents one for their own area is usually describing a strategy.

Strategy is owned by product leadership, in partnership with the executives who control the other levers: commercial, technology, finance. In a smaller company the head of product or a founder holds it. In a larger one, each business unit or product area has its own, nested inside a company strategy. The owner has to be able to say no to a project and defend it.

Roadmap is owned by product managers and product leads for their areas, in negotiation with engineering and design. This is the document that changes most often, and the one with the most stakeholders who want edits.

When the roadmap owner is also expected to invent the strategy and the vision, with no cover from above, they end up making the roadmap the strategy by default. That is not a failure of the individual. It is a gap in the organization, and it is a good reason to bring in outside help to fill the strategy layer, which I cover in what a product strategy consultant does.

How long each one lasts, and what makes it change

A useful discipline is to attach a shelf life to each document and a trigger for revising it.

Vision: two to five years. Revised when the company’s purpose genuinely shifts, such as a new market, a new customer or a fundamental change in technology.
Strategy: reviewed every quarter, rewritten every six to twelve months. Revised when the diagnosis stops being true or an assumption breaks: a competitor move, a change in unit economics, a regulatory shift.
Roadmap: reviewed monthly, adjusted constantly. Revised when evidence from delivery or customers changes priorities.

If your vision changes every quarter, it is not a vision. If your strategy has not changed in two years, it is probably not being used. If your roadmap never changes, nobody is learning from the work.

Where the documents go wrong

Each layer has a typical failure mode.

A vision without a strategy

The vision exists on a slide and in the lobby, and the roadmap is built from customer requests. People can recite the vision and cannot explain how any specific project advances it. The cure is a strategy that connects them.

A strategy that is really a feature list

“Our strategy is to build X, Y and Z.” That is a roadmap with a loftier title. The tell is the absence of a diagnosis and the absence of anything you will not do. Add a diagnosis, add exclusions, and what remains is the strategy.

A roadmap without a strategy

This is the feature factory. The team ships a lot and cannot say whether it is helping. Melissa Perri calls this pattern the build trap in her book on product management: organizations measure output instead of outcomes and keep building because building is what they know how to do. The roadmap becomes a queue of requests, ordered by who pushed hardest.

A roadmap treated as a promise

Dates on a roadmap become commitments the moment a customer or executive sees them. Then discovery work finds that the first idea was wrong, and the team has to choose between shipping the wrong thing on time and breaking a promise. Time horizons like Now, Next and Later, which many teams use, are a reasonable defense: they signal that confidence drops with distance.

Strategy that never meets implementation

A strategy that does not change the roadmap is a document, not a strategy. The question to ask of any roadmap is: which strategic choice does each item serve? Anything that cannot answer is either strategically unimportant or secretly a different strategy.

Everything at the wrong altitude

Vision statements that name features. Roadmaps that list company values. Strategies that quote customer tickets. Each document should live at its own level, and when you notice an item at the wrong altitude, move it.

How a decision travels between the three

The relationship is not purely top-down. Good teams run a loop.

Down: the vision frames the problem space, the strategy picks the approach, the roadmap sequences the work. Each layer constrains the one below.

Up: what you learn from delivery and from customers should flow back. If three consecutive roadmap bets in a strategic theme fail, the strategy’s assumption about that theme is probably wrong. If customers keep asking for something your strategy excludes, either they are the wrong customers or your exclusion is wrong, and you should find out which.

A practical device I use is a line of sight. For each roadmap item, I should be able to trace a line up to a strategic choice, and from there to the vision. If I cannot, it is not necessarily a bad item, but it is not part of the plan, and the team should decide consciously whether it belongs.

A worked example

The following is an illustrative example, not a client. Imagine a company building invoicing software for owner-managed businesses.

Vision. Owners of small businesses spend their evenings doing paperwork. We want them to run a business without financial admin.

Strategy. Diagnosis: the target customers do not fail at invoicing, they fail at chasing payment. Late payment is the number one cash-flow problem, and existing tools treat invoicing as record-keeping. Where to play: businesses with fewer than twenty employees that invoice other businesses; not consumers, not enterprises. How to win: own the moment between sending an invoice and getting paid, using data about payer behavior that competitors lack. Guiding policy: every product investment must shorten the time between invoice and payment. What we will not do: general accounting, payroll, or custom reporting for finance teams. Success measure: median days to payment.

Roadmap.

Now: automated reminders based on payer behavior; one-click payment links on every invoice.
Next: payment-prediction signals shown at invoice creation; integration with the two leading bank-feed providers.
Later: short-term financing offers triggered by outstanding invoices (dependent on regulatory work and a partner decision).

Look at how each document does a different job. The vision would barely change in three years. The strategy would be reviewed each quarter against median days to payment. The roadmap would shift monthly, with Later items moving up or being dropped as evidence arrives. And every roadmap item can be traced to the guiding policy, which is how the team defends saying no to a request for custom reports.

Where OKRs, the north star and principles fit

Teams often ask where the other planning tools slot in.

A north star metric belongs with the strategy. It is the single measure of whether the strategy is working. I cover how to choose one you can actually move in choosing a north star metric.

OKRs are a cadence for turning strategy into time-boxed goals. Objectives sit between strategy and roadmap: they translate a strategic theme into what must be true by the end of the quarter, and the key results measure it. Treat them as an operating rhythm, not a replacement for any of the three documents.

Design principles sit near the strategy. They describe how you build, in a handful of statements, and give teams a common language for local choices.

Experiments sit under the roadmap. Each is a test of an assumption in the strategy. I describe running a growth experiment backlog and how to rank it in experiment prioritization.

A short audit you can run today

Take your current documents and ask the following. Each “no” points to a layer that needs work.

Can a new hire read the vision and explain what the company is trying to change for customers?
Does the strategy contain a diagnosis, a guiding policy, and at least three things you will not do?
Could a smart competitor reasonably choose the opposite of your strategy?
Can every roadmap item be traced to a strategic choice?
Does the roadmap say how confident you are in each item?
When did the strategy last change because of evidence from the roadmap?
Who owns each document, and can they say no to a request?

If you answer “no” to the third question, you have a value, not a strategy. If you answer “no” to the fourth, you have a feature factory.

The short version

Vision: where we are going and why it matters. Two to five years. Owned by the CEO or founder.
Strategy: how we will win, with a diagnosis, a guiding policy, coherent actions and explicit exclusions. Reviewed quarterly. Owned by product leadership.
Roadmap: what we will do and in what order, with confidence levels. Reviewed monthly. Owned by product managers.
Each layer constrains the one below and is tested by it. Learning must flow back up.
A vision without a strategy is a poster, a strategy that is a feature list is a roadmap in disguise, and a roadmap without a strategy is a feature factory.
A roadmap is a plan with changing confidence, not a promise. Use outcomes and horizons, not dates.
Run the line-of-sight test: every roadmap item should trace to a strategic choice.

Where to go next

To write the middle layer properly, read how to write a product strategy that actually gets implemented. If AI is forcing your team to rethink what goes on the roadmap, AI product strategy shows how to decide where models belong before they take over the plan. And if the gap in your organization is the strategy layer itself, product strategy consulting explains how a short engagement can fill it.

I am Deepanshu Grover, a Senior Product Strategy Consultant in Paris. I take ambiguous, high-stakes product and business questions, run the analysis, and see the recommendation implemented. If your vision, strategy and roadmap have collapsed into one, connect on LinkedIn or get in touch.