Building a Product Strategy and Roadmap

Choose where to compete, how to win and which work to decline. Connect those choices to a prioritized backlog and a roadmap that distinguishes commitments, bets and exploration.

Why this matters

A feature list cannot explain why one investment deserves resources over another. Enterprise products face competing customer promises, platform dependencies and long sales cycles. Strategy gives those requests a shared test.

Start with the challenge and explicit choices. Filter opportunities against them, then score the survivors. As Cagan argued in 2026, faster AI-assisted building increases the importance of choosing the right work.

What strategy is, and what it isn’t

Rumelt’s kernel

Richard Rumelt’s Good Strategy/Bad Strategy (2011) defines a three-part kernel:

• Diagnosis: names the most important challenge and simplifies a messy situation into the one problem that matters most, including why it exists.
• Guiding policy: the overall approach to the obstacles the diagnosis found. It rules options out as much as in.
• Coherent actions: coordinated actions, policies and resource commitments that carry out the guiding policy and reinforce one another. A list of independent initiatives doesn’t qualify, however good each one is.

Start with diagnosis so reviewers can judge whether the actions address the challenge.

Rumelt identifies four hallmarks of bad strategy:

A proximate objective is reachable enough to make the challenge actionable: diagnosis acceptance across the top 50 accounts by next June, for example. A chain-link system performs at its weakest link. Strong diagnosis cannot enable adoption while security blocks deployment.

Test any guiding policy this way: can a stranger who reads it predict three requests you’ll refuse? If not, it isn’t ruling anything out.

Playing to Win: the choice cascade

A. G. Lafley and Roger Martin, in Playing to Win (2013), define strategy as an integrated set of choices and lay it out as a cascade of five questions:

1. What is our winning aspiration? The purpose, framed in terms of winning.
2. Where will we play? Customer segments, buyers, geographies, channels, product categories and stages of the value chain.
3. How will we win? The value proposition and competitive advantage in those arenas.
4. What capabilities must be in place? The activities that make the how-to-win real.
5. What management systems are required? The systems, structures and measures that build and sustain those capabilities.

The choices constrain one another, so iterate across the cascade. Nest the product cascade within business-unit and company choices. Record any conflict.

In “The Big Lie of Strategic Planning” (2014), Martin distinguishes controllable activities and budgets from strategic bets on customers and competitors. Planning feels safer because it avoids that uncertainty.

Make where-to-play choices explicit: practitioner or economic buyer, direct enterprise or partners, system of record or a layer on other data. Trying to satisfy every option spreads investment thin.

Rumelt and Martin fit together. Many cascades leave out Rumelt’s diagnosis and jump straight to aspiration. Martin’s where-to-play and how-to-win make Rumelt’s guiding policy concrete. Use the kernel as the spine and the five questions as the checklist.

For each option, ask what would have to be true about customers, competitors, capabilities and economics. Test the least certain conditions using the discovery methods in Chapter 01.

Gibson Biddle: DHM and the SMT lockup

Gibson Biddle, Netflix product leader from 2005 to 2010, connects four questions in his January 2025 Ask Gib post. GLEe frames the long term: get big, lead, expand. GEM force-ranks growth, engagement and monetization with proxy metrics. Strategy hypotheses explain delivery choices, and the roadmap sequences them.

DHM asks how to Delight customers in Hard-to-copy, Margin-enhancing ways. The SMT lockup pairs each Strategy hypothesis with a Metric and Tactics. Shipping tactics without moving the metric challenges the hypothesis.

Proxy metrics matter because top-line metrics move too slowly to steer by. Biddle’s Netflix example is retention: it’s the metric that matters, and no single experiment can move it in time to learn from. A good proxy is measurable, moveable by the team and correlated with the top metric. Chapter 02 covers metric trees.

DHM needs translation for B2B:

• Delight splits across personas. The on-call engineer wants speed, the VP an ROI story, the security reviewer controls. Delight only the practitioner and you can stall in procurement.
• Hard to copy for platforms usually means data that improves with use, integration depth and switching costs, ecosystem position or proprietary evaluation data. Chapter 16 covers moats.
• Margin-enhancing is central again for AI products, because inference cost compresses gross margin. A feature that delights and can’t be copied but loses money on every use isn’t a strategy. Chapter 15 covers pricing.

Biddle also says strategy is top-down and bottom-up, meeting in the middle. Leadership sets the cascade, teams propose SMTs that serve it, and the roadmap reconciles them.

The strategy one-pager

The strategy one-pager combines the models in nine fields: diagnosis, winning aspiration, where to play, DHM, guiding policy and refusals, coherent actions as SMTs, capabilities and systems, necessary conditions, and outcomes with guardrails.

