Product Roadmaps: How the Best Product Teams Plan for Uncertainty

Audio Version ($)

We need to talk about product roadmaps.

I once worked at a startup where our product roadmap was literally an Excel spreadsheet full of feature ideas. Most of them came from our CEO. Our head of product simply prioritized the rows. Based on what, I have no idea.

This is more common than you think. Most people define a product roadmap as a list of features and release dates.

The next startup I worked at organized their roadmap by themes. But it wasn't very different from the feature roadmap. Themes were simply collections of features. Everyone knew exactly what we were going to build for the next six months.

Or so we thought.

Finally, I worked at a startup where we dropped the product roadmap altogether. We set outcomes, our teams explored and ran experiments. It was glorious—for the product team. But it didn't work for our sales and marketing teams.

Product roadmaps have been contentious for decades. It's hard to find a format that satisfies everyone's needs. Product teams need the freedom to explore and experiment. Sales teams need to know what to tell prospects. Marketing needs to plan campaigns.

Today, we are going to look at the evolution of the product roadmap, why the best format keeps changing as we try to address everyone's needs, and how generative AI is exacerbating these long-held tensions.

For each type of product roadmap, we'll look at the strengths and limitations, I'll provide a product roadmap example for each, and you'll get step-by-step instructions for how to create each one.

By the end, I'll extend a popular product roadmap format to better meet the demands of today. Let's dive in.

The Traditional Product Roadmap: Features and Dates

Let's start with what most people mean when they say "product roadmap." It's a document that lists what features each team will ship and when.

An example product roadmap with features and dates:

Each row is a team. Each column is a quarter. Each cell is a feature the team has committed to delivering by that date. Simple, clear, and easy for anyone in the organization to read.

What Feature Roadmaps Get Right

Feature roadmaps give the rest of the organization exactly what they need: clear visibility. Sales knows what's coming and when so they can set expectations with customers. Marketing can plan launches. Leadership can report to the board.

For work that's genuinely committed—contractual obligations, regulatory requirements, features shipping in the next sprint—feature-level detail makes sense. Even the strongest critics of feature roadmaps agree on this point.

Where Feature Roadmaps Fall Short

The problem is that feature roadmaps extend this level of certainty far into the future. That's unrealistic. Nobody can predict the future.

Janna Bastow, co-founder of ProdPad and Mind the Product, has argued that every feature-and-date roadmap is built on three false assumptions:

1. You know how long each feature will take and nothing will disrupt your plans,
2. Each feature will work as soon as you finish it, and
3. Each feature on the roadmap actually deserves to exist and should be assigned a delivery date.

Most product roadmaps are out of date as soon as the ink touches the paper. Features take longer to deliver than we estimated. An urgent customer demand interrupts the current project. The organization gets distracted by a competitor release.

Feature-based roadmaps are fiction. Everyone on the product team knows it. The challenge is the rest of the organization sees it as a contract. When the product team breaks the contract, as they inevitably will do, trust erodes.

Feature-based roadmaps don't acknowledge the uncertainty that is pervasive in product work. They don't give flexibility for the organization to react to a dynamic market. We've simply outgrown feature-based roadmaps.

And yet they are still everywhere. Organizations are addicted to the false certainty they represent. So if you are being asked to build a feature-based roadmap, I'll provide some guidance on how they are typically created. But know that I don't recommend this format. It causes more problems than it solves.

How to Build a Feature Roadmap

This type of product roadmap is typically created during annual or quarterly planning. Each team proposes features, leadership negotiates priorities, and dates get assigned based on rough estimates. The result is a grid of features mapped to time periods with team swim lanes.

Once features are assigned to time periods, teams do capacity planning—working through dependencies between teams, identifying bottlenecks, and adjusting the schedule. When the Search team can't start their Q3 work until the Platform team finishes a Q2 dependency, the Search team has to find something else to work on in the interim. This dependency negotiation is often the most time-consuming part of roadmap creation and a major source of the false precision that makes feature roadmaps fragile.

I wrote about this problem back in 2014 in Drop Feature-Based Product Roadmaps. The argument holds up, but what's changed since then is that the industry has developed better alternatives. Let's look at how product roadmaps have evolved.

Theme and Outcome-Based Roadmaps: Better Framing, Same Visibility Problem

Product teams got tired of committing to what they knew was fiction and started to experiment. Two early experiments were theme roadmaps and outcome-based roadmaps (also called outcome-driven roadmaps).

