For years, we’ve treated our roadmaps like a contract—a list of features with committed deadlines that we present to stakeholders for alignment. But let’s be honest, how often does that linear plan survive contact with reality, especially now with AI?
The core challenge is that building with AI isn’t like traditional software development. It’s less deterministic and more experimental. You can’t just ‘build’ a recommendation engine with the same certainty you can build a login button. You’re testing a hypothesis, training a model, and iterating based on uncertain outcomes.
Shoving these probabilistic projects into a rigid, feature-based roadmap is like trying to fit a square peg in a round hole. It creates friction with engineering, sets false expectations for stakeholders, and stifles the very innovation it’s meant to enable.
This is why many teams are shifting towards outcome-based or hypothesis-driven roadmaps. Instead of committing to shipping ‘Feature X,’ we commit to exploring the hypothesis that ‘we can achieve Outcome Y by experimenting with Z technology.’ This reframes the conversation from output to impact and gives teams the flexibility to pivot.
How is your team adapting your roadmapping process for the inherent uncertainty of AI and ML-driven projects?