Product Manager Hub

PM Roadmapping (Now/Next/Later, Outcome-Driven): A Working Guide (2026)

In short

PM roadmapping in 2026 has converged on outcome-driven Now/Next/Later as the dominant pattern, displacing feature-list quarterly timelines at most modern tech companies. The strongest roadmaps describe outcomes the team will achieve, not features the team will ship — they survive contact with reality because outcomes can be achieved multiple ways. The dominant operational failure: roadmaps that promise specific features for specific dates, then break under scope drift, technical surprises, or shifted priorities. Linear's published company roadmap and GitLab's public product handbook are two real-world references for what outcome-driven Now/Next/Later looks like in production.

Key takeaways

  • Now/Next/Later replaces quarterly Gantt-shaped roadmaps. Now is what's in flight; Next is the most-likely upcoming work; Later is the directional intent.
  • Outcome framing beats feature framing: 'Lift activation 8pp for new mobile users' is durable; 'Ship onboarding redesign' is brittle.
  • Real worked Now/Next/Later artefact below — based on the public Linear and GitLab patterns.
  • Three stakeholder-pressure patterns break roadmaps: drive-by adds, customer escalations, HiPPO overrides. Same patterns that break prioritization.
  • Roadmaps are communication artefacts, not commitment artefacts. Treating them as commitments is the dominant failure mode.

Now/Next/Later: a real worked artefact

Worked example for a growth PM team owning new-user activation on a 12M-MAU consumer subscription product. Each row is an outcome with the underlying hypothesis and 1–2 candidate solutions; the candidate solutions are visible but not committed.

Now (in flight, this 4-week cycle)

  • Outcome: Lift step-4 (Code Entered) conversion from 41% → 50% across all sources.
    Hypothesis: The 6-digit-code entry pattern fails on mobile-app-first traffic.
    Solution in flight: Magic-link-instead-of-code A/B test (50/50 split, 4-week run).
    Eng partner: Identity team. Status: Day 9 of 28.
  • Outcome: Reduce onboarding-completion drop between session-1 and session-2 from 38% to 30%.
    Hypothesis: Users abandon when day-2 isn't valuable enough to return.
    Solution in flight: Personalized day-2 content recommendations.
    Eng partner: Recommendations team. Status: Day 5 of 28.

Next (most likely 6–8 weeks ahead)

  • Outcome: Lift week-2 retention by 6pp on the social-graph-active cohort.
    Hypotheses (un-prioritized): (a) Friend-discovery surface; (b) shared-content nudges; (c) social-proof in onboarding.
    Decision pending: Customer-discovery interviews due by week 4 to pick hypothesis.
  • Outcome: Reduce trial-to-paid friction at upgrade prompt.
    Hypothesis: Pricing-page copy and placement.
    Decision pending: Pricing experiment design with finance partner.

Later (directional intent, 3–6 months out)

  • Activation experiments on geo-expansion markets (Q3).
  • Habit-loop intervention on day-7-active cohort (Q4).
  • Re-engagement playbook for 28+ day dormant users (Q4).

