Product manager
- When to use it
- Direction to requirements: PR/FAQs, strategy frameworks, OKRs, business cases, interviews, PRDs, journey maps, and success measurement.
- Covers
- Decide what to build (10)
- Where you decide
- G0 human — discover → ratify
- Size
- 15 skills · 1 loop · 1 gate, 1 needs a person
1–2 hours of working time, plus the interviews themselves a session
npx skilldrop-cli install --pack product-manager
Installs 15 skills, including core.
Other ways to install
The pack's loops too, each as an invokable skill:
npx skilldrop-cli install --loop --pack product-manager
In Claude Code, as a plugin (after /plugin marketplace add sananthanarayan/skilldrop):
/plugin install product-manager@skilldrop
Into Cursor, Kiro or another IDE:
npx skilldrop-cli install --pack product-manager --ide cursor
Start here: Pressure-test a product idea before anyone builds it
Paste this into your agent:
Write a PR/FAQ for a feature that lets customers pause their subscription for up to three months instead of cancelling.
- How to tell it worked
- prfaq returns a launch press release, a customer FAQ and an internal FAQ that names the hard questions.
- If nothing happens
- If prfaq does not activate, ask for it by name ("use prfaq") and check that its folder exists in your skills folder (
~/.claude/skills/by default).
A typical session
When: You are deciding what to build and need a requirement a human has agreed to before design starts. About 1–2 hours of working time, plus the interviews themselves.
You bring:
- the feature idea or problem and who it is for
- the stakeholders you can talk to
- interview notes or evidence you already have
-
- You
- Describe the feature idea and list the stakeholders.
- You get
- An interview kit per stakeholder with up to seven questions ranked by how much the answer changes the design, at least one disconfirming question each, and an assumptions ledger.
-
- You
- Paste the interview notes once you have run the interviews.
- You get
- One brief with every field tagged explicit, implied, inferred or missing, quoting the source.
- You decide
- Resolve the missing fields yourself; the PRD must not invent them.
-
- You
- Hand it the resolved brief.
- You get
- A PRD with an evidence-backed problem statement, numbered MoSCoW requirements, non-goals, and a success line per goal.
-
- You
- Run it on the PRD, then take the result to whoever owns the decision.
- You get
- A severity-tagged critique of the PRD with a verdict and a fix for each finding.
- You decide
- Gate G0, a human call: PROCEED, PROCEED WITH CONDITIONS, REVISE (back to the brief), RECONSIDER (wrong problem) or BLOCKED.
-
- You
- Once the PRD is ratified, ask how you will know the feature worked.
- You get
- One primary metric with baseline, target and timeframe, guardrail metrics, the events to instrument, and a decision rule if the target is missed.
You end with: Interview kits, a tagged brief, a ratified PRD, and a measurement plan agreed before anyone builds.
Loops
- discover — Take raw signal — interviews, journeys, a strategy question — to a requirement a human has ratified, so design starts from an agreed problem rather than an assumed one.
gather → structure → specify → ratify [G0]
Compare Product manager with another pack
Skills in this pack (10)
- business-case Build a business case for a build/buy/defer investment decision — do-nothing always included as the baseline, benefits quantified as re-runnable calculations with confidence tags, full costs (build + run + opportunity), ranges instead of false precision, and the flip-assumption named. Use when the user needs to justify an investment, write a business case, compare build vs buy vs defer, or get budget/sponsor approval for an initiative. heavy
- feedback-synthesis Turn raw customer feedback — interview notes, support tickets, NPS or CSAT verbatims, app-store reviews, sales-call notes — into ranked themes a product decision can rest on, each a problem statement rather than a feature request, counted by distinct people or accounts not mentions, with segments, severity kept separate from frequency, verbatim quotes with source IDs, what people value, where sources disagree, what the sample cannot tell, and the questions for the next interviews. A stdlib script computes the counts. Use when the user says "what are customers telling us", "synthesise this feedback", "find the themes in these tickets / reviews / NPS comments", "affinity map these interview notes", or "what should we fix first based on feedback". standard
- lean-canvas Turn a startup or internal-product idea into a lean canvas that finds what could kill it — the nine boxes filled only from what the user said, each entry tagged evidence-backed (with its source) or assumption, the assumptions ranked by how likely each is wrong times how badly the idea fails if it is, the cheapest test with a pass/fail line set in advance for the top ones, a computed unit-economics check when price and costs are given, and a plain call when the idea should change before anything is built. Use when the user says "lean canvas", "help me think through my startup idea", "what are the riskiest assumptions", "how do I validate this idea", "is this idea worth building", or "poke holes in my business model". standard
- okr-cascade Cascade company OKRs to team-level OKRs — with a gap registry for objectives no team credibly owns, and a causal metric tree connecting each team KR to the north-star it's supposed to move. Use when the user wants to set or cascade OKRs, align team goals to company goals, "turn strategy into quarterly objectives", or audit existing OKRs for gaps and vanity metrics. standard
- prd-draft Draft a Product Requirements Document from a feature idea or brief — evidence-backed problem statement with zero solution language, testable MoSCoW-prioritized requirements, mandatory non-goals, and a success line per goal. Use when the user needs a PRD, wants to capture business requirements for a feature, or asks to turn an idea, pitch, or brief into a requirements doc. standard
- prfaq Write an Amazon-style PR/FAQ — the launch press release for a product that doesn't exist yet, plus the customer FAQ and internal FAQ that force the hard questions before engineering starts. Use when the user wants a PRFAQ, a working-backwards document, a "write the press release first" exercise, or needs to align stakeholders on what a product must be before committing a team to build it. standard
- requirements-interview Generate per-stakeholder interview kits for feature discovery — ≤7 questions per stakeholder ranked by how much the answer changes the design, each naming the decision it informs, with at least one disconfirming question per script and an assumptions-to-validate ledger. Use when the user is gathering business requirements, preparing stakeholder or user interviews, or asks "what should I ask the sponsor/users/ops before we build this". standard
- strategy-analysis Run a strategy framework — SWOT/TOWS, Porter's Five Forces, or PESTLE — on a product, company, or market question, choosing the right framework for the question and forcing every cell to carry evidence and a so-what. Use when the user asks for a SWOT, a competitive/market analysis, "should we enter this market", "what's our position against X", or a macro-environment scan. heavy
- success-metrics Define how a feature's success will be measured before it's built — one primary metric with target, timeframe, and baseline; guardrail and counter-metrics; an instrumentation plan naming every event; and a pre-committed decision rule for what happens if the target is missed. Use when the user asks "how do we know this worked", needs KPIs or success criteria for a feature, or wants a measurement/instrumentation plan before launch. standard
- user-journey-map Map a customer's end-to-end journey toward an outcome — 3–6 stages, each with actions, emotions, pains, and opportunities, plus a rendered Mermaid emotion arc and the ranked pain points design should attack first. Use when the user wants a journey map, customer experience map, "map the user's path through onboarding", touchpoint analysis, or "where do users feel friction". standard
Included from core (5)
- brief-intake Turn raw mess — a Slack thread, meeting transcript, Jira ticket, half-written Notion page, email chain, or paragraph of free-form context — into a structured brief that the downstream skill (adr-generator, design-doc, runbook-generator, exec-summary, slide-outliner) can consume without further intake. Use whenever the user has unstructured source material and is about to invoke another skilldrop skill, or when a draft is missing the load-bearing context the next step will need. standard
- context-graph Map the decisions behind a codebase from its ADRs, RFCs and design records — each record's status and date, what supersedes or amends what, which records cite which, the files and folders each decision governs, and with git the commits that implemented it and the commits that changed each decision's code since it was made, and who made them — then answer "why is it like this?" from the record and check the record is still true. Finds supersessions only one side records, current decisions pointing at code that is gone, code that has drifted from its decision, two current decisions governing the same path, and references to records that don't exist. Use when the user asks "why do we use X", "which decisions govern this file or service", "is this ADR still current", "has the code drifted since we decided this", "are our ADRs out of date", "what was decided before I change this", wants a map of the architecture decisions, or is onboarding onto a codebase's history. standard
- council-review Convene a council of distinct senior-engineer personas (Architect, Security, Operator/SRE, Pragmatist, User-Advocate, plus optional bench seats) to deliberate a decision, design, or code change — each takes an independent stance, the genuine disagreements are surfaced as named cruxes, and a Chair issues a reconciled verdict that records dissents and states what would change the decision. The "Claude Council." Use when a choice has real tradeoffs and one reviewer's voice isn't enough: architecture decisions, risky changes before merge, RFC/design scrutiny, "should we adopt X?", rewrite-vs-refactor, or a pre-mortem. heavy
- doc-critique Review an existing document — ADR, design doc, runbook, exec summary, tech-comparison matrix, deck outline, decision log — and produce a structured critique against the same quality bars the skilldrop generators enforce. Categorizes findings by severity (blocker / major / minor / nit), points to the exact section/line, and suggests a concrete fix for each. Use when the user wants a second-pair-of-eyes review before sharing a doc, or has been handed someone else's artifact and wants to know what to push back on. heavy
- output-hygiene Review agent-written text before it ships and strip the machine artifacts it carries — invisible Unicode, non-breaking spaces, homoglyphs, harness-added provenance trailers, trailing chat closers — then flag the prose tells a script cannot catch, each quoted with a rewrite. Use when the user wants to clean up AI-generated output, asks to remove a Claude watermark, attribution footer, or "Generated with" line, wants a draft that does not read as machine-written, or needs a pre-ship hygiene pass on a document, commit message, or pasted chat answer. standard