Product roadmaps: why date-based ones always fail (and what to use instead)

Your roadmap is lying to everyone, and they know it

You’ve been there. Q2 planning, leadership asks for the roadmap, you spend two weeks building a Gantt chart that shows Feature X shipping in April, Feature Y in May, Feature Z in June. By mid-April, Feature X is delayed because the API integration was more complex than anyone estimated. Now your entire roadmap is fiction, but it’s still being shown to customers, referenced in board decks, and used to set sales expectations.

The problem isn’t that your team is bad at estimating. The problem is that date-based roadmaps are fundamentally incompatible with how software actually gets built. They create false precision that breaks trust with stakeholders, incentivizes engineers to pad estimates, and forces product teams to defend commitments they never should have made.

Here’s the uncomfortable truth: the most effective product teams have largely abandoned date-based roadmaps. And until you do the same, you’ll keep playing a game you can’t win.

Why date-based roadmaps always fail

Date-based roadmaps don’t fail sometimes. They fail reliably, predictably, and for the same reasons at every company I’ve worked with or advised. Understanding these failure modes is essential before we talk about what actually works.

False precision creates broken promises

When you put “Feature X: April 15” on a roadmap, you’re claiming a level of certainty that doesn’t exist. Software development involves unknowns that can’t be estimated until you encounter them. That third-party integration might have undocumented edge cases. The performance requirements might need architectural changes. The legal review might surface compliance issues.

Stripe famously discovered this when building their first version of Stripe Connect. What they estimated as a 3-month project took over a year because the regulatory complexity of money movement across borders was impossible to scope in advance. No amount of better estimation would have fixed this—the uncertainty was inherent to the work.

The moment you assign a date, stakeholders treat it as a commitment. Sales books revenue against it. Marketing plans launches around it. Executives report it to the board. When the date slips—and it will—you haven’t just missed a deadline. You’ve broken a promise that rippled through the entire organization.

The estimation gaming problem

Experienced engineers have learned the rules of this game. If roadmap dates are treated as commitments, the rational response is to pad estimates significantly. A senior engineer who thinks something will take 3 weeks will estimate 6, because they’ve been burned before.

This creates a death spiral. Padded estimates mean the roadmap shows less work getting done. Leadership responds by adding pressure for “more aggressive” timelines. Engineers respond by padding more, or by cutting corners to hit arbitrary dates. Quality suffers. Technical debt accumulates. The product gets harder to change over time, which makes future estimates even less reliable.

At one company, I watched an engineering team consistently deliver on time because they’d learned to 3x every estimate. Leadership celebrated their “predictability” while competitors shipped twice as fast. The roadmap looked accurate. The company fell behind.

Marty Cagan’s case against output roadmaps

Marty Cagan, whose work at Silicon Valley Product Group has shaped how a generation of PMs thinks about roadmaps, argues that traditional roadmaps—what he calls output roadmaps—are fundamentally an anti-pattern for empowered product teams.

His reasoning: when you commit to delivering specific features by specific dates, you’re telling the team what to build before they’ve had a chance to discover the best solution to the customer problem. You’ve removed the product team’s ability to learn and adapt. They become a feature factory, executing on decisions made months ago by people who may not have understood the problem deeply.

The alternative Cagan advocates: give teams problems to solve, not features to build. Measure them on outcomes, not outputs. Let the roadmap communicate strategic direction without locking in implementation details that should emerge from discovery work.

This isn’t just theory. Cagan’s research shows that empowered teams consistently outperform feature teams on every metric that matters—user satisfaction, business outcomes, and even shipping velocity. The roadmap format you choose either enables empowerment or undermines it.

Four roadmap formats that actually work

The good news: you don’t have to choose between having a roadmap and having a roadmap that works. These four formats each solve different problems. Choose based on your team’s situation, not based on what looks most professional in a slide deck.

Now/Next/Later: the default for most teams

The now/next/later roadmap is the format I recommend for most product teams. It communicates what matters—priority order—without claiming to know what you can’t—exact timing.

Now is what the team is actively working on this sprint or this month. These are committed items with real progress being made.

Next is what’s been validated and is queued up. The team has done enough discovery to know this work is worth doing and roughly how to approach it, but they haven’t started yet.

Later is everything else that’s on the radar. These items are real possibilities, but they haven’t been validated yet. They might move up, might get cut entirely.

The genius of this format is that it sets appropriate expectations by design. When a stakeholder asks “when will Feature Y ship?” you can honestly say “It’s in Next, which means it’s our second priority. We’ll start it when we finish what’s in Now, and we’ll have a better estimate then.”

Notion has become the default tool for now/next/later roadmaps because its database views make it easy to move items between columns and filter views for different audiences. You can learn more in our guide to the [INTERNAL_LINK: now next later roadmap] format.

Outcome-based roadmaps: best when you have clear OKRs