Review the one-pager quarterly. Revise choices when evidence challenges them. Evaluate customer requests against the policy before changing it.

Prioritization frameworks compared

A scoring framework makes assumptions explicit and ranks comparable items consistently. It has two limits:

1. The inputs are opinions dressed as numbers. Multiplying three guesses gives you a precise-looking guess.
2. The score ranks only the items in front of it. A perfectly scored list of the wrong things is still the wrong list.

So the order is fixed: strategy filters first, scoring ranks second. An item that serves none of your coherent actions shouldn’t be scored at all.

RICE

Sean McBride, at Intercom, described RICE as an estimate of total impact per time worked:

RICE score = (Reach × Impact × Confidence) ÷ Effort

Reach is people or events per period (customers per quarter, say), from real product data where possible. Impact per person uses a fixed scale: massive 3, high 2, medium 1, low 0.5, minimal 0.25. Confidence is high 100%, medium 80% or low 50%; McBride treats anything lower as a moonshot. Effort is person-months across product, design and engineering. McBride’s own caveat: the score isn’t a hard rule, and a lower scorer may go first as a dependency or as table stakes for certain customers, as long as the trade-off is visible.

RICE fits many comparable, medium-sized items with usage data behind them. In B2B it has a structural bias: reach counts users, and enterprise value isn’t spread evenly across users. One regulated customer’s audit requirement can unblock a large renewal while scoring low on reach, and platform enablers score low because their reach is indirect. Define reach in accounts or ARR touched, and say so at the top of the scorecard.

ICE and the Confidence Meter

ICE multiplies Impact, Confidence and Ease on relative 1–10 scales. Sean Ellis developed it for growth experiments. It suits fast triage of small tests, but all three inputs rely on judgment.

Itamar Gilad’s Confidence Meter grades evidence. Conviction and opinions receive little weight, anecdotes and market data more, customer research more still, and observed usage the most. Use it to qualify confidence in any scoring method.

MoSCoW

MoSCoW, from the DSDM agile framework maintained by the Agile Business Consortium, sorts scope within a timebox. Must have is the minimum usable subset: without it the release is pointless, unsafe or illegal. Should have is important, with a workaround. Could have is desirable and first to drop. Won’t have this time is agreed out of scope for this timebox. DSDM’s guidance: Must Haves take no more than about 60% of estimated effort, with a pool of Could Haves at about 20% as contingency. Above 60%, the release is at risk.

Use MoSCoW for fixed-date scope such as enterprise contracts, compliance deadlines and events. It cannot order value within a bucket. Publish the Won’t list early so the field understands the boundary.

Kano

The Kano model comes from Noriaki Kano and colleagues’ 1984 paper “Attractive Quality and Must-be Quality.” Must-be features are expected: absence hurts, presence earns nothing. Performance features satisfy roughly in proportion to how much you deliver. Attractive features delight when present and cost nothing when absent. Indifferent features don’t matter, and Reverse and Questionable results usually flag survey problems. You ask a pair of questions per feature (how would you feel if you had it, and if you didn’t?), each answered with one of five options (like it, expect it, neutral, can tolerate it, dislike it), and the pair of answers classifies the feature.

Categories decay: today’s delighter becomes tomorrow’s must-be. In this book’s view, AI-generated summaries in enterprise tools have already made that trip. Kano fits decisions about a release’s mix of table stakes and differentiators. Respondents can’t rate features they’ve never seen (a real limit for novel AI capabilities), and personas disagree: an engineer may rate autonomous remediation attractive while the security reviewer rates its controls must-be. Run Kano per persona.

WSJF and cost of delay

Don Reinertsen’s The Principles of Product Development Flow (2009) emphasizes cost of delay: the economic cost of waiting. CD3 divides cost of delay by duration to prioritize value delivered per unit of time.

The Scaled Agile Framework (SAFe) turned this into WSJF (weighted shortest job first): relative cost of delay divided by relative job duration, where cost of delay combines user and business value, time criticality, and risk reduction or opportunity enablement. WSJF ignores sunk costs, and priorities update as inputs change. Opportunity enablement credits the connector framework or data layer that unlocks later features, which RICE can’t see; time criticality credits renewal-linked features, regulatory deadlines and competitive windows.

Practitioners debate whether SAFe’s relative points lose Reinertsen’s economics. In B2B the money version is often within reach: ARR at risk at a known renewal date gives you a defensible cost of delay per month. WSJF fails through gamed relative scores and unreliable duration estimates for discovery-heavy work, which includes most AI features.

Opportunity scoring and value versus effort

