How to Prioritize a Product Roadmap When Everyone Wants Something

• Scoring every request doesn’t settle roadmap arguments. Ranking forty items still tells thirty-six people “later,” which they hear as “yes, eventually.”
• Now, Next, Later only works once you add a fourth list, Not Now, with a written reason beside every item on it.
• Cap Now at three outcomes or fewer. The cap turns every new yes into a visible swap.
• A good reason names a goal, a missing piece of evidence or a dependency. “We’re slammed” isn’t a reason, so the request comes back next week.
• Every Not Now item also needs the condition that would bring it back. If you can’t write one, the honest answer is no.
• Send a one-page decision record to the people above you, so they see the trade and not just the list.

Sales wants the integration a prospect mentioned on Tuesday. Your biggest customer wants a custom report by the end of the month. Someone above you saw a competitor’s AI feature and wants to know why you don’t have one. And you’ve got three ideas of your own that you still think matter more than any of them.

Every one of those requests is reasonable. That’s the problem. Reasonable requests don’t get turned down, they get added, and a roadmap that only grows stops being a plan. It becomes a wishlist, and every stakeholder meeting turns into a negotiation over whose wish moves up.

Most advice on how to prioritize a product roadmap reaches for a scoring model at this point. Score each request on reach, impact, confidence and effort, sort the list, build from the top. Scoring is useful for comparing things that arrive in different shapes. But it doesn’t settle the argument, because nobody in that meeting is disputing the score. They’re disputing that their item sits below the line.

A ranked list of forty items, of which your team can build four, tells thirty-six people “later.” They hear “yes, eventually.” So they keep asking, and they’re right to, because nothing on the list has ever been told no.

The format most small teams land on is Now, Next, Later: three columns instead of a timeline. Janna Bastow, who invented it at ProdPad, puts the logic in one line: “The Now column is definite, while the Later column is full of possibilities.” Work gets less certain the further right it sits, and nothing carries a date it can’t support.

That’s a real improvement on a Gantt chart. But the three columns only record how sure you are about the things you’ve said yes to. None of them records what you’ve decided against, which is what everyone in the stakeholder meeting actually wants to know.

So add a fourth list, Not Now, and give the whole roadmap two rules. Now has a hard cap. And nothing goes into Not Now without a reason written beside it. Everyone already has the template. The rules are what make the roadmap defensible.

Pick a number for Now and don’t move it. For a small team, three outcomes is plenty, and one or two is often more honest. Base it on how many things the team can actually finish at the same time, not on how many things feel important. Those are different numbers, and the second one is always bigger.

The cap counts outcomes, not tickets. “Cut no-shows” is one Now item even if it takes twelve tasks. “Add a button to the settings page” isn’t an outcome. It’s a task looking for one.

Here’s why the cap matters more than any scoring model. Without it, saying yes is free. Each new request slides onto the list, and the cost shows up months later as everything being late. With a cap, every yes has a visible price, paid in the same meeting:

• To an executive: “Yes, we can do that now. Which of these three should come out to make room?”
• To sales: “If this deal needs it, bring it to the next review against the import work and make the case there.”
• To your biggest customer: “It’s not in our next release. Here’s what is, and here’s what would change that.”
• To yourself: the same question. Your own ideas don’t get to skip the line because you’re the one holding the pen.

None of those is a refusal. You aren’t the person saying no. The cap is. Your job is to show the trade and let the person asking decide whether it’s worth it. Faced with a specific swap rather than an abstract “later,” people often decide it isn’t.

A Not Now list without reasons is just a slower no. The requester can’t argue with it or strengthen their case, so they escalate.

Good reasons are specific enough that someone could disagree with them. Most fall into one of five kinds:

• Different goal. It serves something you aren’t working toward this quarter.
• One voice. One customer asked, and you haven’t heard it from a second.
• Out of order. It depends on something that isn’t built yet.
• Cheaper answer. A process change, an export or a tool you already pay for covers most of the need.
• Can’t tell if it worked. Nobody can say what would change for the user, or how you’d know.

Bad reasons sound like “not a priority,” “we’re slammed” or “maybe next year.” They’re true and useless. They don’t say what the request is up against, so it comes back next week with a louder sponsor.

Then add the return condition: the specific thing that would move the item back onto the roadmap. A second customer in the same industry asks. The import work ships. A return condition tells the requester exactly what evidence to bring, which turns an argument into something they can go and do.

Illustrative example: a Not Now list for a booking product

This company is fictional: a small team selling online booking software to independent hair salons. It doesn’t describe a Rigoris client or a real product. Now holds three outcomes: cut no-shows with text reminders, let salons import their existing client list, and stop double-bookings. Here’s what’s waiting, and why.

Every row can be argued with. That’s the point. The sales lead now knows exactly what to bring to the next review, and nobody has been told their idea is bad.

There’s a serious argument that you shouldn’t. Basecamp’s Shape Up, Ryan Singer’s book on how the company plans product work, argues against keeping a central backlog. Ideas pile up, tending them eats time and the team feels permanently behind. Its answer is blunt: “Really important ideas will come back to you.”

For a team that sets its own priorities, that’s fair. For a sponsor, it breaks down. People will ask, in three months, what happened to their request, and “it’ll come back if it matters” isn’t an answer you can give a vice-president or a paying customer.

So keep the list, but treat it as a record of decisions, not a backlog to groom. Keep it short. And when you can’t write a return condition for something, stop calling it Not Now. You’ve already decided. Say no, say why and take it off. A clear no is kinder than a not-now that never arrives.

The roadmap shows what you chose. It doesn’t show why, and the why is what the people above you get asked about when you aren’t in the room.

Software teams worked out a version of this years ago. In 2011, Michael Nygard proposed on the Cognitect blog that teams keep short architecture decision records, a page or two each, capturing the context, the decision and its consequences. Without them, a later team either blindly accepts a choice whose reasons have expired or blindly reverses one whose value it can’t see. Roadmap decisions have exactly the same problem.

After each roadmap review, write one page and send it to whoever has to defend the plan. Five parts:

• The decision. The items in Now, one line each, with the outcome each one should move.
• What we considered instead. The two or three serious alternatives, including at least one that someone senior wanted.
• What we’re assuming. The beliefs that would change the plan if they turned out to be wrong.
• What’s deferred, and why. The Not Now items people will ask about, with their reasons.
• What would change it. The return conditions, and the date of the next review.

The main reader is the executive who missed the meeting. They can see the trade without reopening it, and repeat it accurately to their own board. It also protects you. Six months from now, when someone asks why you didn’t build the integration, the answer won’t depend on your memory.

If this sounds like scoping, it is. The mistake that sinks a fixed-price project, agreeing to work nobody has defined, sinks roadmaps too. We made that argument about contracts in fixed price vs hourly. A roadmap is the same discipline applied every month instead of once.

This is close to how we run roadmap work ourselves: a small committed horizon, a shaped next one, a later list and a visible Not Now list, revisited when the evidence changes. The longer version of that process is on our product roadmap page.

It also helps to raise the quality of what comes in. A one-line request is hard to weigh against anything. One that says what the person is trying to achieve, and why the workaround falls short, can be compared honestly. We wrote the requester’s side of that in how to write a feature request that actually gets built. It’s worth sending to your sales team.

Open the current roadmap. Circle the three outcomes that belong in Now. Move everything else into Not Now, and write one sentence of reason and one return condition beside each item. Anything you can’t write a return condition for, mark as no.

Then send the one-page record before the meeting, not after. The first time someone asks why their item isn’t there, you’ll point at a sentence instead of starting a negotiation.