Productside Webinar

Roadmap Rage

How to Answer “When Is Later?”

Date:

09/16/2026

Time EST:

1:00 pm
Watch Now

Delete the dates, they said. Outcomes over outputs. Now, Next, Later. You tried, and your stakeholders came looking for the one thing you took away. So you kept the dates and assumed the gap was your fault. 

It wasn’t. Dates were never the problem. A date with nothing behind it is. Learn how to earn the dates you already publish, using an opportunity backlog you can stand up tomorrow. Then answer the question no framework has: when is “Later”?

 

What You’ll Learn:  

  • Why the outcome-based roadmap playbook failed in practice, and what it left out 
  • The three entry criteria that separate an opportunity ready for a date from a wish 
  • How to run an opportunity backlog alongside your development backlog, without a process change or anyone’s permission 
  • A defensible answer to “when is Next?” that survives a stakeholder review 
  • One exercise to run this week on an item already on your roadmap, to find out whether you can defend it 

 

Welcome and Introductions

Kenny Kranseler & Ryan Cantwell | 00:00:00 – 00:01:35

We can dive in and get started. So, as the title says, we’re going to talk about roadmap rage, or more specifically, how to reduce the amount of rage you have around roadmaps. And really what we’re going to do is answer that question that product managers so often get: when is Later? We’ll dig into all of that, but before we dive in we have some housekeeping to handle. First, let’s introduce ourselves.

I’m Kenny Kranseler, consultant and trainer at Productside. I’ve been here for about seven and a half years. Prior to that, I spent 20 or 30 years as a product manager, product director, product leader, and chief product officer at places like Amazon and Microsoft and a bunch of startups in the Seattle area. I actually started my product management career at Kentucky Fried Chicken, so if you want to know the secret recipe, don’t ask me. I don’t know it.

Ryan Cantwell | 00:01:01 – 00:01:35

I’m Ryan Cantwell, Vice President of Product and Services at Productside. Before this, I got to do great things like Kenny, helping clients as a consultant and trainer. And even before that, I was a real product person, leading product teams and managing complex portfolios of hardware, software, and services. I’m excited to bring those experiences to all of you today.

About Productside

Ryan Cantwell | 00:01:35 – 00:03:13

If you’ve been here with us before, great to see you again. If this is your first time, we’re excited for you to get to know us a little better.

At Productside, what you need to know is that we believe bad thinking kills more products than bad execution. The teams we meet are rarely short on effort and speed. They’re trying really hard. But what they’re short on is the capacity and rigor for the thinking that happens before work starts. That thinking should answer the fundamental questions in product:

  • Who is this for?
  • What problem does it solve?
  • Does it even deserve to exist at all?

AI has made every product team faster. It hasn’t necessarily made any product person out there any righter. That belief is why Productside exists. We’ve spent more than two decades teaching product people to make decisions that survive first contact with whoever is in the room. Our training, assessments, advisory, and services all serve that one idea: your outcomes matter most.

Housekeeping and Community Engagement

Ryan Cantwell | 00:03:13 – 00:04:44

A few quick items before we dive in:

  • Can I watch this later? Yes. You will get a recording link in your inbox after we wrap up, so sit back and enjoy
  • Kenny and I like to keep things informal. Talk to us live, use the chat, or use the Q&A function. Think of this as a conversation between friends. Our team will be monitoring and we’ll answer questions live and in real time
  • We’d love to stay in touch after today. Connect with us on LinkedIn. It’s where we share AI tips and tricks, the ongoing argument about what makes product management work, and a room full of people wrestling with the same problems you are. Scan the QR code or use the link in chat

The Failure of Roadmaps and the Myth of Dates

The Five-Year Roadmap Story

Kenny Kranseler | 00:04:44 – 00:07:54

We’re going to talk about roadmap rage. We’re going to provide a fix for it by talking about what’s been missing, talk a little bit about dates, and then dive into what might be the actual fix: an opportunity backlog.

But before we get to the fix, we owe you something. About two years ago we delivered a webinar on roadmaps and release plans, and countless other product management thought leaders also delivered similar webinars, wrote blogs, and gave hundreds of talks on roadmaps. That content was probably telling you something you couldn’t do. We provided you some incomplete information, and I want to start with a story.

