assimovt 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:
- Betting table: Leadership reviews shaped pitches and bets on what to build next cycle. Not everything gets picked.
- Cool-down: 1-2 weeks between cycles for bug fixes, exploration, and shaping future work.
- 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:
| Horizon | Outcome | Evidence | Status |
|---|---|---|---|
| Now | Reduce onboarding drop-off to under 30% | 5 interviews, 60% current drop-off | In progress, week 2/3 |
| Next | Enable self-serve data export | 12 support tickets/month | Shaped, needs team |
| Later | Multi-workspace support | 3 enterprise prospects requested | Unvalidated |
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.