Model Roadmap What-If Scenarios Against Real Data

Workflow area: Strategy & Roadmap · Tier: Core · Hands-on time: ~35 minutes

Roadmaps meet reality as a series of what-ifs: a key engineer leaves, a deal demands a feature pull-forward, scope has to shrink to hit a date. Most teams reason about these verbally, which means the loudest projection wins. Feeding the real roadmap export to a model turns the what-if into structured analysis — dependencies traced, capacity re-summed, dates recomputed — in minutes. The catch is arithmetic and eagerness: models mis-sum columns, invent dependencies that sound plausible, and present both fluently. So the recipe splits cleanly: AI proposes the impact analysis, the source spreadsheet verifies every number, and the decision memo cites cells, not chat.

When to use — and when not to

• Use it before planning reviewswalk in with three scenarios already modeled instead of modeling them live under questioning.
• Use it when a disruption actually landsa re-org, a slipped dependency, a competitor launch. The 30-minute structured pass beats a week of hallway re-planning.
• Use it to price a stakeholder's request"what would pulling feature X into Q3 actually displace?" answered with names and dates ends more arguments than any principle does.
• Skip it if your roadmap data is fictionscenario analysis on estimates nobody believes is precision theater. Fix the estimates' honesty first, or model at the epic level only.
• Skip pure-AI conclusionsnever let a model's recomputed dates flow into commitments without the sheet check; a plausible wrong date in a planning doc is a promise you'll break.

The recipe

1. 1.

   Export the real roadmap to a clean sheet. From Jira, Linear, or your planning sheet: item, team, estimate, start/end, dependencies, priority, status, and the objective each item serves. One row per item, stable IDs. This export is the ground truth everything gets checked against — save a copy so the baseline can't drift mid-analysis.

2. 2.

   Define two or three scenarios precisely. A scenario is a concrete perturbation, not a mood:

   Copy

   S1: Cut Q4 scope 30% by effort; protect items tagged OBJ-retention.
   S2: Competitor ships an equivalent of FEAT-112 on Oct 1; we want
       our answer live within 6 weeks of that.
   S3: Payments team loses 2 engineers (of 5) from Sep 1.
   

3. 3.

   Run the scenario analysis with show-your-work rules. Paste the export (CSV) and the scenarios:

   Copy

   You are analyzing roadmap scenarios against the attached export.
   Treat the export as the ONLY source of truth.
   
   For each scenario:
   1. AFFECTED ITEMS: list item IDs directly affected, and items
      affected via dependency chains — show each chain explicitly
      (A blocks B blocks C).
   2. IMPACT TABLE: item ID | change (dropped / delayed / resequenced)
      | old dates | new dates | the arithmetic, shown step by step.
   3. OBJECTIVE IMPACT: which stated objectives lose coverage, and
      how much (sum the effort by objective, show the sums).
   4. OPTIONS: 2-3 distinct response options with trade-offs — not
      one recommendation dressed three ways.
   5. FLAGS: anything you had to assume because the export doesn't
      say — mark each ASSUMPTION explicitly.
   
   Rules: cite item IDs for every claim; show all arithmetic; do not
   invent dependencies not present in the export; if the export's
   data is insufficient for a computation, say so instead of guessing.
   

4. 4.

   Verify every load-bearing number in the sheet. This is the step that makes the analysis quotable. Re-sum the capacity math with actual formulas — model column sums are wrong often enough that this check is non-negotiable. Confirm each cited dependency exists in the export, and spot-check that no real dependency was skipped for the top scenario. Recompute the two or three dates the decision will hinge on. A verified finding looks like:

   Copy

   S3 impact: payments loses 12 eng-weeks of Q4 capacity.
   Sheet check: SUM of estimates for PAY-items, Sep–Dec = 29 ew;
   model claimed 31 (double-counted PAY-118, already Done). Corrected.
   FEAT-097 slips ~5 weeks (dependency PAY-104 → confirmed in export).
   

   Every correction goes back into the analysis before anyone sees it.

5. 5.

   Write the decision memo from verified numbers only. One page per scenario: the perturbation, the verified impact table, the objective coverage change, the options with trade-offs, and your recommendation — written by you, because choosing between options is exactly the judgment that stays human. Assumptions the model flagged appear as open questions, not silently accepted.

Make it yours

• The live planning-room variant: keep the conversation open during planning review; when an exec asks "what if we also did X?", run it as S4 against the same export — but say the numbers are unverified until you've done the sheet pass, and verify before minutes go out.
• Sheet-native formulas: for recurring scenario types, have AI write the Google Sheets formulas once (capacity by team by month, dependency lookups) so future scenarios are slider-driven in the sheet itself and the model only narrates.
• Pair with pb-21: feed the surviving scenario into the pre-mortem seat — "this re-plan failed; why?" — before you commit to it. Scenario math tells you what moves; the red-team tells you what breaks.

Quality check

• The export is the only source of truththe model neither added items nor assumed capacity that isn't in the sheet; every ASSUMPTION flag got resolved by a human.
• All arithmetic was re-done in the sheetsums, dates, and coverage percentages match formula results; any silent disagreement means stop and re-verify everything.
• Dependency chains were confirmed, not admiredeach cited chain exists in the export, and the top scenario got a check for missed chains too.
• Options are genuinely distinctif the three options are one idea at three intensities, rerun step 3 asking for a real alternative, including "do nothing and accept the slip."
• The recommendation is yoursthe memo's decisive paragraph reads like a PM choosing, not a model summarizing; that paragraph is the part stakeholders are paying you for.