Anthony Ulwick’s opportunity scoring, covered in Chapter 01, ranks customer outcomes rather than features: importance plus any positive gap between importance and satisfaction. It works at strategy level, showing which needs are underserved before you’ve chosen solutions. It costs a careful survey and can miss needs customers can’t yet articulate. In B2B, survey each buying-group role separately.

The value versus effort 2×2 has no single originator and many quadrant names (quick wins, big bets, fill-ins, money pits). It’s a good first cut in a workshop and an easy picture for executives, but both axes are guesses, risk and timing vanish, and optimistic estimates drift everything toward quick wins. Adding a confidence column makes it much more honest.

Choosing a framework

Choose the scoring lens deliberately. RICE favors reach, WSJF time-sensitive work and enablers, and Kano feature mix. Use the guiding policy to choose the lens and record the reason on the scorecard.

Building and keeping a healthy backlog

The 2020 Scrum Guide defines the Product Backlog as an emergent, ordered list linked to a Product Goal. Maintain one sequence and revise it as evidence changes. The Product Owner may delegate work while retaining accountability.

Pichler’s DEEP criteria are Detailed appropriately, Estimated, Emergent and Prioritized. Add detail near delivery. For backlogs of several hundred items, he recommends deriving a fresh backlog from the roadmap.

Ryan Singer’s Shape Up uses a betting table to select pitches for six-week cycles. Unchosen pitches stay outside a central backlog. Their advocates may return with them later.

Teresa Torres’s opportunity solution tree links the backlog to strategy. The desired outcome sits at the root, customer opportunities branch from it, and solutions and assumption tests sit below. In her framing, a solution placed in the delivery backlog is a bet, and discovery reduces its risk.

Three stores, not one list

For an enterprise or platform team, stop treating every request as a backlog item. This book recommends three stores:

1. Request inbox. Every raw ask from customers, sales, partners and support, linked to the account and its ARR. Never ordered and never promised, but searchable, so a seller can see that a request was logged and where it went.
2. Opportunity backlog. Requests clustered into customer problems, sized by accounts and ARR, and linked to the strategy’s coherent actions. Strategy filtering happens here.
3. Delivery backlog. Ordered, refined, sized and short: only enough for the next one or two cycles of the Now column.

An item enters the delivery backlog with a linked opportunity and outcome, an evidence level, an owner, a rough size and acceptance criteria; AI features also need an eval or quality bar (Chapter 31). Items untouched for two quarters are archived with a reason, and every request gets a status a seller can quote, such as “logged, mapped to the multi-tenant theme, not planned this half.”

The policy also declares a capacity split across new value, platform and enablers, quality and debt, and customer commitments. Chapter 06 treats technical debt as a product decision; the split is where that decision becomes visible. If the split isn’t written down, the urgent crowds out the important.

Roadmaps that tell the truth

Why feature-and-date roadmaps fail

In 2013, Cagan argued that at least half of product ideas fail and successful ideas usually need several iterations. Feature-and-date roadmaps commit before either uncertainty is resolved.

In “The Alternative to Roadmaps” (2015), Cagan proposes vision and strategy, team business objectives, and high-integrity commitments where dates matter. Review how many previous roadmap items met their business objectives.

In October 2026, Cagan described the tension as outcomes versus predictability. His cited Kniberg formulation, “100% predictability = 0% innovation,” challenges treating an entire roadmap as fixed promises. Use commitment techniques where predictability is genuinely required.

This book’s position follows. Every roadmap item is one of three types, and says which:

• Commitments carry a date because a customer, regulator, partner or launch depends on it. Make one only after enough discovery that the team knows the solution is valuable, usable and feasible, and engineers have estimated it. Then keep the date. Deprecations, contracted features and regulatory deadlines are commitments by nature.
• Bets are framed as outcomes, sized by how much you’re willing to spend and open to being killed on evidence. Nobody outside the team sees a date.
• Explorations are discovery only, with no delivery promise.

The mix is a health check. A roadmap that is mostly commitments leaves no room to learn; one with no commitments won’t survive enterprise sales.

Now, next, later

Janna Bastow first sketched now-next-later in 2012 and described its development in 2022. Now is well-defined work underway. Next has less detail and depends on learning. Later contains larger problems with unresolved solutions.

Bastow’s rules make the format work. Items are problems first, with ideas and experiments attached and tied to objectives. Columns reflect confidence, not calendar time, and needn’t be the same size. You commit only to near-term work, though a time-sensitive item can carry a deadline, and accountability lives in objectives rather than dates.

Enterprise products need one adaptation. Sales and customers legitimately need dates for contracted features, compliance deadlines and deprecations. Keep the structure, mark that small set of commitments explicitly, and leave everything else undated.

Theme-based roadmaps

