A 12-month product roadmap written in 2026 is a high-velocity list of assumptions. Which isn’t a criticism of roadmaps, but a fact that has always been true.
In sixteen years of building products I’ve never seen a long roadmap followed to the letter, and I’ve never thought that was a failure. A roadmap is a journey plan: you know the destination, you roughly know the route, and you accept that the inevitable roadblocks, diversions and occasional comfort break mean it won’t play out exactly as it was drawn. The outcome - your north star - stays fixed, but how you get there flexes.
What has changed in the age of AI however is how quickly you can tell which decisions on the route are right.
There are options around how you deliver a roadmap, and you need to know in advance of development how productive (or not) a feature will be in terms of furthering progression towards your north star.
If you were driving, it would be obvious: you take the fastest route, and you opt for the quick stop for picky bits from M&S over a long lunch in a sunny beer garden.
In product it is not always so clear but, where identifying those features that offer the best route used to take 3 months of development, now it only takes days. And a clear north star with quick, testable hypotheses enables you to constantly learn and course-correct.
For years, a roadmap for an eCommerce app looked something like this:
January: build single sign-on
February: add “100 bought in the last 24 hours” tags
March: create “3000 others also liked this product” tags
April: personalise content around liked products
Every line is a feature, and every feature contains a silent assumption about why it matters. Single sign-on is there because somebody believes logged-in users are more valuable and that friction at login is what’s holding them back. Social proof tags are listed because somebody believes they’ll nudge basket adds.
Now these beliefs may well be right. But a feature roadmap like this commits engineering capacity to them before anyone has checked - and in a world where AI has made building fast and cheap, building the wrong thing quickly costs more in the long run.
The roadmap our Product Builders work from keeps the shape stakeholders recognise: the same visual, the same months across the top. But each line item is now an outcome, with the hypotheses for reaching it underneath.
So the first two months of that same eCommerce roadmap might now read:
January: increase the share of monthly active users who are logged in
Hypothesis 1: offering Google and Apple single sign-on will lift logged-in sessions from 22% to 30%, because password friction is the main drop-off at login.
Hypothesis 2: prompting sign-in at the moment a user saves or favourites an item will lift logged-in sessions by a similar amount, at a fraction of the build cost, because the value of logging in is obvious at that point.
Hypothesis 3: a “we’ll remember your basket” message on the login prompt will lift completed sign-ins by 10%, which we can test with copy alone before building anything.
February: increase the number of items added to basket per session
Hypothesis 1: a social-proof tag (“48 bought this in the last 24 hours”) on product pages will lift add-to-basket by 8%.
Hypothesis 2: a low-stock tag (“only 3 left”) will lift add-to-basket by more than the social-proof tag, because urgency outperforms popularity in this category.
Hypothesis 3: moving the add-to-basket button above the fold on mobile will lift adds by 5% without any new data feed at all.
…and so on through the year.
Notice that the original feature is still there in both months. It hasn’t been thrown out; it’s been demoted from a commitment to a candidate, and it’s now competing against a number of cheaper or faster routes to the same outcome.
And that’s the difference between a hypothesis-led roadmap and a feature roadmap: choosing between different routes based on evidence instead of simply justifying one route in isolation. It’s the hypothesis-led roadmap only that allows adjustments and trade-offs based on learnings.
It’s important to note that the listed targets aren’t guesses but benchmarks the Product Builder pulled in while framing the problem, which is the first turn of what we might call the ‘build-to-learn’ loop.
None of it requires a new process. The loop our Product Builders run is one any product person will recognise: frame the problem, form hypotheses, build something testable, validate it with users, then learn and either commit or pivot.
What’s changed is how little each turn of the loop now costs, and how much of it a Product Builder can do independently, without pulling on design or engineering:
Framing and benchmarking. To set a hypothesis you need a number to beat. Finding it used to mean hours of desk research across analyst reports and annual summaries but that research now takes minutes, which means we can put a benchmark and rough ROI against every hypothesis before anything is built, and drop the ones that wouldn’t move the needle even if they worked.
Building. Getting something real into users’ hands used to mean months with developers or weeks with designers, but a Product Builder can now stand up a realistic, usable prototype in hours.
Validating. We test with real users first, then extend the signal with synthetic users to pressure-test the edges. With a well-formed hypothesis, it is quickly obvious whether a feature lands - and whether it is tracking towards the benchmark.
Learning. The only decision that then matters is: does this feature drive the initiative, does it need adapting, or do we pivot entirely? Either answer is a good one at this stage because the bad answer is the one you don’t get until three sprints into production.
In 2019 I was working with Disney when Amazon Alexa launched. The brief was an Alexa skill to read bedtime stories to children, and our hypothesis was that parents would use it at bedtime. We built a mock Alexa skill, which took weeks, and tested it with parents.
They didn’t want it. Parents didn’t want technology in their children’s bedrooms and wanted to read the bedtime story themselves. What they did want from Alexa was something to keep the kids entertained while they cooked dinner and so we went back, re-prototyped a musical statues game set to Disney songs, which of course then tested brilliantly.
The loop worked. We learned early and pivoted before a line of production code was written. But the whole discovery process took months. Run today, with a Product Builder benchmarking in minutes and prototyping in hours, the same journey would take just weeks, and the first prototype might have been in front of parents the day after the brief had landed.
If you sit on a leadership team or a board, the roadmap you see from us still looks like a roadmap. It still gives direction, still supports budget cycles and dependency planning, still tells you what the business will have achieved by when. What it no longer does is promise a specific feature in a specific month, because that was always the promise most likely to be broken.
Instead, it promises an outcome and also shows you the evidence trail: which hypotheses were tested, which were dropped, and why the feature that did ship was the one worth building.
Speed has made the old roadmap riskier. But it has also, finally, made the hypothesis-led roadmap deliverable.
To discuss this further? Book a 30-minute call.