Build roadmaps organized by outcomes, not feature lists. A roadmap answers "what problems are we solving and in what order?" — not "what features will we ship and when?" Dates on a roadmap beyond 6 weeks are fiction. Treat them that way.

Now / Next / Later

Three time horizons, decreasing in certainty:

Now (Committed — this cycle)

• Currently in progress or about to start
• Fully shaped: problem defined, solution scoped, appetite set
• Team assigned, expected to ship this cycle
• 1-3 items maximum

Next (Shaped — next 1-2 cycles)

• Problem validated, solution partially shaped
• Not yet assigned to a team
• May change based on what we learn from "Now" items
• 3-5 items maximum

Later (Raw — ideas worth exploring)

• Problems we believe are real but haven't validated
• No solution shaped yet
• Will be promoted to "Next" when evidence supports it, or killed
• No limit, but prune quarterly

Roadmap Items Are Outcomes, Not Features

Each roadmap item is framed as a problem to solve or an outcome to achieve:

Bad (feature-list roadmap):

• Build team collaboration features
• Add CSV export
• Redesign settings page

Good (outcome-based roadmap):

• Reduce time-to-first-value for team signups from 15 min to under 5 min
• Enable users to get their data out without contacting support
• Reduce settings-related support tickets by 50%

The solution emerges during shaping, not during roadmap planning.

Shape Up Cycle Planning

For teams using Shape Up cycles:

1. Betting table: Leadership reviews shaped pitches and bets on what to build next cycle. Not everything gets picked.
2. Cool-down: 1-2 weeks between cycles for bug fixes, exploration, and shaping future work.
3. No carry-over: Work that doesn't ship in a cycle is not automatically carried over. It must be re-pitched.

Presenting the Roadmap

Keep it to one page or one screen. If your roadmap needs scrolling, it's too detailed.

Format as a simple table:

Guidelines

• CRITICAL: NEVER put dates on roadmap items beyond 6 weeks. You don't know and pretending you do erodes trust.
• NEVER build a feature-list roadmap. Organize by outcomes and problems.
• ALWAYS limit "Now" to 1-3 items. If you're working on 8 things, you're finishing none of them.
• NEVER let "Later" items skip to "Now" without shaping and evidence.
• ALWAYS prune "Later" quarterly. Kill items that haven't gained evidence in 3 months.
• ALWAYS review and update the roadmap at the start of every cycle, not just quarterly.
• NEVER present a roadmap without evidence for each item. A roadmap without evidence is a wish list.

Built on Shape Up (Basecamp) cycle planning and the Now/Next/Later framework. Skills from productskills.