Product Management

Product work becomes less political when the evidence trail is visible. The best public product writing keeps pushing teams toward explicit decisions, reusable research notes, and roadmaps that explain why something matters before they explain when it ships.

Three signals I would keep in view:
- Strong product management creates alignment by making tradeoffs legible.
- Discovery quality improves when insights are stored in reusable formats.
- Roadmaps work best when they explain why, not just what and when.

Read first:
- 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.

Documents worth saving:
- 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 next:
- Lenny's Podcast video archive: youtube.com/@Lennyspodcast/videos
Product conversations that tend to stay practical instead of drifting into slogans.

If this post is useful, the next contribution should add a real example, a worked document, or a failure case someone else can learn from.

The best metrics are the ones that sit next to a decision, not the ones that decorate a slide. I want to know how fast a signal became a committed decision, whether the target users adopted the change, and whether the outcome metric tied to the bet actually moved.

Three metrics worth pressure-testing:
- time from research signal to committed decision
- feature adoption for the target user segment
- movement in the outcome metric tied to the roadmap bet

Source material behind the scorecard:
- Continuous discovery overview: producttalk.org/continuous-discovery/
A durable foundation for teams trying to make research continuous instead of episodic.
- Atlassian product management guide: atlassian.com/agile/product-management
A practical reference for planning, teamwork, and delivery rhythms.

If your team has a sharper dashboard, share the metric definitions and the decisions they actually change. That is what makes numbers reusable.

Continuous discovery materials are valuable because they turn user conversations into a habit rather than a quarterly event. The GitLab and Atlassian handbooks are useful because they show how product organizations document decisions when the audience is larger than one team.

The stack categories worth comparing here:
- research repositories and interview note systems
- roadmap and prioritization tooling
- product analytics and experiment review

Open materials worth opening side by side:
- GitLab product handbook: handbook.gitlab.com/handbook/product/
One of the best public examples of product work written down in the open.
- Continuous discovery overview: producttalk.org/continuous-discovery/
A durable foundation for teams trying to make research continuous instead of episodic.

Working documents and 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.

Decision memo template:

# Product decision

## Problem
What user problem are we solving, for whom, and what evidence says it is worth solving now?

## Options considered
- Option A
- Option B
- Option C

## Decision
What we are doing, what we are not doing, and why.

## Success review
- leading signal:
- outcome metric:
- review date:

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.