Product Manager

---
name: product-manager
description: "Use when an org role acts as product manager and must turn strategy into a prioritized roadmap, align stakeholders and solve validated problems. Covers Now/Next/Later roadmaps, RICE and MoSCoW scoring, stakeholder mapping, saying no with trade-offs, and outcome-based requirements."
tags: ["product","planning","strategy","communication"]
tools: []
license: Apache-2.0
source: https://github.com/monoes/monomind
---
# Product Manager — Best Practices

## Focus
Owns the "why" and "what" of a product: turning strategy into a prioritized roadmap, aligning stakeholders, and ensuring what ships actually solves a validated problem.

## Best practices
- Use a "Now / Next / Later" roadmap instead of fixed dates: Now is high-confidence current-cycle work, Next is the upcoming cycle's priorities, Later is validated problems not yet scheduled. Label confidence explicitly so "Later" isn't mistaken for a commitment.
- Prioritize with an explicit framework (RICE: Reach × Impact × Confidence ÷ Effort, or MoSCoW) rather than gut feel — it gives stakeholders an auditable reason for the ranking.
- Map stakeholders by influence vs. interest and tailor communication accordingly — not everyone needs the same depth of update.
- When declining a request, don't just say no — show what's being prioritized instead and why it ranks higher, so the trade-off is visible.
- Frame roadmap items as bets tied to outcomes/strategic themes, not as guaranteed deliverables — this sets the right expectation for a learning process.
- Write requirements as verifiable outcomes ("reduce signup drop-off by X%") not just feature descriptions, so success is measurable after ship.
- Revisit the roadmap on a fixed cadence (monthly/quarterly) and actively move items between horizons rather than letting it go stale.

## Common pitfalls
- Treating the roadmap as a fixed contract instead of a living, confidence-labeled plan — this destroys trust the first time priorities shift.
- Prioritizing by whoever asked loudest or most recently instead of a consistent scoring method.
- Shipping features without a clear success metric defined up front, so nobody can tell afterward if it worked.
- Saying "no" without explaining the trade-off, which reads as dismissive and erodes stakeholder buy-in.
- Conflating output (features shipped) with outcome (problems solved) when reporting progress.

## Tools & techniques
- RICE / MoSCoW / Value-vs-Effort scoring for backlog and roadmap prioritization.
- Stakeholder influence/interest mapping to calibrate communication cadence and depth.
- Now/Next/Later roadmap format with explicit confidence labels (Committed / Directional / Exploratory).
- Outcome-based requirement writing: state the metric that defines success before scoping the solution.