Lombardo, McCarthy, Ryan and Connors’s Product Roadmaps Relaunched (2017) organizes themes around customer problems, vision and business objectives. Use broad horizons and disclose uncertainty. Add features and confidence where audiences need them. Build agreement through individual conversations before the review.

Themes are the bridge from strategy. Each coherent action in the kernel should map to one or more themes, and each theme should name the outcome metric it moves. If a theme traces to no coherent action, ask why it’s on the roadmap.

One roadmap, several views

Build the roadmap once, then generate a view per audience:

• Executives: outcomes, bets, the capacity split, risks and decisions needed, on one page (Chapter 35).
• Sales and the field: dated commitments, undated themes, the Won’t list, how to log a request and your company’s forward-looking disclaimer; get legal guidance on roadmap disclosure before you publish (Chapter 27).
• Customers: the problems you’re solving and your direction, commitments only where contractual, and design-partner invitations instead of feature promises.
• Partners and developers: API changes and deprecation timelines, with longer notice than direct customers get, because partners have their own customers to tell.

Every view carries a changelog of what moved and why. A roadmap that changes silently loses trust faster than one that changes often and says so.

How to apply it

This method builds the Strategy dimension of a Product 360 and connects it to the roadmap. It takes about six weeks the first time and a few days each quarter after that.

Weeks 1 and 2: Diagnose and choose.

1. Gather the evidence: the hypothesis and personas (Chapter 01), the vision and North Star (Chapter 02), win/loss notes, churn reasons, competitive moves, unit economics and two quarters of customer requests.
2. Draft the diagnosis in one paragraph and test it with your manager, the engineering lead and a sales leader. Rewrite until they agree it’s the real problem, even if they don’t like it.
3. Work through the cascade. For each where-to-play choice, write what would have to be true and mark the conditions you’re least sure of.
4. Write the guiding policy with three explicit refusals, and check it against Rumelt’s four hallmarks.

Week 3: Make the bets testable.

5. Write the DHM, then turn the coherent actions into three to five SMTs, each with a proxy metric the team can move within a quarter.
6. Set one proximate objective, assemble the strategy one-pager and get it signed off by your manager and reviewed by peer PMs whose products it touches.

Week 4: Prioritize.

7. Rebuild the backlog into three stores. Cluster the request inbox into opportunities and drop those that serve no coherent action.
8. Choose your scoring lens and say why, then score the surviving opportunities with an evidence level beside every score. Write the decision column yourself (commit, bet, explore or no), with a reason for any departure from score order.

Week 5: Build the roadmap.

9. Place items in now, next and later, labeled commitment, bet or exploration. Date only commitments that have passed discovery and been estimated by engineering.
10. Write the backlog policy: stores, entry criteria, ageing rule, capacity split and cadence.

Week 6: Communicate.

11. Generate the audience views from the single roadmap, and hold the one-to-one conversations before the group review. Brief sales leadership on the Won’t list before it reaches the field.
12. Publish with a changelog and set the cadence: weekly refinement, monthly opportunity review, quarterly strategy and roadmap review (Chapter 29).

The AI lens

Roadmapping AI products when capabilities shift every quarter

Model capabilities, retirement schedules and regulation can change an AI roadmap within a planning cycle.

Capability moves fast. METR, a research group that evaluates frontier models, reported in March 2025 that the length of tasks frontier agents could complete with 50% reliability had doubled roughly every seven months over about six years, while noting wide uncertainty in that estimate. Releases come often: Anthropic, for example, announced Claude Opus 5.5 on 22 September 2026, Sonnet 5.5 six days later and Haiku 5.5 on 7 October. A Later item can become feasible within a quarter, and a Now item built around a model’s limitation can be obsolete before it ships.

Models retire on someone else’s schedule. Anthropic commits to at least 60 days’ notice before retiring a publicly released model; its published table shows Claude Sonnet 4.5 deprecated on 30 September 2026 and retiring on 30 November 2026. An externally dated retirement makes model migration a commitment-class item whether you planned for it or not.

Regulatory dates move too. The EU AI Act entered into force on 1 August 2024 and became generally applicable on 2 August 2026. The Digital Omnibus on AI (Regulation (EU) 2026/1744), in force from 27 July 2026, moved obligations for Annex III high-risk systems from 2 August 2026 to 2 December 2027, six days before the original date arrived. Treat regulatory deadlines as commitments whose date can change: track the source and replan when it moves (Chapter 33).

The practical rules:

• Frame items as outcomes that don’t depend on a particular model. “A diagnosis an on-call engineer trusts in under five minutes” survives a model change; “a fine-tuned root-cause model” may not.
• Keep a capability watchlist. For each capability-dependent Later item, record the threshold that would move it to Next, measured on your own evals, and re-run them on each new model (Chapter 31).
• Budget a fixed lane for evals and model migration in the capacity split. It’s recurring work with external dates.
• Treat unit economics as a roadmap constraint. This is Biddle’s M. Inference cost changes with model choice, so a roadmap can grow usage while shrinking margin.
• Refresh “what would have to be true” each quarter for every AI bet.
• Never give customers a date for a capability that depends on a model improvement that hasn’t shipped. That stays a bet.

Prioritization shifts as well. When AI makes building cheaper, effort estimates shrink and stop telling items apart, so weight evidence more and effort less. Cagan noted in October 2026 that A/B tests get slower and costlier for AI features, so evals come earlier and live tests are reserved for proving value. That changes how fast a bet can earn a higher Confidence Meter grade.

Doing strategy and roadmap work with AI

Use approved CRM, support, tracker and call-note connectors to cluster requests, attach accounts and revenue, flag stale items, draft evidence-linked diagnoses, compare scoring methods and generate roadmap views.

Keep strategic choices with accountable people. Review AI drafts for bland compromises that avoid tradeoffs. Link themes to source requests and accounts. Use tools approved for customer and CRM data.

The Beacon case: choosing what Beacon won’t do

The bad draft. It opens “Become the #1 AI agent platform for IT operations with best-in-class AI” and lists twelve initiatives. Against Rumelt’s hallmarks it shows fluff (best-in-class), a goal posing as strategy (#1) and a laundry list, and it has no diagnosis. Margin and the bundling threat don’t appear.

The kernel. You rewrite it.

• Diagnosis: Beacon’s lead in alert correlation is eroding as large observability platforms bundle AIOps. Customers trust Beacon to summarize but not yet to act, and agentic features cut gross margin from 81% to 72%. The critical challenge is converting diagnosis trust into supervised action without breaking margin.
• Guiding policy: win on trusted diagnosis and supervised remediation across the customer’s existing tools, through connectors and MCP, with Northlight Observe data as an accelerant rather than a requirement. That settles the old tension between building on Observe and staying tool-agnostic. Three refusals: no Beacon metrics store, no fully autonomous actions outside customer allowlists, and no edition for small teams on a single-vendor stack.
• Coherent actions: raise diagnosis acceptance with cited evidence and evals; launch Beacon Agents at Northlight Live with the approval gates and audit logs Sam needs; move toward per-resolved-incident pricing so price tracks value and funds inference; cut inference cost per incident through model routing; sunset Beacon Classic to free a team. Trust enables action, action justifies outcome pricing, pricing and routing restore margin, and the sunset funds the work.
• Proximate objective: diagnosis acceptance rate above 60% across the top 50 accounts by the end of Q2 2027.

Where to play and DHM. Enterprise SRE and platform teams running observability from several vendors, plus MSPs like Leo’s for the mid-market; not small teams on one vendor’s stack, where the bundled feature is good enough. Delight: Dana gets “what broke and what to do” in under five minutes. Hard to copy: resolved incidents feeding retrieval and evals through the Learn loop, connector breadth, and approval and audit design that security teams have already signed off. Margin: per-resolved-incident pricing plus model routing.

Two frameworks, two answers. You score five candidates: (a) an EU AI Act documentation pack, (b) multi-tenant billing for MSPs, (c) autonomous rollback for allowlisted actions, (d) Beacon Classic migration tooling and (e) a connector for a widely used ticketing system. RICE, with reach in accounts, puts MSP billing and the ticketing connector on top because they touch the most accounts. WSJF puts the AI Act pack and the migration tooling on top: the first is time-critical and unblocks stalled EU deals, and the second enables the sunset that frees a team. The guiding policy breaks the tie. Supervised action depends on gatekeeper trust, so time criticality and enablement matter most this half. You choose WSJF and write that choice at the top of the scorecard.

Then the Digital Omnibus moves the Annex III dates to December 2027. You re-score the AI Act pack: its cost of delay drops but not to zero, because EU customers are still asking and Sam’s needs haven’t changed. It moves from Now to Next, and the changelog says why.

The roadmap. Now: Beacon Agents supervised remediation, generally available at Northlight Live (commitment); Beacon Classic sunset with dated migration milestones (commitment); diagnosis citation quality (bet). Next: a per-resolved-incident pricing pilot, MSP multi-tenant views and the AI Act documentation pack (all bets). Later: broader autonomous resolution for low-risk incident classes, gated by eval thresholds on future models (exploration, on the capability watchlist). The capacity split across the five teams is 50% new value, 20% platform and connectors, 15% quality, evals and model migration, and 15% commitments and the Classic migration.