Both of these iterations were designed to give product teams more room to explore and figure out what might work.

What is a Theme Roadmap?

A theme roadmap replaces specific features with strategic focus areas or themes.

An example product roadmap with themes and dates:

Instead of committing to "AI-powered search,"—a solution that may or may not work—the Search team commits to a "search relevance" theme.

What Theme Roadmaps Get Right

Theme roadmaps allow a company and a team to align around a strategic theme. A theme is an area of focus, but it doesn't constrain the team. It doesn't commit them to delivering specific features. Both the company and the team acknowledge that product work is unpredictable and they account for that uncertainty.

If AI-powered search doesn't work, the Search team can try other solutions without breaking their contractual commitment. As long as they improve search relevance, they've done their job.

Where Theme Roadmaps Fall Short

The biggest gap with theme roadmaps is that, while they meet the needs of the product team, they don't meet the needs of the rest of the organization.

Sales needs more specifics than "search improvements are coming." Prospects want to know if the product does exactly what they need it to.

Marketing can't plan marketing campaigns around a theme. They want to plan marketing campaigns around a specific feature launch.

Customer support can't get up to speed on how a theme works. They need to know exactly how the product will work before its release so that they are prepared to answer customers' questions.

What ends up happening is that product teams start with themes, but they quickly commit to features as well. This is the only way the rest of the organization can do their jobs. Theme roadmaps quickly devolve back to feature roadmaps.

Theme roadmaps, however, are still popular in organizations where the executive teams set quarterly strategic initiatives. Themes allow the organization to cluster teams around those initiatives.

How to Build a Theme Roadmap

If you are being asked to create a theme roadmap, the first question that will come up is, "How do we identify the right themes?"

Themes should be derived from a clear vision and strategic objectives. If these are missing, your themes will likely just represent clusters of features. So start with your strategic context.

Then decide how many teams need to be assigned to each theme and let them fill in the details. But remember, the rest of the organization needs those details, so make sure you hold your teams accountable to closing that gap as they learn what will work and what won't.

Outcome-Based Roadmaps

Another challenge with theme roadmaps is that it's not always clear if a team delivered on their theme. Themes can be vague. This is where outcome-based roadmaps (also called outcome-driven roadmaps) come in.

Outcome-based roadmaps add a quantitative metric to each theme. Instead of the search team focusing on "search relevance" as a theme, they commit to "reducing the time it takes to find something." These effectively say the same thing, but the latter is measurable while the former is not.

An example product roadmap with outcomes and dates:

What Outcome-Based Roadmaps Get Right

Like theme roadmaps, they give product teams the latitude to explore and experiment. They also hold teams accountable. They make it clear if a team accomplished their commitment.

Where Outcome-Based Roadmaps Fall Short

Outcome-based roadmaps have the same visibility problem as theme roadmaps. "Reduce time-to-find" doesn't tell marketing what features to announce or sales what capabilities to promise. And like with theme roadmaps, product teams end up committing to both outcomes and features.

How to Build an Outcome-Based Roadmap

In Continuous Discovery Habits, I argue outcomes should be a two-way negotiation between the executive team and the product team.

The executive team should define how each team can provide value to the business. Each product team needs to communicate how much impact they can have and by when.

The way this happens in practice is the executive team identifies business outcomes (e.g. revenue, retention, market share), then the product team (usually with the help of the product executive) translates those business outcomes into product outcomes (e.g. specific behaviors in the product that are leading indicators of those business outcomes). Each team then chooses one outcome to focus on for the quarter.

To learn more about outcomes, see Outcomes vs. Outputs: What's the Difference and Why Does It Matter?

Both theme and outcome-based roadmaps give product teams more latitude to explore. But they do it at the cost of what our marketing, sales, and customer support teams need—visibility into what comes next.

The Now Next Later Roadmap: Balancing Uncertainty with Predictability

In 2012, Janna Bastow created the Now Next Later roadmap while building ProdPad. The insight was simple but powerful: the further away something is, the more uncertain it is. Your roadmap should reflect that. Bastow calls it "a prototype for your product strategy"—the value is in the process of roadmapping, not in the artifact.

Instead of quarters, the Now Next Later roadmap uses three time horizons. Here's an example product roadmap:

Now is what the team is actively building. These items are clearly defined, fully spec'd, and in progress. They should have clear timelines for delivery and your sales, marketing, and customer support teams should be using this time to understand what is coming and when.

Next is what's on deck—it's what you will work on after you finish the work in the Now column. These items are not fully spec'd out, the specific timeline (beyond the fact that they are next in the queue) is unknown. Sales can let prospects know these features are coming. Marketing teams can start thinking about campaign ideas. But neither can set timelines yet.

Later is on the radar but not yet committed. These items still need a lot of exploration and may still change. They give a directional indicator, but sales and marketing should not be making promises based on this column.

What Now Next Later Roadmaps Get Right

The most important attribute of the Now Next Later roadmap is that it gets rid of dates for anything that is outside the Now column.

Software development is unpredictable. Engineering estimates are notoriously hard to get right. Yes, coding agents are speeding up the timelines for deterministic code. But if you are building AI features and services, the estimates are getting even harder. It's hard to know upfront what will work and by when.

This format acknowledges that certainty decreases over time. We can and should commit to what is currently in flight. The closer we get to delivering, the clearer our deadlines should get. This allows our sales, marketing, and customer support teams to plan around our releases.

But the further out we look, the less certain we can be. The Next column gives our sales, marketing, and customer support teams an indicator of what they can expect down the road. But it doesn't guess at when.

The Later column doesn't carry any commitment at all. It communicates the idea that this is on our radar and nothing more.

The Now Next Later format is a nice compromise between what product teams need and what the rest of the organization needs.

Where Now Next Later Roadmaps Still Fall Short

The challenge with the Now Next Later format is that most teams fill all three columns with features. Most sales, marketing, and customer support teams interpret all three columns the same way—they treat them all like feature commitments.

When every column contains features, the team is still committing to what to build across the entire time horizon, even if they're not committing to when. They've acknowledged time-based uncertainty but not solution-based uncertainty.

If the product team learns a feature won't work as planned, the rest of the organization still feels like they are backing away from a commitment.

Now Next Later roadmaps work well for managing contractual obligations. When you know you have to build a feature—due to a new regulation or a prospect requiring it to sign a contract—a product team can clearly communicate if this is something they can build now, next, or later.

How to Build a Now Next Later Roadmap

If you are being asked to build a Now Next Later roadmap, here's how you can get started.

• For the Now column, only include what is currently in development. This work should be fully spec'd and estimated. As you get closer to completion, you might even add a target release date.
• For the Next column, only include what is already being explored in discovery. You should be confident that you can and will deliver this solution. What's less clear are the specifics on the how and the when.
• For the Later column, don't let this turn into an infinite backlog. Only include items that are timely and will support your current outcome or strategic initiative. These items might not be spec'd out at all and you may have no idea when or even if you'll get to them. But it's a good way to communicate "here's what else we are considering."

I've long been a fan of Now Next Later roadmaps. But they only work well when the rest of the organization respects the intent of the Next and Later columns. Let's now look at a format that helps to encourage that.

The Sweet Spot: Now Next Later Meets Your Discovery Work

Here's what I've seen work best: Take the Now Next Later format, but instead of filling every column with features at different levels of detail, change the type of content as you move across columns.

Remember, Now Next Later roadmaps are trying to acknowledge that the future is uncertain. We don't know what features we might build in the future. But we should know something about our future work. And that's where the same structural elements that go on an opportunity solution tree can and should go on your Now Next Later roadmap.

Specifically, I list solutions in the Now column, opportunities in the Next column, and outcomes in the Later column.

Here's our example product roadmap in this extended format:

Notice the shift. Now contains specific solutions in progress—the same concrete detail that makes feature roadmaps useful for the rest of the org. Next contains opportunities—customer needs and pain points, not yet committed solutions. Later contains outcomes—the measurable results teams are driving toward.

This naturally mirrors how certainty decreases over time. You're most certain about what you're building right now. You might know which opportunities you want to go after next, but until you start to explore them, you have no idea what solutions you'll build. And after that, all you might know is what outcomes matter to your team.

The Now column gives your sales, marketing, and customer support teams exactly what they need to prepare for launch. The Next column allows your sales team to talk to prospects about which opportunities you'll address next, without overpromising on specific solutions. Marketing teams can plan benefits-based campaigns long before you've identified a specific solution. And the whole organization can see that you've identified the right outcomes for the future.

