Advanced product strategy is the discipline of connecting a fixed long-term vision to the specific bets, resource trade-offs, and delivery decisions that make that vision real, operating as a system of coherent, mutually reinforcing choices rather than a static document. Six layers do the work: vision, positioning, diagnosis, moats, bets, and execution.
Advanced product strategy links six layers — vision, positioning, diagnosis, moats, bets, and execution — into one traceable chain. If you can't connect this week's sprint ticket back to the vision statement in a few hops, the strategy isn't a system yet. It's a slogan with a roadmap attached.
Strategy Is a System of Coherent Choices, Not a Document
Most strategy work fails before a single feature ships because it treats strategy as a document to approve rather than a system of choices that has to stay coherent under pressure. Richard Rumelt's "kernel" and Roger Martin's "cascade" are two rigorous, largely compatible descriptions of that same system.
Rumelt, in Good Strategy/Bad Strategy, spends less energy defining good strategy than diagnosing bad strategy, because bad strategy is what most organizations actually produce. He names three recurring symptoms: fluff (jargon dressed up as insight), a failure to face the challenge (no honest diagnosis of what's actually in the way), and mistaking goals for strategy (a list of desirable outcomes with no theory of how to get there).
His alternative is a kernel with three parts: a diagnosis naming the specific obstacle, a guiding policy for approaching it, and coherent actions that reinforce each other instead of merely coexisting in the same slide deck. Roger Martin and A.G. Lafley's strategy cascade, from Playing to Win, asks the same question at a different altitude — a winning aspiration, a choice of where to play, a choice of how to win there, the capabilities required, and the management systems that keep it running.
The two frameworks disagree on vocabulary but agree on the mechanism: strategy happens at more than one altitude, and a senior PM's actual job is translating between them. A change in guiding policy has to show up in the backlog within a quarter, and a stubborn pattern in the backlog has to get noticed as evidence the guiding policy needs to change. Most strategy documents only work in one of those two directions.
This guide treats those models as compatible descriptions of one system with six practical layers: vision, positioning, diagnosis, moats, bets, and execution. To keep the layers concrete, we'll follow one illustrative company through all six. Call it Meridian — a hypothetical mid-market spend-management SaaS business at roughly $18M ARR, squeezed between free spreadsheet habits on one side and well-funded, all-in-one finance suites on the other. Nothing about Meridian is a real case study; it's a composite built to carry the connective tissue between layers.
Here's the map of the whole guide — six layers, in the order a coherent strategy actually has to answer them:
| Layer | Core Question | Typical Artifact | What Breaks Without It |
|---|---|---|---|
| Vision | Where are we going, and why does it matter? | One durable sentence | Teams optimize for local wins with no shared destination |
| Positioning | Who do we win for, against what alternative? | Positioning statement, competitive map | Sales and product argue past each other; messaging drifts every quarter |
| Kernel (diagnosis) | What is actually in our way? | Diagnosis + guiding policy | Roadmaps become wish lists instead of responses to a real obstacle |
| Moats | Why won't this advantage get competed away? | Moat / power assessment | Differentiation erodes the moment a competitor copies the feature |
| Bets | Where do we deliberately over- or under-invest? | Portfolio allocation across horizons | Every initiative gets equal resourcing; nothing gets enough to win |
| Execution cascade | What ships this quarter, and why? | OKRs, roadmap themes, backlog | Strategy and delivery become two unrelated documents |
Vision: The Fixed Point on the Horizon
Vision is the one layer of strategy that shouldn't move when the market does — it's the fixed point every other layer gets tested against. A working vision statement is specific enough to make some future choices obviously wrong, yet durable enough to survive years of tactical change underneath it.
Vision isn't mission (why the organization exists), and it isn't strategy (how you'll win). It's closer to a bet on where the world is going and a claim about the role your product plays once it arrives. Meridian's vision might read: "Every finance team makes spend decisions with the real-time confidence of a trading desk." Notice what it doesn't do — it never mentions expense reports, approval workflows, or any feature that exists today.
Vision also runs on a different clock than the rest of the system. Positioning might get re-tested every six months and the kernel every quarter, but a vision built to last should survive five to ten years of tactical change underneath it. If it's being rewritten every planning cycle, it was never a vision — it was a goal wearing a vision's title.
A vision statement earns its keep by passing three blunt tests:
- Does it rule anything out? If a competitor's tagline could swap in for yours and nobody would notice, it isn't a vision — it's a mood.
- Could a new hire repeat it, unprompted, after one meeting? If it needs the slide to make sense, it's leaning on delivery instead of the sentence itself.
- Does it still hold if today's flagship feature disappeared tomorrow? A vision anchored to a feature is a roadmap item wearing a vision's clothes.
Most vision statements fail the second test specifically — written to be approved at a leadership offsite, not repeated by an engineer three months later in a design review. Writing one that clears that bar is a specific, learnable craft rather than an inspiration exercise; the deeper walkthrough on writing a product vision people actually repeat covers the drafting mechanics this guide doesn't have room for.
Positioning: Choosing Who You Win For, and Against Whom
Positioning translates a vision into a specific, falsifiable claim: for this customer, against this alternative, we win because of this attribute. April Dunford's method — built around competitive alternatives, unique attributes, translated value, and target market characteristics — remains the sharpest tool for making that claim testable instead of aspirational.
Senior PMs tend to skip positioning work, assuming marketing solved it back at launch. That's a mistake: positioning decays as fast as the category evolves, and the competitive alternative a product beat two years ago is rarely the one it's actually losing deals to now. For a lot of B2B products, the honest competitive alternative was never a named competitor at all — it was a spreadsheet, an intern doing the work manually, or "we'll get to it next quarter."
Dunford's method, from Obviously Awesome, works through five components in order:
- Competitive alternatives — what would the customer do if your product didn't exist?
- Unique attributes — what do you have that those alternatives don't?
- Value — what does that attribute actually let the customer do or avoid?
- Target market characteristics — which customers care most about that value?
- Market category — the frame that makes the value obvious without an explanation.
That unique-attribute claim usually comes from Jobs-to-be-Done-style research — understanding the underlying job a customer is "hiring" the product to do — rather than from a feature audit. Clayton Christensen's framing of the job as the actual unit of analysis is what keeps this exercise from collapsing back into a feature list dressed up as insight.
Market category is the most consequential of Dunford's five components, because it's the one senior PMs most often inherit instead of choosing. Competing inside an existing, well-understood category borrows credibility but caps the price customers expect to pay; naming a new one earns pricing power but costs education time most sales cycles don't have. Neither choice is free, which is why it belongs in the strategy conversation, not just the launch deck.
Meridian's honest competitive alternative isn't a rival spend-management vendor — it's a finance analyst manually reviewing card statements in a spreadsheet once a month, alongside a legacy tool like Concur handling approval routing. Meridian's unique attribute is real-time, policy-aware anomaly detection at the point of swipe, not after-the-fact approval. The target market is mid-market finance teams of 50–500 employees with no dedicated FP&A analyst to do that review by hand. That combination — not a longer feature list — is the positioning.
Positioning claims go stale quietly. The competitor you beat at launch is rarely the one costing you deals two years later.
Running a structured teardown of the two or three alternatives customers actually compare you to, on a fixed half-yearly schedule, is the practical habit that keeps a positioning claim honest instead of nostalgic — the complete guide to teardowns and case studies covers how to run one well.
The Kernel: Diagnosis, Guiding Policy, Coherent Action
The kernel is the mechanism that turns a vision and a position into an actual strategy: a clear-eyed diagnosis of the real obstacle, a guiding policy for tackling it, and coherent actions that reinforce rather than contradict each other. Skip the diagnosis, and everything downstream is a list of goals wearing a strategy's clothes.
Diagnosis is the hardest and most frequently skipped step, because it requires naming an uncomfortable truth rather than a comforting ambition. "We want to grow 40% next year" is a goal. "We're competing as a workflow-automation vendor in a category that's commoditizing fast, and the differentiated data we actually own is sitting unused" is a diagnosis. Only the second one tells you what to do differently.
Building that diagnosis from evidence instead of opinion is exactly the gap that situational-awareness tools are built to close. Mapping the value chain underneath a product, and where each component sits on the evolution axis from genesis to commodity, turns a diagnosis from a hunch into something defensible in a room full of skeptical engineers — the guide to Wardley Mapping and seeing the whole board walks through how to build that map.
Guiding policy is the overall approach implied by the diagnosis — not a goal, an approach. Coherent actions are the specific steps that follow from the policy and reinforce each other, rather than a portfolio of individually defensible ideas that happen to share a strategy document.
The most common diagnosis mistake isn't laziness, it's stopping one level too early — naming a symptom ("churn is rising") instead of the mechanism producing it ("customers can't tell our anomaly detection apart from a rules engine they already own"). A useful check borrowed from systems thinking: keep asking what's causing that, one more time than feels comfortable, until the answer points at something a guiding policy can actually act on.
| Kernel Component | Definition | Meridian's Version |
|---|---|---|
| Diagnosis | The single obstacle that most explains current performance, stated as a specific claim | "We're competing as a workflow vendor in a commoditizing category; our differentiated transaction data sits unused." |
| Guiding Policy | An overall approach for tackling that obstacle — not a goal, an approach | "Reposition from expense workflow to real-time spend intelligence; treat transaction data as the product." |
| Coherent Actions | Specific, mutually reinforcing steps that follow from the policy | Kill the custom approval-chain builder; ship anomaly detection; renegotiate card-issuer data feeds; re-price around insight delivered, not seats |
Bad strategy rarely looks bad line by line. It looks bad when you hold two lines next to each other.
A guiding policy to "win on data, not workflow" is incoherent alongside a pricing model that still bills per seat for workflow access — the pricing quietly keeps rewarding the thing the policy just said it would stop competing on. Coherence is what separates a kernel from a wish list.
Moats: Making Advantage Durable
A competitive advantage is anything that currently makes you better than the alternatives; a moat is the mechanism that stops a well-funded competitor from copying that advantage within a budget cycle. Hamilton Helmer's 7 Powers and Michael Porter's Five Forces both formalize the same question: what actually stops this from being replicated?
Most features senior PMs call a "moat" aren't moats at all — they're advantages a funded competitor could copy in a quarter. Better UX, more integrations, a longer feature list: real advantages, thin moats. The moats that actually hold tend to come from a short, recognizable list:
| Moat Type | How It Forms | Meridian Test |
|---|---|---|
| Network economies | The product improves for each user as more users join | Does every customer's transaction data improve detection for everyone, or just for that account? |
| Switching costs | Leaving gets more expensive (money, time, risk) the longer a customer stays | Is the policy library embedded deep enough that leaving means starting over from zero? |
| Counter-positioning | Incumbents can't copy without damaging their own core business | Would a legacy suite have to cannibalize seat-based pricing to copy this? |
| Process power | Operational know-how competitors can't easily observe or replicate | Are the models trained on patterns a competitor can't see without the same transaction volume? |
Two more of Helmer's powers deserve a mention even where they don't fit Meridian yet: scale economies, where unit costs drop as volume grows in a way smaller entrants can't match, and branding, where trust built over years lets you charge a premium a feature-equivalent challenger can't. Both are real. Both are also the two powers most often claimed without evidence, which is exactly why the test matters more than the label.
Meridian's honest answer, mid-year, was that it had an advantage — real-time detection — but not yet a moat. Nothing stopped a well-funded competitor from shipping the same feature within two quarters. The moat, if it forms at all, will come from the network economics of transaction data: every new customer's spend pattern improves the anomaly baseline for every other customer, a mechanism a competitor can't shortcut by copying the interface.
That data-driven moat carries a governance obligation. Once a model is making judgment calls about what counts as suspicious spend, an unexplainable or ungoverned model turns the moat into a liability instead of an asset — a false-positive spree erodes trust faster than a missing feature ever would. The practices in the complete guide to advanced responsible AI are what keep a data-driven moat from becoming a trust problem.
Bets: The Portfolio That Turns Guiding Policy Into Resources
A guiding policy only becomes strategy once it's translated into an explicit portfolio of bets — initiatives that get deliberately more resourcing precisely because everything else gets less. The three-horizons model (protect the core, build the emerging business, create genuinely new options) makes that allocation intentional instead of accidental.
Rumelt's "failure to face the challenge" shows up here as a fear of choosing: a strategy document listing twelve equally weighted priorities isn't being thorough, it's avoiding the decision. If everything is a priority, resourcing spreads evenly, and nothing gets enough of it to actually win. The three-horizons model, laid out originally by McKinsey's Baghai, Coley, and White, forces the opposite: name what you're protecting, what you're building, and what you're merely keeping alive as an option.
The natural gravity of any budgeting process pulls resources toward Horizon 1 — defending the core is always the easiest line item to justify in a review — which is exactly why Horizon 3 so often starves before it has a real chance to prove anything. Protecting the second and third horizon's resourcing from the first horizon's constant emergencies is a leadership function, not a planning one.
| Horizon | Time Frame | Resourcing Posture | Meridian's Bet | Primary Risk |
|---|---|---|---|---|
| 1 — Defend the core | 0–12 months | Fund enough to hold share, not to grow it | Keep expense-workflow reliable and boring | Over-investing here starves Horizons 2 and 3 |
| 2 — Build the emerging business | 12–30 months | The largest deliberate bet | Ship and monetize real-time anomaly detection as its own line | Under-resourcing it so it never reaches escape velocity |
| 3 — Create new options | 30+ months | Small, cheap, option-like investments | Explore embedded credit lines priced off live spend data | Killing it too early for not yet showing Horizon-1-scale revenue |
A useful discipline for keeping the portfolio honest: cap the number of Horizon 2 bets that get real resourcing at one, maybe two, at a time. A portfolio with five "strategic" Horizon 2 bets is really a portfolio with none — Rumelt's fear-of-choosing symptom again, just relabeled as a horizons chart instead of a priorities list.
None of this works without a resourcing rule stated in advance — what share of the roadmap is genuinely protected for Horizon 2 and 3, regardless of how loud Horizon 1's fires get that quarter. Without that rule written down before the fires start, Horizon 1 wins the argument every time, not because it's the better bet but because it's the only one with a customer already on the phone.
The Execution Cascade: Connecting Vision to What Ships Monday
The execution cascade mechanically translates a bet into an annual objective, a quarter of OKRs, a set of roadmap themes, and finally a backlog, with a line traceable in both directions. If you can't start at a sprint ticket and walk it back to the vision in a few hops, the cascade is broken somewhere in the middle.
This is where strategy quietly dies most often — not in the vision statement, which usually survives fine, but in the handoff between guiding policy and objective-setting, where a good bet gets restated as a vague aspiration and loses its teeth. OKRs are the connective tissue built for exactly this handoff: the Objective should restate a specific bet in outcome language, and each Key Result should be a leading indicator of whether that bet is actually working, not a vanity metric that moves regardless. The complete guide to advanced OKRs covers how to write KRs that behave like leading indicators instead of activity logs.
Watch for the anti-pattern sometimes called OKR theater: objectives copied verbatim from the annual plan into every team's quarterly doc, with key results chosen because they're easy to measure rather than because they'd actually prove the bet is working. A cascade with no judgment applied at each handoff isn't a cascade — it's a mail-merge.
From there, roadmap themes translate a quarter's OKRs into a small number of named efforts, and a backlog turns each theme into epics and stories a delivery team can pull from a sprint board. How disciplined that last mile is — how well themes become a working backlog without losing the "why" — is mostly a delivery-process question, and the complete guide to agile delivery is the sharper resource for getting that mechanics right.
Walking Meridian's cascade top to bottom looks like this:
- Vision: "Every finance team makes spend decisions with the real-time confidence of a trading desk."
- Guiding policy: Reposition from workflow automation to spend intelligence.
- Bet (Horizon 2): Ship and monetize real-time anomaly detection as its own line of revenue.
- Annual objective: Prove anomaly detection is a paid, retained product line, not a bundled feature.
- Quarterly
OKR:KR— a meaningful share of accounts adopt anomaly alerts;KR— alert precision clears an agreed threshold before the next renewal cycle. - Roadmap theme: "Real-time anomaly detection v1."
- Backlog: ingestion pipeline, baseline model, alert UI, feedback loop for marking false positives.
Seven steps, one line, no gaps. That's the cascade working. The moment step four gets written by someone who never saw step two, the line breaks, and nobody notices until a retro six months later asks why the backlog doesn't seem to be going anywhere in particular.
Making Strategy Stick: Sensing, Review Cadence, and the Discipline to Say No
Strategy doesn't stay coherent by default — markets shift, competitors copy, and the diagnosis that was accurate at kickoff quietly goes stale. Making it stick means building a deliberate cadence for re-testing the diagnosis, re-scoring the moat, and, most often skipped, killing bets that no longer earn their resourcing.
Research on strategy execution — most associated with Donald Sull's work for Harvard Business Review — has repeatedly found that only a small minority of leaders consider their organization good at both setting strategy and following through on it. The gap usually isn't a bad kernel. It's the absence of a review mechanism that catches drift before a full year has passed.
A workable quarterly review re-runs four questions, in order:
- Has the obstacle changed? Re-test the diagnosis against what actually changed this quarter, not against last year's assumptions.
- Is the position still true? Run a fresh teardown of the real competitive alternatives, not the ones from the launch deck.
- Is the moat getting stronger or thinner? Re-score it against the same table used at kickoff, honestly.
- Is Horizon 2/3 resourcing still protected? Or did Horizon 1's emergencies quietly eat it again this quarter?
Pair that review with kill criteria set before a bet launches, not after it disappoints — a pre-mortem exercise, the technique psychologist Gary Klein popularized, that names in advance the specific evidence which would mean "stop funding this." It's worth the hour it costs. Sunk-cost bets that limp along with no explicit kill line are one of the more reliable ways good strategy quietly turns bad.
Keeping the System Honest
Key Takeaways
- Strategy is a system of six connected layers — vision, positioning, diagnosis (kernel), moats, bets, and execution — not a single document approved once a year.
- Rumelt's kernel (diagnosis, guiding policy, coherent action) is the mechanism that turns an aspiration into a defensible plan; skipping the diagnosis is the most common failure.
- An advantage and a moat aren't the same thing — test every claimed moat against how fast a well-funded competitor could copy it.
- Deliberately under-resourcing some bets, per the three-horizons model, is a feature of good strategy, not an oversight to fix later.
- If a sprint ticket can't be traced back to the vision in a handful of hops, the cascade is broken, not the ticket.
- Strategy decays without a standing review cadence that re-tests the diagnosis, re-scores the moat, and kills bets that stopped earning their resourcing.
Frequently Asked Questions
What's the difference between product strategy and a product roadmap?
Product strategy is the set of choices about where to compete and why you'll win there; a roadmap is one artifact, several layers downstream, that sequences the work those choices imply. A roadmap with no guiding policy behind it is a prioritized wish list, however well it's organized.
How is Rumelt's kernel different from a vision statement?
A vision statement says where you're headed and should stay fixed for years; the kernel — diagnosis, guiding policy, coherent action — explains how you'll get past the specific obstacle in front of you right now, and needs revisiting far more often than the vision itself. Conflating the two is why so many "strategies" are just restated ambitions.
How often should senior PMs revisit product strategy?
Most organizations get more value from a light quarterly re-test of the diagnosis and bet allocation than from an annual offsite that rewrites everything. Save a full positioning rewrite for when the market genuinely shifts — often every 18 to 36 months, or whenever a component in the value chain visibly crosses toward commodity — and treat the vision itself as good for years longer than that.
What's the difference between a competitive advantage and a moat?
An advantage is anything that currently makes you better than the alternatives; a moat is the specific mechanism — network economies, switching costs, counter-positioning, and similar forces from Hamilton Helmer's 7 Powers — that stops a well-resourced competitor from copying that advantage within a budget cycle or two. Most things PMs call moats in a QBR are actually just advantages.
How do OKRs connect strategy to daily execution?
OKRs sit in the middle of the cascade: the Objective should restate a specific bet in outcome language, and each KR should be a leading indicator of whether that bet is actually working. That's what lets a roadmap theme, and the backlog under it, trace cleanly back to the guiding policy that justified the bet.