The best roadmap I ever built was mostly a list of things we weren't building

If you have searched for a product roadmap template, you probably already have a roadmap. What you don't have is agreement.

That is worth separating out before you download anything. A template solves a formatting problem. Almost nobody has a formatting problem.

There are four things you can build.

The thing you want to build.

The thing you should build.

The thing you shouldn't build.

And the thing people are asking you to build.

Most roadmaps show the first one and label it the second. That is the mistake, and it is almost impossible to spot from the inside, because the thing you want to build and the thing you should build feel identical when you are the person who thought of it.

They are, by design, a list of good intentions arranged left to right. Which is useful, as far as it goes.

If you are building on your own, it goes quite a long way. A roadmap keeps you structured. It stops you running ahead and building the thing you really want to build before anyone has asked to use it. That is a real service and I would not talk you out of it.

If you are an organisation, it does something different. It tells everyone what you are trying to achieve now and roughly where it is going. Also useful. Also, mostly, the reason people go looking for a template.

Here is what it does badly.

A roadmap is very poor at communicating what you are not going to build.

Everything on it reads as a promise. And there is a quiet assumption baked into the far right-hand column that you will eventually arrive at something a person mentioned six months ago, in a meeting, with some confidence, before anything had been tested.

You won't. You shouldn't. But nothing on the roadmap says so, and so it sits there accruing expectation.

It is worth taking the word literally for a moment.

A map is not fixed. A new road opens. A building goes up where there was a field. The map gets redrawn, and the route you had planned changes — not because you lost your nerve, but because the ground moved.

A roadmap should behave the same way. Infrastructure shifts. New points of interest appear, and most of them are put there by users rather than by the room. Which means the destination is held firmly and the route is held loosely. A template will not help you tell those two apart.

There is a related trap that costs more.

It is very easy to build the thing you think will pay you first.

But what matters more — being paid, or finding out what people will pay you for? Those are not the same project, and confusing them is expensive. Most people do not want another piece of software to install. There has to be genuine pain in the process as it currently stands, and a genuine belief that you will remove it. Anything less than that is a nice-to-have, and nice-to-haves do not survive a budget conversation.

You only find that out by watching what people actually do with what you have built.

In my experience it is almost never the thing you thought. They will use a feature you considered secondary. They will ignore the part you spent three months on. They will describe your product back to you using a word you have never used, and that word is usually the one you should have been leading with.

One more, because it wastes more time than anything else on this list.

Don't get stuck in the epic. The subscription model before anyone has subscribed. The onboarding flow before anyone has onboarded. The elaborate educational workflow explaining a feature that nobody has yet asked to use.

Give people the feature. Don't tell them how to use it. Watch what they need to know, and then build the thing that tells them.

What to do instead of downloading a template

Open the thing your team actually looks at. The Notion board, the Jira epics, the spreadsheet, the Miro frame covered in stickies.

First, check it is a roadmap at all. A backlog is everything anyone has ever asked for. A roadmap is the small number of those things you have decided to do, and roughly when. If yours has ninety items on it, you have a backlog wearing a roadmap's name, and that is your actual problem.

Then add a second column and head it: Not now — and here's why.

Move at least three things into it. Not the obvious ones. The ones with someone's name attached.

Then have the conversation that column exists for. Agree with your team, and with whoever sits above them, what is still only an idea. Agree what would move something out of the backlog and onto the roadmap — a number of customers asking, a deal that depends on it, a support cost you can actually measure. Without that threshold, things arrive by persistence rather than evidence.

And be clear about where you are heading, because there is always more than one way to get there. Any map will show you three routes to the same town. Sketching the alternatives early is worth the hour: it turns your chosen route into a decision rather than an assumption, and when the ground moves you already know what the other options were.

If you can't fill that Not now column, the roadmap isn't your problem. Nobody has agreed what you're not doing, and no template will get you that agreement.