This format—combining the Now Next Later columns with the opportunity solution tree structural elements—helps an organization interpret the Now Next Later roadmap exactly the way Janna Bastow intended, as a prototype for our product strategy.

I use this format myself. I shared my own Now Next Later roadmap in my 2021 annual letter and again in my 2025 annual letter.

Here's an example of one slice of my current product roadmap:

I'm actively building AI-generated opportunity solution trees (OSTs)—that's a specific solution in flight. Next, I want to explore how product teams can collaborate with the AI rather than just being given an OST—that's an opportunity, not a committed solution. And later, I'm driving toward increasing the number of teams who have qualifying interviews—that's an outcome that will guide my direction but doesn't constrain my path.

How to Build a Now Next Later + OST Roadmap

1. Start with your opportunity solution trees. Each team should have an outcome at the top, opportunities in the middle, and solutions at the bottom. If your teams don't have OSTs yet, start there. (See Opportunity Solution Trees: Visualize Your Discovery to Stay Aligned and Drive Outcomes for the full guide.)
2. The Now column pulls from the bottom of the tree—the solutions currently in flight. Include the opportunity each solution addresses so the rest of the org understands why this work matters. If a solution isn't working, the team can pivot to a different solution for the same opportunity.
3. The Next column pulls from the middle of the tree—indicate which opportunity you plan to address next. No committed solutions yet. The team might have ideas, but they haven't done the discovery work to know what to build.
4. The Later column pulls from the top of the tree—the outcomes the team is driving toward. This communicates strategic direction without false precision.
5. Review and update regularly. As teams complete discovery on Next items, opportunities move to Now with specific solutions. As a team explores a new outcome, its opportunities get pulled into the Next column.

Why This Works

This approach solves the two biggest problems that plague every other roadmap format:

1. Product teams have the latitude to explore and experiment. They only make feature commitments when they know what's going to work.
2. The rest of the organization gets clarity in detail on what's in development right now. They can plan their work accordingly. They get visibility into what's coming next, but not at level of detail that promises false certainty.

The format itself teaches the organization how to interpret the document. We avoid the trap of committing to fictions, inevitably breaking an implied contract, and end the erosion of trust.

Making the Transition: Start Where You Are

If your organization currently uses feature roadmaps, you don't need to overhaul everything overnight. Here's how to evolve incrementally.

Don't fight the ideological war. If your organization requires feature roadmaps, don't refuse to create one. Instead, start adding context: connect each feature to the opportunity it addresses and the outcome it drives. Over time, this shifts the conversation from "What are we building?" to "What problem are we solving?"

Ellen Juhlin recently shared how she did exactly this. She started by adding outcomes to her existing roadmap spreadsheet—a small change that introduced outcome thinking into priority conversations without requiring wholesale change.

When leadership was used to seeing a list of outputs, Ellen connected each output to the outcome it would drive, like winning a big customer or increasing engagement. (You can read more about her approach in My Leaders Still Want Roadmaps with Timelines—What Should I Do?)

Start with the Now column. Even if your Next and Later columns are still full of features, connecting your current work to the opportunities it addresses is a meaningful first step.

Use missed deadlines as opportunities. When a solution doesn't ship on time or doesn't have the expected impact, that's the perfect moment to introduce the opportunity behind it: "The solution changed, but the opportunity we're addressing hasn't." This helps stakeholders see that the work is still on track, even when specific features shift.

AI pressure can actually help. If your stakeholders are demanding AI features on the roadmap but you genuinely can't predict timelines, that's the perfect moment to introduce the Now Next Later format: "Here's what we're testing now. Here's the problem we're exploring next. Here's the outcome we're driving toward." The inherent uncertainty of AI features makes the case for you.

Product Roadmaps Should Reflect Reality

The best product roadmap reflects the actual state of your knowledge. You know the most about what you're working on right now. You know less about what's next. You know even less about what's further out. A good roadmap mirrors this—specific in the near term, directional in the long term.

Here's a next step you can try today: The next time you update your roadmap, look at your Next column (or Q3, or whatever comes after your current work). For each item, ask, "Is this a solution, an opportunity, or an outcome?"

If it's a solution, either push it to Now because you're ready to build it or replace it with the opportunity it addresses. That one shift—replacing future solutions with the problems they're meant to solve—is where the evolution starts.

Audio Version

The audio version is only available for paid subscribers.