Lesson 10: Product Strategy Basics

Lesson 9 ended with an unresolved gap: a project management company had a genuinely well-written vision — asynchronous work as the future — and a roadmap that quietly contradicted it, because nothing connected the two. This lesson exists to fill that exact gap. If a vision answers "where are we going and why does it matter," product strategy answers the much harder question: "given where we are right now, with our specific constraints, what is the smallest number of deliberate choices we can make, in what order, that plausibly gets us there — and just as importantly, what are we choosing not to do?"

Strategy is frequently confused with ambition, with a list of priorities, or with a roadmap dressed up in more formal language. This lesson treats strategy as something much narrower and more useful: a coherent, evidence-based diagnosis of the situation, a guiding policy for responding to it, and a set of coordinated actions that follow from that policy — a structure closely associated with strategy scholar Richard Rumelt's work, and one that stands in sharp contrast to what Rumelt calls "bad strategy": a restatement of goals, a list of priorities with no underlying logic connecting them, or motivational language mistaken for an actual plan.

This matters because most of the damage done by "strategy" in real product organizations comes not from having the wrong strategy, but from never having one at all — operating instead on an implicit assumption that ambition, hard work, and a good vision will somehow add up to a coherent path forward, without ever doing the harder, more uncomfortable work of explicitly ruling things out.

Learning Objectives

1
Define product strategy using the diagnosis–guiding policy–coordinated action structure, and distinguish it from a goal, a vision, and a roadmap.
2
Identify "bad strategy" patterns: fluff, failure to face the challenge, mistaking goals for strategy, and a grab-bag of disconnected objectives.
3
Explain why a real strategy necessarily excludes options, and why an unwillingness to exclude anything is itself a sign that no real strategy exists.
4
Apply a basic method for connecting a stated vision (Lesson 9) to a concrete near-term strategy through sequenced, evidence-based choices.
5
Distinguish a strategic choice from a tactical or operational one, and explain why conflating the two produces the "vision without strategy" failure from Lesson 9.

Lesson 7 (Value Proposition) and Lesson 9 (Product Vision). This lesson assumes fluency with the Altitude Ladder (Mission → Vision → Strategy → Roadmap → Features) and treats strategy as the specific, missing middle layer between a stated long-term direction and this quarter's concrete work.

The Core Definition: Diagnosis, Guiding Policy, Coordinated Action

A useful, precise definition of strategy, adapted from Richard Rumelt's influential formulation, breaks it into three necessary components:

Diagnosis: a clear-eyed, evidence-based account of the actual situation — what's really happening, what's really constraining progress, and why. Not a wish list of what you'd like to be true, but an honest assessment of the current reality.
Guiding policy: a general approach for dealing with the situation identified in the diagnosis — the overall logic that will govern subsequent decisions, without yet specifying every individual action.
Coordinated actions: the specific, mutually reinforcing set of near-term steps that follow from, and are consistent with, the guiding policy.

Notice how this differs from simply stating an ambitious goal. "We will become the market leader in project management software" is a goal, not a strategy — it contains no diagnosis of why the company isn't currently the market leader, no guiding policy for how that gap will be closed, and no specific coordinated actions. A real strategy for the same ambition might read: "Our diagnosis is that enterprise buyers currently choose incumbents primarily on compliance and integration depth, not features, and our current product is feature-competitive but integration-weak (diagnosis). Our guiding policy is to win through a narrow, best-in-class integration ecosystem rather than competing broadly on feature count (guiding policy). Our coordinated actions this year are: build our top three requested integrations, deprioritize a planned but unvalidated new module, and reallocate that engineering capacity to an integrations team (coordinated actions)."

Bad Strategy: The Patterns to Recognize

Rumelt's work identifies several recurring patterns of "bad strategy" that are worth naming explicitly, because they are common, superficially plausible, and easy to produce without realizing a real strategy was never actually developed:

Fluff: language that sounds sophisticated or strategic but, on close inspection, states nothing concrete or falsifiable — restating a goal in more abstract vocabulary rather than actually diagnosing anything.
Failure to face the challenge: a strategy document that never actually names the core obstacle standing in the way, often because naming it honestly would be uncomfortable (it might implicate a prior decision, a beloved product area, or a powerful stakeholder's pet project).
Mistaking goals for strategy: stating an ambitious outcome ("increase market share by 20%") as if the statement itself constituted a plan for achieving it, with no diagnosis or guiding policy attached.
A grab-bag of disconnected objectives: a list of priorities that may each be individually reasonable, but that don't reinforce or build on each other, and that could just as easily be reordered or partially abandoned without the overall plan changing in any coherent way — because there was never really a unifying logic connecting them in the first place.

A useful diagnostic test for any strategy document: does it name a specific, honestly identified obstacle, and does it explain a specific logic for overcoming that particular obstacle — or could the same document, with only the company's name changed, be handed to a direct competitor with an entirely different situation and still sound equally plausible? A real strategy should not be interchangeable across companies in fundamentally different situations; a fake one usually is.

Why Real Strategy Necessarily Excludes Things

The single most reliable signal that a strategy is real, rather than decorative, is that it says no to some genuinely plausible, individually reasonable options — not because those options are bad in the abstract, but because pursuing them would dilute focus, resources, or coherence relative to the chosen guiding policy. This directly echoes Lesson 7's argument that a value proposition trying to serve "everyone" has made no real choice at all — strategy operates on the same underlying logic, at a broader scope.

A strategy that endorses every plausible initiative simultaneously — more features, more markets, more integrations, more platforms, all pursued at once, all described as "priorities" — has not actually made the hard trade-offs that define real strategic work. This is uncomfortable precisely because every individual excluded option usually has a genuine, articulable case in its favor; the discipline of strategy is choosing anyway, based on the diagnosis, rather than trying to avoid the discomfort of exclusion by pursuing everything at a diluted level of investment.

Connecting Vision to Strategy: The Missing Middle Layer

Recall Lesson 9's Detailed Case Study: a company had a specific, well-written vision (a future of asynchronous work) and a roadmap that quietly worked against it, because no strategy connected the two. The practical method for closing this gap involves working backward from the vision through a specific sequence:

Name the current gap. What is the honest, evidence-based distance between where the product is today and the described future state? (This is the diagnosis.)
Identify the two or three highest-leverage obstacles actually standing in the way of closing that gap — not every possible obstacle, but the ones that, if resolved, would most unlock progress toward the vision.
Choose a guiding policy for addressing those specific obstacles — a general logic, not yet a full task list.
Derive coordinated near-term actions from that guiding policy, explicitly checking each one against the Vision Filter from Lesson 9 (does this action move toward the vision, sit neutral, or conflict with it?).
Explicitly name what will NOT be pursued, even if individually reasonable, because it doesn't follow from the chosen guiding policy.

Applied to the asynchronous-work case: the diagnosis might reveal that the biggest obstacle to the vision isn't a lack of async-specific features, but the fact that the product's core interaction model still assumes synchronous presence by default (the live "who's online now" indicator being a symptom, not a cause). The guiding policy might then be: "redesign core workflows to default to async-first patterns, rather than adding async features on top of a fundamentally synchronous core." Coordinated actions might include redesigning the update/notification model around structured async check-ins, and — critically — explicitly deprioritizing further investment in real-time presence and live-notification speed, even though these were individually popular with some customers, because they run counter to the chosen guiding policy.

Common Mistakes to Avoid

Presenting a goal as if it were a strategy

"Our strategy is to double revenue this year" states an ambition with no diagnosis of the current obstacle and no guiding policy for overcoming it — it is a target, not a strategy, and stating it more forcefully or more often does not make it one.

Writing a strategy document full of fluff that could apply to any company

Sophisticated-sounding language ("we will leverage synergies to drive customer-centric innovation") that states nothing falsifiable or specific to the actual situation is the clearest sign that real diagnostic work was skipped.

Refusing to exclude anything

A "strategy" that endorses every plausible initiative as a simultaneous priority has not made a real choice, and functions more as a wish list than a plan — echoing Lesson 7's "for everyone" value proposition failure at a broader scope.

Confusing strategic choices with tactical or operational ones

Deciding which specific bug to fix first this sprint is an operational decision; deciding which integration ecosystem to build a competitive moat around is strategic. Treating every decision as equally "strategic" dilutes the term and makes it harder to recognize when a genuinely consequential choice is actually being made.

Skipping the diagnosis and jumping straight to guiding policy

A guiding policy chosen without an honest diagnosis of the actual obstacle tends to reflect whatever approach the team already prefers or is most comfortable with, rather than the approach that genuinely fits the situation — strategy built backward from a preferred solution, rather than forward from an honest read of reality.

Product Strategy Basics