roadmap-planninglisted

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