Scrolls
7 min read
On this page

Vision & Strategy

Vision is where you want to be in three to five years. Strategy is how you get there. The vision inspires. The strategy constrains. Most companies have a vision statement hanging on the wall. Far fewer have a strategy that actually guides decisions. The difference matters because a strategy without trade-offs is not a strategy — it is a wish list. And "we will do everything for everyone" is the absence of strategy, not the presence of ambition.

Vision vs Strategy vs Execution

These three concepts are often confused. They serve different purposes and operate at different time horizons.

Vision:     Where are we going? (3-5 years)
Strategy:   How will we get there? (1-2 years)
Roadmap:    What are we building? (Quarters)
Execution:  How are we building it? (Sprints)

Example:
  Vision:     "Every developer can ship production-grade infrastructure
               without needing a dedicated DevOps team."
  Strategy:   "Build the simplest deployment platform for small teams,
               starting with web applications on AWS."
  Roadmap:    "Q1: one-click deploy for Node apps. Q2: database provisioning.
               Q3: custom domains and SSL."
  Execution:  "Sprint 1: CLI tool for Node deploy. Sprint 2: Dockerfile
               generation. Sprint 3: AWS integration."

Vision is aspirational and relatively stable. Strategy changes as you learn. Roadmap is a plan that adapts to reality. Execution is the daily work.

What Makes a Good Vision

A good vision is specific enough to guide decisions but broad enough to survive market changes. It describes the world you want to create, not the product you want to build.

Characteristics of a Good Vision

Good vision:
  - Describes a future state, not a product
  - Inspires the team and attracts talent
  - Is ambitious but believable
  - Is specific enough to say "no" to things
  - Survives technology shifts

Bad vision:
  - Describes a feature set
  - Is so vague it could apply to any company
  - Is a financial target disguised as a vision
  - Changes every quarter

Vision Examples

Stripe:  "Increase the GDP of the internet."
  Why it works: Describes an outcome, not a product. Guides decisions
  (anything that makes internet commerce easier is in scope).

Notion:  "Make it possible for everyone to shape the tools that shape
          their lives."
  Why it works: Aspirational, human-centered, specific enough to
  exclude things (they are not building social media).

Figma:   "Make design accessible to everyone."
  Why it works: Clear mission, guides product decisions (collaboration,
  browser-based, free tier).

Bad:     "Be the leading provider of integrated enterprise solutions."
  Why it fails: Could be any enterprise software company. Does not
  inspire or constrain.

Bad:     "Reach $1B ARR by 2028."
  Why it fails: Financial targets are outcomes of strategy, not vision.
  They do not guide product decisions.

What Makes a Good Strategy

Strategy is the set of choices that determine how you will achieve the vision. A good strategy is a coherent set of policies, actions, and resource allocations that address a specific challenge.

Richard Rumelt's "Good Strategy Bad Strategy" defines the structure:

Good strategy has three parts:
  1. Diagnosis:     What is the challenge we face?
  2. Guiding policy: What approach will we take?
  3. Coherent actions: What specific steps follow from the policy?

Diagnosis

The diagnosis is an honest assessment of your situation. It identifies the most important challenge — not all challenges, the central one.

Example diagnosis:
  "Small development teams waste 30% of their time on infrastructure
   tasks that are undifferentiated for their business. Existing solutions
   (AWS, GCP) are powerful but require dedicated expertise. These teams
   cannot afford a DevOps hire but need production-grade infrastructure."

A good diagnosis cuts through noise and focuses attention. "We face many challenges in a competitive market" is not a diagnosis. "Our biggest challenge is that our activation rate is 12% because new users cannot figure out how to set up their first project" is a diagnosis.

Guiding Policy

The guiding policy is the approach you will take. It is not a goal — it is a direction. And critically, it implies trade-offs. Choosing one direction means not choosing others.

Guiding policy examples:
  "Focus exclusively on small teams (under 10 developers) and make
   the product so simple that no documentation is needed for basic
   use cases."

  Trade-offs this implies:
  - We will not build enterprise features (SSO, audit logs) yet
  - We will sacrifice power-user flexibility for simplicity
  - We will target self-serve adoption, not sales-led
  - We will support fewer cloud providers (AWS only initially)

If your guiding policy does not force trade-offs, it is not a strategy. "We will build the best product and win the market" is not a guiding policy. It does not constrain anything.

Coherent Actions

Actions are specific initiatives that follow logically from the guiding policy. They should reinforce each other.

Coherent actions:
  1. Build a CLI that deploys a web app in one command
  2. Create interactive tutorials that replace documentation
  3. Offer a free tier generous enough for real projects
  4. Build integrations with GitHub (where small teams live)
  5. Invest in a community forum instead of a sales team

Incoherent actions (doing these alongside the above):
  - Building an enterprise sales team
  - Adding Kubernetes configuration options
  - Creating a certification program
  - Building a marketplace for third-party add-ons

Coherence means the actions work together. Each one reinforces the others. An incoherent strategy pulls in multiple directions and dilutes resources.

Strategy as Trade-Offs

The essence of strategy is choosing what not to do. Michael Porter's famous insight: "The essence of strategy is choosing what not to do." If you are not saying no to things, you do not have a strategy.

