Why your AI product roadmap is probably wrong
I've reviewed about two dozen AI product roadmaps in the past year, across startups and established companies. Most of them share the same structural problem: they're built on assumptions about where AI technology will be in 12 months, and those assumptions are almost certainly wrong.
This isn't a criticism of the teams who built them. Predicting AI capabilities on a 12-month horizon is genuinely hard right now. The pace of improvement is non-linear, the cost curves are shifting faster than anyone expected, and every quarter brings capabilities that would have seemed unlikely the quarter before.
But "it's hard to predict" isn't a reason to give up on roadmapping. It's a reason to roadmap differently.
The prediction problem
Most AI roadmaps I see are structured like traditional product roadmaps: a sequence of features with estimated timelines. "Q2: Add AI-powered search. Q3: Build recommendation engine. Q4: Launch AI assistant." The implicit assumption is that the team knows what's technically feasible at each stage and can estimate the effort.
That assumption breaks down with AI for a few specific reasons.
The cost of inference is dropping faster than most teams model. A feature that requires $50,000/month in compute costs today might cost $5,000/month in a year. This changes the ROI calculation for every AI feature on your roadmap, but most teams don't revisit these numbers.
Foundation model capabilities improve in unpredictable jumps. When a new model generation drops, it often makes previous approaches obsolete. Teams that invested months in prompt engineering and fine-tuning for a specific model find that a newer model handles the same task out of the box, better.
The competitive landscape shifts just as fast. The AI feature that felt differentiated six months ago might now be offered by five competitors or available as an API from a platform vendor. Your roadmap needs to account for this, and most don't.
There's also a subtler problem that I think gets underrated: the compounding effect of wrong assumptions. If your Q2 plan is based on assumptions about model capability, and your Q3 plan builds on Q2's outputs, a single wrong assumption in Q2 cascades through the rest of the year. Traditional roadmaps have some cascading risk too, but with AI the variance in each assumption is much wider, so the cascade is more severe.
How to roadmap for uncertainty
Teams need direction. Leadership needs to see a plan. The answer is to build roadmaps that account for uncertainty instead of pretending it doesn't exist.
Use time horizons, not timelines. Instead of structuring roadmaps as "Q2, Q3, Q4," try the "Now (committed, in flight), Next (validated problem, exploring solutions), Later (opportunity area, monitoring)" format that Tim Herbig and others have written about. This now-next-later approach works particularly well for AI because it doesn't overcommit to specific solutions in future quarters.
Build in decision points, not just milestones. At the end of each sprint or cycle, include an explicit decision: "Continue on this path, pivot the approach, or stop?" This turns your roadmap from a commitment into a series of options. You're not promising to build a recommendation engine in Q3. You're promising to evaluate whether a recommendation engine is still the right approach given what you've learned and what's changed in the market.
Separate the problem layer from the solution layer. Your roadmap should commit to problems, like "Customers can't find relevant content quickly enough," while keeping solutions flexible. It could be search improvements, recommendations, an AI assistant, or something that doesn't exist yet. When a new capability emerges that solves the problem better than your planned approach, you can adapt without abandoning the roadmap.
Include a technology monitoring layer by dedicating a small amount of team capacity (I suggest 10-15%) to staying current with AI capabilities. Someone on the team should regularly test new models, evaluate new APIs, read benchmarks, and report back on what's changed. This isn't research for research's sake. It's an early warning system that helps you update your roadmap assumptions before they lead you astray.
The quarterly recalibration
Every quarter, before you plan the next cycle, run through these questions.
What AI capabilities have changed since our last planning cycle? New models, new APIs, cost changes, new competitor features. Be specific.
Which of our roadmap assumptions are still valid? If you assumed a certain level of model capability or a certain compute cost, check whether those assumptions still hold.
Are any of our "Later" items now technically feasible? Sometimes capabilities that were speculative last quarter are achievable now. Moving them forward can be a source of competitive advantage.
Are any of our "Now" items no longer differentiated? If competitors have shipped similar features or if the capability is now available as a commodity API, reconsider whether custom building still makes sense.
What have we learned from our experiments? Every AI feature that's in production should be generating data about what works and what doesn't. Use that data to inform the next quarter's priorities.
I'll share a concrete example. A team I worked with had planned to build a custom classification system for Q3, requiring a fine-tuned model and significant labeling effort. During their Q2 recalibration, they discovered that a newly released foundation model could handle the same classification task with zero-shot prompting at 91% accuracy, compared to their fine-tuned model's 94%. The 3% accuracy gap wasn't worth the three months of fine-tuning and maintenance cost. They pivoted to the API-based approach, shipped the feature in three weeks instead of three months, and redirected the engineering time to a different problem that actually required custom work. Without the recalibration ritual, they would have spent Q3 building something that was no longer the best use of their time.
This isn't just good AI roadmapping. It's good roadmapping, period. The AI context just makes the recalibration more urgent because the landscape shifts faster.
Communicating AI roadmap uncertainty to leadership
This is the part that most PMs struggle with. You've internalized the need for flexibility. You understand why committing to specific AI solutions 9 months out is risky. But your VP wants a slide that says what you're building each quarter. Your board wants to see a plan. "We'll figure it out as we go" is not a satisfying answer, even if it's closer to the truth.
I've found a few approaches that work.
Frame flexibility as risk management, not indecision. Most executives understand risk. When you explain that committing to a specific AI implementation 9 months out is like locking in a vendor contract before knowing the market price, they get it. The roadmap isn't vague because you don't have a plan. It's structured to reduce the risk of investing in the wrong approach.
Commit to problems and metrics, not solutions. Leadership usually cares more about outcomes than implementations. "By Q4, customers will find relevant content 3x faster" is a commitment your VP can put on a slide. The fact that you're keeping the technical approach flexible is an implementation detail, not a strategic gap. Marty Cagan has talked about this as the difference between feature teams and empowered product teams. Feature teams commit to building specific things. Empowered teams commit to solving specific problems.
Show the decision framework, not just the decisions. When you share your roadmap with leadership, include the decision points and the criteria you'll use at each one. "At the end of Q2, we'll evaluate whether to build custom or buy an API based on these three criteria." This gives leadership confidence that there's rigor behind the flexibility.
Report on what you've learned, not just what you've shipped. In quarterly updates, include a section on what changed in the AI landscape and how your roadmap adapted. This builds credibility over time. Leadership starts to see that the flexibility isn't a lack of planning, but rather a planning advantage that prevents wasted investment.
What I've seen go wrong
Three patterns emerge repeatedly that derail AI roadmaps.
The first is the "boil the ocean" approach. A team plans to build an AI-powered everything: search, recommendations, summarization, chatbot, analytics, content generation. All in the same year. They spread themselves thin, and nothing ships at a quality level that moves the needle. The fix is ruthless prioritization. Pick the one AI capability with the highest chance of changing user behavior, nail it, and then move on.
The second is getting "technology-forward." A team gets excited about a specific AI capability (say, RAG or agents), builds a roadmap around it, then goes looking for customer problems to apply it to. This is the build trap in AI clothing. Melissa Perri would recognize this immediately. Start with customer problems instead, then evaluate which AI capabilities could address them.
The third is the "one and done" mindset. A team ships an AI feature and moves on to the next one without investing in monitoring, iteration, and improvement. AI features are living systems that need ongoing tuning, quality monitoring, and user feedback loops. Your roadmap needs to include post-launch investment, not just initial build.
A realistic AI roadmap structure
If I were building an AI roadmap today, here's how I'd structure it.
The top layer is the problem portfolio: the three to five customer problems I'm targeting this year, ranked by impact and feasibility.
The middle layer is the solution portfolio: for each problem, the approaches I'm considering (including non-AI approaches), with current evaluation status.
The bottom layer is the capability portfolio: the AI capabilities my team is building or acquiring, mapped to the solutions that need them.
The key insight is that these layers don't have to move at the same pace. The problem portfolio is relatively stable (customer problems don't change quarterly). The solution portfolio shifts as technology evolves and experiments yield results. The capability portfolio changes fastest as new tools and models become available.
By separating these layers, you can update your AI roadmap frequently without losing strategic direction. The problems stay the same. The solutions evolve. And the capabilities flex with the technology.
This structure also makes communication easier. When a board member asks "what's your AI strategy?", you start with the problems. When an engineer asks "what should I learn next?", you point to the capability portfolio. When a competitor ships something new, you check it against your solution portfolio to see if it changes your approach. Same roadmap, different entry points for different audiences.
The human side of AI roadmapping
One thing I've learned from watching AI roadmaps succeed and fail: the biggest risk isn't usually the technology. It's the people dynamics.
Engineers who spent months building a fine-tuned model don't want to hear that an API call now does the same thing. PMs who championed a specific AI feature don't want to admit the competitive landscape made it irrelevant. Leaders who told the board about the AI strategy don't want to pivot six months in.
These are real human reactions, and if you don't account for them, your roadmap recalibration process will fail even when the data clearly supports a change. I've seen teams continue investing in approaches that were obviously no longer the best path, purely because of sunk cost psychology and organizational inertia.
The fix isn't to eliminate these dynamics. It's to normalize them. Make "we learned something and we're changing course" a celebrated outcome, not a failure. Include "what did we stop doing?" as a regular part of your quarterly review, and treat smart pivots with the same respect as successful launches. The teams that roadmap AI well aren't just good at planning. They're good at updating their plans without breaking organizational trust.
This article is part of a series on product management in an AI-transformed landscape.