If your team has well-defined OKRs, an outcome-based roadmap organizes work around those objectives rather than around features or themes.

Spotify popularized this approach. Instead of a roadmap that says “Build playlist sharing feature,” an outcome-based roadmap says “Increase weekly playlist shares by 40%.” The team then has latitude to discover the best way to hit that target—maybe it’s a sharing feature, maybe it’s better notifications, maybe it’s something they haven’t thought of yet.

The structure typically looks like:

• Objective: The outcome you’re trying to achieve (qualitative)
• Key Results: How you’ll measure success (quantitative)
• Current Bets: The initiatives the team is pursuing to hit those results
• Confidence Level: How likely the team thinks they are to hit the target

This format works when you have mature analytics that can actually measure outcomes, and when leadership trusts teams to find the right solutions. It fails when OKRs are poorly defined or when stakeholders really do need to know about specific features (enterprise sales situations, for example).

See our deep dive on [INTERNAL_LINK: OKRs for product teams] for how to set objectives that make this format work.

Opportunity roadmaps: best for discovery-heavy teams

Teresa Torres’ opportunity solution tree framework has given rise to opportunity roadmaps—roadmaps organized around customer problems rather than features or outcomes.

The structure:

• Desired Outcome: The business or product outcome you’re pursuing
• Opportunities: Customer problems, needs, or desires that, if addressed, would drive the outcome
• Solutions: Potential ways to address each opportunity (kept deliberately vague until discovery validates them)

This format shines when your team is doing continuous discovery and the right solution isn’t yet known. It’s particularly valuable for teams working in newer markets or on innovative products where the build-measure-learn cycle needs to happen quickly.

The challenge: this format requires stakeholders to accept significant uncertainty about what will actually get built. Enterprise stakeholders who need to plan integrations or procurement often can’t work with this level of ambiguity. Use it internally, but you may need a translation layer for external communication.

Theme-based roadmaps: best for stakeholder communication

Sometimes you need a roadmap that executives can put in a board deck or sales can share with prospects. Theme-based roadmaps solve this by organizing work into strategic buckets without committing to specific features or dates.

Common themes:

• Platform Reliability (performance, infrastructure, security work)
• Enterprise Readiness (compliance, admin features, SSO)
• User Activation (onboarding, aha-moment optimization)
• Market Expansion (new use cases, integrations, geographic features)

Under each theme, you list the general areas of investment without committing to specific features. “We’re investing heavily in Enterprise Readiness this year, including compliance certifications and admin controls” is a statement stakeholders can work with, but it doesn’t lock you into a specific feature set.

Productboard has become the go-to tool for theme-based roadmaps because it lets you create customer-facing views that show themes and general direction without exposing the messy internal prioritization details. See our [INTERNAL_LINK: product management tools] guide for a full comparison.

What every good roadmap includes

Regardless of format, the best roadmaps share certain characteristics. These aren’t optional—they’re the difference between a roadmap that drives alignment and one that gathers dust.

The why behind the order

Every item on your roadmap should have a visible rationale. Why is this in Now rather than Next? What customer problem does it solve? What business objective does it support? What evidence do you have that this is the right priority?

When stakeholders can see the reasoning, they’re far more likely to accept decisions they disagree with. “We’re prioritizing X over Y because our data shows 40% of new users drop off at this step” is a conversation. “X is higher priority than Y” is a power struggle.

What’s explicitly NOT on it

The items you’ve decided not to do are as important as the items you’re doing. Every good roadmap should have a “Parking Lot” or “Not Now” section that lists requests you’ve received and explicitly deprioritized.

This serves two purposes: it shows stakeholders that their feedback was heard (even if not acted on), and it prevents the same conversations from happening repeatedly. When someone asks about a feature that’s in the Parking Lot, you can point to it and explain why it’s there rather than relitigating the prioritization.

A review cadence

A roadmap without a review schedule is a roadmap that becomes fiction. Every roadmap should clearly state when it will be reviewed and potentially updated.

For most teams, this means:

• Now column: Reviewed weekly in sprint planning
• Next column: Reviewed bi-weekly or monthly
• Later column: Reviewed quarterly

This cadence sets expectations. Stakeholders know that if something is in Later, it won’t be reconsidered for at least a quarter. If something is in Next, there’s an opportunity to influence it in the next couple of weeks.

What good roadmaps never include

This is the harder discipline. These are the things you’ll be pressured to add that you need to resist.

Dates beyond the current work

The only dates that should appear on your roadmap are for work that’s actively in progress. “Feature X: 60% complete, estimated ship in 2 weeks” is fine. “Feature Y: targeting June” is not.

The moment you put a future date on an item that hasn’t been started, you’ve created a commitment you can’t keep. Resist the pressure. If stakeholders need dates, give them the now/next/later format with the understanding that “Now” items have estimates, “Next” items will have estimates when they move to “Now,” and “Later” items won’t have estimates until they’ve been validated.