The artefact lives in Notion or Linear (Linear's roadmap surface supports outcome-grouped initiatives). It's published to the broader org, reviewed weekly with eng/design partners, and updated as outcomes are hit or hypotheses are killed. The Now section is the only commitment; Next and Later are working assumptions.

Outcome vs feature framing

Two roadmap rows, same intent:

Feature framing (brittle)Outcome framing (durable)
Ship onboarding-redesign v2 in MarchLift step-4 activation conversion from 41% to 50% by end of Q1
Launch the social-graph featureLift week-2 retention by 6pp on the social-graph-active cohort
Build a recommendation engineReduce session-1-to-session-2 drop from 38% to 30%

The outcome framing is durable because there are usually 3+ candidate solutions for the same outcome. If the first hypothesis fails (the magic-link experiment doesn't move step-4), the team still owns the outcome and tries a different hypothesis. The feature framing collapses on first contact: 'we shipped onboarding-redesign v2; conversion didn't move; what now?'

Marty Cagan's 'outcomes over outputs' framing is the canonical reference for this shift; SVPG's writing on outcome-driven roadmaps documents the pattern at scale across coached companies.1

Real published roadmap examples

Two public examples worth studying:

  • Linear's company roadmap. linear.app/method documents the outcome-driven cycle-based shipping cadence; specific public roadmap surfaces (e.g., Linear changelog) reveal the actual shipping rhythm.
  • GitLab's public product handbook. handbook.gitlab.com/product publishes the company's product strategy, OKRs, and roadmap publicly. The level of detail is rare; reading it demystifies how a 1,000+ person product org actually shapes a roadmap.2

What both have in common: outcomes named at the top of each roadmap section; hypotheses listed but not committed; date commitments are coarse (this quarter, next quarter, later) rather than fine (March 14).

Stakeholder pressure patterns

The three patterns that break prioritization (drive-by adds, customer escalations, HiPPO overrides) also break roadmaps. Roadmap-specific defenses:

  1. Drive-by add: 'Can we add X to the Now section?' Move it to Later by default. Promotion to Next requires a customer-discovery cycle; promotion to Now requires displacing a current Now item. Make displacement explicit.
  2. Customer escalation: 'Big customer wants Y by Q2.' Pipeline the request through the customer-input → roadmap process. If Y is genuinely strategic, it goes through Next; the pipeline-shape forces the trade-off conversation.
  3. HiPPO override: 'I want Z on the roadmap.' Get the override in writing; force it to displace an existing commitment, named explicitly. The HiPPO can override; what they can't do is override silently while the PM owns the missed commitment.

What hiring managers screen for

Senior+ PM interviews on roadmapping converge on three signals:

  • Outcome-vs-feature judgment. 'Walk me through your last roadmap' — strong PMs lead with outcomes; junior PMs lead with feature lists. The choice is the screen.
  • Naming the trade-off. 'What did you cut to make room for X?' If the answer is 'we found capacity,' the screen tightens. Real roadmaps require visible cuts.
  • Stakeholder-follow-up scenarios. 'Tell me about a time you held the roadmap against a senior leader's drive-by add.' Specifics matter. The PM who can name the conversation, the trade-off documented, and the outcome of the override decision converts better than the PM with a clean roadmap and no friction.

Frequently asked questions

Should I publish my roadmap externally?
Public roadmaps work for developer-tools and B2B SaaS where customers benefit from visibility (GitLab, Linear, Stripe Connect changelog). Skip for consumer or competitive contexts where the roadmap is a strategy reveal.
How frequently should I update the roadmap?
Now section: weekly. Next section: every 2 weeks. Later section: monthly. The cadence matches the commitment level.
What if exec stakeholders demand date commitments?
Trade specific dates for confidence intervals. 'We're 80% confident this ships in March; 95% confident by end of Q1' carries more information than a single date and is harder to misuse politically.
How do I roadmap research and discovery work?
Treat discovery as outcomes too: 'understand why the trial-to-paid step-3 has a 41% drop' is a valid Now-section item. The output of discovery is hypotheses for Next-section work, not features themselves.
Should roadmaps include eng debt and platform work?
Yes for cross-team visibility. Outcome framing: 'reduce p99 page-load latency from 4.2s to 2.5s' is the platform-work equivalent of a feature-work outcome. Mixing them on one roadmap clarifies trade-offs across the portfolio.
How does roadmapping change at FAANG?
Cross-org coordination dominates. Within-team roadmaps still work as outcome-driven Now/Next/Later. Cross-org roadmaps are mostly about negotiated alignment with adjacent teams; the artefact becomes a coordination tool more than a planning tool.
Should I use a roadmap tool (Productboard, Aha!, Roadmunk) or a Notion page?
Smaller teams: Notion or Linear is enough. Larger teams or B2B SaaS with explicit customer roadmap surfaces: Productboard or Aha! pay for themselves through stakeholder integration. Don't buy a tool until the size justifies it.
What's the most common roadmap failure mode?
Treating the roadmap as a commitment artefact rather than a communication artefact. The roadmap is what we currently believe will produce the outcomes; it's not a contract. Teams that treat it as a contract end up shipping the roadmap rather than the outcomes.

Sources

  1. Marty Cagan / SVPG — Outcomes vs Output (the canonical outcome-driven roadmap framing).
  2. GitLab Product Handbook — Public product strategy, OKRs, and roadmap (live reference).
  3. Linear — The Linear Method (cycle-based outcome shipping cadence).
  4. Teresa Torres — Opportunity-Solution Trees (continuous discovery and roadmap shaping).
  5. Lenny Rachitsky — How to build a product roadmap (case studies and templates).

About the author. Blake Crosley founded ResumeGeni and writes about product design, hiring technology, and ATS optimization. More writing at blakecrosley.com.