A friend of mine who’s a product manager got a call right around the time we delivered that webinar two years ago. His VP of sales called and asked for a five-year roadmap for his annual sales meeting: every release, every feature, looking 20 quarters out. His first reaction was panic, mostly because nobody can really predict five years of product development.

So he asked the VP what he actually needed. It turned out the VP didn’t want just a bunch of ideas. He wanted hard dates, locked down, something he could hand to a client so they could be assured and sign up. So here’s what this product manager did: he guessed. He tried to guess what the next five years would look like. And then, because they were truly guesses, he stapled disclaimers to every single one of them about how little confidence he had. Then he published the numbers. He didn’t believe in them and he told everyone else they probably shouldn’t either. Potential clients looked at what he presented and ran the other way.

What this product manager shared was probably the worst of both worlds. And unfortunately, it’s what most of us do. You keep the dates on those pages because taking them away starts a fight you probably cannot win, and then you caveat them into meaninglessness, which just teaches stakeholders to ignore any caveat you write.

What he didn’t do, and what nobody told him to do, was write down why he believed any of it. The reasoning behind all 20 quarters lived in his head. So the dates he wrote weren’t commitments and they weren’t bets. They were just numbers that didn’t mean anything.

Common Roadmap Mistakes and the Now Next Later Trap

Kenny Kranseler | 00:07:54 – 00:12:17

What are the mistakes we all make around roadmaps?

Dates are treated like contracts signed in blood. This has been true for product managers for decades. Your stakeholders treat a roadmap like a contract. It’s not a misunderstanding on their part entirely. Your roadmap is disguised as a release plan. It’s all about outputs, with no connection to your product strategy. Every one of these is a real thing happening at real companies.

A lot of folks have shared the concept of a now-next-later roadmap. It has become something of a centerpiece of roadmap advice. Business outcomes at the top. Then now, next, later with product outcomes sorted into each bucket. No dates anywhere.

But what does this tell a stakeholder?

  • Now means we’re working on it
  • Next means we’ll probably work on it after that
  • Later means sometimes

That’s truly the entire information this document provides.

Here’s the question we stopped asking, but our stakeholders never stopped asking: what has to happen for something to move from later to next, or from next to now? Things tended to move between columns because smart product people moved them based on sensible reasoning. But we didn’t tend to share that rationale. So stakeholders asked the next logical question: what’s the date?

It’s not that the intention behind the now-next-later roadmap is inherently bad. Deleting the dates was presented as the outcome of adopting a better framework. But we assumed you and your stakeholders knew what to do next. If your company forwards that roadmap to customers, or your VP of sales sits down at planning meetings with it, you got run over. And the way that failure feels from the inside is like a personal failure, as if everyone else figured out how to make it work and you didn’t.

That’s not what happened. Everyone who tried it and it didn’t work: it was likely not an execution problem. The advice was incomplete. You just didn’t know which part was missing.

Dates, or the lack of them, were never the problem. A date with nothing documented behind it is the problem. Everything I’ll talk about going forward is about that.

You heard from well-meaning product people: delete the dates. What nobody told you was what to put behind them. Your stakeholders came for dates, and taking them away removed the only thing they could act on.

Poll: Biggest Roadmap Challenges

Kenny Kranseler & Ryan Cantwell | 00:12:17 – 00:14:39

Before I go any further, I want to get a sense of where folks are. So we’re putting up a poll. Pick the one that stings the most. What’s your biggest problem with roadmaps?

  • Someone overrides my priorities
  • Annual planning produces a document that’s wrong by spring
  • I publish dates I can’t connect to a strategy
  • I dread when someone asks about Later
  • Honestly, it’s them. It’s not me

That last option makes me chuckle. It’s them. It’s not me. Of course it’s always someone else.

Results: the big one is someone overriding priorities, followed by annual planning producing a document that’s wrong by spring and publishing dates not connected to strategy.

Four of the five here are really the same problem seen from different angles. Publishing an indefensible date, getting overridden, a plan that dies by spring, and dreading the Later question are all downstream symptoms of one thing: the reasoning behind your roadmap isn’t written anywhere.

