Two years ago a friend of mine got a call from his VP of Sales. He wanted a five-year product roadmap for the annual sales meeting. Every release, every feature, twenty quarters out.
My friend’s first reaction was panic, because nobody can predict five years of product development. So he asked what the VP actually needed. It turned out he didn’t want ideas. He wanted hard dates, locked, something he could hand a client so they’d feel safe signing.
So my friend guessed. Then he stapled a disclaimer to every guess explaining how little confidence he had in it. He published numbers he didn’t believe and told everyone else not to believe them either. The client read it and ran the other way.
That’s the worst of both worlds, and it’s what most of us do. You keep the dates because taking them away starts a fight you can’t win. Then you caveat them into meaninglessness, which teaches your stakeholders to ignore your caveats. What my friend never did, and what nobody told him to do, was write down why he believed any of it. The reasoning behind all twenty quarters lived in his head. Those dates were never commitments and they were never bets. They were numbers.
I’ve spent about thirty years in product, starting at Kentucky Fried Chicken and running through Amazon, Microsoft, and a pile of startups in Seattle. I’ve watched this play out at every size of company. And I’ll own something before I go further: Productside ran a webinar in 2024 telling you to delete the dates from your product roadmap. We gave you incomplete advice. This is my attempt to finish it.
Dates Were Never the Problem
Let’s start with the symptoms, because I think we can agree on them. Roadmaps are release plans in disguise. Dates get treated like contracts signed in blood. Everything on the page is an output. Dependencies blow the plan apart. There’s no visible connection to strategy.
Those symptoms are real. The treatment prescribed for them is where things went wrong.
Two years ago, we shared the ”Now, Next, Later” roadmap that has become standard in Agile Development efforts. Business outcomes across the top, product outcomes sorted into three columns, no dates anywhere. It’s become the centerpiece of nearly all roadmap advice given to product managers over the last several years.
Look at what it really communicates. “Now” means we’re working on it. “Next” means after that. “Later” means sometime. That is the entire timing information content of the document.
Here’s the question we stopped asking and our stakeholders didn’t: what has to happen for something to move from Later to Next? Things move between those columns because we move them, based on reasoning that’s usually sound and almost never shared. So stakeholders ask the only logical follow-up available to them. What’s the date?
The intention behind the format was never bad. The problem is that deleting the dates was presented as the natural outcome of adopting a better framework, and we assumed you and your stakeholders would know how to operate in a world without them. If your company forwards the roadmap to customers, or your VP of Sales sits in your planning meetings, you got run over. And the way that failure feels from the inside is personal, like everyone else figured this out and you’re the one who couldn’t.
It wasn’t an execution problem. Dates were never the problem. A date with nothing documented behind it is the problem.
Nothing Went Stale. Someone Escalated.
The easy story is that everything got faster and nobody can stop it. AI writes the code, build cycles compressed, your twelve-month plan now goes stale in weeks because the machine outran the document.
It’s a good line. The data doesn’t support it.
DORA surveyed roughly five thousand teams last year and found deployment frequency has barely moved since 2023. Nearly half of teams still take more than a week to get a commit into production. There’s even a randomized trial where experienced developers were measurably slower using AI tools while being convinced they were faster.
Your plan isn’t going stale because engineering outran it. It’s going stale because someone escalated. Around 60% of product managers name leadership escalation as the #1 reason their priorities change. Not new evidence from customers. Not changes in the market. Not a competitor shipping something. A person with more authority than you asking for something on a Tuesday that contradicts what everyone agreed to on Monday.
That’s precisely why our 2024 advice couldn’t work. Escalation is a political problem. Now, Next, Later is a formatting choice. You cannot reformat your way out of a VP overriding you. Taking the dates off your roadmap didn’t make you harder to override. It made you easier to ignore.
Here’s the part about HiPPO product management that nobody says out loud. Escalation doesn’t beat you because the executive has more authority. It beats you because you have nothing on the table. When someone escalates, the conversation becomes their request against your judgment, and your judgment is invisible. It lives in your head. So the exchange turns into a contest of confidence, and they win that every time, because they’re asking for something specific and you’re defending something you never wrote down.
Think about what your stakeholder actually sees on the roadmap. A quarter and a name. From their side, that’s a commitment. From your side, it was always a bet. You knew it was a bet. You just never said so anywhere they could read it.
So when the date moves, they don’t experience a revised estimate. They experience a broken promise, and they can’t point to a single document that would have told them otherwise, because there isn’t one. They aren’t being unreasonable. From where they sit, a number with no visible reasoning behind it is indistinguishable from a commitment.
That’s the gap. Not your format. Not your discipline. The reasoning behind every dated item you publish lives in exactly one place, and that place isn’t shareable.
Product Roadmap vs Release Plan
One of the most common mistakes in product roadmap prioritization is building a release plan and calling it a roadmap.
A product roadmap is strategic. It maps strategy visually, communicates direction, aligns stakeholders, and works over the long term. It’s a compass. A release plan is tactical. It feeds the backlog, shapes features and epics, serves the development team, and operates in the near term. It’s a calendar.
One is about outcomes. The other is about outputs. Most of the friction in your stakeholder conversations comes from people using a single word for both artifacts.
This distinction matters more than it looks, because outcomes are conditions you pursue rather than destinations you arrive at on a Tuesday. You might never fully get there. You keep working at it. Putting a date on an outcome is a category error, and it’s a large part of why dated roadmaps feel dishonest even when nobody is lying.
The Opportunity Backlog Is the Product Roadmap Prioritization Framework You Were Missing
You’re going to leave with one artifact. Not a process change, not something you need your VP to approve. A list, in whatever tool is already open on your machine.
You already have a development backlog holding the work you’ve committed to. Your team knows it well. What you don’t have is anywhere to put the things you haven’t committed to yet, which is why every one of those ends up either on your roadmap with a date it never earned, or nowhere at all.
The opportunity backlog is that place. Both your roadmap and your release plan feed from it. Toward the roadmap, an item earns a position and a stated confidence. Toward the release plan, it earns a date. Same source, two artifacts, two different outputs.
The interesting part isn’t the list. It’s the gate, and the gate sits at the back rather than the front.
Most roadmap advice is about defending the roadmap. Say “no” better. Push back harder. Protect the quarter. That advice assumes you have the standing to say “no”. However much you feel like the driver of your product’s destiny, most of us aren’t, and pretending otherwise is how you end up overridden anyway, except now you’ve also spent political capital you needed elsewhere.
So do the opposite.
Getting in is deliberately easy. Two things get an item through the door: a named requester and a stated problem rather than a stated solution. Someone escalates because they want an integration to close a deal. You say yes. It goes on the opportunity backlog today, with their name on it. You’re not rejecting anything. If they hand you a solution, ask what problem it solves and write that down instead. That’s the only friction in the entire intake, and it’s where your pushback belongs.
Earning a date is deliberately hard. Three things:
- An assumption. What must be true for this to work? Not a goal, not a benefit. A statement that could turn out false. If you can’t finish that sentence, you don’t have an opportunity. You have a preference.
- A test. A tiny act of product discovery. Six customer calls. A prototype you never ship. A landing page. An afternoon sitting in the support queue. Small enough to run without asking for a new budget, and pointed enough that it could come back against you. If it can’t come back against you, it isn’t a test. It’s a demo.
- Evidence. What came back, recorded somewhere your stakeholders can read it. Everyone skips this one, because once you know the answer it feels redundant to write it down. It isn’t redundant. It’s the entire asset.
What this buys you is the ability to stop arguing about whether something is important. It’s on the list. Everything is on the list. The conversation moves to what it would take to earn a date, and that’s a conversation you can win, because it’s about evidence rather than authority.
A Tiny Act of Discovery in Practice
Let me show you what this looks like when it’s real.
A product manager I’ve worked with, who I’ll call Suni, had her company president walk up to her desk one morning holding a competitor’s press release. They’d announced a new feature. When is this going on our roadmap?
Notice what he brought her. Not a market need. Not a framed problem. A solution, already built, by somebody else. And Suni felt the pressure, because the person asking outranked everyone she could appeal to.
Here’s what she said instead of yes. “I don’t know yet whether that feature solves a problem our customers have. Give me two weeks to find out and see how it fits our roadmap strategy. If it does, it goes on the release plan and I’ll tell you exactly when. If it doesn’t, we just saved a quarter and didn’t waste the money.”
That isn’t a no. That’s the two gates. The item went on the opportunity backlog immediately with the president’s name attached. It just didn’t get a date.
The assumption: customers have the problem this feature solves. The test: two weeks of customer conversations, plus digging into why the competitor built it.
What came back surprised her. There was no customer signal at all. Nobody was asking for it. And the competitor hadn’t built it because their customers wanted it either. They built it because a different competitor shipped it first. Two companies had spent real engineering capacity on a feature, and neither was solving a problem worth solving.
Suni could prove that, with evidence, in a document the president could read.
Had she simply agreed, two things happen. A quarter goes to matching a competitor, and the strategy gets handed over for free. Best case, you ship the same thing they have. There’s no version of that where you win. Instead, the capacity went to a problem already on the roadmap that they knew was real, and the existing release plan dates held. They shipped something differentiated. And the next time the president considered walking over with a press release, the conversation started somewhere better.
Sorting the Requests You’ll Get This Week
Four things I’ve heard said to product managers recently, and where each one goes.
- “Engineering found a new technology. When does it go on the roadmap?” Opportunity backlog. Same shape as Suni’s story from a different direction. Someone brought a solution and skipped the problem. It sits there with their name on it until somebody can say what must be true for it to matter.
- “We ran six calls. Four of six named it a blocker, and both connectors came up by name.” Release plan. This is the only one that earned a date, and look at how little it cost. Six conversations is about a week. Assumption stated, test run, evidence back, scope narrowed to two named connectors. There’s nothing left to decide, just work to estimate.
- “I need this in the roadmap or I can’t close the deal.” Opportunity backlog. This is the hardest one, because there’s revenue attached and a person who’ll be unhappy with you. But the deal being real doesn’t tell you the problem is real, or that this is the right solution, or how big the work is. Put it on the list today, run the small test, come back in two weeks. Two weeks is cheaper than a wasted quarter and a far better answer than yes or no.
- “Customers keep churning at month three and we don’t know why.” Investigate first. That’s a real problem, stated as a problem, from a named requester. But it isn’t one opportunity. It’s an undefined question that might contain five of them. Drop it on the list as a single item and it sits there forever, because no assumption is specific enough to test. Investigate, find out what’s actually in there, then add the real opportunities individually.
Only one of those four had any work behind it. The other three are legitimate and worth pursuing, and none of them earned a commitment. You can place every one in about ten seconds, without a fight and without saying no to anybody.
Why Discovery Produces a Date
The objection I usually get at this point is fair. Evidence tells me the thing is worth doing. It doesn’t tell me when it ships.
Correct, and that’s the point. Discovery doesn’t predict the future. It defines the work.
You can’t date an undefined thing. Not you, not your architect, not your VP. If you don’t know what the thing is, any number you attach to it is a guess in a costume, and everyone in the room can tell.
So later has no date not because the future is unknowable, but because you haven’t done the work to know what later contains. That reframe matters, because it changes whose problem it is. If the future is unknowable, you’re off the hook and permanently stuck. If the scope is merely unknown, that’s something you can go reduce, and reducing it is the job.
Discovery gives you two things that land in different places. On the roadmap, confidence. You know how sure you are that an outcome is worth pursuing and you can say why it sits ahead of others. Still no date. On the release plan, a date, because you now know what the work is and your team can size it. That isn’t prediction. It’s estimation, and estimation is something product teams are allowed to do.
The date was never something you earned by being more confident. You earned it by learning what the thing was.
Four Roadmap Traps
This fails in four predictable ways, and I’ve watched all four.
- Writing the assumption after you already decided. You know you want the thing, so you reverse-engineer an assumption that supports it. If you can’t imagine the evidence coming back against you, that’s a justification, not an assumption.
- Running a test that cannot fail. Demoing to a friendly customer isn’t a test. Asking whether someone would like a feature isn’t a test. People say yes to everything in the abstract, because there’s no tradeoff in the question.
- Keeping the evidence in your head. You run the calls, you make the right call, and you never write it down because once you know the answer it feels redundant. The written record is the whole asset. Without it you’re back to a contest of authority, and you know how that ends.
- Letting the backlog become a graveyard. Easy to get in, nothing ever moves. Ninety items, nobody looking, and every stakeholder has learned that your backlog means nowhere. You’ve invented a slower way to say no. The fix is a rhythm rather than a rule. Every week or two, pick one item and run one small test. One. Small enough that you’ll actually do it.
One more practical note, since I get asked every time: keep the two backlogs as two separate lists. Discovery in one place, development in the other, and items move between them. They inform each other constantly, and that’s healthy, but they aren’t the same list.
Ten Minutes This Week
Open your release plan. Pick one item with a date on it. Not the easiest one. Pick the one you’d least want a stakeholder to ask you about.
Write down what must be true for that date to hold. One sentence.
Most of you won’t be able to finish it. That’s the point of the exercise, and it isn’t a judgment on you. It’s the gap showing up in your own file.
If you can write it, good. You have your first documented bet. Now name the test.
If you can’t write it, you’ve just learned that the item hasn’t earned its date. It belongs on your opportunity backlog. Move it, and you’ve started the list without a process change, without approval, and without telling anyone.
One item. Ten minutes. Before the end of the week.
Build a Product Roadmap Framework That Holds Up
- If you want the full session, including both live polls, the four traps that kill an opportunity backlog, and the Q&A on where discovery capacity comes from when your team is already committed, watch “Roadmap Rage: How to Answer ‘When Is Later?'”. Kenny Kranseler and Ryan Cantwell work through the requests you’ll get this week and where each one actually belongs.
- If you want to go deeper, not just running an opportunity backlog but building the strategic thinking, frameworks, and business acumen that make your judgment visible before someone escalates, join our Optimal Product Management course. It’s live online and instructor-led, with no more than 20 people per session, so you get real feedback on your own roadmap rather than another course you watch at 1.5x speed.
- What’s your honest answer when someone asks when Later is? Share it on LinkedIn and tag @Productside. We’d love to hear which of the four traps hits closest to home.
