flpbalada/fb-skills

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

Identify product-management anti-patterns and replace them with better practices.

First seen May 4, 2026

Installation

$ npx skills add flpbalada/fb-skills --skill what-not-to-do-as-product-manager

Summary

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

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from flpbalada/fb-skills · top by installs.

npx skills add flpbalada/fb-skills

Browse all from flpbalada/fb-skills

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Stars 7
Default branch main
Open issues 0
Status Active

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 2,924 B
  • docs SUMMARY.md 332 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 11 installs

SKILL.md

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

Output

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