The AI Capability Roadmap Template: Planning How Your AI Gets Better Over Time
TL;DR
A feature roadmap shows what you will ship. An AI capability roadmap shows when your AI will be good enough to ship it. The two documents must exist in parallel because AI capability improvements unlock entire feature categories. This template covers the four sections of a capability roadmap, how to set eval thresholds as launch gates, and how to answer the single most common stakeholder question about AI products: "When will it be ready to do X?"
The AI PM Minute
One tactic to make you a sharper AI PM, twice a week. 60 seconds to read. Free.
No fluff. Unsubscribe anytime.
Why AI Products Need a Capability Roadmap
Traditional product roadmaps assume you control the capability underneath the feature. You can ship a new filter because your engineers can write that filter. AI products do not work this way. A feature like "automatically draft a contract from a voice conversation" requires the AI to reach a specific quality threshold on transcription, entity extraction, legal language generation, and self-consistency checking before it can be shown to any user. If the model is not there, the feature cannot ship regardless of how much engineering work surrounds it.
This creates a planning gap that most AI teams handle informally: engineers know roughly when a capability will be good enough, PMs put features on the roadmap based on optimistic assumptions, and the gap becomes visible only when a feature gets delayed because the AI "isn't ready yet." That phrase signals the absence of a capability roadmap.
Without a capability roadmap
Features get added to the roadmap without a defined quality bar. Ships happen when the team decides 'it feels good enough.' Stakeholders have no way to predict when features land.
With a capability roadmap
Each future feature has a named capability dependency with a measurable threshold. Features ship when the eval metric crosses the gate. Stakeholders can see capability progress and anticipate unlocks.
Common triggers for needing one
More than two features delayed for 'AI quality' reasons in a single quarter. Stakeholders asking 'when will the AI be good enough for X?' without a meaningful answer. Engineering and PM operating on different mental models of capability.
Who should own it
AI PM owns the capability roadmap and keeps it current. Applied scientists and ML engineers own the underlying capability projections. Leadership reviews it quarterly alongside the feature roadmap.
The Four Sections of the AI Capability Roadmap
The template has four sections. Copy these into a shared doc, populate them for your current model stack, and update them quarterly. This document should live next to your feature roadmap and be referenced in every quarterly planning session.
Section 1: Current Capability Baseline
Name every capability your AI product relies on. For each one, document: (a) what you are currently measuring it with (your eval suite or a proxy metric), (b) the current score on that measurement, and (c) the score at which you consider the capability production-ready. This gives you a snapshot of where you are today.
Example
Example row: Capability = 'Contract clause extraction accuracy'. Measurement = 'Precision/recall on 200-clause held-out set'. Current score = 0.81. Production-ready threshold = 0.91. Status = Not ready.
Required fields
Section 2: Capability Improvement Bets
For each capability that is not yet production-ready, document what you are doing to improve it and when you expect to cross the threshold. Be honest about confidence levels. A planned fine-tuning run with high data quality is a medium-confidence bet. Waiting on a foundation model upgrade is a low-confidence bet because you do not control the timeline.
Example
Example row: Capability = 'Contract clause extraction'. Improvement bet = 'Supervised fine-tune on 5,000 labeled examples from legal team'. Expected threshold crossing = Q4 2026. Confidence = Medium (data quality risk).
Required fields
Section 3: Feature Unlock Map
For each planned feature on your roadmap, list the capability dependencies that must be met before the feature can ship. A feature may depend on more than one capability. The feature's earliest possible ship date is the latest expected threshold crossing across all its dependencies.
Example
Example: Feature = 'Auto-draft contract from meeting'. Dependencies = 'Clause extraction (Q4 2026 medium confidence) + Legal language generation (Q3 2026 high confidence) + Self-consistency check (Q1 2027 low confidence)'. Earliest ship = Q1 2027.
Required fields
Section 4: Model Upgrade Schedule
Track the major model upgrades you plan to evaluate (whether from your own training runs or from foundation model provider releases). For each planned upgrade, note which capability gaps it is expected to close and how you will validate it before promoting to production.
Example
Example: Upgrade = 'GPT-5.7 migration (if released Q3 2026)'. Expected capability improvement = 'Clause extraction +8 points based on benchmark data'. Validation plan = 'Run held-out eval, shadow production traffic for 2 weeks, staged rollout at 5% traffic'. Timeline = 4 weeks from release date.
Required fields
Setting Eval Thresholds as Launch Gates
The capability roadmap only works if your thresholds are real. A threshold you move when the feature deadline approaches is not a threshold, it is a suggestion. Here is how to set and hold thresholds that actually gate launches.
How to set a threshold that holds
1. Anchor to user impact, not model performance
A threshold of 91% precision means nothing to a stakeholder. A threshold of 'fewer than 9 incorrect clauses per 100 reviews' means something. Define thresholds in user-facing terms so the consequence of not meeting them is legible to everyone, not just the ML team.
2. Set the threshold before you start measuring
Thresholds set after seeing performance data are almost always anchored to current performance. Set them when you define the capability, before you run the eval. This removes the 'we already got to 84%, can we just ship at 84%?' negotiation.
3. Document who can waive the threshold and under what conditions
Every gate needs a waiver process for genuine edge cases. Document it: the VP Product can waive a threshold with a written risk acceptance if the feature ships to less than 5% of users in beta and a production eval suite is in place. Without a documented waiver process, every threshold ends up waivable informally.
4. Run the eval on held-out data the model has not been optimized on
Thresholds gamed by eval data are not thresholds. Keep a held-out set that the ML team does not train or tune on. This is your production-representative gate. The training set and the gate eval set are different documents.
Hard gate
Feature cannot ship regardless of other factors. Used for safety-critical accuracy (medical, legal, financial). No waivers.
Soft gate
Feature can ship with waivers if conditions are documented: limited beta, compensating monitoring, explicit user disclosure of current limitations.
Progressive gate
Ship at lower threshold to 1-5% of users with enhanced monitoring. Promote to full rollout only when threshold is met on production traffic.
Master AI Product Planning in the Masterclass
The AI PM Masterclass covers capability roadmapping, eval-driven development, and the planning frameworks that make AI feature timelines predictable. Taught live by a Salesforce Sr. Director PM.
Communicating the Capability Roadmap to Stakeholders
The hardest stakeholder question in AI product management is: "When will the AI be good enough to do X?" Most AI PMs answer this wrong because they answer the feature question ("Q3") when the real answer is a capability question ("when the model hits 91% on our extraction eval, which we expect in Q3 if the fine-tuning run goes well").
Engineering team
Live doc or Notion page with full technical columns.Show the full technical template. They need the eval details, the threshold definitions, and the validation plans. They are co-owners of the capability improvement bets.
Product leadership
One-page summary table in the quarterly planning deck.Show a simplified view: capability name, current status (red/amber/green), expected threshold crossing quarter, and the features it unlocks. Skip the eval methodology details.
Executive stakeholders
Three bullet summary in the business update. Offer to share the detailed view if asked.Translate to business impact. Instead of 'clause extraction at 81%, threshold is 91%,' say 'the legal automation feature requires one more quarter of model improvement before it is ready for production. Here is what we are doing to get there and what the timeline looks like.'
Sales and customer-facing teams
One-page capability maturity sheet, plain English, no model scores.They need to know what they can promise. Give them a simplified capability maturity sheet: what the AI does well today, what it does partially, and what it cannot do yet. Update this every quarter and share it proactively.
The Quarterly Capability Review
The capability roadmap only earns trust if it is updated regularly and if reality is reported honestly, including when capabilities are progressing slower than expected.
Run every eval before the quarterly review, not after
Quarterly planning conversations should start with fresh eval results. If you run evals only when you think you are ready to ship, you lose the planning signal.
Update all four sections, not just the capabilities that are doing well
The capabilities that are behind schedule are the ones stakeholders most need to see. Reporting only progress is a form of selective communication that erodes trust when delays surface.
Re-anchor feature unlock dates when capabilities slip
If a capability is 3 months behind, move the dependent features 3 months on the feature roadmap in the same meeting. Do not carry impossible timelines alongside a capability roadmap that says they cannot be met.
Celebrate threshold crossings explicitly
When a capability moves from amber to green, name it in the quarterly update. Teams need to see that the model is improving and that their work on data quality, fine-tuning, and eval tooling is landing. This is a meaningful milestone, treat it like one.
Archive old capability roadmaps
Keep a copy of each quarter's roadmap. Over time, this becomes a record of your AI development velocity that informs future planning: how long did it take to improve clause extraction by 10 points? Use that to calibrate next year's bets.
Quick-start: the first version of your capability roadmap
If you have never built one before, start small. Pick the three capabilities your product depends on most critically. Run or find existing evals for each. Set a threshold for each. Map which features depend on each. That is your v1. You can formalize the template and expand coverage over the next two quarters.
The goal is not a perfect document. The goal is a shared conversation between PM and ML about when your AI will be good enough to do what the roadmap says it will do. Any version of this document that enables that conversation is better than no version at all.
Build AI Products on a Foundation That Plans
The AI PM Masterclass covers every planning template you need: capability roadmaps, eval frameworks, launch checklists, and the stakeholder communication playbook. Cohort starts September 1, 2026.
Related Articles
Before you go: get the AI PM Minute
One tactic to make you a sharper AI PM, twice a week. 60 seconds to read. Free.
No fluff. Unsubscribe anytime.