monoes/monomind/senior-pm

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.