Skip to main content

Roadmaps: Now/Next/Later, Capacity vs Wish-List

What This Concept Is​

A roadmap converts a strategy into a sequenced plan. The now/next/later format (Janna Bastow, ProdPad) organizes work by time horizon and commitment level rather than by fixed dates:

  • Now. In flight this quarter. Resourced. Has a committed owner and completion criteria. Date-bearing.
  • Next. Intended for the next quarter or two. Scoped enough to estimate. Not yet fully resourced; may be displaced by Now slippage.
  • Later. Directionally intended, one or more quarters out. Not scoped. Placeholder for strategic intent; should not be sold as a commitment.

The format trades the false precision of Gantt-chart roadmaps for honesty about confidence. A Now item is a commitment; a Later item is an intent.

Why It Matters Here​

Engineering roadmaps fail the same way strategies fail: they become wish lists. Symptoms:

  • every quarter's "Now" is the previous quarter's "Next" minus the 30% that slipped
  • "Later" grows without bound because adding items costs nothing
  • no item is ever killed; items migrate sideways indefinitely
  • capacity is never added to the math, so the roadmap shows 150% of a team's real capacity

A Staff+ engineer should be able to produce a roadmap that honestly accounts for capacity, reflects the strategy's guiding policy, and gets more trustworthy over time - not less.

Concrete Example​

Orders platform team, paved-road strategy from Concept 5. Team capacity: 4 engineers, ~60% project time after on-call and interruptions = ~10 engineer-weeks per quarter.

Now (Q1, committed, ~10 eng-weeks):

  • Publish golden-path catalog v1 (4 eng-weeks)
  • Migrate two pilot product teams to golden path (3 eng-weeks)
  • Retire two specific consulting engagements, one at a time (2 eng-weeks)
  • On-call + unplanned buffer (1 eng-week)

Next (Q2, intended):

  • Product-team tier-1 rotation standup (estimated ~3 eng-weeks)
  • Retire embedded-engineer program (estimated ~2 eng-weeks)
  • Golden-path v2 (database, queue) (estimated ~5 eng-weeks)

Later (Q3+, directional):

  • Paved-road self-service portal
  • Deprecation of legacy platform-consulting runbooks
  • Cross-team paved-road adoption metric as a company OKR

Notice: Now adds up to real capacity. Next is estimated but unresourced. Later is intentional but uncommitted. Nothing is promised at a date it cannot support.

Concrete Counter-Example: A Wish-List Roadmap​

Most published roadmaps, if examined honestly, look closer to this:

Q1: Orders rewrite, Payments latency fix, new Admin UI, database migration, SSO integration, observability revamp. Q2: Real-time fraud detection, partner API v2, regional expansion (3 new regions), dark mode, accessibility audit. Q3: AI-assisted ordering, merchant self-serve, loyalty platform, mobile v3, data warehouse migration.

No capacity math is shown. Every quarter contains at least four quarters of work. The guiding policy is invisible: if the policy is "focus on Orders reliability," Q1 should not also cover SSO; if it is "grow the merchant platform," regional expansion is out of scope. The list is the sum of what each stakeholder asked for, not a prioritized plan.

A Staff+ engineer reviewing this roadmap should ask three questions before anything else: What guiding policy does this derive from? What is the team's real net capacity per quarter? Which items will be killed this quarter, not just deferred? The answers are usually "unclear," "we don't know," and "none," which is the diagnosis.

Common Confusion / Misconception​

"Dates equal commitment." Dates on a wish list are fiction. Commitment is capacity + owner + completion criteria. A "Q3 launch" without an owner and without capacity is not a commitment; it is a hope.

"A roadmap is a strategy." No. A roadmap implements a strategy. If your roadmap does not derive from a guiding policy (Concept 4), it will get trimmed arbitrarily under budget pressure because it has no principle to protect.

"Later is where we put everything we hope to do." Later should still be filtered by strategy. If an item does not support the current guiding policy, it does not belong on any horizon - it belongs in a "considered and rejected" list.

"Capacity is manager work." Staff+ engineers who do not think in capacity produce overpromised roadmaps their managers cannot defend. Capacity is an IC concern when you are the person naming what the team will ship.

