Overview

The mistake most CTOs make with AI roadmaps: They plan like AI capability is stable. They commit to specific models, specific architectures, specific timelines. Six months later, Claude releases a new model with 10x longer context windows. Their entire plan is obsolete.

Good AI roadmaps don't predict the future. They plan in waves. Quick wins that fund the next wave. Foundational work that enables options. Strategic bets on where the market's headed.

This is how you go from scattered AI experiments to coordinated AI strategy that actually compounds over time.

The Wave Planning Model

Instead of a linear roadmap, think in waves. Each wave is 6 months.

Wave 1 (Months 1-6): Foundation and Quick Wins

Goal: Build organizational muscle memory around AI while setting up infrastructure.

Quick wins (60% of effort): Pick 2-3 high-impact, low-complexity problems. Customer support automation. Code generation for boilerplate. Data summarization for reports. These fund themselves within 6 months. They prove AI value to the organization. They attract talent.

Concretely, if you're a SaaS company: pick one customer-facing use case and one internal use case. The external one builds your AI narrative. The internal one lets you iterate without customer risk.

Foundation (40% of effort): While quick wins run, build infrastructure that doesn't have customers depending on it yet. Feature store architecture. Model monitoring. Integration patterns. When wave 2 starts, you don't rebuild these.

This is the period where you're also experimenting with models. Which actually works for your use case? GPT-4 vs. Claude vs. open source? You don't commit yet. You test.

Staffing: A product manager (driving prioritization), 2-3 engineers (building), 1 data scientist (feature engineering and evaluation). That's 5 people. If you have less, focus only on the quick win in wave 1. Hire in parallel.

Wave 2 (Months 7-12): Capability Expansion

Goal: Expand to 4-6 AI capabilities across the product and organization.

By now you've learned from wave 1. You know which models work. You've built infrastructure once. You can move faster.

Expand into new areas: product features, internal tools, data analytics, process automation. The goal isn't to boil the ocean. It's to have AI touching every part of your business in a way that meaningfully improves something.

Staffing: The team from wave 1 (now more senior) plus a second team. You might have a dedicated ML engineer focused on fine-tuning or building domain-specific models. A senior engineer architecting platform infrastructure that all AI capabilities use.

By end of wave 2, you should have 3-5 engineers working on AI full-time, plus distributed AI expertise across the engineering org.

Wave 3 (Months 13-24): Strategic Positioning

Goal: AI becomes part of your product narrative. It's a differentiator, not an experiment.

By now, your quick wins from wave 1 are either working great or they've been killed. You've either solved the use case or you've learned it's not worth solving. Either way, you know.

Wave 3 is where you make bigger bets. Maybe you build a domain-specific model. Maybe you invest in real-time AI features that require new infrastructure. Maybe you partner with an AI company to build something custom.

These bets are informed by 18 months of learning. They're not random. They're not chasing hype. They're solving hard problems you've already identified.

Staffing: You probably have 8-12 engineers working on AI across teams. You've got ML specialists. You might have a VP of AI if you're at that stage. More importantly, AI is embedded in product teams, not siloed.

The Roadmap Principle: Plan in waves of 6 months. Quick wins fund infrastructure. Infrastructure enables scaling. Scale funds strategic bets. Each wave stands on its own.

Managing Model Velocity

Here's something nobody talks about: model improvements happen faster than software releases. A new version of Claude drops. A new capability opens up. Your roadmap is suddenly partially obsolete.

Model Velocity Requires Capability Roadmaps: Don't commit to specific models or architectures in your roadmap. Commit to capabilities: "we need classification, summarization, and recommendation." Let the model choice be a quarterly decision, not a multi-quarter commitment. This way, when Claude 4 drops with 10x better performance, you can upgrade without roadmap churn.

You need a way to incorporate this without constantly pivoting.

Reserved Capacity for Rapid Iteration

Build in 20% of engineering time for "model improvements." Not speculative work. Concrete: "Claude 3.5 is out, let's test it in our three key use cases." If it's better, we upgrade. If not, we don't. But we're actively looking, not passively accepting whatever we built six months ago.

This feels inefficient. It's not. It's the difference between your AI stack aging gracefully and becoming a legacy system.

Capability Rather Than Product Roadmap

Don't plan "release feature X with AI." Plan "add reasoning capability to our decision engine." The first is rigid. The second is flexible. When a new model enables that capability cheaper or faster, you can shift tactics without missing the deadline.

