Product vision and strategy skill

Product Vision and Strategy

How to create the strategic context that enables empowered teams to make good autonomous decisions. Without a compelling vision and clear strategy, empowered teams are just autonomous teams making disconnected decisions.

Product Vision

What a Product Vision Is

The product vision describes the future you want to create for your customers -- typically 2-5 years out. It is the North Star that aligns all product teams toward a shared direction and inspires the daily work of discovery and delivery.

Characteristics of a strong product vision:

• Customer-centric (describes the world from the customer's perspective, not the company's)
• Inspiring (makes people want to be part of building this future)
• Ambitious but achievable (stretches beyond current capability but is grounded in reality)
• Solution-agnostic (describes outcomes, not specific features or technologies)
• Stable (changes rarely -- perhaps once every 2-3 years)
• Concise (expressible in 1-3 sentences)

Vision Examples

Weak visions (and why):

• "Be the #1 project management tool" -- Competitive framing, not customer-centric. Tells you nothing about what customers experience.
• "Leverage AI to transform enterprise productivity" -- Technology-first, buzzword-heavy, and too vague to guide decisions.
• "Build a comprehensive platform for all business needs" -- Too broad to focus anyone. Everything and nothing fits.

Strong visions (and why they work):

• "Every small business owner can access the financial tools that were previously available only to large corporations" -- Customer-centric, inspiring, specific enough to guide decisions, ambitious enough to drive years of work.
• "Creators spend their time creating, not managing the business of creation" -- Clear customer (creators), clear problem (business overhead), clear aspiration (more creating, less administrating).
• "Any team can build and ship software with confidence, regardless of their technical infrastructure" -- Specific customer (development teams), specific outcome (shipping with confidence), specific barrier removed (infrastructure complexity).

Creating a Product Vision

Step 1: Identify the core customer truth

What fundamental insight about your customer's world drives your company's existence? This is not a feature or capability -- it is an observation about the world that creates an opportunity.

Examples:

• "Small businesses are underserved by financial tools designed for enterprises"
• "Most knowledge workers spend more time managing work than doing work"
• "Learning a new skill shouldn't require quitting your job or going into debt"

Step 2: Describe the future state

What does the world look like when this problem is fully solved? Describe it from the customer's perspective.

Step 3: Make it vivid

The vision should create a mental image that people can rally around. Use concrete, human language. Avoid jargon, buzzwords, and abstractions.

Step 4: Test it

Share the vision with team members, customers, and stakeholders. A strong vision makes people say "I want to help build that" or "I want to live in that world." If the reaction is confusion or indifference, iterate.

Vision Communication

A vision that lives in a document nobody reads is useless. The CEO and product leadership must evangelize the vision relentlessly:

• Reference it in all-hands meetings
• Connect quarterly objectives to the vision
• Use it to explain "why" when making strategic decisions
• Revisit it with new hires during onboarding
• Display it visibly in team spaces

---

Product Strategy

What Product Strategy Is

Product strategy is the sequence of steps that will realize the vision. If vision is the destination, strategy is the route. Strategy answers: Which customers do we serve first? Which problems do we solve first? What is our competitive advantage?

Characteristics of a strong product strategy:

• Sequenced (defines what comes first, second, third -- not "do everything at once")
• Focused (says "no" to most things in order to say "yes" effectively to a few)
• Leveraged (builds on existing strengths and advantages)
• Evidence-based (grounded in customer knowledge and market data)
• Revisited quarterly (adapts to new evidence without whiplash)

Strategy Components

1. Market Focus

Decision: Which customer segments do we target, and in what order?

Considerations:

• Start with the segment where your product delivers the most value today
• Expand to adjacent segments where your core capabilities apply
• Avoid trying to serve conflicting segments simultaneously (enterprise and SMB have different needs)
• Consider the segment's ability to pay, accessibility through your channels, and strategic value

2. Problem Focus

Decision: Which customer problems do we prioritize?

Considerations:

• Severity of the problem (hair-on-fire vs nice-to-have)
• Size of the affected population within your target segment
• Alignment with your competitive advantage
• Ability to validate and deliver within a reasonable timeframe
• Strategic sequencing (which problems, once solved, unlock others?)

3. Competitive Differentiation

Decision: How will we win against alternatives (including non-consumption)?

Sources of differentiation:

• Superior customer knowledge (you understand the problem better)
• Technology advantage (you can deliver a solution others cannot)
• Distribution advantage (you can reach customers more efficiently)
• Data advantage (you have data that improves the product over time)
• Network effects (more users make the product more valuable)

Strategy Anti-Patterns

Anti-Pattern	Why It Fails	Fix
"Do everything" strategy	Spreads resources too thin; nothing gets done well	Sequence ruthlessly; do fewer things better
"Copy the leader" strategy	You'll always be behind; you cannot out-execute the leader at their own game	Find a different angle -- different segment, different problem, different approach
"Technology-first" strategy	Building capabilities without knowing if customers need them	Start with customer problems, then identify which technology enables the best solution
"Growth at all costs" strategy	Acquires users who don't retain; masks product problems with marketing spend	Focus on retention and value delivery; growth follows product-market fit
"Strategy by committee" strategy	Compromises produce mediocre results that satisfy nobody	Product leadership must make hard choices and own the consequences

---

Product Principles

What Product Principles Are