Someone picked option five. Sometimes stakeholders are the problem. But the point is you’re not going to change them. What you can change is what you give them. That’s really the only leverage you’ve got.

Roadmaps vs. Release Plans

Kenny Kranseler | 00:14:39 – 00:16:53

Let’s talk about what everyone’s been getting wrong about roadmaps. One of the biggest problems is building a release plan and calling it a roadmap. There are really two documents here:

  • A roadmap is about outcomes: the compass telling you what direction you’re going
  • A release plan is about outputs: the calendar about how, when, and where you’ll get there

Most of the confusion in your stakeholder conversations comes from using one word for both artifacts.

Outcomes are conditions you pursue. They are not destinations you arrive at at a certain date. Putting a date on an outcome is a fundamental category error, which is part of why dated roadmaps feel dishonest even when nobody’s lying.

What actually breaks your plan is neither of these documents. It’s the thing that happens on a Tuesday morning.

Think about the last time a date moved and someone was angry about it. Ask yourself: what document could they have read to understand why it moved? Usually there isn’t one. The assumption behind that date, the reason you believed a specific quarter was achievable, the thing you were unsure about: it all lived in your head. You published the output of your reasoning but kept the reasoning hidden. When the date moves, your stakeholder doesn’t experience a revised estimate. They experience a broken promise.

The date isn’t and never was the problem. The problem is the empty space behind that date.

The Real Cause of Stale Plans: Escalations

Kenny Kranseler | 00:16:53 – 00:20:42

The easy story is that everything is getting faster and no one can stop it. AI wrote the code, build cycles compressed, your 12-month plan goes stale in weeks because the machine outran the numbers. It’s a good story. But the data doesn’t support it.

DORA, the DevOps Research and Assessment organization, surveyed about 5,000 product teams last year. Deployment frequency has barely changed. Nearly half of teams still take more than a week to get a commitment 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 is not going stale because engineering outran it. It is going stale because someone escalated.

60% of product managers in a survey named leadership escalation as the number one reason their priorities change. Not new evidence from customers. Not new evidence from the market. Not a competitor’s new products or actions. A person with more authority is asking for something on a Tuesday that’s different from what you committed to on Monday.

That’s why the advice from a couple of years ago could not and would not work. Escalation is a political problem. Now-next-later is a formatting choice. You can’t reformat your way out of a VP overriding you. Taking the dates off your roadmap didn’t make you harder to override. It just made you easier to ignore.

What survives escalation is not a cleaner format or a plan missing dates. It’s a documented bet. Something you can put on the table and say: “Here’s what I assumed. Here’s how I tested it. And here’s what I found.” That’s a conversation. A colored rectangle labeled Later is not.

Here’s the secret about what makes escalation so effective against a product manager: it’s not that the VP has more authority. It’s that you have nothing on the table. When someone escalates, the conversation is their request against your judgment, and your judgment is invisible. It’s in your head. So that argument becomes a contest of confidence, and they will win every time, because they are asking for something specific and you are defending something you never wrote down.

Poll: Why Roadmaps Change Mid-Quarter

Kenny Kranseler & Ryan Cantwell | 00:20:42 – 00:23:16

I showed you that 60% of product managers say leadership escalation is the top reason their priorities change. Let’s find out what’s going on in this room.

Think about the last time your roadmap changed mid-quarter or mid-month. Not a full rewrite at planning time, but a change after you’d already told everybody the plan. What caused that change?

  • Someone senior asked for something different
  • We learned something from a customer
  • Team capacity changed
  • Our roadmap never changes once it’s set

Kenny Kranseler: The product manager I was talking about at the top of the conversation reported to me at the beginning of the year. His roadmap was his masterpiece. It was beautiful until about six weeks later when a salesperson came in and said, “We have the biggest deal we’ve ever gotten. We have to develop these features to close it.” He could just see his roadmap being picked up and torn to pieces.

Ryan Cantwell: Exactly. And what you’re saying is he was close to that roadmap. He had evidence. It was well-researched. But other people didn’t see the trade-off being made. They didn’t understand his rationale, or why things were in place to keep existing committed clients happy rather than chasing a prospect that was maybe 10% committed at best.