The communication pack. Marcus gets outcomes and the ROI story. Sales gets the two dated commitments (Agents GA and the Classic end-of-life date), undated themes for everything else and the Won’t list. Priya’s team is invited to be a design partner for the citation work. Leo gets API and deprecation notice periods, longer than direct customers get. Sam gets the AI Act documentation timeline, with the Omnibus change explained.

The reprioritization. Mid-quarter, a hallucinated root cause leads a customer to roll back the wrong service. Trust work jumps the queue: the citation-quality bet gets two more engineers and a stricter eval bar, and MSP multi-tenant views slip a cycle. The changelog names the incident, what moved and why. Sales only ever had multi-tenant views as an undated theme, so nobody has to retract a promise.

Product 360 artifacts

# Strategy kernel · [Product] · v[n] · [Date]

**Owner:** [PM]   **Approver:** [Name]   **Review date:** [Date]

## Diagnosis
The critical challenge is [challenge] because [cause].
Evidence: [win/loss, churn, usage, competitive or economic data, with sources]

## Guiding policy
We will [overall approach].
Therefore we will not:
1. [Refusal]
2. [Refusal]
3. [Refusal]

## Coherent actions (3 to 5)
| # | Action | Owner | Resource commitment | How it reinforces the others |
|---|---|---|---|---|
| 1 | | | | |

## Proximate objective
By [date] we will have [measurable, achievable result].

## Bad-strategy check
- [ ] No fluff: every sentence commits to something.
- [ ] The challenge is named and faced.
- [ ] Goals are not standing in for strategy.
- [ ] Not a laundry list; actions are coherent.
- [ ] A stranger could predict three requests we'll refuse.

# Product strategy · [Product] · Horizon: [12 to 24 months]

**Owner:** [PM]   **Last reviewed:** [Date]   **Nests inside:** [business unit or portfolio strategy]

1. **Diagnosis:** the one critical challenge, with evidence.
2. **Winning aspiration:** what winning looks like for customers and for us.
3. **Where we play / where we don't:** segments, buyers, channels, ecosystem position.
4. **How we win (DHM):**
   - Delight (per persona): [end user] / [champion] / [economic buyer] / [gatekeeper]
   - Hard to copy:
   - Margin-enhancing:
5. **Guiding policy:** the approach, plus the three things we'll say no to.
6. **Coherent actions as SMTs:**

| Strategy (hypothesis) | Proxy metric (current → target) | Tactics (projects, experiments) | D / H / M |
|---|---|---|---|
| | | | |

7. **Capabilities and systems we must build:**
8. **What would have to be true:**

| Condition | Confidence (H/M/L) | Test | Owner | Due |
|---|---|---|---|---|
| | | | | |

9. **Outcome metrics:** North Star [metric]; inputs [2 to 3]; guardrails [margin, trust, quality].

**Changes since last review:** [what changed and the evidence that changed it]

# Prioritization scorecard · [Product] · [Period]

**Lens chosen:** [WSJF / RICE with reach in accounts / MoSCoW / Kano / other]
**Why this lens:** [how the guiding policy makes this lens the right one]
**Reach unit:** [accounts / ARR touched / users]

## Strategy filter (before scoring)
Only items linked to a coherent action are scored. Items removed at the filter:
| Item | Reason removed | Status told to requester |
|---|---|---|
| | | |

## Scored items
| Item (opportunity or bet) | Strategy link | Accounts / ARR affected | Customer value (1 to 3) | Cost of delay per month | Risk reduction / enablement | Effort (team-weeks) | Evidence level | Score | Decision (commit / bet / explore / no) |
|---|---|---|---|---|---|---|---|---|---|
| | | | | | | | | | |

Evidence levels (Confidence Meter): opinion · anecdote or market data · customer evidence · MVP or launch data.

## Departures from score order
| Item | Moved from → to | Reason | Decided by |
|---|---|---|---|
| | | | |

# Roadmap · [Product] · v[n] · [Date]

**Strategy:** [link to one-pager]   **Owner:** [PM]   **Next review:** [Date]

| | Now (in delivery) | Next (discovery under way) | Later (problems to solve) |
|---|---|---|---|
| Theme / outcome | | | |
| Target metric | | | |
| Type | Commitment / Bet / Exploration | | |
| Confidence (H/M/L) | | | |
| Date (commitments only) | | Not dated | Not dated |

## Commitments register
| Commitment | Who depends on it | Date | Discovery done? | Engineering estimate | Owner |
|---|---|---|---|---|---|
| | | | | | |

## Capability watchlist (AI products)
| Later item | Capability threshold to move to Next | Eval used | Last model tested | Result |
|---|---|---|---|---|
| | | | | |

## Capacity split
New value [x]% · Platform and enablers [x]% · Quality, evals and model migration [x]% · Commitments [x]%

