A roadmap that wasn't built on user evidence isn't a plan. It's a wishlist with dates on it.
That sounds harsh. It's also what most roadmaps actually are. Stakeholders contribute requests. Engineering contributes capacity estimates. Product writes it up in a tidy quarter-by-quarter view. The thing that's missing — the one that would make the difference between a wishlist and a plan — is whether any of this corresponds to what the users actually need.
The roadmap is downstream of the discovery work. If the discovery didn't happen, the roadmap is fiction.
How roadmaps end up disconnected from users
It's not that teams don't believe in user research. They mostly do. The disconnect happens through pressure, not principle.
The quarterly planning cycle has a deadline. The exec team needs the roadmap by Friday. Discovery work takes longer than that — well-run discovery is weeks of careful work. So the roadmap gets built without it, with the intention to "validate" later. Validation rarely happens. The roadmap becomes the input to engineering, the work begins, and the assumption that anything was actually validated quietly drops away.
The other path is "we already know what users want". The team has been in the space for years. The exec has the customer relationships. The PM did discovery six months ago. So new evidence is treated as optional — confirmation of what's already known. That's not how user needs work. They drift. Yesterday's evidence is partial today.
Both paths produce the same thing: a roadmap that nobody can trace back to a recent user conversation.
What "built on users" actually means
It's not that every line on the roadmap needs a quote attached. It's that every line should be traceable back to a user need or a clear business outcome that you have evidence for.
A few markers:
You can name the user problem each item solves. Not at the level of "improves activation". At the level of "users abandon at step three because they don't understand what's expected of them — this fixes that". If you can't say it that specifically, the work is going to optimise for the wrong thing.
You know which users it's for. The product probably has multiple user types. Each item on the roadmap is more valuable to some than others. If you can't name the segment, you're going to ship for nobody in particular.
You have a recent reason to believe this matters. Recent meaning weeks, not months. The user need was described to you, or shown in support tickets, or confirmed in usage patterns. If the most recent evidence is from a research session two quarters ago, the work is being prioritised on memory.
A roadmap that fails any of these on most items has a credibility problem. The team will ship things, the metrics may move, but the connection between the work and the actual users will be a coincidence rather than a design.
What to actually do about it
Three habits that move a wishlist toward a plan:
Run discovery before planning, not after. Two weeks of focused user conversations before the quarterly planning cycle, not three weeks after the roadmap is signed off. The order matters. Discovery before planning shapes the roadmap. Discovery after planning becomes a presentation in search of an audience.
Make user evidence a required field. Every item on the roadmap should have a small block of supporting evidence — what user need, what segment, what's the recent signal. If the block is empty, the item shouldn't make it. This sounds like bureaucracy. It's the smallest gate that filters out the items that wouldn't survive a discovery pass.
Build a small user panel you can reach in 48 hours. Most teams treat user research as a long process because their default channel is — recruit through an agency, schedule, host. Build a short list of users who've agreed to take a quick call when you need one. Now research is a 48-hour cycle instead of a 4-week one. The pace of discovery starts to match the pace of planning.
When the roadmap and the users disagree
Sometimes the discovery work surfaces evidence that contradicts what the team already wanted to build. That's the test of whether the discovery is real.
A real discovery process changes the roadmap when it finds something. A theatrical discovery process produces a deck that confirms what the team had already decided. The first is uncomfortable. The second is comforting. Only one of them ships better products.
The conversation when the roadmap and the users disagree is the most important conversation product leadership has. The instinct is to back the roadmap because the work is already in motion. The right move is to take the user evidence seriously, even if that means changing the plan in flight.
That's not failure of planning. It's the planning working as intended.
The shift
A roadmap is only as good as the discovery work that built it. Without the discovery, the roadmap is a guess dressed up as a plan.
Do the discovery first. Make the evidence visible on every item. Be willing to change the plan when the evidence says so. Then the roadmap stops being a wishlist and starts being a tool the team can actually use.
If you're building for the user, not the roadmap, discovery-led roadmaps are the version that survives that test. And making discovery a habit, not a phase, is what keeps the roadmap connected over time instead of drifting back into a wishlist.