Results: the plurality learned something from a customer, with a few others saying capacity changed or someone senior asked. Option three, learning something from a customer, is really the roadmap working as designed: you learn something, you change course. Everything else is the roadmap being acted upon rather than you acting.

The person who escalated may even have been right. And that’s what makes this hard. You can’t beat an escalation by being more disciplined about your format. You beat it by having something on the table when that discussion starts.

The Fix: Implementing an Opportunity Backlog

Introducing the Opportunity Backlog

Kenny Kranseler | 00:23:16 – 00:27:21

So, up to now I’ve talked about diagnosis: what’s the problem and why did it happen? Now let’s get to the part you can act on.

You’re going to leave this webinar with one artifact. Not a framework, not a process change, not something you need your VP to approve. It’s a list. You can start it in whatever tool is already open on your screen. Nobody has to give you permission for that.

The idea is simple. You have a development backlog. It holds the work you’re committed to. Your product owner is working it in Jira or something similar. What you do not have is somewhere to put the things you have not committed to yet, which is why everything either ends up on your roadmap with a date it hasn’t earned or nowhere at all. The opportunity backlog is that place.

And the interesting part: it’s not the list itself that matters. It’s the gate you put at the end of it.

Your roadmap is strategy and your release plan is execution. Both are fed by the same opportunity backlog. That’s the piece that’s been missing.

Watch what the three criteria on either side of this do, depending on which way an item moves:

  • Toward the roadmap: an item earns a position and a stated confidence, not a date. Outcomes don’t get dates. An outcome is a condition you pursue. You might get there, you might never get there. Putting a date on that is a category error, and it’s the reason dated roadmaps feel dishonest even when nobody’s lying.
  • Toward the release plan: an item earns a date because you’ve done some discovery. You’ve defined the work. You know what it is and now you can estimate it.

Three criteria, two outputs. Confidence on the roadmap. Dates on the release plan.

This is how you answer the question in the title of this webinar. When someone asks when is Later, they’re pointing at your roadmap and asking for a release plan answer. They’re different documents. Later is about a roadmap position and the reasoning behind it. The date they want exists once that work crosses over into the release plan, not before. It might seem like a dodge, but it’s really not. It’s the actual structure of the problem, and hopefully it’s the first time you’ve had a place to stand while you explain it.

Creating an Easy Intake, Strict Gate Model

Ryan Cantwell & Kenny Kranseler | 00:27:21 – 00:31:17

A lot of the advice you’ve probably received about roadmaps is about defending it. Say no better. Be more convincing. Push back harder. Protect that quarter. This advice assumes you have the standing to actually say no.

Unfortunately, wherever much you feel like you’re the driver of your product’s destiny, most of us aren’t. Pretending otherwise is how you end up getting overridden anyway. And now you’ve also spent some of your precious political capital.

So do the opposite. Make it trivial to get in.

Someone escalates. They want an integration to close a deal. Put it on the opportunity backlog today with their name on it. You’re not rejecting anything. Two things get in the door: the person who wants it, and a problem rather than a solution. If they hand you a solution, ask what problem it solves and write that down instead. That’s the only friction. The push back is focused on one thing: tell me what problem your proposed solution is actually solving.

The gate is not at the front. It’s at the back. Getting on the list costs nothing. Getting a date costs three things, and those are what we’ll spend the rest of the webinar on.

What this buys you is the ability to stop arguing about whether something is important. If they’re mentioning it, it’s important. It’s on the list. Everything gets on the list. The conversation moves to what it would take to earn a date from that list. And that’s a conversation you can win because it’s about evidence, not authority.

Ryan Cantwell: If a salesperson comes to you and says “A customer wants this great new feature,” and they bring the solution, is it their job to translate that to a problem, or yours?

Kenny Kranseler: If they’re the one bringing the solution, they need to go work with the customer to discover what problem is driving that request. It depends on what the relationship is between sales and the customer, or you and the customer. But somehow the customer has a problem. Find out what it is. I’ve seen product managers make the mistake of turning around to the salesperson and saying “Don’t come back to me until you have a problem.” We need to work together on that. Go back to the customer and ask: this is a great solution, but why do you need it? What are you trying to do that you can’t do today?

