Build for the user, not the roadmap

The roadmap is a business document. Users don't care about it.

They care about whether the product solves their problem. They care about whether it's fast, clear, and worth coming back to. They don't care that this feature was on the plan since Q1, or that it took three sprints to build, or that the CEO is excited about it.

When product teams forget that, they start building for the roadmap instead of the user. The features ship. The metrics don't move. And everyone is confused about why.

The conflict is real and it happens constantly

Here's what it looks like in practice. The roadmap says build feature X — it's been planned, scoped, and stakeholders are expecting it. Then user research comes back and says feature X isn't what users need right now. They're stuck somewhere earlier in the journey. Feature X won't help them because they haven't solved the prior problem yet.

What do you do?

The wrong answer is to ship feature X anyway because it's on the roadmap. The roadmap is a plan, not a contract. Plans change when the evidence changes.

The right answer is harder: go back to the stakeholders, show them the research, and make the case for changing course. That conversation is uncomfortable. It's also exactly what a product leader is supposed to do.

How to stay user-first when the pressure is on

Three practices that keep the user in the room even when the business pressure is pointing toward the roadmap.

Talk to users regularly, not just at discovery. Most teams front-load research and then execute. By the time they're three sprints into build, the user insights are months old. A short user conversation every two weeks — even informal — keeps you honest about whether your assumptions are still holding.

Make user evidence part of every prioritisation conversation. Not just the data — the actual insight. "Users told us they abandon at this point because they don't understand what happens next" is more persuasive than "activation rate is 40%". The number tells you there's a problem. The quote tells you what the problem is.

Be willing to call out features that don't have a user rationale. Every item on the roadmap should be traceable back to a real user need or a clear business outcome. If it's not, that's worth surfacing before it goes into build — not after.

The hard truth about roadmaps

A roadmap that never changes isn't a sign of a disciplined team. It's a sign of a team that stopped listening.

The best roadmaps evolve because the team is close enough to the user to know when something has changed. That's not a failure of planning — it's the point. You plan so you have a direction. You stay close to the user so you know when the direction needs to change.

Build for the user. Use the roadmap to get there.

This approach is one of the fundamentals that separate good PMs. And if you're navigating stakeholder conversations about changing the roadmap, here's how to hold your position without burning the relationship.