Roadmapping — Part 5: now, next, later

Steedan Crowe
5 min readNov 28, 2023


With a Now, Next, Later roadmap, you know what you’re working on, but you may not know how long it will take or when it will be worked on, just that you have to finish item 1 before working on item 2.

Previously, in Part 4, we talked about the outcomes-based roadmap, which focuses on what you’re trying to achieve and allows a set amount of time to work on reaching that objective. It’s a great way to time-box efforts and commit to delivering value in a specified timeframe.

Although that’s pretty good already, you can get much more agile with the now, next, later roadmap. Move blazingly fast, focussing on what’s ahead, and think about the future in more detail when you get there.

This post was originally published in my Substack Newsletter, Roadmap Weekly.

I love the now, next, later format. Although it’s not always practical, I think you can achieve some of the best results this way in terms of speed and outcomes, and it reminds me of my days of working on scrappy teams at early-stage startups before they became encumbered. You don’t have to pretend to know how you’re solving the next problem; you’ll figure it out when you get there.

With a Now, Next, Later roadmap, you know what you’re working on, but you may not know how long it will take or when it will be worked on, just that you have to finish item 1 before working on item 2. That almost makes it sound like you can build whatever you want, but these tasks should still tie back to an objective, so don’t make the mistake of just building what’s next on your mind. Prioritization is just as important here.

Time horizons, not deadlines

Estimating everything you will build for the quarter or year is unnecessary. Get granular about what’s right in front of you, and keep an eye on the future. This keeps things flexible. As you approach, you can get more details about the work ahead. You’ll know a lot more by the time you get there and can plan the rest of the work much easier the closer it gets.

The Now

In your roadmap’s “Now” section, you’re actively engaging with well-articulated, meticulously detailed initiatives. These are not just broad ideas but are broken down into tangible tasks, ready for immediate action. This clarity and detail reflect your understanding and readiness to tackle these initiatives head-on, as they form the core of your current efforts.

The Next

Transitioning to the “Next” section, this is where your future focus lies after the completion of the “Now” tasks. The initiatives here are less granular, brushed with broader strokes as they are not immediately pressing. They remain contingent on the outcomes of your current projects, and while their place in the queue is acknowledged, detailed planning is not yet a priority.

The Later

Lastly, the “Later” section holds your long-term aspirations, those plans that loom on the horizon but are not immediately actionable. Here, you have an overarching view of the challenges you aim to address, though specific solutions are not yet in focus. This section serves as a reminder of your broader product vision, maintaining a trajectory for future exploration and refinement as these initiatives gradually shift from distant prospects to imminent realities.

Let’s summarize the benefits of now, next, later

Save time: Don’t waste hours estimating, scoping and preparing a detailed roadmap months or quarters into the future. Put your effort into learning your users’ needs, and you’ll get a clear picture of what to build next.

No wild guessing: No making wild guesses about how you will solve future problems. There is no scoping, planning and estimating to prioritize value vs. effort of things you might never even build.

Implement your learnings faster: Let the feedback and learnings from your current work inform your future work. As you finish what you’re working on now, you’ll have more details about what you will build next. You may even decide to shelf something because of what you learned, saving you from building the wrong things.

Avoid false promises: We know deadlines often get shared, and customers get disappointed. Let’s talk priorities instead of timelines and avoid these false hopes.

Outcomes over output: When you’re not stressing about deadlines and the cascading effects of not hitting a launch date, you can focus on ensuring you deliver the right things and avoid becoming a feature factory.

When not to use a now, next, later roadmap

Let’s be honest: a now, next, later roadmap won’t work for everything. Here are some times you may want to use one of the previously discussed formats or create a hybrid format.

3rd party integrations: especially if they’re already well-documented. In these cases, a well-detailed integration plan is ideal.

Security, Compliance or Regulatory deadlines: These deadlines are imposed on you, and you cannot change them. You must plan and work around these obstacles, keeping the rest of your roadmap flexible.

Strategic client needs: Especially applicable in enterprise software, your clients have deadlines, and a large-paying contract may have requirements and deadlines you have to work around. These items become priorities, and you can plan the rest of your roadmap around them. Hopefully, you’re working closely with your business development team and can keep these deadlines reasonable.

To learn more about roadmaps, check out the rest of this roadmapping series.

Roadmapping Series

Part 1: A living document

Roadmaps aren’t intended to remain static. We’ll explore some ways to help keep your roadmap fluid and up-to-date as things change.

Part 2: Prioritization and planning process

How do you decide what gets put on your roadmap?

Part 3: Milestones

When should you add Milestones to your roadmap? What constitutes a milestone?

Part 4: Outcome-based roadmaps

This type of roadmap focuses on outcomes over features or solutions.

Part 5: Now, Next Later 👈

Avoid concrete timeframes and focus on priorities.

Part 6 Development Roadmap

The roadmap you build for your dev team differs significantly from what you would create for your stakeholders and customers.

Part 7: Layering your roadmaps

How layering shows different levels of detail within your roadmap for various stakeholders and taking a simple approach to maintaining them.

Let me know if there’s anything else about roadmaps you want to see expanded on, and I’ll develop this series more if there’s enough interest.

Originally published at



Steedan Crowe

I’m Steedan, writer of, a newsletter for people doing Product Management