Now Next Later Roadmaps: The Simple Framework That Oversimplifies Strategy

I’m going to say something unpopular: Now Next Later roadmaps are overrated.

They’re everywhere. Product Twitter loves them. Agile coaches recommend them. Startups adopt them because they’re simple. And therein lies the problem—they’re too simple. The simplicity that makes them appealing is exactly what makes them dangerous.

Now Next Later strips away the hard parts of roadmap planning. Which sounds liberating until you realise those hard parts exist for a reason.

What Is Now Next Later?

For the uninitiated, Now Next Later is a roadmap format that organises work into three time-based buckets:

• Now: What we’re working on currently
• Next: What we’re planning to work on soon
• Later: What we’re considering for the future

No dates. No commitments. No specific quarters. Just three buckets with decreasing certainty as you move right.

The appeal is obvious:

• Simple to understand and communicate
• Doesn’t require precise estimates
• Embraces uncertainty about the future
• Easy to maintain and update

So far, so reasonable. So why am I skeptical?

Problem 1: No Capacity Visibility

Here’s the question Now Next Later can’t answer: Who is doing the work?

When you organise by Now/Next/Later, you’re organising by TIME, not by CAPACITY. But capacity—the available hours of actual humans—is the real constraint.

A grid-based roadmap shows you that Squad A has 3 sprints of capacity in Q1, with one objective already allocated. You can see what’s possible and what’s not.

A Now Next Later roadmap shows you a pile of items in “Now” with no visibility into:

• Which team is working on each item
• Whether you have enough people to do everything in “Now”
• How items in “Next” will fit when “Now” is done
• Whether “Later” is realistic given existing commitments

This isn’t a minor oversight—it’s the central failing of the format.

Without capacity visibility, you can’t answer the most important roadmap question: Is this achievable?

For why this matters, see our deep dive on capacity-based roadmap planning .

Problem 2: “Later” Becomes a Graveyard

In theory, “Later” is for items you’re seriously considering but haven’t committed to yet.

In practice, “Later” becomes where ideas go to die.

I’ve audited dozens of Now Next Later roadmaps. The pattern is consistent:

• Now: 5-10 items, actively being worked
• Next: 15-20 items, vaguely planned
• Later: 50+ items, never looked at

That “Later” column isn’t a planning bucket—it’s a guilt-free way to say “yes” to every idea without actually committing to anything. It’s a parking lot that nobody revisits.

And here’s the insidious part: stakeholders see their idea in “Later” and feel heard. They don’t realise “Later” is where requests go to be forgotten.

Eventually, someone notices that “Later” never becomes “Next.” Trust erodes. The roadmap loses credibility.

Build roadmaps with real capacity constraints—sign up free

Problem 3: Avoids Hard Prioritisation Decisions

The hardest part of roadmap planning is saying “no.”

When capacity is visible, you can’t avoid it. You have 4 squads × 6 sprints = 24 squad-sprints of capacity. If you have 30 objectives, 6 don’t fit. You must choose which 6 to cut.

Now Next Later lets you avoid this moment of truth.

“We’re not saying no—it’s in Later.”

This feels diplomatic. It feels collaborative. It feels humane.

But it’s a lie. You ARE saying no—you’re just not admitting it. And by not admitting it, you’re not having the strategic conversation about which things don’t fit and why.

Real prioritisation requires constraints. Now Next Later removes the constraints that force prioritisation.

Problem 4: No Firm Footholds

In our article on limiting work in progress , we discuss the concept of “firm footholds”—completing things before starting new things.

Now Next Later roadmaps struggle with this. Because there’s no explicit capacity allocation, it’s unclear when “Now” is complete and “Next” can begin.

The result: scope creep in “Now” (it’s never really done), premature starts on “Next” (because someone’s available), and a growing list of partially-complete work.

Without clear capacity boundaries between buckets, work bleeds across them. You end up with everything in progress and nothing finished.

When Now Next Later Actually Works

I don’t hate Now Next Later unconditionally. There are contexts where it makes sense:

1. Very Early Stage Startups

If you have 3 people, you don’t need capacity planning. You ARE the capacity. Everyone knows what everyone else is doing.

Now Next Later provides just enough structure without overhead. You’ll outgrow it quickly, but that’s fine.

2. High-Uncertainty Discovery Phases

When you genuinely don’t know what you’re building yet—pre-product-market-fit, major pivots—detailed capacity planning is premature.

Now Next Later acknowledges the uncertainty: “Here’s what we’re testing now, here’s what we’ll test next, here’s what we might test later.”

3. External Communication

Sometimes you need to communicate direction to external stakeholders (customers, partners) without making commitments.

Now Next Later is a safe format for this: “We’re working on X now, considering Y next, thinking about Z eventually.” No dates, no promises.

But notice: these are all special cases. For established teams with meaningful capacity to allocate, Now Next Later falls short.

What to Use Instead

The alternative isn’t more complexity for its own sake—it’s appropriate complexity for the problem you’re solving.

Option 1: Squad × Sprint Grid

The approach we use in RoadmapOne :

• Rows = Squads (teams with capacity)
• Columns = Sprints (time periods with boundaries)
• Cells = What each squad is pursuing each sprint

