The Key Insight: Two Cascades, Not One
Most companies think of strategy as a single chain: Mission → OKRs → Projects. But multi-vertical B2B companies actually have two cascades running in parallel, a company-level cascade that sets constraints and allocates resources, and a product-level cascade per vertical that determines what gets built. The Roadmap Decision Framework sits at the intersection, translating both cascades into a binary eligibility test.
What it answers
"Why does this company exist? What change are we creating in the world?" The mission rarely changes. It's the north star that every other layer ultimately serves.
How it influences product decisions
The mission does not filter individual projects, it's too broad for that. Instead, it constrains which markets, customers, and problems are in scope at all. If something has nothing to do with the mission, it shouldn't exist in any layer below.
Update cadence
Almost never. Only changes with fundamental pivots. Reviewed at annual board strategy sessions to confirm it still holds.
Test: Is the mission doing its job?
Can you name three categories of product work that your mission would clearly exclude? If not, it's not constraining enough, but that's expected. Constraint comes from layers below.
What it answers
"What does the world look like if we succeed?" The vision describes a future state, it's aspirational and specific enough to be falsifiable. It's what Marty Cagan calls the product vision: "What positive change will we create?"
How it influences product decisions
The vision sets the direction of travel. It doesn't tell you what to build this quarter, but it tells you whether a strategic bet is moving toward the destination or away from it. The vision should make certain 3-year strategies obviously wrong.
Test: Is the vision doing its job?
Can you name a plausible 3-year strategic objective that your vision would clearly rule out? If not, sharpen the vision.
THIS IS THE MISSING LAYER for most companies
Strategic pillars sit between vision and OKRs. They are the explicit, named bets the company is making, and critically, they define what you're not doing. OKRs are then set per pillar, which is what makes them narrow enough to filter.
What makes a good pillar?
- 3–5 pillars maximum (forces trade-offs)
- Each pillar is a bet, not a department or function
- Each pillar has a clear owner on the exec team
- You can articulate what you're not investing in because of each pillar
- If a pillar fails, you'd change strategy, not just miss a target
How pillars solve the "everything fits" OKR problem
Without pillars, OKRs are set against broad ambitions ("grow revenue"). With pillars, OKRs are set against specific bets ("win [core use case] as [Vertical A] beachhead"). A PM pitching a tangential feature can't claim alignment because the pillar explicitly constrains which part of the vertical you're investing in.
Test: Are the pillars doing their job?
For each pillar, name one plausible project that sounds good but doesn't serve this pillar. If everything fits every pillar, they're themes, not bets.
OKRs set per pillar, not per function
The critical design choice: each OKR must trace to a specific strategic pillar. This creates the "narrowness" that makes OKRs useful as a filter. Quarterly Key Results then provide the measurable targets that projects can be ranked against.
How OKRs influence product decisions
- Objectives → too broad to filter individual projects
- Key Results → specific enough to rank competing projects ("which moves KR X more?")
- The "Direct Connection Test": every initiative maps to a specific KR, not just an Objective
Each vertical has its own mini-cascade
Product Vision → Product Strategy (phased) → Strategic Pillars (how we'll win) → ICP → JTBDs → Roadmap. This is where vertical PMs live. The company cascade constrains which verticals exist and what phase they're in; the vertical cascade determines what gets built.
What it contains
- Vertical Product Vision, the future for THIS market
- Phased Strategy, Phase 1 (PMF) → Phase 2 (Market Leadership) → Phase 3 (Category)
- Product Strategic Pillars, how this vertical will win (competitive advantages)
- ICP & JTBDs, who we serve and what jobs we solve
- Maturity Stage, Exploring / Committed / Market Leadership
Where all the layers converge
The framework encodes both cascades into binary, testable questions. Gate 1 comes from company strategy (e.g. net new revenue). Gate 2 comes from vertical product strategy (ICP, JTBD, maturity stage). Gate 3 comes from platform needs. Gate 4 comes from partnership strategy.
Stage A: Filter (Binary), "Does this belong?"
The 4-gate framework. Projects pass or fail. No scoring. Company strategy sets Gate 1; vertical product strategy sets Gate 2. This is where mission/vision/OKRs are already embedded, through the specific questions the gates ask.
Stage B: Prioritise (Ranked), "In what order?"
This is where OKR Key Results earn their keep. Among projects that pass the filter, which one moves a specific KR most? The "Direct Connection Test": name the KR and the expected metric movement.
Stage C: Sequence (Capacity), "Can we, and when?"
Dependencies, team availability, deal timelines, technical readiness. The "when" layer.
Every roadmap item is traceable
Each item carries: a rationale label (PMF / Named Opportunity / Platform / Partnership), a strategic pillar it serves, a Key Result it advances, and the gate evidence that got it through the filter. If someone asks "why are we building this?", you can trace it all the way up to the mission.
Tickets inherit context from above
Every ticket should be traceable to a roadmap item, which is traceable to a gate path, which encodes a strategic bet. The framework doesn't add overhead here, the traceability was established when the roadmap item was approved.
Assess Your Strategy Stack
Use this tab to evaluate what exists at each layer in your company. Most companies have strong material at several levels. The gaps are typically not about missing strategy, they're about missing connections between layers and a missing "narrowing" step between broad company OKRs and specific product decisions.
What to look for
A clear, compelling statement that constrains your company to a specific domain but allows multiple verticals. It should NOT filter individual projects (that's by design). If your mission could apply to any tech company, it's too broad.
Self-assessment
Write your mission here. Does it clearly define the domain you operate in? Can you name markets that are clearly out of scope?
What to look for
A strong vision is time-bound, falsifiable, and ambitious. It should imply your company is essential and embedded in customer workflows, not just providing data or tools. The vision should support a multi-vertical strategy while still being specific enough to rule out certain 3-year bets.
Self-assessment
Write your vision here. Is it time-bound? Can you name a plausible strategic bet it would rule out? Does the word choice imply the right positioning (essential vs. nice-to-have)?
Common pattern: pillars exist but aren't crystallised
Most companies have strategic objectives in their multi-year strategy doc and "Strategy on a Page" documents. But these aren't framed as explicit, named bets that constrain what's in scope. The material exists, it just needs synthesis into 3–5 pillars with clear "not doing" statements.
Template for company pillars
- Pillar 1: Win [Vertical A] as beachhead, achieve PMF in core use case, expand across sub-segments
- Pillar 2: Establish [Vertical B] proof points, secure pathway through pilots and early wins
- Pillar 3: Platform for Horizon 2, advance core capabilities, multi-source data, real-time processing
- Pillar 4: Secure data/infrastructure resilience, resilient data pipelines, extensible architecture
Key question for leadership
Are these the right 3–5 bets? What are you explicitly NOT betting on this year? For each pillar, can the exec team name one real project request they'd reject because of it?
OKR 1: Market Penetration
New contracts, pilots, brand positioning, product bundles, partnerships across your primary verticals.
OKR 2: Product Advancement
Key capability milestones, proof points, platform reliability improvements.
OKR 3: Org Capacity
Headcount targets, AI enablement, pricing strategy, employee engagement.
OKR 4: Financial Discipline
ARR growth targets, CAC payback, gross margin, net revenue retention.
OKR 5: New Vertical Prep
Market validation, strategic partners, commercial framework, sales playbook.
The "everything fits" problem
When OKRs are structured by function (Sales/Product/People/Finance/GTM) rather than by strategic pillar, a PM can justify almost any product work under the broadest objectives. The fix: map each OKR to a specific pillar, then use the Key Results (not Objectives) for prioritisation.
Beachhead Vertical Product Vision
Your most mature vertical should have a specific, ambitious product vision that is distinct from the company vision. It should create a clear test: does this feature help achieve the vertical's core goal?
Product Strategic Pillars (How You'll Win)
- 1. Data Fusion & Predictive Intelligence, fusing multiple data sources for superior insight
- 2. Active Intervention & Prevention, closing the loop from insight to action
- 3. Product-led Growth, shareable features driving organic acquisition
- 4. Product Excellence, world-class UX, clarity, ease of use
- 5. Cross-Sector Partnership, bridging commercial and government customers
Phase 1: Achieve PMF
Core product capabilities, advanced alerting, AI prototypes. Focus on the primary use case for your target customer.
Phases 2 & 3 (future)
Expanded market capabilities, cross-sector collaboration, autonomous AI-powered solutions.
Your framework already encodes strategy, just not visibly
Gate 1 encodes company strategy (e.g. net new revenue). Gate 2 encodes vertical product strategy (ICP + JTBD for committed; viable pursuit area for exploring). Gate 3 encodes platform needs. Gate 4 encodes partnership strategy. The framework works, the PMs just can't always see the connection to mission/OKRs.
What's typically missing: Stage B (Prioritisation)
The framework filters but doesn't rank. When 15 projects pass, how do you choose 8? This is where OKR Key Results should operate, not as another gate, but as a ranking signal among projects that have already passed.
How Enterprise Companies Connect Strategy to Product Decisions
Different companies solve this differently, but they all have the same structural need: a way to cascade broad strategy into specific project decisions without losing either alignment or agility.
The Cascade
- Mission: Earth's most customer-centric company
- Strategy: "More products, cheaper, faster" (long-term, stable)
- Tenets: Per-team principles that constrain decisions (e.g., "we will not compromise on latency to save cost")
- PR/FAQ: Before any project gets approved, write a press release as if it's launch day. Forces clarity on customer benefit.
- 6-page memo: Deep narrative analysis replaces PowerPoint decks
What you can learn
Tenets as per-team constraints: Each vertical team could define tenets like "We will not build features that only serve [adjacent use case] until [core use case] PMF is achieved." These are more specific than company OKRs but more stable than quarterly KRs. They act as a middle layer of constraint.
The Cascade
- Company V2MOM: CEO writes it. Vision + Values + Methods + Obstacles + Measures.
- Department V2MOM: Each dept creates their own, aligned to company
- Team V2MOM: Each team creates theirs, aligned to department
- Individual V2MOM: Every employee has one
The key insight: each V2MOM includes Obstacles (what could go wrong) and Methods (how we'll execute), not just goals. This forces realistic planning.
What you can learn
Per-vertical V2MOM: Your beachhead vertical product strategy likely already has vision, strategy, and pillars. Adding explicit "Obstacles" (what could prevent PMF?) and "Measures" (how do we know we've achieved it?) strengthens the connection to company OKRs.
The Cascade
- North Star: GPTN (Global Payments Treasury Network), one concept that everything serves
- Product Buckets: Payments Core → Optimisation → Revenue Ops → Business Solutions (sequenced, not parallel)
- Decision Logs: Every PM documents each decision, rationale, and expected outcome
What you can learn
Decision logs for gate path decisions: The Roadmap Framework's rationale labels are already a lightweight version of this. Going further: every time a project passes or fails the filter, log it. Over time this creates a precedent library that makes future decisions faster and more consistent across PMs.
Why CrowdStrike is relevant
CrowdStrike has a single data platform (Falcon) serving multiple verticals/modules, each at different maturity stages. They face the exact same challenge: how to allocate engineering between platform investment and vertical-specific features.
Their approach
- "Modules per customer" as north star metric, measures platform adoption breadth
- Module maturity stages, new modules get investment ratios different from mature ones
- Platform-first architecture, shared data lake, per-module UI
What you can learn
CrowdStrike's module maturity model maps directly to vertical maturity stages (Exploring → Committed → Market Leadership). The investment ratio should differ by stage: Exploring verticals get discovery budget, Committed verticals get build budget, Market Leadership verticals get defend-and-expand budget. This could be made explicit in your framework.
The Palantir approach
- Two products, one platform: Gotham (government) + Foundry (commercial) share core data infrastructure
- Forward-Deployed Engineers (FDEs): Embed with customers to discover real needs, feed back to product
- Product vs. Services tension: Palantir famously struggled with this, custom work for enterprise customers vs. scalable product
What you can learn (and what to avoid)
Palantir's biggest lesson: don't let enterprise customer customisation eat your product roadmap. A "bespoke to single opportunity" inactive rationale and reusability tests in your framework directly address this. The framework's insistence on reusability is the right approach.
Common Gaps, Open Questions, and Recommendations
These are the most common issues to resolve when building a complete, connected strategy cascade for a multi-vertical B2B company. Organised by layer, with concrete recommendations for each.
The Gap
Most companies have strategic objectives in their multi-year strategy. They have annual OKRs. They may have product pillars per vertical. But there's no single, shared set of 3–5 company-level strategic pillars that explicitly says "these are our bets and everything else is out of scope."
The Fix
Work with the exec team to define 3–5 company pillars. Proposed test: for each pillar, the exec team must be able to name one real project request they'd reject because of it. If they can't, the pillar isn't constraining enough.
Open questions for leadership
Is your newest vertical a "pillar" (active bet) or a "watchlist item" (not investing yet)? Is org scaling a pillar or a supporting capability? Where does data/infrastructure resilience sit, company pillar or platform concern?
The Gap
OKRs are often structured by function (Sales/Product/People/Finance/GTM) rather than by strategic pillar. They're not mapped to specific bets, which is why everything can be justified. A PM says "this supports OKR 1", but OKR 1 covers multiple verticals, which is most of the company.
The Fix
Two changes: (1) Tag each OKR to its parent pillar. (2) Add a "Stage B: Prioritise" step after the filter where PMs must name the specific Key Result (not Objective) their project advances, and estimate the expected metric movement. This gives you ranking power without weakening the binary filter.
The Fix
Add a one-page preamble to your Roadmap Decision Framework (before the first section) that shows: "Here are our company strategic pillars. Here are the OKRs mapped to each pillar. Here's how each gate encodes these. When pillars/OKRs change, gates may change too." This gives PMs the connection they're asking for without adding gates.
Specifically, map:
- Gate 1 ← Company pillar: your primary growth lever constraint
- Gate 2 (Committed) ← Beachhead Vertical Product Strategy: ICP, JTBDs
- Gate 2 (Exploring) ← Exploring Vertical Strategy: viable pursuit areas from Problem Fit Score
- Gate 3 ← Platform pillar: Horizon 2 transition, multi-vertical architecture
- Gate 4 ← Partnership strategy: named GTM partnerships
The Gap
Your most mature vertical likely has a full product strategy (vision, pillars, ICP, JTBDs, phased roadmap, success metrics). Newer verticals may only have a Problem Fit Score methodology or an opportunity matrix. The newest vertical may be in pure exploration. This is fine, they're at different maturity stages, but it means the framework gates for exploring verticals are less well-defined.
The Fix
This doesn't all need to happen now. For exploring verticals, the Problem Fit Score IS the strategy. But as a vertical moves toward Committed, it will need a full product strategy equivalent to the beachhead. New verticals stay as exploration/discovery until activation is approved, at which point they need their own product vision, ICP, and JTBDs.
The Tension
Your beachhead vertical's product pillars are the "how we'll win" for one vertical. Company OKRs are the "what we need to achieve" across all verticals. These should reinforce each other, but they're often created somewhat independently.
The ideal flow (from Hoshin Kanri "Catchball")
Top-down: Company pillars say "win [Vertical A] beachhead" → vertical product strategy says "here's how, via these pillars" → OKRs set measurable targets. Bottom-up: The vertical team says "to achieve our pillar, we need X capability by Q3" → this informs the KR targets. The bidirectional loop is what creates realistic, achievable OKRs that actually constrain.