The Problem
A PM has four AI opportunities that all cleared feasibility triage from the last lesson: a policy-lookup assistant, an escalation-risk flagger, an automated onboarding Q&A bot, and a full autonomous refund-handling agent. Leadership wants to know which one ships first, and the honest answer is "whichever one the last person to pitch in the planning meeting argued for most persuasively" — which is not a roadmap, it's a coin flip dressed up as a decision.
Worse, the plan for the one that does get picked — the refund-handling agent, because it sounds the most impressive — is "build it, then launch it." There's no staged plan. If the agent's refund-approval logic has a flaw that only shows up on edge cases, the team finds out when it's already live and issuing incorrect refunds to real customers, not before.
Both problems have the same root cause: no structured way to compare opportunities against each other, and no structured way to de-risk the one that gets chosen before it's fully live. This lesson gives a PM both: RICE scoring (adapted for AI's specific uncertainty) to sequence which bet goes first, and crawl/walk/run staging to de-risk how any single bet actually rolls out.
RICE scoring for AI opportunities
RICE scores an opportunity on four factors — Reach (how many users/events does this touch in a given period), Impact (how much does it move the needle per user touched, usually a rough scale like massive/high/medium/low/minimal mapped to a number), Confidence (how sure are you about the Reach and Impact estimates, as a percentage), and Effort (person-months to build) — and combines them as (Reach × Impact × Confidence) / Effort. Higher score, higher priority. This isn't unique to AI; it's a standard product prioritization framework (see the Intercom resource below for the original methodology).
What's specifically different for AI opportunities is the Confidence factor deserves an extra discount that a typical feature doesn't need. For a normal feature, confidence uncertainty is usually about market/user behavior — will people actually use this? For an AI feature, there's a second layer of uncertainty stacked on top: will the model actually perform well enough on this task, at this scale, with this data? A PM should discount Confidence for an AI opportunity based on two things beyond normal market uncertainty: how validated the feasibility triage from the last lesson actually was (a feature that cleared triage cleanly deserves a smaller discount than one that cleared with several scoped mitigations), and how novel the AI approach is for the team (a fourth RAG feature built by a team that's shipped three before is more predictable than a team's first agentic feature).
A high RICE score with low confidence is a bet worth staging, not skipping
Don't let a low-confidence AI opportunity fall off the roadmap just because its RICE score looks weaker than a safer bet — a high-Reach, high-Impact opportunity with real uncertainty about AI performance is often exactly the kind of bet that's worth taking, as long as it's staged so the first investment is small and produces a real answer about whether the bigger investment is justified. The RICE score should influence sequencing (what goes first, and how big a first bite to take), not act as a binary yes/no filter that kills anything uncertain.
Crawl/walk/run: staging a single bet
Once an opportunity is sequenced onto the roadmap, crawl/walk/run structures how it actually rolls out, in three stages, each with its own explicit validation goal:
- Crawl — the smallest version that produces a real signal about whether the bet is worth the next stage. Often this means a human-in-the-loop version (the AI drafts, a human approves before anything ships to a customer), a limited user segment, or both. The goal of Crawl isn't to be impressive — it's to cheaply answer the riskiest open question from feasibility triage. For the refund-handling agent, Crawl might be: the AI drafts a refund recommendation, a human reviewer approves or rejects it, and the team measures how often the AI's recommendation matches what a human would have decided, with zero refunds actually auto-issued yet.
- Walk — expand scope (more users, more scenario coverage) while keeping a safety net the team can act on — this is often where automation increases but human oversight doesn't disappear, it shifts from reviewing every case to reviewing a sample or handling exceptions. For the refund agent, Walk might be: auto-issue refunds under $50 with no human review, but require review above that threshold, and monitor an error rate against a defined ceiling.
- Run — full automation at full scale, only after Crawl and Walk have produced real evidence (not just optimism) that the failure rate is low enough and well-understood enough to operate without a human safety net for the covered cases.
The critical design decision at each stage isn't "how do we make it bigger" — it's "what specific question does this stage need to answer before we're allowed to move to the next one." A crawl/walk/run plan without an explicit validation question per stage is just a slower launch, not a de-risked one.
A team is staging the rollout of an AI-powered content moderation feature that flags posts for removal. The proposed Crawl stage is: "launch to 100% of users immediately, but only flag the most obviously severe violations." Is this a well-designed Crawl stage?
Limiting to "most severe violations" narrows the type of risk but launching to 100% of users immediately abandons the core purpose of a Crawl stage, which is to validate the riskiest open question -- here, likely the false-positive rate on real, messy, diverse content -- on a limited population before the blast radius of a mistake (wrongly removing a legitimate post) is company-wide. A real Crawl stage would test on a small user segment, or route flagged posts to human review before removal, and only expand exposure once the false-positive rate is measured and acceptable. Even a highly-accurate-on-paper model can behave differently on real production content than it did in testing, which is exactly the gap staged rollout exists to catch before full-scale exposure.
Sequencing dependent bets
Some AI bets depend on groundwork that has to happen first, and a roadmap that doesn't sequence around that dependency will hit the same wall the opening scenario hit with root-cause categorization. If two opportunities both need improved data labeling, but one is otherwise a bigger, more valuable bet, the data-readiness work should usually be sequenced first regardless of which feature "gets credit" for it in a planning doc — building it while sequencing the higher-priority feature to start right after ships more real value, sooner, than building the same groundwork twice or blocking the bigger bet on redoing it.
The general sequencing principle: infrastructure and data-readiness work that unblocks multiple future bets should usually be pulled forward on the roadmap even if its own standalone RICE score looks unimpressive, because its Impact score should really be counted as the sum of everything it unblocks, not evaluated in isolation as its own feature.
Two AI opportunities are both on the table: Opportunity A (a churn-prediction dashboard) has a strong standalone RICE score. Opportunity B (building a unified customer-event data pipeline) has a mediocre standalone RICE score, but Opportunity A and two other planned features all depend on the data pipeline existing first, and none of them can start meaningfully without it. How should these be sequenced?
This is exactly the sequencing principle the lesson describes: infrastructure or data-readiness work that unblocks multiple future bets should usually be pulled forward even when its own standalone RICE score looks unimpressive, because its real Impact is the sum of everything it enables, not just its own isolated value. Building Opportunity A first without the pipeline either blocks it entirely or forces redundant, throwaway data work that would need to be redone once the shared pipeline is eventually built -- which is slower and more expensive than sequencing the shared dependency first.
Communicating roadmap uncertainty honestly
An AI roadmap that promises a fixed ship date for a feature that hasn't cleared Crawl yet is setting up a broken promise — the whole point of staging is that Walk and Run are conditional on what Crawl actually shows, not guaranteed next steps. The honest way to communicate this to stakeholders: commit firmly to the Crawl stage and its timeline (that part is usually predictable), and frame Walk and Run as "planned, pending Crawl results meeting [specific, named bar]," not as pre-committed dates. This isn't hedging — it's the same discipline as the feasibility triage's red-flag test: a specific, checkable bar for progression is far more credible to a stakeholder than either a falsely confident fixed date or a vague "we'll see how it goes."