21 — Product Roadmaps That Don't Lie

The Document Everyone Wants and Nobody Trusts

Product roadmaps are strange documents. Everyone wants them. Engineering wants to know what to build. Sales wants to know what to sell. Customers want to know what to expect. Leaders want a plan they can show the board. So PMs produce roadmaps. And then nothing on those roadmaps ships when it was promised, the priorities shift, and within a quarter the roadmap is out of date. Everyone secretly knows this is what happens. Everyone still wants the roadmap.

The trouble is that traditional roadmaps lie about uncertainty. They show specific features in specific quarters with specific dates, even though everyone involved knows that some of those features won't ship and some quarters won't go as planned. The roadmap pretends to know things it doesn't know, and everyone who reads it makes plans based on the false certainty.

This article is about how to build roadmaps that are useful without being dishonest. We will cover what roadmaps should contain, what they should not contain, how to communicate uncertainty without losing usefulness, and how to handle the political pressure to commit to dates you can't actually hit.

What a Roadmap Is For

Different people read roadmaps for different reasons, and a good roadmap serves several at once.

For the Team

Engineering and design need to know what they are working on this quarter, what is coming next, and what the longer-term direction is. They use the roadmap to make architectural decisions today that will support the work coming later.

For Stakeholders

Sales, marketing, customer success, and leadership use the roadmap to plan their own work. Sales wants to know what to promise customers. Marketing needs lead time for launches. Customer success wants to know what to prepare for. Leadership wants confidence that the team is moving in the right direction.

For Customers

Customers want to know whether the product is investing in things they care about. They use this to decide whether to stay, expand, or churn. Public roadmaps are a marketing tool as much as a product tool.

For Yourself

The PM uses the roadmap as a thinking tool. Putting work in rough order forces decisions about priority, sequencing, and trade-offs. Many of the most useful insights from building a roadmap come from the act of building it, not from the finished document.

Two Bad Roadmap Patterns

Most roadmaps fail in one of two ways. Knowing the patterns helps you avoid both.

The Wishful Calendar

Specific features assigned to specific quarters with specific dates. Quarter one will ship features A, B, and C. Quarter two will ship D, E, and F. The document looks confident and specific. Everyone planning around it makes commitments based on the dates. Then quarter one ships only A and a partial version of B. Quarter two's plan was already wrong by the time quarter one ended. Everyone who relied on the dates is frustrated. Trust erodes. The PM produces another roadmap anyway, and the cycle repeats.

The Vague Vision

The opposite failure. The roadmap shows broad themes with no dates and no specifics. This year we focus on growth. Next year we focus on enterprise. Nobody can plan around it. Engineering doesn't know what to architect for. Sales doesn't know what to promise. The roadmap is honest about uncertainty but useless for coordination.

The good roadmap is between these two: specific enough to be useful, vague enough to be honest. The trick is using time horizons appropriately, with more specificity in the near term and less in the far term.

The Now / Next / Later Format

The format that has worked best for us is one borrowed from Janna Bastow at ProdPad: Now, Next, and Later. Three columns. Each represents a different time horizon and a different level of certainty.

Now

What the team is actively working on. Specific items, with specific outcomes, currently in flight. Time horizon: this quarter or the next few weeks. Certainty: high. These items have been validated, scoped, and committed to.

What the team plans to work on after the current items ship. Specific enough that you can describe each one in a sentence, but not yet committed to dates. Time horizon: roughly the next quarter. Certainty: medium. Most of these will probably happen, but priorities can still shift.

Later

Themes and large initiatives the team is considering for future quarters. Less specific, more directional. Time horizon: six months to a year out. Certainty: low. These items will likely change shape before they enter the Next column. They communicate where the team is heading without committing to specific work.

Column Time Horizon Specificity Certainty

Now This quarter / weeks Specific features and outcomes High

Next Next quarter Named initiatives, light scope Medium

Later Beyond next quarter Themes and directions Low

