Now Next Later Roadmap Explained

Every product team has experienced this: you publish a roadmap with dates, and within two weeks, something shifts. A critical bug forces you to reprioritize. A key customer requests something urgent. Suddenly your "Q2 Roadmap" is fiction, and the team is either scrambling to update it or, worse, ignoring it entirely.

The now next later roadmap solves this by replacing fixed dates with time horizons. Instead of promising "Feature X ships on April 15," you communicate "Feature X is what we're working on now." It's a simple shift, but it changes how your entire team thinks about prioritization.

I started using this framework at Feeqd after burning through three timeline roadmaps in a single quarter. The problem wasn't planning. The problem was false precision. Once I switched to now/next/later buckets driven by real user feedback, the roadmap became a tool the team actually trusted.

What Is a Now Next Later Roadmap?

A now next later roadmap organizes work into three time-based horizons instead of specific dates:

• Now contains the work your team is actively building. These items are committed, scoped, and in progress. Think of "now" as your current sprint or the next 2-4 weeks.
• Next holds items that are validated and prioritized but haven't started yet. They're the next batch of work once the "now" column clears. Roughly 1-3 months out.
• Later captures items worth doing but not yet prioritized in detail. These are future possibilities, often based on early feedback signals. Three months or more away.

The framework was popularized by Janna Bastow at ProdPad as an alternative to Gantt chart-style roadmaps. It aligns well with the outcome-based roadmap thinking that Marty Cagan advocates at SVPG. The core insight is that certainty decreases as you look further into the future, and your roadmap format should reflect that.

Items in "now" have high certainty: you know what you're building and roughly when it ships. Items in "later" have low certainty: they might change shape entirely before you get to them. A now next later roadmap makes this uncertainty visible rather than hiding it behind fake dates.

How It Maps to Feeqd's Roadmap

If you use Feeqd's roadmap feature, you'll notice the kanban layout uses four columns: Pending, Next, In Progress, and Completed. The mapping is direct:

This gives your team a working board and your users a clear, public view of what's happening. No dates to defend, no quarterly promises to break.

Why It Works Better Than Timeline Roadmaps

Timeline roadmaps create three problems that now/next/later avoids entirely.

1. False Precision Creates False Promises

When you put a date next to a feature, stakeholders treat it as a commitment. "You said Q2" becomes the refrain in every status meeting, even if the original estimate was a rough guess. The now next later format communicates intent and priority without locking you into a delivery date that was always uncertain.

2. Reprioritization Breaks the Format

Timeline roadmaps assume linear execution: Feature A, then B, then C, each by a date. But product development doesn't work that way. New data comes in, priorities shift, and scope changes. With a timeline roadmap, every change requires updating dates and re-communicating the new plan.

With now/next/later, moving something from "next" to "now" is a natural part of the process. The format expects change.

3. Teams Align on Priority, Not Deadlines

When a roadmap is organized by time horizons, the conversation shifts from "when will this ship?" to "is this the right thing to work on next?" That's a much more productive conversation. It forces teams to discuss relative priority rather than absolute dates.

I've found this especially valuable when sharing roadmaps publicly. Users who see a now/next/later roadmap understand that "next" means "this is coming, but we're not committing to a date." It sets honest expectations. If you want to see how closing the feedback loop ties into this, that's the communication side of the same coin.

How to Build a Now Next Later Roadmap

Here's the process I use, and it starts well before you touch the roadmap itself.

Step 1: Collect Feedback With Voting

The foundation of a data-driven roadmap is quantified user demand. You need to know not just what users are requesting, but how many users want each thing.

In Feeqd, this means setting up feedback boards where users can submit feature requests, report bugs, and share ideas. Other users can then upvote those submissions. The vote count becomes your demand signal.

Without voting, you're relying on whoever emails the loudest. With voting, you have a board-level ranking that surfaces the most requested features automatically.

Step 2: Review Rankings and Group by Theme

Once you have voting data, pull up your board rankings. Sort by vote count and look for patterns:

• Are the top 5 requests all related to a single area (e.g., integrations, reporting, mobile)?
• Are there quick wins mixed in with large projects?
• Which requests align with your product vision, and which are edge cases?

Group related requests into themes. "Add Slack integration," "Add Zapier support," and "Connect to my CRM" might all fall under an "Integrations" theme.

Step 3: Assign Items to Buckets

Now you make the actual prioritization decisions. For each theme or individual item:

Move to "Now" if:

• It has high vote count AND your team has capacity to start
• It aligns with your current strategic focus
• It unblocks other high-value work

Move to "Next" if:

• It has strong demand but the "now" column is full
• It requires design or research before development can start
• It depends on something currently in progress

Move to "Later" if:

• It has moderate interest but doesn't fit the current focus
• It's a big initiative that needs more user validation
• The feedback signal is early (a few votes, but growing)

In Feeqd, this means dragging feedback entries from your board into your roadmap and placing them in the appropriate column. Each roadmap item stays linked to its original feedback entry, so you can always trace a roadmap decision back to the user votes that justified it.

Step 4: Make It Public

A now next later roadmap works best when your users can see it. Publishing your roadmap creates transparency and reinforces the feedback loop: users submit feedback, they see it appear on the roadmap, and they know their input matters.

This is what separates a data-driven roadmap from an internal planning document. When users can see their upvoted feature move from "Next" to "Now," they trust the process. That trust leads to more feedback, which leads to better prioritization. It's a virtuous cycle, and it's the core of what a good feedback management tool should enable.

Step 5: Review and Rotate Weekly

A now next later roadmap isn't a set-and-forget artifact. Review it weekly with your team:

• Move completed "now" items to "done"
• Promote the highest-priority "next" items to "now"
• Check if any "later" items have gained enough votes to move up
• Archive items that are no longer relevant

The voting data makes these conversations objective. Instead of debating opinions, you're looking at numbers.

Now Next Later Roadmap Examples

Here's how the buckets might look for a SaaS product at different stages.

Example: Early-Stage SaaS (50 Users)

At this stage, "now" is dominated by basics: fixing what's broken and adding table-stakes features. "Later" captures aspirational requests that aren't urgent yet.

Example: Growing SaaS (500 Users)

With more users, the vote counts are higher and the signal is clearer. You can see exactly which integrations matter most and which "nice to have" features are building momentum in "later."

FAQ

What is the now next later framework?

The now next later framework is a roadmap format that organizes planned work into three time horizons: "now" (actively in progress), "next" (validated and coming soon), and "later" (on the radar but not yet prioritized). It was created as an alternative to timeline roadmaps, replacing specific dates with relative priority. The framework is especially popular among agile teams because it accommodates changing priorities without requiring constant date updates.

How is a now next later roadmap different from a timeline roadmap?

A timeline roadmap assigns specific dates or quarters to each feature ("Ship search in Q2"). A now next later roadmap assigns relative priority without dates ("Search is what we're building now"). The practical difference: timeline roadmaps break every time priorities shift, while now/next/later expects and accommodates change. Timeline roadmaps also create implicit commitments to stakeholders, while now/next/later communicates intent and priority honestly.

Can you add dates to a now next later roadmap?

You can, but it partially defeats the purpose. Some teams add rough time ranges to the "now" column (e.g., "shipping this month") since items in active development have reasonable date estimates. Adding dates to "next" or "later" reintroduces the false precision problem. A better approach: use dates only for items in "now" and let the horizon labels handle everything else. If stakeholders need dates, share them verbally with caveats rather than embedding them in the roadmap.