Honesty Scales Better Than Certainty: Why Time-Based Roadmaps Are Promises You Can’t Keep

Every quarter, the same scene plays out in product organizations around the world. A Product leader stands in front of the leadership team with a roadmap. Sometimes a Gantt chart. Sometimes a tidy set of quarterly columns. Other times, it is a Kanban-style board with Q1, Q2, Q3 headers. The format varies. The outcome does not. Everyone nods. Everyone feels reassured. And three months later, that same Product leader is apologizing for the fact that half of it didn’t happen.

The problem is not execution. The problem is that any roadmap structured around time turns strategic intent into implicit promises, and the entire organization then optimizes around keeping those promises, rather than around building the right things. The 2026 State of B2B Product Management survey found that 41% of teams use quarterly time-based roadmaps, another 9% use sprint or monthly timelines, and 8% use specific date-driven delivery charts. Add those up: roughly 58% of the industry is still organizing product work around calendar slots. Only 27% have moved to Now-Next-Later. That means the vast majority of Product teams use formats that structurally produce broken commitments.

We invented the Now-Next-Later roadmap because Simon and I watched smart, capable Product teams get crushed by formats that reward false precision over strategic clarity. The argument here is simple: honesty scales better than certainty. Organizations that communicate what they know (and what they don’t) make better decisions, build more trust, and ship better products than organizations that perform confidence they do not have.

Why Time-Based Roadmaps Feel Comforting but Mislead

Time-based roadmaps are popular because they answer the question every executive wants answered: “When?” A Gantt chart with features slotted into Q2 and Q3 gives the illusion of control. A quarterly roadmap with big friendly columns gives the illusion of flexibility. Both look like a plan. Both feel like a commitment. And that is precisely the problem.

The quarterly roadmap: the friendliest trap

Gantt charts get a lot of criticism, and they deserve it. But the quarterly roadmap is the format that actually catches the most teams, because it looks so reasonable. Three or four columns. Big, open spaces. No exact dates. Just “Q1,” “Q2,” “Q3.” It even looks a bit like a Now-Next-Later if you squint.

The difference is structural and it matters enormously. A quarterly roadmap organizes work by when. A Now-Next-Later roadmap organizes work by priority order of problems to solve, sequenced by confidence level.A quarterly roadmap says “we plan to do this in Q2.” A Now-Next-Later roadmap says “this is the next most important problem, and we are currently exploring solutions.” One is a time commitment dressed in casual clothes. The other is a strategic statement about what matters and how certain we are about the path forward.

The moment an item sits in the Q2 column, every department reads it as “shipping in Q2.” It does not matter that the Product leader meant “we hope to start exploring this in Q2” or “this is roughly Q2-ish.” The column is a timebox, and timeboxes are read as deadlines. The quarterly roadmap inherits every pathology of the Gantt chart while looking modern enough to escape criticism.

The comfort of false precision

Any time-based roadmap provides the psychological comfort of certainty in an environment that is fundamentally uncertain. Nobody knows what they will learn three months from now. Nobody knows which customer need will suddenly become urgent, which technical assumption will collapse, or which market shift will change the calculus entirely.

Marty Cagan has written extensively about how roadmaps become de facto commitments the moment they are shared, regardless of the caveats stapled to the front page. It does not matter how many disclaimers you add. The moment a feature appears on a Q3 column (or a “Q3” section, or a “H2 2026” bucket), every department treats that time period as a ship date. Sales starts promising it. Marketing starts planning campaigns around it. Customer success starts telling unhappy customers to hold on. The disclaimer evaporates; the expectation remains.

Certainty theater erodes trust faster than honesty

The cruel irony of time-based roadmaps is that they should build trust, but they systematically destroy it. A Product leader who presents a quarterly roadmap in January and then revises it in April looks like they failed to deliver. A Product leader who communicates honestly about confidence levels and problem priorities from the start never creates the expectation that needs to be walked back.

This is a pattern that compounds over time. Each missed “deadline” (which was never a deadline, but the format made it look like one) erodes a little more credibility. After a few quarters, the rest of the organization stops trusting the roadmap entirely, and starts treating Product as a team that can’t keep promises. The problem was never the team. The problem was a format that manufactured promises nobody should have been making.

How Timeboxing Distorts Prioritization

The damage caused by time-based roadmaps runs deeper than missed expectations. When every item on a roadmap carries an implied delivery window (whether that window is a specific date or a quarter), the entire system of prioritization warps around protecting those windows, rather than around maximizing outcomes.

The vicious cycle of buffers and Parkinson’s Law

