AI Product Roadmap with Tradeoffs

Most product roadmaps are wishlists in disguise. The list has 14 items, all marked Q2, all marked High priority. The team commits to all 14 and ships 5. The remaining 9 slip to Q3, where they join 11 new items, all marked High priority. The cycle repeats. The roadmap is treated as ambition rather than commitment, and stakeholders learn to discount the dates. The cost is paid in trust: nobody believes the dates, the team feels constantly behind, and prioritization decisions get made by whoever shows up in the planning meeting most insistent rather than by what the strategy actually requires.

A useful roadmap looks different. Items are scored explicitly (RICE: Reach × Impact × Confidence ÷ Effort) so the prioritization is defensible. The structure is now/next/later rather than Q2/Q3/Q4 because the dates are illusions but the order is real. Each item has competitive context (why this bet over the alternative). The OKRs the roadmap supports are named explicitly per item, so the team can defend the choice. Items the team is choosing not to do are written down with reasoning, so future stakeholders asking "why aren't we doing X" have an answer that is not "we ran out of time." The discipline produces a roadmap that survives the board meeting, the engineering review, and the new VP who joins six months in. The /crest-roadmap skill encodes the discipline.

Why generalist AI ships wishlist roadmaps

Ask Cursor or ChatGPT for a roadmap. You get a list of feature names grouped by quarter. The list looks like a roadmap. It also has no scoring, no competitive reasoning, no OKR alignment, no not-now decisions, and no tradeoff acknowledgment. The output is the wishlist version, which is what the team had before; the value of a roadmap is in the prioritization, and the prioritization is exactly what was skipped.

The other failure mode is the missing not-now list. A roadmap that does not document what the team is choosing not to do invites the question "why aren't we doing X" indefinitely. Every quarter, somebody asks. The team rebuilds the reasoning from memory. Sometimes the reasoning has changed, sometimes not. The not-now list closes the loop: this is what we considered, this is why it is not in the next two quarters, this is what would change to put it back on the roadmap. Without the list, the team is reanswering the same questions on a rolling basis.

What a defensible roadmap contains

A roadmap that survives scrutiny has five parts. Now (committed, in the current cycle): items the team is actively building, with engineering scope locked. Next (probable, next cycle): items the team is preparing, with briefs in shape. Later (intended, beyond next cycle): items in the right direction but with details unresolved. RICE scoring per item: explicit numbers for reach, impact, confidence, and effort, with the resulting score driving the now/next/later placement. Competitive context: a paragraph per major bet explaining why this versus the alternatives. OKR alignment: each item names which company OKR it supports. Not-now: items that were considered and explicitly deferred, with the reasoning.

The discipline is to be honest about confidence. Items in Now have high confidence (the brief is shaped, engineering can estimate); items in Later have low confidence (the direction is right, the details are not). RICE scores reflect that: Confidence is part of the score, so a high-Reach high-Impact item with low Confidence ranks below a medium-Reach medium-Impact item the team can deliver. The honest prioritization is what makes the roadmap survive contact with reality.

How /crest-roadmap works

Step one: gather the candidates

When invoked, /crest-roadmap asks for the candidate items: features, initiatives, and bets the team is considering. The list comes from briefs, customer feedback, competitive analysis, and team intuition. The skill is opinionated about not roadmapping past underspecified candidates; if an item is too vague to score, it is flagged for /helm-brief before the roadmap continues.

Step two: score with RICE

Each candidate gets a RICE score. Reach: how many users this affects in the relevant time frame. Impact: how much it moves the metric per affected user (massive, high, medium, low, minimal, with explicit multipliers). Confidence: how certain the team is in the estimates (high = 100%, medium = 80%, low = 50%). Effort: person-months from engineering. The score is (Reach × Impact × Confidence) / Effort. The numbers force the team to be specific about each dimension; vague answers produce vague scores that fall in the middle of the ranking.

Step three: now/next/later with competitive context

Items are placed in Now, Next, or Later based on RICE score and confidence. Now items have RICE in the top tier and Confidence high. Later items have RICE in the top tier and Confidence low (the direction is right, the details are not). Each major bet gets a paragraph of competitive context: what alternative was considered, why this won, what would change to revisit. The context is what makes the roadmap defensible against the board member or new VP asking why.