Ryan Cantwell: And something unexpected happened for me when I did this as a practicing product manager. I now had an army of people excited about collecting evidence and allowing me to make better decisions. They wanted to go get their things on the release plan. They had learned what it took.The Three Gate Criteria: Assumption, Test, and Evidence

Kenny Kranseler | 00:31:17 – 00:33:37

Write these three things next to any item on your opportunity backlog. Once they’re proven, the proposed opportunity gets a date.

First: an assumption. Not a goal, not a benefit. A statement that could turn out to be true or false. What must be true for this to work? If you can’t finish that sentence, you don’t have an opportunity. You have a preference.

Second: a test. And I want to be specific about the size of that test, because this is where people give up. Run a tiny act of discovery:

  • Six customer calls
  • One prototype you never ship
  • A landing page
  • An afternoon sitting in a support queue

The test has to be small enough that you can run it without asking anyone for a new budget, and pointed enough that it could come back against you. That it could fail. If it can’t come back against you, it’s not a test. It’s a demo.

Third: evidence. What actually came back from that tiny act of discovery, recorded somewhere your stakeholders can read it, not hidden in your head. This is the part that changes your next escalation conversation, and it’s the part most people skip because once they know the answer it feels redundant to write it down. It’s not redundant. It’s the entire asset. It’s the reason for being.

Now why does this produce a date? Not because evidence predicts the future. Nobody can predict the future. It produces a date because it defines the work. You can’t date an undefined thing. The reason Later on your roadmap has no date is not that the future is unknowable. It’s that you don’t yet know what that thing is.

Case Study: Pushing Back Against the HiPPO

Kenny Kranseler | 00:33:37 – 00:36:33

Let me tell you a story about another product manager. I’ll call her Sunny.

It starts like this: the company president walks up to Sunny’s desk one morning holding a competitor’s press release. They’d announced a new feature. The president asks Sunny, “When is that going on a roadmap?”

Notice what the president brought. Not a market need. Not a framed problem. A solution already built by somebody else. Sunny felt pressure in the moment because the person asking outranked everyone she could possibly appeal to. That was the HiPPO: the Highest Paid Person’s Opinion.

Instead of immediately agreeing, here’s what Sunny said: “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 with our roadmap strategy. If it does, I’ll put it on our release plan and tell you exactly when. If it doesn’t, we just saved a quarter.”

It’s not a no. It’s two gates.

The item went on the opportunity list immediately with the president’s name on it. It just didn’t get a date yet.

Then the assumption: what must be true for this to be worth building? Customers have a problem that this new feature solves.

The test Sunny ran was small and fast: two weeks of customer conversations and a little digging into why the competitor built this in the first place.

What she learned surprised her. It wasn’t a customer signal at all. Nobody was asking for this. It turns out the competitor hadn’t built it because customers wanted it either. They built it because another competitor shipped it first. Two companies had spent real engineering capacity on a feature that appeared to solve a problem nobody had. And Sunny could prove it with evidence in a document she could share with the president.

If Sunny had agreed and just built it, two things would have happened. One: a quarter spent matching a competitor and their strategy handed over for free. At best, they ship the same thing the competitor has. There’s no version of that where they win. Instead, the engineering capacity went to a problem already on the roadmap that they knew was real. They shipped something differentiated. And the next time the president considered bringing Sunny a competitor press release, hopefully the conversation started in a different place.

How Discovery Defines Work and Earns Dates

Kenny Kranseler | 00:36:33 – 00:39:55

Here’s an objection I think you might all be having: evidence tells me that the thing is worth doing. It doesn’t tell me when it ships.

100% correct. And that’s because discovery does not 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.

The reason Later has no date is not that the future is unknowable. It’s that you haven’t done the work yet 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 your job.

What does discovery actually give you? Two things, landing in different places:

  • On the roadmap: discovery provides confidence. You know how sure you are that this outcome is worth pursuing and you can say why it sits ahead of other outcomes. Still no date, because outcomes do not get dates.
  • On the release plan: you can now determine a date, because you know what the work is. You can work with your team to define what performing that work involves and what it would take to complete. It’s not a prediction. It’s at least an informed estimate. And an estimation is something product teams are allowed to do.