This format communicates uncertainty honestly. Items in Now are commitments. Items in Next are intentions. Items in Later are directions. Stakeholders can plan accordingly: build around Now, prepare for Next, watch Later. The format also makes it natural for items to flow from Later to Next to Now as they get more refined and prioritised.

Outcome-Based vs. Feature-Based Roadmaps

There is a long-running debate about whether roadmap items should be features (specific things to build) or outcomes (specific changes you want to see). Both have merit. The right answer depends on the time horizon and audience.

Feature-Based

Build the export to PDF feature. Add Slack integration. Redesign the dashboard. Concrete, specific, easy to understand. Engineering knows what to build. Sales knows what to promise. The downside: features can ship without producing the outcome you wanted. You build the export to PDF, and users still don't share reports more often.

Outcome-Based

Increase weekly active users by twenty percent. Reduce time to first value to under five minutes. Lift expansion revenue in the mid-market segment. Honest about what success looks like. The team has flexibility on how to achieve it. The downside: harder to plan around for stakeholders. Sales can't tell customers what they will get; they only know what should improve.

A Useful Hybrid

In our experience, the most useful format is outcome-based in the Later column, hybrid in Next, and feature-based in Now. Now items are committed, so they should describe what is shipping. Next items are intentions, so they describe both the work and the outcome it should produce. Later items are directions, so they describe outcomes (specific features will be designed later). This shape lets the roadmap be useful for planning today while staying flexible about how outcomes are achieved later.

What to Include and Exclude

Include

Strategic themes : the high-level areas of investment this year. Three to five themes is plenty.
Outcomes you are aiming for : what should change in the product, the business, or user behaviour.
Major initiatives : large pieces of work, named and briefly described.
Time horizons : rough sequencing through Now, Next, and Later.
What is explicitly out of scope : items the team has considered and decided not to pursue, with a brief reason.

Exclude

Specific dates beyond the current quarter . They will be wrong and will be remembered.
Every backlog item . The roadmap is for major work, not for every ticket.
Internal-only details . Architecture decisions, engineering investments, and similar items belong in engineering plans, not the public roadmap.
Dependencies on uncertain external factors . If a roadmap item depends on a partner deal that may or may not close, putting it on the roadmap creates false certainty.
Items the team has not validated . If you don't know whether the work will actually move outcomes, putting it on the roadmap implies more confidence than you have.

Public vs. Internal Roadmaps

Many companies maintain two roadmaps: an internal one for the team and an external one for customers and prospects. The two share content but differ in tone and detail.

The Internal Roadmap

More detailed. More candid about uncertainty. Includes engineering-only work like infrastructure and tech debt. May include specific dates for the current quarter and rough sequencing for the next. Shared internally with engineering, design, sales, and leadership.

The External Roadmap

Less detailed. More directional. Avoids commitments to dates. Focuses on themes and outcomes that customers care about. Often shown as a public page on the website or shared in sales conversations. Should be honest enough that customers feel informed but vague enough that you can adjust without breaking promises.

How to Build a Roadmap

Building a good roadmap is a process, not an event. The first version is rarely the right one. Here is a sequence that produces useful results.

1. Start with strategy. The roadmap should serve the strategy, not the other way around. If you don't have a clear strategy, fix that first.
2. Identify outcomes for the year. What should change in the product, the business, or user behaviour? Three to five major outcomes per year is the right scale.

3. Generate initiatives that would produce those outcomes. For each outcome, list the

major pieces of work that could plausibly contribute to it. Cast a wider net than you will eventually pursue.

