How To Build Now, Next, Later Roadmaps (With Examples)

Roadmaps should communicate a destination (goal), set a direction and lay out the steps that we need to take to get there.

Whilst some roadmapping techniques focus on timelines and release dates, a Now, Next, Later roadmap takes a more flexible approach that focuses on looking at what’s important right now and changing what is coming up as we ship.

The Agile manifesto talks about this approach, encouraging Agile teams to value responding to change over following a plan. The idea is that by being more flexible, we are in a better position to deliver value to our customers by responding to their needs faster.

A Now, Next, Later roadmap gives you the information that a roadmap should — the destination, direction and steps to get there. But, crucially, it doesn’t dictate rigid release dates or a fixed order of doing things. This can help a product team (and the whole business) to stay agile and respond to changing business and customer needs.

What is a Now, Next, Later roadmap?

It won’t surprise you that a Now, Next, Later roadmap consists of three columns. In its most basic, feature-driven form, it might look something like this:

As you can see in the example above (made in Notion), a Now, Next, Later roadmap provides us with a high-level view of the steps that we will be taking and the direction of travel, without committing to specific timeframes. The groupings should be defined by the following:

1. Now: Items that have been validated and are currently being executed. These are initiatives where we have high confidence that they are feasible, viable and desirable, through work done in our discovery phase.

2. Next: Items that are in or pending discovery, but might be discarded if we find that we aren’t confident enough in their technical feasibility, market viability or that they will provide value to our customers or end users.

3. Later: These are long term priorities where the scope is still undefined and haven’t yet undergone a full discovery phase. In fact they may never be selected for discovery as we learn from our customers and our priorities change – and that’s the point!

Theme-based vs feature-based Now, Next, Later roadmaps

This topic deserves its own post, but another (and arguably better) way to look at your Now, Next, Later roadmap is to plan by themes rather than features. This keeps you, and those who you present the roadmap to, out of feature wishlists and instead shows what problems we plan to solve. This will keep you focused on delivering value rather than simply churning out sparkly new features.

It might look something like this:

In the above example you can see that we avoid referencing specific features, and rather talk about user goals or themes. Within these cards—particularly those that are in the “Now” column—we will include references to specific features, but this will happen after we have been through discovery and decided on the best solution to the problem.

We start in the “problem” space, before working to a solution – read or watch Dan Olsen for more on this concept.

Presenting to stakeholders

For stakeholders more familiar with a traditional roadmapping approach (such as an objective timeline roadmap), you will need to lay some groundwork before showing them this style of roadmap.

It’s important to be aware that this isn’t just a different way of visualizing a traditional roadmap; it is a fundamentally different approach to planning a product. A Now, Next, Later roadmap embraces uncertainty, acknowledges priorities change and remains reactive to what we learn as we release features. Your stakeholders need to be comfortable with these principles before adopting this roadmapping tool. If not, it’s going to be a hard sell.

A Now, Next, Later roadmap embraces uncertainty, acknowledges priorities change and remains reactive to what we learn as we release features

Tools to use

If you’re working with your team in person, a Now, Next, Later roadmap can simply be a set of post-it notes on a wall that are visible to everyone. The advantage of this is that it can be seen by the team at all times. The disadvantage is that it’s not exactly portable when you need to show it to the wider team.

Digital tools like Trello, Notion or Miro will also do the job just fine – you can move things from column to column; add detail with descriptions, labels and comments; and share with the wider team easily.

There are, of course, specialist roadmapping tools out there – a quick Google will reveal a bunch of options.

When to use a Now, Next, Later roadmap

The strength of a Now, Next, Later roadmap lies in its flexibility. It is a commitment to learning and adapting, rather than to a twelve month development plan, which helps a team react to business and user requirements quickly. This also limits wasted work, since features/themes are only specced up when moved into the ‘Next' column and not before.

Some strengths of a Now, Next, Later roadmap are that:

• It’s easy to understand
• It’s low maintenance (no fiddly Gantt charts to edit)
• It’s flexible as priorities change

Use it if you work in an organization that values adaptability and lean ways of working above knowing a detailed release plan.

When not to use a Now, Next, Later roadmap

A Now, Next, Later roadmap can be limited in the detail that some teams demand (e.g dates). It is therefore not recommended when you need to present to stakeholders who want firm dates and timelines, or a concrete plan for several months in advance.

Some weaknesses of a Now, Next, Later roadmap are that:

• Timelines and features are not explicitly laid out
• It’s not a “traditional” roadmap, so might need some buy-in from stakeholders
• It’s not useful as part of a waterfall development process
• It doesn’t have a lot of detail, so is less useful for developers and some stakeholders

If these sound like blockers, you’ll want to consider an objective timeline roadmap – a more traditional roadmapping approach, useful for organizations that require exact delivery dates and detailed feature requirements a long time in advance.

You can also get a nice combination of roadmapping and delivery by using user story mapping for your roadmapping. This works well for highly technical teams, as it introduces strategy and the “why”, whilst still allowing the team to come up with technical solutions for users.

When to update your roadmap

There are no hard and fast rules about how often to update a Now, Next, Later roadmap, but reviewing every six weeks makes sense for a lot of teams.

Six weeks is half a quarter, and is enough time to run a discovery or development phase. In this time you can research and validate a concept or build something meaningful and ship it. You’ll want to take everything you have learned here and check that your roadmap still matches up to it.

In these sessions you should review as a team whether new cards need to be added, existing ones should be moved or if any should be removed. As a product manager, you’ll be reviewing the roadmap more regularly, thinking about what’s next as you learn from week to week.

In summary

A Now, Next, Later roadmap encourages us to only invest time into problems that are worth worrying about right now. The format communicates to the whole organization that building a product involves juggling a set of competing priorities, and that these priorities will change as we ship and learn – and that’s healthy.

If you and your organization want to work in a flexible way that can respond to change quickly, a Now, Next, Later roadmap can be an excellent tool.