Regular Model Tournaments

Every quarter, run a tournament on your key use cases. Claude vs. GPT-4 vs. Llama vs. whoever's new. Speed, cost, quality. Which wins? Use that for the next quarter. Change winners, and you've already got a migration plan.

This isn't procrastination. It's systematic. You're not making random choices. You're gathering data on what actually works in your specific context.

Failure Modes: Common Roadmap Mistakes

Failure Mode 1: The Linear Roadmap

You plan wave 1, wave 2, wave 3, assuming wave 1 goes as planned. It doesn't. Halfway through wave 1, you discover you chose the wrong model. Now you're off track. The whole roadmap cascades.

Fix: Think in waves, not timeline. Each wave stands alone. Wave 1 succeeds if you learn, not if you hit a specific date. Adjust wave 2 based on wave 1 learnings. Roadmap is a learning machine, not a fixed plan.

Failure Mode 2: The "Move Fast and Break Things" Roadmap

You ship 20 AI features in 6 months. No evaluation, no monitoring, no governance. Half of them don't work. Users complain. You lose trust. Now you have to rebuild governance and people don't believe in AI anymore.

Fix: Quality matters. Evaluate what you build. Monitor in production. Don't ship broken systems because you're moving fast.

Failure Mode 3: The Ambitious Roadmap Nobody Believes In

You commit to building 50 AI features in 12 months. Your team thinks it's impossible. They're skeptical. Midway through, you're behind. The roadmap becomes a source of stress, not inspiration.

Fix: Build roadmaps the team believes in. Conservative is better than ambitious-but-impossible. You can always accelerate if things go well. You can't fix broken trust from overselling.

Real Case Study: Startup AI Roadmap

A Series A company (10 engineers) built an AI roadmap: Wave 1 (6 months) = 2 quick wins + infrastructure. Wave 2 (6 months) = 4 capabilities across product. Wave 3 (12 months) = strategic bets.

Reality: Wave 1 went long. One quick win worked great (recommendations). One didn't (search ranking). Infrastructure took longer than expected. They learned a lot. They adjusted wave 2: doubled down on the working use case, killed the one that didn't work, added 3 new ones.

Wave 2 went faster because they had infrastructure. By end of wave 2, they had decided to hire an ML specialist (not obvious from wave 1, but learned need). Wave 3 included building fine-tuning pipeline.

Roadmap wasn't a plan that came true. It was a learning journey. They shipped more AI features faster because they were willing to adjust based on reality.

The Risk Layer: What If You're Wrong?

Real roadmaps account for being wrong. AI is unpredictable enough that you should assume you will be.

Technical Risks

Model performance hits a wall: You commit to building a feature on Claude's 200k context window. In production, you realize the quality degrades below 100k. You've now got a feature that works at partial capacity. This should be in your plan.

Mitigation: Don't commit to capability limits you haven't tested at scale.

Cost surprises: Your projections said $1k/month in tokens. Actual usage is $10k/month. This happens more than you'd think.

Mitigation: Run pilots with real load, not synthetic load. Measure cost per business outcome, not raw token cost. Build alerts that trigger when cost hits a threshold.

Latency becomes a problem: You built something assuming 2-second response time. Users see 8 seconds. It's worse than the non-AI version.

Mitigation: Latency requirements belong in your initial spec, with fallback plans if you miss them.

Organizational Risks

Your best AI engineer gets recruited by OpenAI: This will happen. Plan for it. Cross-train. Document. Build against knowledge silos.

Board pressure to announce AI: They want to tell customers/investors. You need to make sure you've got something real. Press releases are easy. Shipping actual value is hard.

Mitigation: Have a board communication plan that separates roadmap ambitions from product commitments.

Market Risks

Open source catches up: You've built on Claude. Llama becomes good enough. Now you're paying Claude when you could self-host.

Mitigation: Keep open source pilots running in parallel. Know the delta between what you've built and what open source can do.

A competitor ships your feature first: They moved faster. Now your launch is "catching up," not "leading."

Mitigation: Focus on durable advantages (better data, better workflow, better integrations) not just flashy AI features.

The Concrete 12-Month View

Months 1-3: Proof of Concept
- Pick one high-impact use case
- Build it with whatever model seems best
- Get it to 50+ users
- Measure: cost, quality, user satisfaction
- Infrastructure: feature store for this use case, basic monitoring

