When teams conflate vision, strategy, and roadmap, features get built without direction and the roadmap becomes a wish list that satisfies every stakeholder's pet idea without actually moving the product forward. This confusion is one of the most common reasons product teams feel busy but not effective. Separating the three layers — and understanding how they connect — is foundational product thinking.
The definitions
Vision is where you are going in three to five years. It describes a future state, not a set of features. A good vision statement is specific enough to be meaningful and ambitious enough to be motivating. Strategy is how you will get there — and critically, what you will not do. A strategy without explicit trade-offs is not a strategy, it is a list of good intentions. The roadmap is what you are specifically building in the next quarter and why — concrete deliverables mapped to strategic choices.
The Amazon PR-FAQ method
One of the most effective tools for clarifying vision is the Amazon PR-FAQ: write the press release for your product as if it already exists and has succeeded. Describe what it does, who it helps, and why it matters — in the language of the customer, not the engineer. Then write the FAQ: the tough questions a skeptical journalist or investor would ask. This exercise forces clarity about what you are building and why before you build it. If you cannot write the press release, you do not know your vision yet.
How the three layers connect
Every roadmap item should connect to a strategy choice, and every strategy choice should connect to the vision. If you cannot trace that line, the roadmap item is probably wrong — or the strategy needs to be updated to reflect a legitimate new direction. This traceability is not bureaucracy; it is the mechanism that prevents the roadmap from becoming a random collection of features requested by whoever shouted loudest last quarter.
Using vision as a decision filter
A well-defined vision is a prioritization tool. When a stakeholder requests a feature, ask: does this move us toward our vision? If yes, how much, and at what cost? If not, it belongs in the backlog — and you have a principled reason for putting it there that does not require you to say no to the person directly. The vision absorbs the conflict so the PM does not have to.
What happens without a vision
Without a shared vision, teams argue about priorities using opinion instead of direction. Context switches constantly because there is nothing to say no against. Engineers build features that contradict each other because no one aligned on a coherent future state. Roadmaps get rewritten every quarter. New leadership comes in and throws out the previous work because it was never connected to a direction anyone outside the PM's head could understand. Vision is not idealism — it is the infrastructure that makes execution possible.