Every Product Manager who has worked with a time-based roadmap knows the buffer game. Estimates include padding because nobody wants to be the one who misses a quarterly target. That padding becomes the new baseline. And then Parkinson’s Law kicks in: work expands to fill the time given for its completion. Teams that receive generous estimates use all of them. The buffer disappears. Bigger buffers get added next time. And so the cycle spirals.

ProdPad’s own analysis of the vicious cycle of timeline roadmaps describes this pattern in detail: the added pressure of stacked delivery dates results in a cycle that makes it progressively harder to work in a lean way. Scope creeps in to fill allocated time. Procrastination sets in for anything with a far-off due date. And the teams that should be running fast, small experiments are instead locked into large, time-committed feature builds with no room for course correction.

Quarterly roadmaps are especially vulnerable to this. The quarter itself becomes the timebox. Teams fill the quarter. Work that could have shipped in six weeks stretches to twelve because the column said Q2, and Q2 runs until June.

Timeboxing kills discovery

The most insidious effect of time-based organization is that it crowds out discovery entirely. When a team has committed (even implicitly) to shipping Feature X by the end of Q2, there is no time or incentive to discover that Feature X might be the wrong solution to the problem. The timebox creates a gravitational pull toward output. Ship the thing. Hit the quarter. Move on.

This is how feature factories are born. Teams stop asking whether the work is the right work and start asking whether the work will be done on time. The roadmap becomes a to-do list, and the to-do list becomes the strategy. The original intent behind the feature (a customer problem, a business outcome) gets buried under the urgency of the calendar.

Backlog gravity distorts what gets built

There is another, quieter distortion that time-based roadmaps create. Items that have been on the roadmap the longest accumulate organizational weight. Stakeholders have been told about them. Customers have been promised them. They start rising through the backlog not because they are the highest-impact work, but because they have been there the longest. I call this “backlog gravity,” and it is one of the most reliable ways to ensure that a Product team is building yesterday’s priorities instead of today’s.

A quarterly roadmap makes this worse because items that slip from Q1 to Q2 feel like they are “overdue.” They acquire urgency from their failure to ship on schedule, not from any fresh assessment of their strategic value. The team spends the next quarter paying down roadmap debt rather than working on the highest-impact problems.A lean, outcome-based roadmap disrupts this pattern because items are framed as problems to solve and strategic bets to make, rather than as features owed to someone on a schedule. When an item on a Now-Next-Later roadmap no longer serves an active OKR, it gets deprioritized or dropped, regardless of how long it has been on the list. The roadmap serves the strategy, rather than the other way around.

Priority Order of Problems, Not Calendar Slots

The core distinction between Now-Next-Later and every time-based format (Gantt, quarterly, monthly, sprint-aligned) is the organizing principle. Time-based roadmaps organize work by when it will happen. Now-Next-Later organizes work by which problems matter most, sequenced by how much we know about them. That difference sounds subtle. It changes everything.

What the columns actually mean

Now-Next-Later columns are not disguised quarters. They are confidence horizons.

Now contains the problems the team is actively solving. These initiatives are validated, scoped, and in progress. The team has done enough discovery to be confident they are working on the right problem with a viable approach. If there are genuine external deadlines (a regulatory window, a contractual obligation), they attach here, to specific initiatives, because this is where certainty lives.

Next contains the problems the team is preparing to solve. The problem is well-defined. The team is exploring solutions, running discovery, and testing assumptions. They are not yet ready to commit to a specific approach, which is exactly why these items should not carry a delivery date.

Later contains the strategic bets the team believes will matter, but that need significantly more discovery before they are ready to move forward. These are the problems on the horizon. They might shift. They might get dropped entirely if the team learns something that changes the calculus. Putting these in a Q3 or Q4 column would be dishonest, because nobody has enough information to make that call yet.

The organizing question is never “what quarter does this fall in?” The organizing question is “how important is this problem, and how much do we know about solving it?” That question produces a fundamentally different roadmap, one that invites conversation about confidence and evidence rather than conversation about dates.

Why this matters for how teams work

When the roadmap is organized by problem priority rather than time, the team’s daily work changes. There is no “Q2 crunch” because there is no Q2 column creating an artificial deadline. Items move from Later to Next to Now as discovery progresses and confidence increases, not because a calendar date is approaching. The pace of the work is determined by learning, not by the quarter boundary.

This also changes how teams handle surprises. When a new, urgent customer problem surfaces, a time-based roadmap creates a crisis: something in the current quarter has to get bumped, and that bump cascades into the next quarter, and the quarter after that. The entire schedule unravels. On a Now-Next-Later roadmap, the team re-evaluates priorities, moves the new problem into Now if it warrants it, and adjusts Next accordingly. No cascading schedule changes. No apologetic email to stakeholders explaining why Q2 is “slipping.” The roadmap reflects reality because it was always designed to.