Strategic trade-offs:
  Simplicity vs power:
    "We optimize for the first 20 minutes of use, not the power user
     workflow. Features that add complexity for beginners are rejected
     even if power users want them."

  Speed vs breadth:
    "We support one cloud provider deeply rather than three shallowly.
     We would rather be the best AWS deployment tool than an okay
     multi-cloud tool."

  Self-serve vs enterprise:
    "We invest in product-led growth. No sales team until we hit
     $10M ARR from self-serve. This means losing enterprise deals
     that require custom contracts."

These trade-offs are painful. They mean saying no to real revenue, real customers, and real opportunities. That is the point. A strategy that says yes to everything is not a strategy.

Communicating Strategy

A strategy that lives in the CEO's head is useless. Strategy must be communicated clearly enough that anyone in the company can use it to make daily decisions.

The Strategy Document

Write the strategy down. One document, not a deck. It should include:

Strategy document structure:
  1. Vision (one paragraph)
  2. Diagnosis (what is the central challenge?)
  3. Guiding policy (what approach are we taking?)
  4. Strategic trade-offs (what are we explicitly not doing?)
  5. Key initiatives (what specific things are we building/doing?)
  6. Success metrics (how do we know the strategy is working?)
  7. Risks and assumptions (what could invalidate this strategy?)

The Litmus Test

After communicating your strategy, ask team members: "If you had to choose between Feature A and Feature B, and they both seem valuable, how would you decide?" If they can use the strategy to make that choice, the communication worked. If they say "I would ask my manager," it did not.

Strategy Mistakes

Mistaking Goals for Strategy

"Our strategy is to grow 40% year-over-year" is not a strategy. It is a goal. Goals describe desired outcomes. Strategy describes how you will achieve them. Revenue targets, market share goals, and user growth numbers are important, but they are not strategy.

The Do-Everything Approach

"Our strategy is to be the best at everything: easiest to use, most powerful, cheapest, and most secure." This is not a strategy because it makes no choices. Resources are finite. Trying to be best at everything means being mediocre at everything.

Strategy by Analogy

"We are the Uber for X" or "We will do what Salesforce did for CRM, but for Y." Analogies are useful for quick communication but dangerous as strategy. Your market is not Uber's market. The playbook that worked for Salesforce in 2005 may not work for you today.

Copying Competitors

If your strategy is "do what the market leader does but cheaper" or "do what they do but better," you are running on a treadmill. The leader sets the pace and you are always behind. Find a dimension where you can win, not a race you will always lose.

Real-World Examples

Shopify: The Merchant-First Strategy

Shopify's strategy was to make it possible for anyone to start an online store. The trade-off: they did not build the most powerful e-commerce platform (that was Magento). They built the easiest one. They said no to features that power users wanted if those features made the product harder for beginners. This trade-off was the strategy, and it worked because the market of "people who want to sell online but cannot hire a developer" was much larger than the market of "enterprises that need custom e-commerce."

Netflix: The Content Strategy Shift

Netflix's original strategy was distribution — making it easy to access content. The strategic shift to creating original content was a response to a diagnosis: "content owners will eventually pull their content and compete directly with us." The guiding policy was: "invest in original content that only exists on Netflix." The trade-off was massive capital expenditure and debt. The coherent actions were building production studios, hiring creative talent, and developing recommendation algorithms that could surface original content effectively.

Basecamp: The Anti-Growth Strategy

Basecamp's strategy explicitly rejected venture-scale growth. Their guiding policy was: "build a profitable, calm company that makes one product really well." The trade-offs: no VC funding, no aggressive hiring, no enterprise sales team, no platform strategy. This constrained their market but made every other decision simpler. They could focus entirely on product quality for small teams.

Common Pitfalls

  • Vision without strategy — an inspiring vision with no plan for how to get there is a poster, not a direction.
  • Strategy without trade-offs — if your strategy does not force you to say no to good ideas, it is not a strategy.
  • Confusing strategy with planning — a list of things to build is a plan, not a strategy. Strategy is the reasoning that determines what goes on the plan.
  • Changing strategy every quarter — strategy should be stable for at least a year. If it changes every quarter, you either had a bad strategy or you are confusing strategy with tactics.
  • Strategy by committee — consensus strategies are watered down to the point of meaninglessness. Someone needs to own the strategy and make the hard choices.
  • Ignoring the diagnosis — jumping to solutions without honestly assessing the challenge leads to strategies that solve the wrong problem.

Key Takeaways

  • Vision describes the future you want to create. Strategy describes how you will get there. Vision inspires. Strategy constrains.
  • Good strategy has three parts: diagnosis (the challenge), guiding policy (the approach), and coherent actions (the initiatives).
  • Strategy is fundamentally about trade-offs. If you are not saying no to real opportunities, you do not have a strategy.
  • Communicate strategy clearly enough that anyone in the company can use it to make daily decisions without escalating.
  • Goals are not strategy. "Grow 40%" is a target. The strategy is the set of choices that determines how you will grow and what you will sacrifice to do so.
  • Revisit strategy annually, not quarterly. It should be stable enough to guide execution over meaningful time periods.