what-not-to-do-as-product-manager

When to use

• Reviewing product leadership behavior.
• Diagnosing team dysfunction.
• Coaching or onboarding product managers.
• Reflecting on decision quality, communication, or delivery problems.

Goal

Identify product management anti-patterns. Replace them with clearer ownership, decisions, and collaboration.

Rules

• Focus on behavior and impact, not personality.
• Tie each anti-pattern to a concrete consequence.
• Recommend a better practice.
• Avoid generic advice without evidence.
• Separate product decisions from delivery management.

Anti-Patterns

• Solution-first planning without problem clarity.
• Treating stakeholder requests as strategy.
• Changing priorities without trade-offs.
• Avoiding hard decisions.
• Writing vague requirements.
• Skipping discovery and validation.
• Ignoring engineering constraints.
• Measuring output instead of outcomes.
• Hoarding context.
• Blaming teams for unclear direction.

Warning Signs

• Roadmap is a list of requests.
• Every item is high priority.
• Requirements change during implementation without reset.
• Success metric is missing.
• Team cannot explain why work matters.
• Discovery findings do not affect decisions.
• Engineers learn context too late.
• Stakeholders hear different stories.

Better Practices

• Start with user problem and business goal.
• Define success metric and non-goals.
• Make trade-offs explicit.
• Share context early.
• Validate risky assumptions.
• Write testable requirements.
• Keep roadmap tied to outcomes.
• Review decisions after launch.

Flow

1. Identify the product behavior.
2. Name the anti-pattern.
3. Describe team or user impact.
4. Find root cause.
5. Recommend replacement behavior.
6. Define signal that behavior improved.

Output

## PM Anti-Pattern Review
- Situation:
- Anti-pattern:
- Impact:
- Root cause:
- Better practice:
- Success signal: