Vision STACK
Why vision is the only differentiator in the age of AI
For most of my career, the hard part of building software was the building. Turning an idea into a working product took months of design cycles and engineering sprints, and the teams that won were usually the ones that could ship fastest.
That is no longer true.
AI agents now write code, generate interfaces, and run test suites in minutes. I have watched my own two-day side project turn into a working native app. The cost of building is rapidly approaching zero, and as it gets there, speed stops being an advantage. Everyone has it.
What is left is knowing what to build. If your team is misaligned, shipping ten times faster only means you build the wrong thing ten times faster. Clarity about where you are going, and why, is the scarce commodity now.
The cost of misalignment
Misalignment usually gets diagnosed as a communication problem. In my experience it is a leadership problem. The vision exists, but it lives in the head of a founder or a VP, and nobody has translated it into something a product manager or designer can use to make a decision on their own.
The cost shows up in ways that are easy to miss, because each one looks like a local issue.
Everyone runs in their own direction. Design ships features that sales can't sell. Product optimizes for engagement while engineering optimizes for a re-architecture. Sales promises a custom enterprise feature that breaks the roadmap.
Small decisions get escalated. A UI trade-off or a technical choice climbs two levels for approval because nobody below is sure what the answer should be.
Good people leave. They rarely leave because the work is hard. They leave because they are spending their energy on turn wars instead of user problems.
And a vision that lives on a slide shown once a year at an offsite does nothing to prevent any of this. It has to become an operating system that people use to make decisions without asking. That is what the Vision Stack is for.
The five layers
The Vision Stack has five interdependent layers. Each one narrows the layer above it, from the horizon you are sailing toward down to what the team commits to this quarter. If a layer is missing or vague, everyting under it gets harder to decide.
Principles
Purpose
Mission
Strategy
OKRs
Principles
Principles are different from values. Integrity, respect, and excellence are minimum standards of behavior. They are fine to have, and they give a designer or an engineer no guidance at all when a real decision has to be made under pressure.
A principle is a rule for making trade-offs. It says how the team wins and what it is willing to give up to get there. The test is whether the opposite of the statement would sound absurd. "We value quality" fails, because nobody would say the reverse.
Platitude: "We value great user experience."
Principle: "We optimize for workflow speed, even at the expense of visual polish on secondary screens."
When principles are written this way, a junior designer can make a high-stakes call at 2 AM without waking a manager, because the boundary was set in advance.
Purpose
Principles say how the team behaves. Purpose says why anyone shows up. It is the horizon the company sails toward and never quite reaches.
The most common mistake I see is confusing a business goal with a purpose. "Become the leading B2B platform in our category" is an investor pitch. It attracts people who will sell their time for equity and leave when a competitor offers 15% more.
A real purpose answers the hardest question in hiring: why should a world-class designer or engineer spend the best years of their career on your problem? The purposes that hold up tend to take one of a few shapes:
Taking on a broken status quo. Early Netflix against the late fee.
Arming an underserved group against giants. Shopify giving independent merchants a way to compete with Amazon.
Pushing a technical frontier. SpaceX making people multiplanetary.
Whichever shape it takes, it should be specific enough that a candidate can tell whether they care.
Mission
Purpose is infinite. The mission is finite. It is the specific mountain the organization is climbing right now, usually over a three-to-five-year window.
Most mission statements fail because they can never be completed. "Deliver world-class customer experiences" is an aspiration with no finish line. A mission should be binary. Either you reached the summit or you didn't, and when you did, the team celebrates and picks the next mountain.
A binary mission is also the best tie-breaker I know for medium-term decisions. Does this project raise the odds of reaching the summit? If the answer is no, it doesn't get built, however good the idea is.
Strategy
If the mission is the summit, strategy is the route. It is the most misused word in the business, and most of what gets called strategy is a roadmap: a list of features and revenue targets with no argument connecting them.
A strategy is a coherent response to a specific obstacle. I use Richard Rumelt's three parts because they force the argument into the open:
Diagnosis. An honest read of the main thing standing in your way.
Guiding policy. The approach or the leverage point you will use against it.
Coherent actions. The concrete choices and resource allocations that carry out the policy, and that would make no sense without it.
The practical test is what you said no to. A strategy that never forces the team to turn down a good idea in favor of the right one is a to-do list.
OKRs
Strategy is the route. Objectives and key results are the steps you take this quarter.
The usual way to ruin OKRs is to turn them into a spreadsheet of everything everyone is doing. If every task is an objective, nothing is. The deeper failure is measuring output instead of outcome.
Output: shipped a redesigned onboarding flow, built the API integration, launched the feature. What you did.
Outcome: cut onboarding time by 40%, lifted 30-day retention by 15%, halved support tickets. What you changed.
Nobody cares that the feature shipped on time if it changed nothing for users or the business. Key results should measure the change, and the objective should be traceable back up the stack to the strategy it serves.
Litmus test
It is worth auditing your own stack from time to time to check whether it is still a working tool or has drifted into wishful thinking. This is the table I use.
Feature
Language
Concrete and specific
Vague "corpspeak" and buzzwords
Trade-offs
Explicitly says what we won't do
Pretends we can do everything at once
Constraint
Acknowledges technical and market reality
Ignores resource gaps or real world friction
Utility
Helps an IC make a hard decision independently
Stays on a slide and is never mentioned again
A quick version: if your vision statement could be pasted onto a competitor's website without changing a word, it is a hallucination.
Clarity is the advantage
We are entering a period where almost anyone can build almost anything, quickly. Capital and code are no longer what separates the winners. The organizations that pull ahead over the next decade will be the ones where a founder, a product manager and a new designer all carry the same mental model of where the company is going, and can act on it without a meeting.
That is what the Vision Stack is built to produce. It is less a document than a habit of deciding things in the right order.
What's next?
I am finishing a facilitator kit for running the Vision Stack with a leadership team in a series of 60-minute sessions: the workshop agendas, the stress-test exercises for each layer, and the AI prompts I use to synthesize the output. If you want it when it's ready, get in touch and I'll send it over.