running-product-discoverylisted

# Running Product Discovery ## Overview Discovery is **risk-reduction, not documentation**. Its job is to answer four questions *before* committing build capacity, and to replace opinion (the loudest voice in the room) with evidence from real customers. This skill is the entry point and router for a discovery effort. It orients the cross-functional team and points to the workflow skill for each step. **It does not do the work itself** — it hands off. **When a request arrives as a pre-formed solution ("add a referral feature", "build a dashboard"), do NOT scope, design, or estimate it.** Start at step 1 (`framing-the-opportunity`) and treat the named feature as one untested hypothesis, not the unit of work. ## The four big product risks (the running checklist) Ask these continuously; address the *biggest* first. Teams over-index on feasibility — push on value and viability. | Risk | Question | Owner | |------|----------|-------| | **Value** | Will customers buy it / users choose it? | Product Manager | | **Usability** | Can users figure out how to use it? | UX Designer | | **Feasibility** | Can engineers build it (time/skills/tech)? | Engineer | | **Business viability** | Does it work for legal, finance, sales, brand? | PM + stakeholders | ## Who does what Discovery is a **trio** (PM + designer + engineer) that decides *and* builds together — not a relay of hand-offs. A requirements engineer / BA is a valuable fourth seat for data-heavy, regulated, or enterprise work,