Same act of discovery, two outputs. The date was never something you earned by being more confident. It was something you earned by learning what that thing was and how valuable it might be.

So when someone asks “when is Later,” here’s what you can say: Later means the item hasn’t earned a date yet. Then immediately follow up with three things:

  • Here’s what we assumed
  • Here’s the test we’re running
  • Here’s when we will make a decision

That last phrase matters. Not “here is when we will know.” You can’t promise to know something by Tuesday. Discovery doesn’t work on a schedule and you’ll get caught overpromising. What you can promise is that on a specific day you’ll make a call with whatever information you have. That’s a commitment you can actually control.

Notice what this does to the dynamics of an escalation. The person asking is not being told no and is not being asked to trust you. They’re being told what has to be true, how you’re checking, and when they’ll get an answer. That’s a conversation between two adults about evidence, not a contest of authority, which was the fight you were likely to lose.

Practical Application and Traps to Avoid

Sorting Real-World Scenarios

Kenny Kranseler | 00:39:55 – 00:42:40

Let me share four things someone said to a product manager this week and we’ll sort them.

Engineering found a new technology and wants to know when it goes on the roadmap. It goes to the opportunity backlog. This is really the same thing as Sunny’s story, just from a different direction. Someone brought you a solution and skipped the problem. It goes on the list with their name on it and stays there until somebody can say what must be true for it to matter.

Six customer calls and four of the six named this as a blocker. Both named the same two connectors. This is the only one of the four that has earned a date. Six conversations, maybe a week to get through. Assumption stated, test run, evidence back, scope narrowed to two named connectors. That’s a release plan item now because there is nothing left to decide. Just estimate it.

Sales needs it on the roadmap or the deal doesn’t close. This is Ryan’s story from earlier. Put it in the backlog. This one’s the hardest because it has revenue attached and a person who might be unhappy with you. But the deal being real does not 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 that tiny act of discovery, and come back in two weeks. Two weeks is cheaper than a wasted quarter, and a much better answer than either yes or no.

Leadership says customer churn at month three and nobody knows why. It’s a real problem, stated as a problem, from a named requester. So why not put it on the backlog yet? Because it’s not one opportunity. It’s an undefined question that might contain five different opportunities. If you drop it on the list as a single item, it will sit there forever because there’s no assumption specific enough to test. Investigate it first. Find out what’s actually in there. Then the real opportunities come out of that and those go on the list individually.

The pattern across all four: only one had any work behind it. The other three are legitimate, all worth pursuing, and none of them have earned a commitment yet. You can place every one of them in about 10 seconds without a fight, without saying no to anybody.

Four Roadmap Traps to Avoid

Kenny Kranseler | 00:42:40 – 00:44:26

The opportunity backlog can be a trap. Here are four ways it all fails.

Writing an assumption you’ve 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 not an assumption. It’s a justification.

Running a test that cannot fail. If you demo something to a friendly customer, that’s not a test. Asking whether someone would like a feature is not a test. People tend to say yes. Would you like some candy? Of course. They’ll say yes to everything in the abstract because there’s no trade-off.

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 an authority contest and you’ll lose. Write it down.

Letting the backlog become a graveyard. This is the one that kills the whole system. If you make it easy to get in and nothing ever moves, you’ll have 90 items nobody’s looking at. You’ve just invented a slower way to say no. The fix is not a rule. It’s a rhythm. Every week or two, pick one item and run a tiny act of discovery. Small enough that you will actually do it.

Action Item: The 10-Minute Exercise

Kenny Kranseler | 00:44:26 – 00:45:33

One thing to do this week, between now and Friday. It’ll take 10 minutes and you might not like the result.

Open your release plan. Pick one item that has a date on it. Not the easiest one. Pick the one you would least want a stakeholder to ask you about. Now write down what must be true for that date to hold. One sentence.

Most of you will not be able to finish that sentence. That’s the point of the exercise. It’s not a judgment on you. It’s the gap I’ve been talking about for the last 35 minutes. It just shows up in your own file.

If you can write it, great. You have your first documented bet. Name the test.