This immediately surfaces capacity constraints. You can see:

• Which squads are over-allocated
• Which sprints have too much work
• Which objectives have no home

For more on why grids beat timelines, see Grid vs Timeline .

Option 2: Quarterly Outcomes

Organise by quarter, with clear ownership:

• Q1: Objectives A, B (owned by Squad 1, Squad 2)
• Q2: Objectives C, D (owned by Squad 1, Squad 3)
• Beyond Q2: Lower confidence, subject to change

Still simple, but with capacity (squad ownership) and time (quarters) explicit.

Option 3: Capacity-Constrained Now Next Later

If you must use Now Next Later, add capacity constraints:

• Now: Max 3 items per squad
• Next: Max 5 items total (must fit in next quarter’s capacity)
• Later: Reviewed quarterly, items either promoted or removed

The constraints force prioritisation. “Later” has a shelf life.

See capacity-based roadmaps in action—free sign-up

The Executive Conversation

Here’s a conversation I’ve had with leadership teams:

Me: “Walk me through your roadmap.” PM: “Sure—these items are in Now, these are in Next, these are in Later.” Me: “Great. How many engineers do you have?” PM: “About 40.” Me: “And how much of their capacity goes to each bucket?” PM: “Well… we don’t track it that way.” Me: “So how do you know if ‘Now’ is achievable?” PM: “…”

This isn’t a gotcha—it’s the central question of roadmap planning. If you can’t answer “is this achievable given our capacity?”, your roadmap is wishful thinking.

The Discovery Argument

Advocates argue: “We don’t know what we’ll build until we do discovery. Now Next Later lets us stay flexible.”

I agree with the premise but disagree with the conclusion.

Yes, you don’t know what you’ll build. But you DO know:

• How many people you have
• How much time exists in a quarter
• How many things can be in progress simultaneously

These constraints exist regardless of what you build. Capacity-based planning embraces them. Now Next Later ignores them.

You can do discovery within a capacity-constrained roadmap. The roadmap shows OUTCOMES you’re pursuing , not FEATURES you’re building. Discovery determines the features. The roadmap allocates capacity to outcomes.

What the Popularity of Now Next Later Reveals

The widespread adoption of Now Next Later tells us something uncomfortable: teams find capacity planning hard.

And it IS hard. It requires:

• Knowing your team’s capacity (many don’t track it)
• Making explicit prioritisation choices (uncomfortable)
• Saying “no” to ideas (politically difficult)
• Maintaining the roadmap as capacity changes (ongoing effort)

Now Next Later’s popularity is a symptom of teams avoiding this work, not evidence that the work isn’t necessary.

Migrating Away from Now Next Later

If your team uses Now Next Later and you’re ready to evolve, here’s a migration path:

Step 1: Add Team Ownership

For every item in Now/Next, assign an owning team. If you can’t assign an owner, the item isn’t real.

Step 2: Count Capacity

How many sprints (or story points, or ideal weeks) does each team have per quarter? Make this explicit.

Step 3: Constrain “Now” and “Next”

“Now” can only contain what fits in current sprint capacity. “Next” can only contain what fits in next quarter’s capacity.

Step 4: Purge “Later”

Move to quarterly reviews. If something in “Later” isn’t promoted to “Next” within 2 quarters, remove it. “Later” is not permanent parking.

Step 5: Graduate to Grid

Once you’re tracking capacity per team per time period, you essentially have a grid. Make it visual. Tools like RoadmapOne make this straightforward.

The Bottom Line

Now Next Later roadmaps are popular because they’re simple. But they’re simple because they omit the hard parts of planning—capacity constraints, explicit trade-offs, accountability for completion.

For small teams in high-uncertainty phases, that simplicity may be appropriate. For established teams with meaningful capacity to allocate, it’s not enough.

The question isn’t “Now, Next, or Later?"—it’s “What can our teams actually achieve, and in what sequence?”

That question requires capacity visibility. And that’s what Now Next Later can’t give you.

Frequently Asked Questions

Can RoadmapOne show a Now Next Later view?

Yes—you can filter your roadmap to show items by time horizon. But underneath, the capacity allocation is still visible. You get the communication simplicity of Now Next Later with the planning rigour of capacity-based allocation.

What about stakeholders who love Now Next Later’s simplicity?

Use it for external communication, but plan internally with capacity constraints. Your external “Now Next Later” view is derived from your capacity-planned roadmap, not a replacement for it.

Isn’t demanding capacity planning too heavyweight for agile teams?

Agile doesn’t mean no planning—it means appropriate planning. Knowing how many people you have and how much work fits isn’t heavyweight; it’s table stakes.

What if our capacity is genuinely uncertain?

Model the uncertainty. “We have 3-4 squads (depending on hiring)” becomes a range. “We expect 5-7 sprints of work in Now.” Uncertainty is fine—ignoring constraints isn’t.

How do we handle items that don’t fit anywhere?

That’s the point. If something doesn’t fit, you’ve discovered a truth: you lack capacity for it. Now you can decide—increase capacity, defer other work, or accept that this item won’t happen.