## Changelog
| Date | What moved | From → to | Why |
|---|---|---|---|
| | | | |

# Roadmap communication pack · [Product] · [Date]

**Source roadmap:** [link]   **Disclaimer approved by:** [legal contact, date]

## 1. Executive view (one page)
- Outcomes we're driving and current metric values:
- Strategic bets and what would make us stop:
- Investment mix (capacity split):
- Top risks:
- Decisions needed from you:

## 2. Field view (sales, solutions, customer success)
- Talk track (three sentences):
- Commitments you can quote, with dates:
- Themes for Next and Later (no dates):
- Won't list (do not promise):
- How to log a customer request, and what status they'll get back:
- Forward-looking disclaimer:

## 3. Customer view
- Problems we're solving for you and our direction:
- Commitments (contractual only):
- Design-partner invitations:
- NDA required: yes / no

## 4. Partner and developer view
- API changes and versions:
- Deprecations, with notice periods:
- Platform contracts and dependencies:

## 5. Changelog since last version
| What moved | Why | Who was told |
|---|---|---|
| | | |

# Backlog policy · [Product or team] · [Date]

**Accountable:** [PM]   **Reviewed:** quarterly

## Three stores
1. **Request inbox:** every raw ask, linked to account and ARR. Never ordered, never promised. Searchable by the field.
2. **Opportunity backlog:** requests clustered into customer problems, sized by accounts and ARR, linked to a coherent action.
3. **Delivery backlog:** ordered and refined; covers the next [one to two] cycles of Now only. Maximum size: [n] items.

## Entry criteria for the delivery backlog
- [ ] Linked opportunity and outcome
- [ ] Evidence level stated
- [ ] Owner named
- [ ] Rough size
- [ ] Acceptance criteria
- [ ] AI features: eval or quality bar defined

## Ageing rule
Items untouched for [two quarters] are archived with a reason. The requester's status updates automatically.

## Capacity split
| Category | Share | Notes |
|---|---|---|
| New value | | |
| Platform and enablers | | |
| Quality, debt, evals and model migration | | |
| Customer commitments | | |

## Cadence
- Weekly: refine the top of the delivery backlog.
- Monthly: opportunity review; cluster new requests.
- Quarterly: strategy and roadmap check; reset capacity split.
- Any reorder of a commitment is communicated within [n] business days.

## Request statuses a seller can quote
Logged · Mapped to theme [x] · In discovery · Planned (Now) · Not planned this half · Won't do (with reason)

Prompts

Goal: Find out whether your strategy is a strategy or a plan, before your leadership review does.
Paste in: your draft strategy or one-pager, and the evidence behind the diagnosis.

Act as a demanding strategy reviewer for [product]. Evaluate this draft against Richard Rumelt's kernel and his four hallmarks of bad strategy.

1. Extract the diagnosis, guiding policy and coherent actions as written. If any is missing, say so plainly.
2. For each hallmark (fluff, failure to face the challenge, goals mistaken for strategy, bad strategic objectives), quote the sentences that show it and explain why.
3. Check whether the coherent actions reinforce one another. Name any action that is independent of the rest.
4. List three customer or internal requests this strategy would clearly refuse. If you can't find three, say the guiding policy rules nothing out.
5. Check the where-to-play choices: which segment, buyer, channel or ecosystem position is the draft avoiding a choice on?

Return a critique with specific weaknesses, source evidence and open questions. Reserve the strategy rewrite for a separate task.

[draft strategy]
[evidence]

Check the output: confirm each quoted sentence actually appears in your draft. Treat the refusal test as the most important result; if the model invented refusals the text doesn't support, your policy is too vague.

Goal: Get a first, evidence-cited draft of the diagnosis to argue about.
Paste in (or connect the harness to): win/loss notes, churn reasons, competitive notes and a summary of unit economics for the last two to four quarters. Use only tools approved for customer and financial data.

From this material for [product], identify the three candidate challenges that most limit our growth or retention. For each:
- State it in one sentence, then explain the cause.
- Cite the specific sources that support it (document and passage).
- Note the evidence against it.
- Say whether it's a customer problem, a buying-process or gatekeeper problem, a competitive problem or an economic problem.

Then recommend which one is the critical challenge and why, in one paragraph. Label it "draft diagnosis for discussion."

Check the output: open three of the cited sources and confirm they say what the draft claims. Then ask whether the recommended challenge is the one your team avoids talking about; if it isn't, check whether it's the real one.

Goal: Turn months of raw requests into a short list of customer problems with commercial weight attached.
Paste in (or connect the harness to): feature requests from the CRM, support desk and sales notes for the last [90] days, with account names, ARR and renewal dates. Use an approved tool for customer data.