If you can’t write it, you’ve just found out that the item hasn’t earned its date yet. It belongs back on your opportunity backlog. Move it. You’ve started the list without a process change, without approval, without telling anyone.

One item. 10 minutes. Go run that test before the end of the week.

Poll: Next Steps Commitment

Kenny Kranseler & Ryan Cantwell | 00:45:33 – 00:46:56

Last poll. Not what you thought of the webinar: what you’re going to do next.

What are you going to do first?

  • Start keeping an opportunity backlog
  • Write the assumptions behind one dated item
  • Run one tiny act of discovery
  • Bring this to my team before I try it
  • Nothing yet. I need to think about it

Options one through three are all versions of getting started. Any of them is fine. None of them requires permission from anyone else. If you picked option four, that’s an honest answer. A lot of you might not be able to run this alone. Bring it to your team first. And option five is there on purpose. If you’re not going to do anything, just say so. That’s more useful than clicking something aspirational and forgetting it by tomorrow.

Results: some of you are going to start keeping the opportunity backlog, and a couple are going to bring it to their team first. Whatever you picked, the smallest version is the one that actually happens. One item, one assumption, 10 minutes.

Resources and Q&A

Free Resources and Upcoming Programs

Ryan Cantwell & Kenny Kranseler | 00:46:56 – 00:50:10

We’ve been talking about roadmaps and release plans, and we have some free resources for you. Scan the QR codes on screen to get access to our playbook templates:

  • The Strategic Planning Pack will help you decide which items from your opportunity backlog are roadmap-worthy. Some of the templates in there will help you evaluate which opportunities deserve investment.
  • The Feature Prioritization Matrix connects better to your release plan, helping you identify which things will best achieve your strategy and desired outcomes.

Put them together. They work better as a pair.

Upcoming opportunities to learn more:

  • In-person Optimal Product Management in Austin, Texas: coming up in early December. You’ll cover all of this and much more. When you come to live training, the conversations during lunch and after hours are where the real learning compounds.
  • Upcoming webinar on AI strategy in product management: coming up in a couple of weeks with Dean and Cynthia. Product people are under a lot of pressure when it comes to AI, both using it and building it into products. This session will give you a framework for starting to think about it and work with it better.
  • Live online Optimal Product Management courses: Kenny is doing one in October and November, Dean has another in December. Lots of formats and time zones available.
  • AI Product Management courses: if you want to go deeper on AI and its application in product management, one of those starts next week. Not too late to join.

Q&A: Managing Discovery Capacity

Kenny Kranseler & Ryan Cantwell | 00:50:10 – 00:52:38

Question:
Where does the two-week discovery capacity come from when a team is already fully committed to the release plan?

Kenny Kranseler:
First: make it small enough that it doesn’t require much capacity. You may even be able to do it yourself with minimal help from one other person. You’re not necessarily committing the whole team to that tiny act of discovery. Just a small subset. Find a way to get it done.

Ryan Cantwell:
The two weeks isn’t a concrete rule. What’s important is finding the path of least resistance to learning. Most agile sprint cycles I see are two weeks, so it’s easy to say: we’re committed to this sprint, but let me use this period to learn something before we make the next decision. Find a small window you can carve out for discovery that’s low-cost and low-resource. Figure out how long it will take you to do that discovery, then provide that date as when you’ll get the answer back and make the call.

Kenny Kranseler:
The key question is: what’s the least I can do to learn the most, so I can be confident taking the next step? And if your assumption is very large, break it down. Digest it into smaller pieces and work your way up.

Q&A: Tooling for Opportunity vs. Development Backlogs

Kenny Kranseler & Ryan Cantwell | 00:52:38 – 00:54:24

Question:
If we’re using Jira for development backlogs and Productboard or Aha for roadmaps, are discovery and development separate things? Is there a relationship between them?

Kenny Kranseler:
Keep them separate. Two separate lists. Something sits on the opportunity backlog until you have enough information to move it to the release plan. Then it goes into the development backlog. Don’t treat it as one board with two fields. This is two separate boards. One might sit in Productboard and one in Jira. Or if you’re using Excel, have different spreadsheets for each. Keep them separate because they are two separate lists.

