“`html
Six months ago, I sat in a planning meeting where we confidently outlined our product roadmap for AI-powered backup features. By month three, two of those features were already obsolete—not because we failed to execute, but because the underlying AI models improved so dramatically that our original approach no longer made sense.
Welcome to product management in 2025.
If you’re a product manager trying to build credibility with stakeholders, investors, or your team while navigating the monthly—sometimes weekly—advances in AI capabilities, you’re dealing with a fundamentally different challenge than we faced even two years ago. The traditional product roadmap, with its neat quarterly deliverables and multi-year vision, has met an immovable force: artificial intelligence that evolves faster than our ability to ship.
Working at Veeam managing data protection products that increasingly rely on AI and machine learning, and doing this from Minnesota—a state where directness and honest communication are cultural bedrock—I’ve had to completely rethink how I approach roadmaps. This isn’t theoretical. This is what’s actually working for our distributed team across Minnesota and beyond.
The AI Roadmap Problem Nobody Talks About Openly
Let’s be direct: the traditional product roadmap is a commitment. It’s a promise to customers, a guide for engineering, a document that builds trust through predictability. But AI doesn’t care about your roadmap.
A new open-source language model gets released. Suddenly, the approach you spent two quarters designing is no longer optimal. Or your team discovers that a specific AI capability you were planning to build natively is now available through an API that’s cheaper, faster, and more reliable than building it yourself. Or—and this happened to us—you realize that the AI model you were betting on has serious limitations around data privacy that make it unsuitable for your enterprise customers, and you need to pivot entirely.
The problem compounds when you have distributed teams. When I’m planning features with team members in different time zones, different regions, we can’t just call an emergency meeting and recalibrate instantly. We need roadmaps that are resilient but not rigid. Honest but not paralyzing.
Here’s what I’ve learned: the issue isn’t that traditional roadmaps are bad. It’s that they’re incomplete when AI is a first-class feature component. They assume your building blocks are stable. In the AI era, your building blocks are shifting.
The Minnesota Approach: Honesty Over Confidence
Minnesota culture has given me something invaluable in this moment: a deep discomfort with vaporware and a genuine preference for honest conversation over false certainty.
This is not an accident. Minnesota built some of the most reliable companies in the world—Target, Best Buy, 3M, Mayo Clinic—on a foundation of pragmatism and straight talk. We don’t do hype particularly well here. We do execution. And when execution becomes uncertain, we say so.
I’ve watched product managers in other regions build roadmaps that look impressive in slide decks but crumble when reality arrives. The Minnesota approach is different: we build roadmaps that we can actually defend to a customer in a conversation. Not a sales pitch. A conversation.
When I talk to our customers about AI features in our products, I’m explicit about what’s baked and stable, what’s in active experimentation, and what’s on the horizon pending breakthroughs we can’t yet predict. Some teams worry this undermines confidence. I’ve found it does the opposite. Customers appreciate the clarity. Enterprise buyers especially want to know: can you commit to this, or are we exploring together?
Applied to AI-era roadmapping, this honesty principle means:
- Separate your roadmap layers explicitly. Core features with proven AI models (Foundation Layer). Features dependent on model improvements we’re actively testing (Experimental Layer). Opportunities that require breakthroughs we can’t yet guarantee (Horizon Layer). Don’t mush them together.
- Tell your team and customers which dependencies are volatile. “This relies on Claude’s next release improving accuracy by 15%.” That’s honest. Your team can plan around it. Customers understand the risk profile.
- Commit to the process, not just the outcome. “We will run monthly experiments on this capability and share results with your team quarterly” is a commitment you can actually keep. “We’ll ship AI-powered [vague thing] in Q3” is a guess dressed as a promise.
The AI-Era Roadmap Framework: Four Horizons Model
About eighteen months ago, we needed a new structure for our roadmap. The quarterly-based traditional approach wasn’t working. AI moves in technical cycles (model releases), capability cycles (what becomes possible), and business cycles (what customers need). These don’t align neatly with calendar quarters.
I developed what we call the Four Horizons model, and it’s become the framework we use across our team at Veeam:
Horizon 1: Stable & Operationalized
These are AI capabilities that are in production, performing reliably, with clear metrics and established performance baselines. For us, this includes things like AI-powered anomaly detection in backup data, predictive capacity planning, and basic automated remediation of common issues.
These features have:
- Model performance data from 6+ months of production
- Documented edge cases and failure modes
- Clear SLAs for accuracy and latency
- Customer adoption data
On the roadmap, Horizon 1 is predictable. You can commit to improvements, new training data, optimizations. This is where you’re doing incremental innovation on proven approaches. Roadmap cadence: quarterly updates, customer-facing timeline usually 6-12 months out.
Horizon 2: Validated & Active Implementation
These are capabilities where we’ve proven the concept works (usually through pilot programs or lab experiments), we understand the technical approach, and we’re actively building toward production. They’re not vaporware—they’re in motion. But they’re not ready for customer commitments yet.
Examples from our roadmap right now: using large language models to generate natural-language summaries of backup health across an entire infrastructure, and AI-powered ransomware detection that learns from patterns in your specific environment rather than relying only on signature databases.
These have:
- Completed proof-of-concept with real customer data
- Identified the specific models or approaches that work
- Known technical challenges and mitigation strategies
- A realistic timeline for beta: usually 2-4 months
For distributed teams, Horizon 2 is where clear technical design matters enormously. I’ve learned that when a teammate in a different time zone needs to understand why we’re building something a certain way, documentation and async video walkthroughs are essential. Roadmap cadence: monthly deep-dives on progress, customer communication is “coming soon, beta available to early partners.”
Horizon 3: Emerging & Exploratory
This is the territory where most AI work lives right now. We have a direction, usually based on customer feedback or market observation, and we’re running experiments to validate if it’s technically feasible and valuable.
For example: Can we use AI to predict which backup jobs will fail before they run, and automatically adjust parameters? We think it’s possible, we’re running small experiments, but we haven’t yet proven the underlying models work well enough to be reliable. Another: Could we use generative AI to help customers write backup policies in natural language instead of configuration syntax? That could be valuable, but we need to understand the hallucination risks with our data.
Horizon 3 work is not commitments—it’s learning. These items appear on your roadmap, but with completely transparent language:
- “We’re running experiments on X. We’ll have preliminary results by [date]. Go/no-go decision in [timeframe].”
- “This depends on [specific capability in a foundation model]. If that doesn’t materialize, we’ll pivot to approach B.”
- “Early customer feedback suggests demand for this. We’re validating feasibility with engineering, current confidence level: 60%.”
This is also where remote, distributed teams benefit from structured async communication. We run monthly Horizon 3 reviews where team members in different time zones can see what experiments are active, what the most recent results show, and what the next steps are. No meeting required—the async document with embedded videos and data is sufficient.
Horizon 4: Speculative & Opportunity Scanning
Every six months, we dedicate time to scanning the landscape: What new AI capabilities exist that we didn’t anticipate? What are customers starting to ask about? Where is the field moving that might affect our product in 12-18 months?
Right now, that includes things like: Will multimodal models (that work with video, images, data simultaneously) change how we can help customers visualize infrastructure health? Could prompt engineering and retrieval-augmented generation (RAG) systems let us provide better contextual help to customers troubleshooting issues? What does GPT-5 or Claude’s next release mean for our product strategy?
Horizon 4 is explicitly not a commitment. It’s a conversation starter. It appears on the roadmap as “opportunity watching” or “exploration track,” not as a feature pledge. This is valuable to share with customers and partners precisely because it shows you’re thinking ahead—but you’re thinking, not promising.
The Four Horizons approach changed how I communicate roadmaps. Instead of a long list of features with dates, we have a portfolio view: Here’s what’s solid. Here’s what’s in progress. Here’s what’s promising. Here’s what we’re watching. Each horizon has appropriate transparency, commitment level, and timeline assumptions.
Remote Team Collaboration: Making Distributed Roadmaps Work
Veeam’s teams are distributed. I work with colleagues in Minnesota, but also across the US and internationally. Product management in this context required changing how we actually build and maintain roadmaps.
Here’s what I’ve learned works:
Async-First Roadmap Documentation
We don’t wait for meetings to build our roadmap. The roadmap itself is a living, async document. Every month, the Product team updates it. Changes are tracked. Comments are encouraged. Engineers can leave technical notes. Customers (in some cases) have read access and can see why certain decisions were made.
This sounds simple, but it’s transformative for remote teams. Instead of a meeting where someone in a different time zone is half-asleep at 6 AM, everyone can read the roadmap when they’re sharp, ask questions asynchronously, and the conversation happens over a few days instead of in a single meeting.
Tools matter here. We use a combination of Notion (for the master roadmap and dependencies), Figma (for visualizing how features connect), and GitHub (for technical implementation details tied to specific roadmap items). Each tool has a different audience: executives see the Notion view, engineers see the GitHub details, customers see a simplified public version.
Monthly Horizon Reviews (Async + Optional Sync)
The first Tuesday of every month, I publish a “Horizon Report.” This is a 5-10 minute video where I walk through:
- What moved between horizons this month
- Key blockers or decisions needed
- Experiment results from Horizon 3
- Questions for the team
The video goes into our roadmap Slack channel. For the next 24 hours, people can ask questions asynchronously. If something needs deeper discussion, we schedule a focused 30-minute sync for the people who care about that specific item. But we don’t require everyone to attend a monthly roadmap meeting. They can consume it on their own time.
This has cut our planning meetings from 3-4 per month to maybe one. But the roadmap is more transparent and informed, not less.
Dependency Mapping and Risk Signals
In an AI-heavy product, dependencies are critical and often volatile. A feature we’re planning might depend on:
- A model improvement from OpenAI or Anthropic
- A customer privacy requirement we’re still clarifying
- Infrastructure work from another team
- Data availability or licensing that’s not yet resolved
We map all of these explicitly. Each roadmap item has a “dependencies” section and a “risk level” signal:
- Green: All dependencies clear, timeline confidence 85%+
- Yellow: 1-2 dependencies in progress, confidence 60-85%
- Red: Major uncertainty, confidence <60%
Distributed teams benefit enormously from this. A teammate in a different time zone doesn’t have to wonder why a feature got delayed. They can see that it was yellow (uncertain), and now they can see which specific dependency resolved or created the new issue. The roadmap tells the story asynchronously.
The Reality Check: Staying Credible While Remaining Flexible
I’ll be honest about the tension here. Stakeholders want commitment. Customers want predictability. But AI is genuinely unpredictable in some ways.
The solution isn’t to commit less. It’s to commit smarter and communicate clearly about what kind of commitment you’re making.
Three Types of Roadmap Commitments
Type 1: Foundation Commitments (Horizon 1 items) are hard commitments. “This will ship in Q2 with these specific capabilities. If we slip, we’ll tell you 6 weeks in advance.” These are things we’ve proven work. The risk is execution and priority, not technical feasibility.
Type 2: Progress Commitments (Horizon 2 items) are commitments to the process, not the date. “We will have this in beta by August. We will share monthly progress updates. If we learn it’s not viable, we’ll pivot publicly and tell you within 2 weeks.” Customers know they’re in for the learning journey, and that’s acceptable because you’re being transparent.
Type 3: Exploration Commitments (Horizon 3 and 4) are commitments to learning. “We will run this experiment and share results. We will keep you informed. We will tell you within 30 days whether we’re continuing or stopping.” You’re not promising the outcome, you’re promising the transparency.
When you lay this out explicitly, stakeholders actually trust you more, not less. They understand the risk profile. They can make their own decisions about how much certainty they need.
The “Backfill Planning” Technique
One framework that’s helped our team stay credible: whenever an AI capability shifts (a model gets deprecated, a new one becomes available, an experiment fails), we do “backfill planning.”
Within 48 hours, we update the roadmap to explain what changed and show customers what we’re doing about it. Not a long apology, just clarity: “We were planning to use Model X, it turned out to have [limitation]. Here’s our new approach: [Option A] ships in August instead of June, OR [Option B] is ready now but with [tradeoff].”
This takes a potential credibility hit (the pivot) and turns it into a credibility win (we’re responsive, we adapt intelligently, you can trust us to navigate uncertainty).
Practical Framework: Building Your AI-Era Roadmap
If you’re trying to implement this at your own organization, here’s the operational approach I’d recommend:
Step 1: Inventory Your AI Dependencies (Week 1)
List every feature that relies on:
