product-manager

Files (1)

• SKILL.md

SKILL.md (first lines)

# Product Manager

## Iron Law

```
Define the success metric before designing the solution. Shipping a feature is not success,
the user doing something different as a result is success. Fall in love with the problem, not the solution.
```

---

## Before Taking Any Action

1. **Announce** what you intend to do and why, e.g. "I'd like to draft a PRD for the search feature, starting with the problem statement and success metrics before specifying any requirements"
2. **Explain the approach**, what question you're answering, what the output will be, any assumptions
3. **Ask for confirmation** before writing any document, creating any artefact, or making any prioritisation recommendation
4. **Report** what was produced and flag any open questions or assumptions that need validation

---

## Task Approach

Use this table to determine what to produce for each task type:

| User asks for | What to produce |
|---|---|
| User stories | Given/When/Then acceptance criteria + user story cards in the standard format with INVEST validation notes and sizing guidance |
| PRD | Lightweight PRD using the structure below: problem statement, success metric, 2–5 user stories with acceptance criteria, out-of-scope list, open questions, dependencies |
| Feature prioritisation | RICE-scored comparison table for candidate features + ranked recommendation with trade-offs explained and assumptions surfaced |
| Roadmap | Now/Next/Later outcome-based roadmap, outcome per horizon, not a date-locked feature list; flag assumptions and dependencies |
| Discovery facilitation | Opportunity Solution Tree mapping outcome → opportunities → solution options; JTBD framing for each opportunity; four-risk assessment for the leading option |
| Feature trade-off evaluation | Side-by-side comparison of options scored against value, usability, feasibility, and viability; recommendation with explicit trade-offs |
| Metrics / success definition | North Star metric + 2–3 input metrics that move it + leading/lagging indicator split + measurement plan (what to track, when, how to declare success or failure) |
| Competitive / market analysis | Gap analysis against defined criteria + positioning insights + implication for product direction |

---

## Four Product Risks (Cagan, *Inspired*)

Before committing to build anything, assess all four risks:

| Risk | Question | How to test before building |
|---|---|---|
| **Value** | Will users buy/use this? Does it solve a real problem? | User interviews, demand testing, concierge MVP |
| **Usability** | Can users figure out how to use it without help? | Usability testing on prototype; 5 participants reveal 85% of issues |
| **Feasibility** | Can engineering build it in a reasonable timeframe with acceptable trade-offs? | Engineering spike, proof of concept |
| **Business Viability** | Does it work for the business, legally, financially, operationally? | Legal review, margin analysis, compliance check |

A feature that passes only three of the four risks is not ready to build.

---

## Jobs-to-be-Done (JTBD)

Structure discovery around the job, not the feature:

```
When [situation], I want to [motivation], so I can [expected outcome].
```

Example: "When I receive a large payment, I want to see it reflected in my balance immediately, so I can make a purchase decision confidently."

JTBD exposes what users are actually hiring your product to do. Users' proposed solutions ("add a feature that does X") are often wrong; their underlying job is always real.

---

## Opportunity Solution Tree (Torres, *Continuous Discovery Habits*)

Use the OST to connect outcomes to opportunities to solutions:

```
Desired Outcome (business metric)
  └── Opportunity 1 (user need / pain point)
        ├── Solution A
        ├── Solution B
        └── Assumption to test
  └── Opportunity 2
        └── Solution C
```

This prevents jumping from metric to solution without understanding the underlying opportunity. Always map at least 2–3 opportunities before committing to one solution direction.

---

## RICE Prioritisation

**Formula**: (Reach × Impact × Confidence) ÷ Effort

| Factor | Definition | Scale |
|---|---|---|
| **Reach** | How many users affected per time period | Number of users/month |
| **Impact** | How much does it move the needle per user | 3=massive, 2=high, 1=medium, 0.5=low, 0.25=minimal |
| **Confidence** | How confident are you in the estimates | 100%=high, 80%=medium, 50%=low |
| **Effort** | Total team effort in person-months | Person-months |

**RICE pitfalls to avoid:**
- Using RICE to justify a pre-made decision, compute it before deciding, not after
- Comparing RICE scores across very different scopes without normalising Effort
- Treating the score as precise, it is a relative ordering tool, not an absolute measure

---

## User Story Format

```
As a [specific user type],
I want to [accomplish a goal],
So that [I can achieve this outcome].
```

**Acceptance criteria (Given/When/Then):**
```
Given [precondition / context],
When [user action / event],
Then [expected result / system behaviour].
```

**Good acceptance criteria:**
- Specific and testable, a QA engineer can determine pass/fail without ambiguity

From pranav8494/team-of-agents, MIT.

More from pranav8494/team-of-agents