Using Dates as Constraints, Not Commitments

The argument against time-based roadmaps is sometimes misread as an argument against all dates, everywhere, in all contexts. That is not the point. Dates are valuable when they represent genuine external constraints. They become destructive when they are the structural backbone of the entire roadmap.

Where dates belong

Some dates are real. A regulatory deadline is real. A compliance window is real. A contractual obligation tied to a customer renewal is real. An annual conference where a product capability needs to be demonstrated is real. These are compelling constraints, and they deserve to be tracked explicitly.

The difference between a roadmap and a release plan is critical here. The roadmap is a strategic communication tool. It describes the problems you are solving, in what order, and why. The release plan is a tactical delivery schedule. It tracks the dates, dependencies, and resources for work that has been scoped, validated, and committed to. The two documents serve different audiences, answer different questions, and should live in different places.

When teams conflate these two documents (as every time-based roadmap format does, whether by design or by implication), every strategic intent inherits a delivery window, and every delivery window inherits strategic significance. The result is a document that is too rigid to be a good strategy and too vague to be a good plan.

How Now-Next-Later handles real deadlines

In a Now-Next-Later roadmap, genuine time constraints attach to the OKR or the initiative, not to the format itself. If a regulatory deadline requires a capability by a specific date, that deadline lives on the objective. The initiative linked to it sits in the Now column because it is validated, scoped, and actively in progress. The date is visible. The constraint is respected. And the rest of the roadmap remains free to flex as learning unfolds.This is the structure Marty Cagan calls high-integrity commitments: commitments made only after the team has done enough discovery to understand what they are actually committing to. In ProdPad, this works through the OKR-to-roadmap connection, where every initiative traces back to a business objective, and the objective carries the commitment. The roadmap shows the plan. The OKR carries the accountability. The horizon shows honest certainty.

The dual-direction view for commercial stakeholders

One of the most common objections to dropping time-based roadmaps comes from commercial teams. Sales leaders, business development managers, and account executives want to know when features will ship because they have made promises of their own. This is a legitimate concern, and ignoring it is how Product teams end up isolated from the rest of the business.

The answer is a dual-direction view. Looking at any initiative on the roadmap, a commercial stakeholder can see which business outcomes it contributes to. Looking at any OKR, they can see every initiative that is meant to move the needle, and where each one sits on the horizon. If all the initiatives supporting a year-end revenue target are sitting in Later, that is a visible, actionable signal to course-correct. No status meeting required.

This is a fundamentally different conversation than “When will Feature X ship?” The question becomes “Are we on track to hit our target?” That is a better question with a more useful answer.

What Leaders Should Ask Instead of “When”

The question “When will this ship?” feels natural. It feels like good governance. It feels like holding the team accountable. In practice, it is a question that optimizes for the wrong thing. It optimizes for delivery windows rather than business outcomes. And it trains Product teams to communicate in a language of certainty they do not possess.

From “when” to “what outcome”

The most effective Product leaders I have worked with have retrained themselves (and their stakeholders) to ask different questions. Instead of “When will we have the new onboarding flow?”, they ask “What are we doing to reduce churn in the first 30 days?” The first question drives toward a date. The second drives toward a goal with multiple possible paths.

This shift has structural consequences. When the goal is a date (or a quarter), the team optimizes for shipping the thing as specified. When the goal is an outcome, the team has permission to experiment, learn, and change direction if the first approach does not work. They might discover that a simpler change to the existing onboarding flow moves the metric more than a ground-up rebuild. They might learn that the churn problem is actually a pricing problem, not a UX problem. None of these discoveries are possible if the team is locked into a feature in a quarterly column.

Five questions that replace “when”

Product leaders and executives who want to govern effectively without creating a culture of false precision can start with five replacement questions.

“Which business outcome does this serve?”

Every initiative on the roadmap should connect to an OKR or strategic objective. If it does not, it probably should not be on the roadmap. This question forces specificity: not “we’re building search improvements” but “we’re improving time-to-value for new enterprise users, measured by a reduction in support tickets in the first 14 days.”

“Where does this sit on the horizon, and why?”

The Now-Next-Later horizon communicates confidence level and problem priority, not delivery date. An item in Now is validated, scoped, and in active development. A Next item has a clear problem definition and the team is exploring solutions. A Later item is a strategic bet that needs more discovery. Asking where something sits (and why) gives leaders a realistic picture of certainty without forcing false precision.

“What have we learned so far?”