Step four: not-now and OKR alignment

Items considered and deferred go on the not-now list with the reason. Each Now and Next item names the OKR it supports; items that do not align with an OKR are flagged for revisiting. The OKR alignment forces the question "is this strategically important or is this a side project we like." The not-now list closes the loop with stakeholders so the question "why aren't we doing X" has a documented answer rather than a memory check.

Tonone's /crest-roadmap skill builds defensible product roadmaps with RICE scoring, now/next/later structure, competitive context, OKR alignment, and a documented not-now list.

When to use /crest-roadmap, and when not to

/crest-roadmap is the right call when planning a quarter or half-year and prioritization needs to be defensible, when an existing roadmap lacks rationale, or when preparing for a board review that will ask hard questions about tradeoffs. The skill is also the right call when stakeholders are asking the same prioritization questions repeatedly and the team needs the documented version.

Skip the skill for tactical sprint planning (use the team's existing planning tools). For the strategic narrative that frames the roadmap, /crest-narrative is the right call. For competitive analysis that informs the bets, /crest-compete is calibrated to that work.

A worked example: H2 roadmap

Suppose the brief is: build the H2 roadmap for a B2B SaaS. Run /crest-roadmap.

# H2 Roadmap: Acme

## Now (committed, current cycle)
1. Team Accounts v1 (RICE 320; OKR: Expansion Revenue +20%)
   Beats SSO at this stage because team-level access is
   the gateway feature; SSO is the second-order need.
2. Stripe migration to Billing v2 (RICE 240; OKR: Reliability)
   Beats new payment provider research because consolidation
   reduces ongoing on-call by ~30%.
3. SOC 2 Type II readiness (RICE 180; OKR: Enterprise Pipeline)
   Beats ISO 27001 because all H2 enterprise pipeline asks
   for SOC 2; ISO would unblock a smaller subset.

## Next (probable, next cycle)
4. SSO at the team level (RICE 280; OKR: Expansion)
   Builds on Team Accounts v1; cannot start until v1 lands.
5. Audit log export for compliance (RICE 200; OKR: Enterprise)
   Required by 4 enterprise pipeline deals; brief shaping.
6. Mobile read-only (RICE 150; OKR: Activation)
   30% of users open mobile weekly; current mobile is a wrapper.

## Later (intended, direction confirmed, details TBD)
7. AI-assisted onboarding flow (RICE 350 if Confidence holds; OKR: Activation)
   High potential, low confidence on impact; requires validation
   spike before committing.
8. Workflow automation (RICE 220; OKR: Retention)
   Customer asks point this direction; needs design exploration.

## Not now (with reasoning)
- Native iOS app: $$ + headcount, Mobile read-only is the
  intermediate step.
- Marketplace integrations directory: long tail of partners,
  effort exceeds benefit at our current scale.
- Free tier: brand says 'B2B premium', free tier conflicts.
  Revisit if expansion stalls in Q4.

## OKR coverage
- Expansion Revenue: items 1, 4 (now + next).
- Reliability: item 2.
- Enterprise Pipeline: items 3, 5.
- Activation: items 6, 7 (later).
- Retention: item 8 (later).

Six committed items, three probable, two later, three explicit not-nows. Every item has a RICE score, an OKR alignment, and (for major bets) a competitive context. The roadmap survives the board review because it answers the questions before they are asked.

Related skills

/crest-roadmap produces the roadmap. For the strategic narrative that frames it, /crest-narrative is the right call. For competitive analysis that informs the bets, /crest-compete is calibrated to that work. For OKR design specifically, /crest-okr produces the structure.

Install

/crest-roadmap ships with the Crest agent in the Tonone for Claude Code package. Install Tonone, invoke /crest-roadmap from any Claude Code session, and the skill produces a defensible roadmap with RICE scoring and explicit tradeoffs.

Roadmaps that survive scrutiny are the ones with explicit prioritization. The skill is built so the discipline is the default rather than the response to the board's hard questions.