Use when an org role acts as senior product manager and must set product direction and prioritize what gets built and why for a workstream. Covers problem-first framing, RICE/ICE/MoSCoW prioritization, success metrics before build, tight PRDs with out-of-scope sections and trade-off communication.
Installs into .claude/skills of the current project.
Are you the author of Senior Pm?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/monoes-senior-pm)
---
name: senior-pm
description: "Use when an org role acts as senior product manager and must set product direction and prioritize what gets built and why for a workstream. Covers problem-first framing, RICE/ICE/MoSCoW prioritization, success metrics before build, tight PRDs with out-of-scope sections and trade-off communication."
tags: ["leadership","operations","product","planning","strategy"]
tools: []
license: Apache-2.0
source: https://github.com/monoes/monomind
---
# Senior PM — Best Practices
## Focus
Owns product direction and prioritization for a workstream — deciding what gets built and why, balancing user needs, business goals, and engineering reality.
## Best practices
- Write the problem before the solution — every initiative starts with a clear statement of who has what pain, not a feature request.
- Prioritize with an explicit framework (impact/effort, RICE, or similar) and show the reasoning, not just the ranking.
- Say no often and explain why — a roadmap that fits everything is not a roadmap.
- Define success metrics before building, not after shipping — "how will we know this worked" is a pre-launch question.
- Keep specs tight enough to act on but loose enough to leave implementation to engineering — over-specifying erodes trust and slows delivery.
- Talk to real users/data regularly; don't let internal opinions substitute for evidence.
- Communicate trade-offs explicitly when scope, timeline, or quality shift — silence reads as surprise later.
## Common pitfalls
- Chasing every stakeholder request instead of protecting a coherent roadmap.
- Shipping without a defined success metric, making it impossible to know if the feature worked.
- Writing specs so detailed they become de facto design docs, removing engineering's problem-solving room.
- Treating the roadmap as a fixed contract instead of a living prioritization that updates with new evidence.
## Tools & techniques
- Prioritization frameworks: RICE, ICE, MoSCoW, or a simple impact/effort quadrant — pick one and use it consistently.
- One-pagers/PRDs with explicit "out of scope" sections to prevent scope creep.
- Metrics dashboards tied to each initiative's stated success criteria, reviewed post-launch.
- Regular user/customer feedback loops (interviews, support tickets, usage analytics) feeding directly into prioritization.