Skip to content
Back to skills

Senior Pm

ASecurity

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.

  • 21 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added September 22, 2026
ai-agentsrustgogit

Security analysis

A100/100

Scanned September 28, 2026

npx -y skills add monoes/monomind --skill senior-pm --agent claude-code

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.

Security grade badge for Senior Pm
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/monoes-senior-pm/badge)](https://www.skillsdirectory.com/skills/monoes-senior-pm)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
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.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…