The Product Vision Framework That Actually Sticks

The real problem is altitude

A vision that says "we want to be the operating system for small business finance" is operating at horizon level. That's fine. But when a PM needs to decide whether to build bank reconciliation or multi-currency support next, that horizon gives them nothing to work with. They're left interpreting. And interpretation at scale means every team is quietly running a slightly different strategy.

The vision isn't wrong. It's just working alone at an altitude where it can't make decisions.

This is the uncomfortable truth most CPOs avoid: if your vision requires you to be in the room to translate it, you haven't built a vision framework. You've built a dependency on yourself.

A product vision framework needs exactly three layers

The way I think about it, a usable product vision framework has three layers and only three.

**The horizon.** Where you are going and why it matters. This is the version that lives on the slide. It should be true for three to five years and stable enough that it doesn't need revisiting every quarter.

**The constraint.** What you will not do to get there. This is the layer most frameworks skip, and it's the most important one for decision-making. A vision without a constraint is just aspiration. The constraint is what turns it into strategy. "We will not build for enterprise clients in this phase" or "direct-to-consumer even over B2B partnerships" — these are the statements that actually filter a roadmap.

**The signal.** How you will know you are moving in the right direction. Not lagging metrics like revenue. Leading indicators that tell the team whether the product behaviour you're betting on is showing up. If you can't name two or three signals that would tell you the vision is working, you won't know when to stay the course and when to adapt.

These three layers give every person in the organisation — board, PM, engineer — the same answer to the question: why this, why now, why not that.

Board communication and team alignment are not the same conversation

I've watched CPOs try to solve both with a single document. It never works.

A board needs to understand the horizon and the constraint well enough to stress-test capital allocation. They don't need signal-level metrics in a strategy presentation. A product team needs the constraint and the signal well enough to make daily decisions. They don't need a three-year horizon repeated at every sprint review.

The vision is the same. The framing has to change. Trying to serve both audiences with one artefact usually means neither group gets what they actually need.

Melissa Perri puts it well in *Escaping the Build Trap*: "Strategy is not a document. It is a set of decisions that guides every other decision." A vision framework only works when each layer gives a different part of the organisation the specific input they need to decide.

Stress-test before you present

The fastest diagnostic I know for whether a product vision is actually driving your product is this: take your last five roadmap decisions and ask whether the vision could have made those decisions without you explaining it.

If the answer is yes for most of them, the framework is working. If you have to reconstruct the reasoning each time, the vision is decorating the product rather than directing it.

Do that exercise before your next board meeting or all-hands. It will show you exactly which layer is missing — whether you have a horizon but no constraint, or a constraint with no signal. That's where to work.

The goal is a structure where the vision makes decisions on your behalf when you are not in the room. That's what operational looks like. Start there.