How To Use It​

Build a roadmap in this order:

  1. Start from the strategy's coherent action (Concept 5). The actions are the Now candidates.
  2. Compute capacity honestly. headcount * weeks in quarter * project-time fraction. Subtract on-call, hiring, holidays, and planned toil.
  3. Fit Now to capacity. If Now is over capacity, move items to Next. Don't let Now optimism absorb 100% of the buffer.
  4. Estimate Next. Roughly. One-line estimates. Do not pretend precision.
  5. Keep Later short and directional. If Later has 30 items, it is a wish list. Trim.
  6. Update monthly. Not weekly (noise). Not quarterly (too late).

Check Yourself​

  1. What is the difference in commitment between a Now item and a Later item?
  2. Name three things a Later list should not contain.
  3. How do you compute real project capacity for a team of 4 in a 13-week quarter?

The Capacity Math, Honestly​

A chronic failure mode is publishing a roadmap that does not pass elementary arithmetic against the team's actual calendar. A defensible capacity calculation for a team of N engineers in a Q-week quarter:

  1. Raw engineer-weeks. N * Q. For 4 engineers in a 13-week quarter, 52 eng-weeks.
  2. Subtract planned absence. Vacation, holidays, training, hiring loops. Typically 10-20% at scale-ups; often under-counted at startups.
  3. Subtract on-call overhead. For a primary on-call rotation, ~10-20% of the on-call engineer's time disappears into interruption cost plus follow-up. Count this explicitly.
  4. Subtract keep-the-lights-on (KTLO) work. Security patches, dependency upgrades, oncall remediation tickets. At an honest team this is 15-30% of capacity.
  5. Multiply by a focus factor. Even "project time" is not 100% coded - meetings, PR reviews, design discussions. A realistic focus factor is 0.5 to 0.7.

For the 4-engineer example above, a defensible answer often lands near 15-20 eng-weeks of net project time out of the 52 raw weeks. Leaders who plan against 40 eng-weeks on that same team produce over-committed roadmaps by default. This math is typically what separates a trustworthy roadmap from a wish list; the arithmetic itself is boring, but doing it is how you earn the right to say "no" to new work that does not fit.

Mini Drill or Application​

Take your current team (or a team you have worked with). Build a now/next/later roadmap:

  • compute the team's real project capacity for the next quarter (show the math)
  • list Now items totalling no more than that capacity
  • list 3-5 Next items with rough estimates
  • list 3-5 Later items, directional only

Then delete the weakest Now item and move it to Next. Notice how uncomfortable this feels. That discomfort is the evidence that you are making a real prioritization.

Extension: bring the roadmap to your manager and ask for the formal commitment list (what they will promise to the exec team). The gap between Now and that commitment list is either scope you should negotiate or reality your manager is hiding from their own leadership.

Transfer / Where This Shows Up Later​

Roadmaps are the operational face of strategy and the contact surface where most influence happens:

  • Strategy (Concepts 4-5). The coherent actions are Now candidates; the anti-scope populates what the roadmap should not have. A roadmap that violates anti-scope is a signal the strategy is being ignored.
  • Written-first (Concept 7). The roadmap is itself a written artifact; comments on it are where prioritization is contested. Roadmaps circulated only as slide decks drift because they are hard to comment on.
  • Stakeholder mapping (Concept 8). Every Now item has an Accountable; every Next item should have a Consulted. Roadmap items without stakeholders are how cross-team work stalls.
  • Disagree-and-commit (Concept 9). Disagreements with a roadmap usually land in one of three places: the capacity math, the guiding policy, or the ordering. Naming which is the disagreement is the first move.
  • Communication (Concepts 10-12). Exec versions compress Now into three bullets; peer versions include capacity math; customer versions present only the public-facing cadence. Each is a different artifact.
  • Personal strategy (Concept 15). Your personal 18-month plan is your own now/next/later; the capacity math becomes sustainable-pace rules.
  • Semester 8. M1 (interview prep), M2-M4 (team/service work) all benefit from now/next/later framing. Semester 10 M5 (staff+ career) explicitly applies the model to a career plan.

Read This Only If Stuck​

No local book chunk covers now/next/later directly; closest supporting chunks: