A product vision is often written once, during an early planning exercise, and then rarely referenced again, which suggests it's not actually functioning as a vision so much as a one-time planning artifact. Understanding what a vision is genuinely supposed to do clarifies why that pattern represents a missed opportunity.
What a vision actually does, when it's working
A product vision's job is to answer, in a way the whole team can hold in their heads and act from independently: what future state is this product trying to create, and for whom? It's the reference point that lets a team make dozens of small, independent decisions in roughly the same direction without needing every decision routed through central approval, because everyone is working from a shared understanding of what "good" ultimately looks like.
This is different from a roadmap, which lists specific features and rough timing, and different from a strategy, which describes the approach to achieving the vision. The vision is the destination; the strategy is the route; the roadmap is the specific stops along the way. Confusing these three, treating a feature roadmap as if it were the vision, is a common failure mode that leaves teams without the higher-level compass a roadmap alone can't provide.
The test for whether a vision is actually working
A useful test: can a team member, faced with a decision not explicitly covered by the current backlog, use the vision to reason toward a sensible answer independently? If the vision is vague enough that it provides no real guidance for a genuine judgment call ("build a great product for our customers" fits virtually any decision equally well), it isn't functioning as a vision, regardless of how nicely it's phrased.
A vision that actually works is specific enough to rule some things out. "Become the easiest way for small businesses to manage payroll without needing an accountant" rules out feature directions that would make the product more powerful but also more complex. A vision like that gives a team something to actually reason against, not just a pleasant-sounding aspiration everything technically satisfies.
Why visions decay if they're not revisited
A vision written a year or two ago, based on the market and organizational context at the time, can become quietly stale as circumstances change, without anyone explicitly deciding to update it, because nobody's actively checking it against current reality. Teams that periodically revisit their stated vision, asking whether it still reflects genuine current intent or has just become an unquestioned artifact from an earlier planning cycle, catch this drift before it causes real strategic confusion.
The vision isn't a deliverable to produce once and file away. It's a living reference that should genuinely inform day-to-day decisions, and if it isn't doing that, either the vision needs revisiting, or the team needs to actually start using it as intended.