Ryan Cantwell:
And what’s really important to know is that they inform each other. Your opportunity backlog, as you’re learning, informs what goes into discovery work. As you’re working through discovery, sometimes new opportunities come up that you didn’t expect, and those come back over to the opportunity backlog. A finding in the middle of development doesn’t automatically become another item on the development backlog. It becomes another opportunity for discovery, and something to put on the backlog to figure out what you’re going to do with it going forward.

Closing Remarks

Kenny Kranseler & Ryan Cantwell | 00:54:24 – 00:54:59

Thank you everybody for attending. Hopefully you’ve picked something up from this webinar. You’ll probably have an opportunity to rate it, so please do that. And if there are chances for you to join us in future webinars or training, please do. There’s a lot more where this came from. Thanks everyone and have a great rest of the day.

Webinar Panelists

Kenny Kranseler

Kenny has led product teams from KFC to Amazon to Seattle-based startups. He has the range and strategic insight to differentiate what works from what doesn’t.
LinkedIn

Ryan Cantwell

Ryan Cantwell helps B2B teams align strategy and execution. With energy, clarity, and storytelling, he makes product thinking contagious at Productside.
LinkedIn

Webinar Q&A

Product roadmap prioritization is the process of evaluating validated opportunities, deciding which ones move forward, sequencing them by relative readiness and business value, and communicating that sequence with enough context that stakeholders trust the answer. Stakeholders ask “when is later?” because most roadmaps give them a direction without giving them the evidence behind it. When “later” has no documented assumptions, no win conditions, and no visible prioritization criteria attached to it, it reads as a placeholder rather than a decision. Productside’s Dean Peters and Rina Alexin address this directly: the problem is rarely that a roadmap has dates or horizons. The problem is that the reasoning behind those dates is invisible to everyone outside the product team.
An opportunity backlog is a structured collection of customer and business problems that have been identified and are being evaluated for prioritization, before any commitment to building a solution is made. A development backlog, by contrast, contains work that has already been decided and is moving toward implementation. The distinction matters because mixing the two creates one of the most common roadmap dysfunctions: stakeholders see an item on the backlog and assume it has been committed to, when it has only been identified as worth exploring. Productside’s framework treats the opportunity backlog as the layer where discovery, assumption mapping, and prioritization happen, so that only validated, sequenced opportunities cross into the development backlog with clear evidence behind them.
Product roadmaps can include dates when those dates are supported by documented assumptions, prioritization evidence, and readiness criteria that stakeholders can see and challenge. The problem is not dates themselves. The problem is treating an unsupported estimate as a commitment, and then being unable to explain the reasoning when a stakeholder pushes back. Productside’s approach gives product managers a concrete defense: if someone asks “when is later?”, the answer is grounded in the opportunity’s position in the prioritization stack, the assumptions that would need to be true for it to move forward, and the evidence currently in hand. That answer is far more durable than a quarter label on a slide, because it shows the work rather than just the conclusion.
A Now Next Later roadmap organizes product priorities by relative time horizon rather than fixed calendar dates, communicating direction and sequence without making delivery commitments that are not yet supportable. “Now” covers work actively in progress. “Next” covers validated opportunities being prepared for development. “Later” covers identified opportunities that are not yet ready to sequence because assumptions are still being tested or priorities have not been formally set. Product teams should use this format when the cost of a wrong commitment is high, when discovery is still actively shaping priorities, or when stakeholder trust has been eroded by missed dates. The format does not avoid accountability. It shifts the accountability to the right question: not “when exactly?” but “what has to be true for this to move forward?”
Product roadmap prioritization works best when it is treated as a visible, evidence-based process rather than a decision that happens behind closed doors and gets announced as a slide. Productside’s framework connects each roadmap item to the customer problem it addresses, the assumptions that support it, the win conditions that define success, and the current evidence level. When stakeholders can see that framework, a reprioritization conversation changes shape: instead of “you moved my feature,” it becomes “here is what changed in the evidence, and here is how that shifted the sequence.” Communicating roadmap changes without losing credibility requires two habits: keeping the opportunity backlog current and visible so nothing disappears without explanation, and setting clear criteria upfront for what would cause a priority to move, so a change in sequence reads as the system working rather than as a broken promise.