Months 4-6: Optimization and Expansion
- Optimize the use case (model choice, prompt engineering, UX)
- Pick two more use cases
- Get all three to 500+ users
- Infrastructure: unified monitoring, cost tracking, model comparison framework

Months 7-9: Capability Multiplication
- Three use cases are stable
- Add three more (different problem types)
- Start thinking about platform aspects: shared components, standard patterns
- Infrastructure: platform libraries, fine-tuning pipeline if doing it

Months 10-12: Strategic Assessment
- Six use cases in production
- Clear data on what works and what doesn't
- Understand cost, quality, competitive positioning
- Roadmap next year's bigger bets based on what you've learned

What to Do Monday Morning

If you don't have an AI roadmap yet:

Step 1: Declare your wave structure. "Wave 1 is Jan-June. Wave 2 is July-Dec. We're building foundation and quick wins simultaneously." Write this down. Get alignment.

Step 2: Identify your quick wins. Three use cases max. High-impact, low-complexity. Can you ship an MVP in 6 weeks? If not, it's not a quick win.

Step 3: Allocate infrastructure time. 40% of resources to foundation you'll use in wave 2. This is hard to justify to product teams but essential to success.

Step 4: Set up model comparison framework. Which metrics matter? How will you compare models? Build this before you have strong opinions on winners.

Step 5: Communicate the plan.** Board, product team, engineering. Everyone should understand: we're moving in waves, learning as we go, updating the roadmap based on what we learn. Not a fixed plan. A learning machine.

FAQ: Roadmap Questions

Q: How much of engineering should we allocate to AI?

A: Wave 1 (months 1-6): 3-5 full-time engineers plus 20% of adjacent teams testing and learning. Wave 2: 5-8 engineers plus 30% distributed (team members learning AI part-time). Wave 3: 8-15 engineers plus 40% distributed. Depends on company size and AI criticality to product. Rule of thumb: start conservative, accelerate if successful.

Q: What if a use case fails halfway through a wave?

A: Kill it and reallocate the engineering time. You've learned something valuable: either this problem isn't solvable with current AI, or it's not actually a business priority (or maybe the priority wasn't as high as thought). All useful data. Adjust the roadmap. Don't throw good effort after bad.

Q: Should we commit to open source or proprietary models in the roadmap?

A: Keep both open. Let the use case + cost + quality trade-offs guide you. Your roadmap should be "we'll have classification capability" not "we'll use GPT-4 for classification." The model is an implementation detail. The capability is what matters. Maintain optionality.

Q: How often do we revisit the roadmap?

A: Formally: end of each 6-month wave. Informally: quarterly check-ins. Update if market conditions shift dramatically (new model with breakthrough capability, major customer asks, competitive threat). Don't update weekly based on hype. Do update quarterly based on data.

Q: What if we're moving too fast and breaking things?

A: Add evaluation and monitoring to the roadmap. Allocate 20% of engineering time to quality, not just speed. Build governance lightweight (appropriate to risk). A roadmap that ships broken systems is worse than a roadmap that ships less but better. Better to be slow and right than fast and wrong.

Q: Should we build AI infrastructure or buy/use managed services?

A: For waves 1-2: use managed services (AWS SageMaker, Vertex AI, open-source frameworks). Build internal infrastructure only when you've proven the model works and you have scale. Building infrastructure earlier is overhead you don't need. Exception: if you have very specialized requirements, build custom infrastructure when needed, not speculatively.

Key Insight

Plan in 6-month waves, not fixed annual plans. Wave 1 (60% quick wins + 40% foundation), Wave 2 (expand to 4-6 capabilities), Wave 3 (strategic bets informed by learning). Quick wins fund infrastructure. Infrastructure enables scaling. Allocate 3-5 engineers Wave 1, 5-8 Wave 2, 8-15 Wave 3. Update quarterly based on data, not constantly based on hype.

Building the Roadmap That Adapts

The companies winning with AI don't have better roadmaps than you. They have roadmaps that adapt faster. Roadmaps built on learning, not prediction.

They know the field will shift. They plan for it. And because they do, when it does shift, they're not scrambling to retool. They're just adjusting the wave.

Build that kind of roadmap. And the wins compound.

On This Page

Introduction
Wave Planning Model
Model Velocity
Failure Modes
Case Study
Risk Planning
12-Month Timeline
Monday Morning Action
FAQ
Key Takeaway

Chapter Details

Part ofCh 1: AI-Native Technology Strategy