Discovery Roadmap Template for Product Planning

A delivery roadmap plans what you will build and when. A discovery roadmap plans what you will learn and when. The output of discovery is a decision (build, pivot, or kill), not a shipped feature. Discovery roadmaps feed into delivery roadmaps. Once you have enough signal, the validated ideas move to the delivery side with higher confidence. The [guide to building a product roadmap](/guides/how-to-build-a-product-roadmap) covers the delivery side.

A good benchmark is 30-40% of a PM's time on discovery for growth-stage products. Early-stage products may spend 60-70% on discovery because the problem space is less defined. Mature products may spend 15-20% because the core workflows are established and discovery focuses on expansion opportunities. The [Product Discovery Handbook](/discovery-guide) covers how to balance discovery and delivery.

Reframe the conversation. Instead of "we will ship feature X in 8 weeks," say "we will know whether feature X is worth building in 4 weeks, and if validated, it ships in 8 weeks after that." Discovery reduces the risk of building the wrong thing. A 4-week discovery cycle that kills a bad idea saves 8-12 weeks of wasted engineering time. Frame discovery as risk reduction, not delay.

Two to three active discovery tracks is the practical maximum for a team with one PM and one researcher. Each track requires recruiting, running sessions, synthesizing, and presenting. Running five tracks simultaneously means none get adequate depth. Stagger your bets so you finish one before starting the next, as shown in the timeline section above. ---