4. Prioritise. Not everything makes the cut. Use a prioritisation method (covered in the next article) to decide what is in and what is out.
5. Sequence. Decide what goes in Now, Next, and Later. Consider dependencies, validation status, and team capacity. The most certain items go in Now; the most directional in Later.
6. Pressure-test. Walk through the roadmap with engineering, design, sales, and leadership. Where does it overcommit? Where does it under-commit? Where are the dependencies wrong? Adjust based on feedback.
7. Communicate. Share the roadmap broadly. Write a one-page summary that explains the priorities and the reasoning. Be explicit about what is committed and what is directional.
8. Update regularly. Review and refresh at least monthly. Items that have shipped come off Now. Items in Next move to Now. New items appear in Later. The roadmap is a living document, not a one-time deliverable.

Handling Pressure for Dates

Stakeholders will push for specific dates on items beyond the current quarter. Sales especially. They want to tell customers when features will ship. The pressure is real, and refusing to give dates feels uncooperative. But giving wrong dates is worse than giving no dates.

Some practical responses:

Offer a range, not a date. "Sometime in the second half of next year" is more honest than a specific quarter and is usually acceptable to the asker.
Distinguish commitments from intentions. "We are committed to X by end of quarter; we intend to start Y "next, though we have not yet committed to a date" makes the distinction clear.
Explain what would have to be true to commit. "We can commit to a date once design is finalised and we've validated the approach, which we expect by month X." This shows progress without overcommitting.
Push back on date pressure with consequences. "If we commit to that date, we will need to drop X to hit it. Is that the trade-off you want?" Often the asker realises the trade-off is not worth it.
Don't lie. The PM who gives dates they don't believe in to make a sales person happy is creating a bigger problem six months from now. Better to be unpopular today than untrusted later.

Common Mistakes

Mistake One: Treating the Roadmap as a Contract

When the roadmap becomes a contract, the team stops being able to adapt to new information. New evidence comes in, the right answer changes, but the roadmap blocks the change. The fix is to be explicit at the start that the roadmap is a current best guess, not a contract, and to update it openly when things change.

Mistake Two: Building It in a Vacuum

PMs who build roadmaps alone, then announce them to the team, miss the engineering insight that would have made the plan better. Building the roadmap in collaboration with engineering and design produces a better plan and better buy-in.

Mistake Three: Including Everything

A roadmap with thirty items in Now is not a roadmap; it is a wish list. The team cannot work on thirty things at once. Either you are not actually working on most of them (in which case they don't belong in Now) or you are working on too many things to do any of them well. Three to seven items in Now is usually the right number.

Mistake Four: Never Cutting Things

Roadmaps that only grow are roadmaps that lie. Sometimes items in Later should be cut entirely because the team has decided they are not strategic. Cut them publicly and explicitly. The clarity is more valuable than the optionality.

Mistake Five: Letting It Become Wallpaper

A roadmap that nobody references is doing no work. If it sits in a Confluence page that nobody opens, the energy spent building it was wasted. Reference the roadmap in real decisions. Update it regularly. Make it part of the operating rhythm of the team.

A Final Word

A useful roadmap is honest, current, and used. It tells the team where they are going. It tells stakeholders what to expect, with appropriate uncertainty. It tells customers that the product is investing in the right things. It is not a plan or a contract; it is a current best guess about where the team is heading and what they are committing to in the near term.

Build it. Update it. Use it. Resist the pressure to add false certainty. Be honest about what you know and what you don't. Over time, this honesty will produce more trust than the false confidence of specific dates would. The team that says this is committed, this is intended, this is directional and means it is more credible than the team that says this ships by date X and ships in date Y, every quarter, for years.

Key Takeaways

A roadmap is a communication tool, not a plan or a contract. Its job is to show direction and priorities with appropriate uncertainty.
Now / Next / Later format communicates uncertainty honestly. Specific in Now, intentional in Next, directional in Later.
Mix outcome and feature framing: feature-based in Now, outcome-based in Later, hybrid in between. This balances usefulness and flexibility.
Public and internal roadmaps differ. Internal can be more specific; public should avoid commitments to dates and focus on themes.
Resist pressure for false dates. Better to be unpopular today than untrusted later. Update the roadmap regularly and openly when things change.