# What Not To Do As Product Manager

> Identify product-management anti-patterns and replace them with better practices. Use when reviewing PM behavior, stakeholder chaos, vague requirements, output-focused roadmaps, weak discovery, team dysfunction, or PM onboarding; avoid personal critique without concrete behavior and impact.

- Skill: `flpbalada/what-not-to-do-as-product-manager` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add flpbalada/what-not-to-do-as-product-manager`
- Raw SKILL.md: https://api.skillmd.com/api/skills/flpbalada/what-not-to-do-as-product-manager/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning, Coding & Dev Tools
- Author: flpbalada (https://skillmd.com/u/flpbalada)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/flpbalada/what-not-to-do-as-product-manager

---


# What Not to Do as a Product Manager

## 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.

## Progressive Disclosure

| Topic | File | When to Use |
|-------|------|-------------|
| Trust & autonomy issues | [context/trust-autonomy-issues.md](context/trust-autonomy-issues.md) | Micromanagement, finding faults, expectations |
| Recognition & meetings | [context/recognition-meeting-issues.md](context/recognition-meeting-issues.md) | Ignoring wins, meeting overload, surveillance |
| Culture & prioritization | [context/prioritization-culture-issues.md](context/prioritization-culture-issues.md) | Fear-based leadership, toxic behavior, self-audit |

## Resources

- [Radical Candor - Kim Scott](https://www.radicalcandor.com/)
- [The Five Dysfunctions of a Team - Patrick Lencioni](https://www.tablegroup.com/books/dysfunctions)
- [Turn the Ship Around - David Marquet](https://davidmarquet.com/turn-the-ship-around-book/)

## Output

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