#roadmaps

A useful PM starter pack should include discovery guidance, a public product handbook, a strategy archive, and one writing template that makes decisions legible. That is enough to upgrade most teams more than another prioritization framework ever will.

The kinds of materials worth saving in this space:
- discovery templates that help teams compare evidence
- strategy memos that show the decision behind the roadmap
- metric review frameworks that connect product and business outcomes

Read:
- Continuous discovery overview: producttalk.org/continuous-discovery/
A durable foundation for teams trying to make research continuous instead of episodic.
- SVPG article archive: svpg.com/articles/
Useful for strategy, product operating models, and decision quality.
- Atlassian product management guide: atlassian.com/agile/product-management
A practical reference for planning, teamwork, and delivery rhythms.

Documents and downloadable guides:
- Opportunity solution tree guide: producttalk.org/opportunity-solution-tree/
Still one of the clearest visual frameworks for connecting discovery to roadmap choices.
- Atlassian product management guide: atlassian.com/agile/product-management
A useful operating reference for discovery, prioritization, launches, and stakeholder comms.

Watch:
- Lenny's Podcast video archive: youtube.com/@Lennyspodcast/videos
Product conversations that tend to stay practical instead of drifting into slogans.

Build or inspect:
- GitLab product handbook: handbook.gitlab.com/handbook/product/
One of the best public examples of product work written down in the open.

Image references:
- Opportunity solution tree visuals: producttalk.org/opportunity-solution-tree/
A good visual shorthand for teams trying to make discovery artifacts reusable.

A backlog can absorb almost any amount of ambiguity, which is why teams mistake motion for product thinking. The most expensive mistake is shipping a roadmap item that never had a written problem frame, success criteria, or post-launch review plan.

Common traps to watch:
- confusing backlog grooming with discovery
- publishing roadmaps without decision context
- tracking proxy metrics that never change planning

References that help correct the drift:
- SVPG article archive: svpg.com/articles/
Useful for strategy, product operating models, and decision quality.
- Opportunity solution tree visuals: producttalk.org/opportunity-solution-tree/
A good visual shorthand for teams trying to make discovery artifacts reusable.

This folio post is meant to be saved and revised. Add examples from your own work whenever one of these mistakes keeps resurfacing.

The sequence I trust here is: define the decision, gather enough evidence to compare options, document what you learned in a format others can search, and only then move a roadmap or staffing bet. That is slower than a hot-take roadmap and faster than undoing one.

A sequence I would actually hand to a teammate:
1. Start with the user problem, the business constraint, and the decision to unlock.
2. Capture research and evidence where the team can revisit it later.
3. Translate learning into roadmap movement, launch plans, and follow-up metrics.

Useful operating references:
- SVPG article archive: svpg.com/articles/
Useful for strategy, product operating models, and decision quality.
- GitLab product handbook: handbook.gitlab.com/handbook/product/
One of the best public examples of product work written down in the open.

If your team has a better workflow, post it with the context around team size, constraints, and exactly where the process tends to break.