Product Roadmaps

Marty Cagan argues that product managers who spend their time prioritizing a laundry list of feature requests are working on the wrong problem. A feature-request roadmap pushes unvalidated features into the plan, skips product discovery, and wastes engineering effort on things users may not need. Instead, a product roadmap should be a simple, high-level path toward the vision defined in the product strategy, focused on objectives rather than specs. Public roadmaps should be kept very abstract and conservative, since the dates on any roadmap are hopes until discovery and scheduling are done.

01Key takeaways

• Don't prioritize feature requests as your main output; focus on delivering value, usability, and feasibility.
• Lock in objectives and direction on the roadmap, not specific features, so discovery can determine the solution.
• Make sure you have a product strategy first, or the roadmap lacks context.
• Treat roadmap dates as hopes until discovery and engineering estimates confirm them.
• Keep public roadmaps high-level and conservative, sharing vision rather than commitments.
• Store the roadmap somewhere the team can access and see your reasoning, such as a wiki.

02Key sections

Feature request spreadsheets are the wrong job

Elaborate scoring models for feature requests push through features users don't need and add complexity. The PM's real job is delivering a valuable, usable, feasible product.

Locking in features skips discovery

At roadmap stage there's no evidence a feature is right or designable. Committing to specific features bypasses product discovery, which is where great products come from.

Types of roadmaps

Product roadmaps, portfolio roadmaps for shared engineering, and marketing's public roadmaps serve different purposes. Public roadmaps are essentially sales tools and should stay high-level with conservative dates.

What a good product roadmap looks like

It describes the path from today to the strategy's vision, reflects current priorities as objectives, and is not a spec or feature list. Dates are hopes until discovery and project scheduling confirm them.

03From the post

“A partnership dedicated to teaching best practices to product teams and product leaders”

04Frameworks mentioned

Summary and takeaways written by PM Atlas; quotes are short excerpts. © the original author.