Group these requests for [product] into customer problem themes. Name each theme from the customer's point of view, without proposing a solution. For each theme give:
- number of accounts and total ARR affected;
- ARR renewing in the next two quarters;
- which personas raised it (end user, champion, economic buyer, security or compliance, partner);
- three short verbatim excerpts with sources;
- which coherent action in our strategy it serves, or "none."

Flag duplicate requests, single-account themes and any theme that conflicts with our guiding policy. Our strategy one-pager is below.

[strategy one-pager]
[requests]

Check the output: spot-check five requests to confirm they landed in the right theme, and verify the ARR totals against the CRM. Themes marked "none" are candidates for a polite no, not for scoring.

Goal: See how much your framework choice is changing the answer.
Paste in: five to ten candidate items with whatever you know about reach (in accounts), impact, confidence, effort, time criticality, enablement and cost of delay, plus your strategy one-pager.

Score these items for [product] twice:
1. RICE, with reach measured in accounts per quarter, impact on the 3 / 2 / 1 / 0.5 / 0.25 scale, confidence at 100% / 80% / 50% and effort in person-months.
2. WSJF, with cost of delay as user and business value plus time criticality plus risk reduction or opportunity enablement, divided by job duration.

Show both rankings side by side. For every item whose rank differs by two or more places, explain which input drives the difference. Then say which lens better fits our guiding policy, and why. Grade the evidence behind each input as opinion, anecdote or market data, customer evidence, or usage data, and flag scores that rest mostly on opinion.

[items]
[strategy one-pager]

Check the output: the model will fill gaps with plausible numbers. Strike any input you didn't provide, and rerun. The decision column stays yours.

Goal: Produce consistent executive, field, customer and partner views without retyping the roadmap four times.
Paste in: the source now-next-later roadmap with each item's type (commitment, bet, exploration), the Won't list, the changelog and your company's approved forward-looking disclaimer.

From this roadmap for [product], create four views:
1. Executive (one page): outcomes, strategic bets, capacity split, top risks, decisions needed.
2. Field: a three-sentence talk track, commitments with dates, Next and Later themes without dates, the Won't list, how to log a request, and the disclaimer verbatim.
3. Customer: problems we're solving and direction, commitments only if marked contractual, design-partner invitations.
4. Partner and developer: API changes, deprecations with notice periods, dependencies.

Rules: show dates only for items labeled "commitment." Keep exploration details in internal views. Copy the disclaimer exactly.

[roadmap]

Check the output: search every view for dates and confirm each belongs to a commitment. Read the field view as a seller would: is there any sentence a customer could hear as a promise?

Goal: Decide which AI roadmap items a new model has moved, and which assumptions no longer hold.
Paste in: your capability watchlist, the latest eval results for the current and new models, inference cost per task for each, and the "what would have to be true" list for each AI bet.

For [product], compare the eval results against each watchlist threshold. For every Later or Next item:
- Has the threshold been met, nearly met or not met? Cite the eval figures.
- What would the change in inference cost do to unit economics at current volume?
- Which "what would have to be true" conditions are now true, still open or no longer true?

Recommend which items should move columns, which bets should be killed, and whether any model migration is now time-critical because of a retirement date. Separate what the evals show from your recommendation.

[watchlist]
[eval results]
[cost data]
[conditions]

Check the output: confirm every cited eval figure against the source run. Don't move an item to a dated commitment on the strength of one eval run.

Anti-patterns

Checklist

• The strategy names a diagnosis, with evidence, and a guiding policy with at least three explicit refusals.
• The where-to-play choices name the segment, buyer, channel and ecosystem position, including what’s out.
• Each strategy is an SMT: a hypothesis with a proxy metric the team can move within a quarter.
• The DHM covers delight per persona, what’s hard to copy and how the strategy improves margin.
• The strategy one-pager has a measurable proximate objective and passed a check against Rumelt’s four hallmarks.
• Items are filtered by strategy before they are scored.
• The scorecard states the chosen lens and why, shows an evidence level beside every score, and records every departure from score order.
• The backlog is split into request inbox, opportunity backlog and a short delivery backlog, with an ageing rule.
• The capacity split is written down and reviewed quarterly.
• The roadmap labels every item as commitment, bet or exploration, and only commitments carry dates; every commitment passed discovery and has an engineering estimate.
• Audience views come from one source, the field view includes the Won’t list and the approved disclaimer, and each view has a changelog.
• For AI products, the roadmap has a capability watchlist, an eval and model-migration lane, and no customer dates that depend on unreleased model improvements.
• Externally dated items (model retirements, regulatory deadlines, deprecations) are tracked to their source and replanned when they move.