More than can fit in the current quarter

Anything beyond the current quarter should be held loosely. Markets change. Customer feedback arrives. Competitors move. The features you thought were essential in January may be irrelevant by June.

Your roadmap should have a clear horizon: high confidence for the current quarter, medium confidence for the next quarter, low confidence beyond that. Items beyond the current quarter should be themes or opportunities, not specific features.

Getting stakeholders to accept roadmaps without dates

Here’s the script that works. I’ve used variations of this at three companies, and it’s converted skeptical executives every time.

Step 1: Acknowledge the need. “I understand you need to plan around our roadmap. Sales needs to set customer expectations. Marketing needs to plan launches. The board needs to understand our direction. A roadmap that doesn’t serve those needs isn’t useful.”

Step 2: Share the data on date-based roadmaps. “Over the past year, we’ve had [X] roadmap items with dates. [Y]% of them shipped on time. The average slip was [Z] weeks. This isn’t a people problem—it’s a process problem. We’re making commitments we can’t keep.”

Step 3: Offer the alternative. “Here’s what I’m proposing instead. We move to a priority-based roadmap that tells you what order we’ll do things, but not exact dates. For items in active development, we give date estimates. For everything else, we give you priority order and our confidence level.”

Step 4: Show what they get. “This actually gives you more useful information. Instead of a date that might slip, you know that Feature X is our #2 priority and we’ll start it as soon as we finish #1. When sales needs to set expectations, they can say ‘This is on our near-term roadmap’ rather than making date promises we have to walk back.”

Step 5: Propose a trial. “Let’s try this for one quarter. At the end, we compare: how many commitments did we keep? How much time did we spend re-explaining date slips? How confident are stakeholders in the roadmap? If this isn’t working better, we can revisit.”

The trial is crucial. People are attached to date-based roadmaps because they feel more concrete, even when they’re fiction. Letting them experience the alternative builds the trust needed for permanent change.

The mistakes that kill roadmaps

Even with the right format, roadmaps fail for preventable reasons. These are the patterns I see most often.

Too many items

If your roadmap has more than 15-20 items visible at any time, it’s not a prioritization tool—it’s a wish list. Stakeholders can’t parse a roadmap with 50 items, and neither can your team.

The discipline of a short roadmap forces hard conversations. When you can only have 5 items in “Now,” you have to actually decide what matters most. When “Later” is limited to 10 items, you have to say no to things rather than just deprioritizing them.

Too much specificity too early

Items in “Later” or “Future” should be problem statements, not solution specifications. “Improve new user activation” belongs on a roadmap. “Build an interactive onboarding wizard with 6 steps and gamification elements” does not—that level of specificity should emerge from discovery, not from roadmap planning.

When you over-specify early, you anchor teams to solutions that may not be optimal. You also create arguments about implementation details that distract from the more important question of whether the problem is worth solving at all.

Not enough why

I’ve reviewed hundreds of roadmaps. The single most common failure is that items appear without context. “Build API v2” tells you nothing about why this matters, who it’s for, or how success will be measured.

Every item should have a visible one-liner explaining its purpose. “Build API v2 — Enterprise customers need OAuth support and rate limiting for compliance requirements” changes the entire conversation. Now stakeholders can evaluate whether the priority is right, suggest alternatives, and understand how to talk about it externally.

Choosing the right tool

The tool matters less than the format, but the wrong tool can make good practices harder. Here’s what works for each situation:

For now/next/later roadmaps: Notion or Coda. Database views make it trivial to move items between columns and create filtered views for different audiences. The team sees everything; the exec view shows only high-level items.

For stakeholder-facing roadmaps: Productboard. Its customer-facing portal features let you share a polished view of your roadmap without exposing internal debates or low-priority items. The voting and feedback features also help capture stakeholder input in a structured way.

For team-level execution: Linear has become the default for engineering-centric teams. Its roadmap features tie directly to project tracking, so the roadmap updates automatically as work progresses. This reduces the maintenance burden that kills most roadmaps.

Whatever you choose, resist the temptation to over-engineer. I’ve seen teams spend months building custom roadmap tooling that no one maintains. The best roadmap tool is the one your team actually updates.

Start here

If your current roadmap has dates on it, here’s your next step: go through every dated item and ask “what happens if this date slips by a month?” For items where the honest answer is “it would be fine, we just picked a date,” remove the date and move to a priority indicator. For items where the date is genuinely fixed (regulatory deadline, contractual commitment, planned event), keep the date but mark it visibly as a hard deadline with consequences.

You’ll likely find that fewer than 20% of your dated items have genuinely fixed deadlines. The rest are false precision that’s setting everyone up for disappointment. Remove them, and you’ve taken the first step toward a roadmap that tells the truth.

Frequently asked questions