This question centers the conversation on discovery and evidence. It invites the team to share what customer research, experiments, or data have informed the current plan. It also creates a natural opening to change direction: if what the team has learned suggests a different approach, the conversation supports that pivot rather than punishing it.

“What would need to be true for this to move to Now?”

This is a forward-looking question that surfaces blockers, dependencies, and risks without demanding a date. It might reveal that a Later initiative needs a technical spike, or that a Next initiative is blocked on a decision from leadership. It makes the path forward visible without creating a time-based promise.

“Are we on track for the objective, even if the plan has changed?”

This is the question that replaces quarterly roadmap reviews. Instead of checking whether the features were shipped on schedule, it checks whether the business outcomes are on track. The features are a means to an end. If a team has changed its plan three times but is hitting the Key Results, that is a success. If a team has shipped everything on the original plan and the Key Results have not moved, that is a failure, regardless of how punctual they were.

The System Dynamics Behind Honest Roadmaps

Understanding why time-based roadmaps persist requires looking at the system, not the people. Nobody is trying to mislead anyone. The format itself creates incentives that drive behavior in predictable, damaging directions.

How the format shapes the conversation

A time-based roadmap assumes a level of certainty that decreases the further out you look. But the visual format does not degrade. A feature in Q4 looks just as solid on the quarterly roadmap as a feature in the current sprint. There is no visual cue that says “we are 80% confident about this one and 15% confident about that one.” The format treats all items as equally certain. Gantt charts inherited this from manufacturing and construction, where scope is fixed and unknowns are small. Quarterly roadmaps inherited it from Gantt charts, swapping months for quarters but preserving the same structural assumption. Product development is the opposite environment: scope is flexible, and unknowns are large.

Now-Next-Later encodes uncertainty directly into the structure. Items move from Later (fuzzy, exploratory) to Next (problem defined, solution being explored) to Now (validated, in active development). Stakeholders can read the confidence level from the column position. There is no ambiguity about which items are commitments and which are bets. And because the columns represent problem priority rather than time, the question the roadmap answers shifts from “what ships when” to “what matters most and what are we doing about it.”

Why organizations resist the switch

The shift away from time-based roadmaps requires more than a new template. It requires a change in how the organization talks about product work. Commercial teams need to learn to sell around outcomes rather than features. Executives need to learn to evaluate progress by Key Results rather than ship dates. Customer-facing teams need to learn to set expectations around problems being solved rather than specific functionality arriving in a specific quarter.

This is cultural change, and cultural change is hard. The time-based roadmap persists not because it is good, but because everyone in the organization has adapted their workflows around it. Sales pipelines are built on feature promises. Board decks are structured around quarterly delivery milestones. Compensation plans are tied to shipping dates. Unwinding all of that takes deliberate effort and sustained leadership.

The organizations that do make the shift consistently report two things: they deliver faster (because teams are not wasting time on buffer games and estimate theater) and they build better products (because teams have the flexibility to follow evidence rather than follow the plan).

Still using a time-based roadmap? ProdPad’s free guide walks you through how to move from timeline to Now-Next-Later roadmapping step by step, without throwing away the work you’ve already done.

Honesty as Competitive Advantage

There is a reason why more product organizations are moving toward outcome-based roadmapping formats like Now-Next-Later, and it is not because it is trendy. It is because the organizations that communicate honestly about uncertainty make better decisions.

An honest roadmap does not mean a vague roadmap. Now-Next-Later is extremely specific about what is being worked on now, what is being explored next, and what is on the strategic horizon for later. It is specific about the outcomes each initiative targets, the evidence supporting the approach, and the confidence level of the team. It just refuses to attach false precision (or false quarterly boundaries) where they do not belong.

Teresa Torres has publicly stated she is “a fan of Janna Bastow’s Now-Next-Later roadmaps.” The reason is straightforward: continuous discovery requires a roadmap format that supports changing direction when you learn something new. A time-based roadmap punishes learning. An outcome-based roadmap rewards it.

The Product leaders who build the most trust with their organizations are the ones who say “here is what we know, here is what we are exploring, and here is what we are not yet certain about” rather than “here is what we will ship in Q3.” That honesty, communicated well and backed by a clear strategic framework, earns more credibility than a hundred perfectly formatted Gantt charts or quarterly grids.

Product teams exist to solve problems in priority order, driven by evidence and connected to strategic outcomes. They do not exist to fulfill a delivery schedule written before anyone understood the problem. The roadmap should reflect that reality. When it does, everything downstream gets better: prioritization, discovery, stakeholder trust, team morale, and the quality of the product itself.

The best roadmap is the one that tells the truth about what matters, how much you know, and what you are doing about it. The truth scales better than any calendar ever will.