Product principles are the set of beliefs and values that guide decision-making when the strategy doesn't specify an answer. They express "how we work" and "what we prioritize" in concrete, actionable terms.

Characteristics of useful principles:

• Opinionated (they express a preference; "be good" is not a principle)
• Actionable (they guide real decisions)
• Few in number (5-8 principles; more becomes a rulebook nobody follows)
• Stable (change rarely, perhaps annually)
• Testable (you can look at a decision and determine whether it followed the principle)

Principle Examples

Weak principles:

• "Delight users" -- Too vague. Every company claims this. It doesn't help you choose between two options.
• "Be innovative" -- Meaningless without context. What counts as innovative?

Strong principles:

• "When in doubt, choose simplicity over power" -- This helps a designer decide between a feature-rich interface and a streamlined one.
• "Optimize for the new user experience, even at the cost of power-user convenience" -- This resolves the tension between novice and expert needs.
• "Ship something small and learn, rather than waiting to ship something complete" -- This guides release planning decisions.
• "We do not show ads that interrupt the core experience, even if they would generate significant revenue" -- This resolves business model tensions.

---

OKRs (Objectives and Key Results)

OKRs as Strategy Translation

OKRs translate the product strategy into specific, measurable objectives for each team. They are the primary mechanism for giving empowered teams clear direction without prescribing solutions.

Objective: A qualitative statement of what the team is trying to achieve. Should be inspiring, directional, and connected to the strategy.

Key Results: 2-4 quantitative measures that define success for the objective. Should be specific, measurable, and time-bound.

OKR Design Principles

1. Outcomes, not output

• Wrong KR: "Ship the new onboarding flow" (output -- prescribes the solution)
• Right KR: "Increase 7-day retention from 40% to 55%" (outcome -- the team chooses how)

2. Ambitious but achievable

• OKRs should stretch the team. If a team consistently hits 100% of their KRs, the targets are not ambitious enough.
• A healthy achievement rate is 70-80%. This means the team is stretching beyond comfortable targets.

3. Team-owned

• Each team should have input into their OKRs. Leadership provides the strategic context and business objectives; the team proposes specific key results they believe are achievable and meaningful.

4. Few in number

• 1-2 objectives per team per quarter, with 2-4 key results each. More than this dilutes focus and reduces accountability.

5. Not tied to compensation

• When OKRs are tied to bonuses, teams sandbag (set easy targets) and game the metrics. OKRs should be a planning and alignment tool, not a performance evaluation tool.

OKR Examples

Good OKR:

Objective: New users discover value in their first session
KR1: First-session completion rate increases from 35% to 60%
KR2: Time-to-first-value decreases from 12 minutes to 4 minutes
KR3: Day-7 retention for users who complete first session exceeds 70%

Bad OKR:

Objective: Improve onboarding
KR1: Ship redesigned onboarding flow by March 15
KR2: Add 3 onboarding tooltips
KR3: Create 2 tutorial videos

The bad OKR prescribes solutions (redesigned flow, tooltips, videos) instead of outcomes. The team is not empowered to discover the best solution -- they are assigned features.

---

Outcome-Based Roadmaps

The Problem with Feature Roadmaps

Traditional feature roadmaps list specific features with delivery dates. They create three problems:

1. Commitment before discovery: Features are promised before the team has validated whether they will work
2. Solution lock-in: The team cannot pivot to a better solution without "breaking a promise"
3. Output illusion: Shipping all features "on time" can feel like success even if customer outcomes don't improve

Outcome-Based Alternative

An outcome-based roadmap communicates the problems the team will tackle and the outcomes they aim to achieve, without prescribing specific solutions.

Feature roadmap (problematic):

Q1: Ship new dashboard, Add SSO support, Rebuild notification system
Q2: Launch mobile app, Add team analytics, Integrate with Salesforce

Outcome-based roadmap (empowering):

Q1: Reduce time-to-insight for daily users (target: <2 min)
    Improve enterprise security compliance (target: SOC 2 certification)
Q2: Enable core workflows on mobile (target: 30% mobile MAU)
    Help team leads identify at-risk accounts (target: churn prediction accuracy >80%)

Communicating Roadmaps to Stakeholders

Stakeholders, especially executives and sales teams, often resist outcome-based roadmaps because they want certainty about what will be built and when.

How to manage this transition:

1. Educate on the problem: Share examples of past features that shipped on time but failed to achieve their intended impact
2. Provide high-confidence commitments: Some items (compliance requirements, contractual obligations) do need committed delivery dates. Separate these from discovery-dependent items
3. Share discovery progress: Instead of feature status updates, share learning updates: what you've discovered, what you've tested, what evidence supports the current direction
4. Build trust incrementally: Start with one team using outcome-based roadmaps. When they demonstrate better results, expand to other teams

---

Strategic Context as Enabler

The ultimate purpose of vision, strategy, principles, OKRs, and outcome-based roadmaps is to provide enough context that empowered teams can make good decisions autonomously.

The test: If a team member can answer these questions, they have sufficient strategic context:

• "What future are we building toward?" (Vision)
• "What are we focusing on this year, and why?" (Strategy)
• "What do we prioritize when we face tradeoffs?" (Principles)
• "What outcomes does my team own this quarter?" (OKRs)
• "How do my team's objectives connect to the company's goals?" (Alignment)

If team members cannot answer these questions, leadership has failed to provide adequate context -- and empowerment will produce chaos instead of innovation.