From discover
Defines 4 Risks confidence thresholds, OST hierarchy levels, Knowledge Pyramid tiers, and state design requirements. Use when evaluating user stories, setting confidence scores, referencing OST levels, scoping MVP, or determining validation sufficiency.
npx claudepluginhub shinpr/claude-code-workflows --plugin discoverThis skill uses the workspace's default tool permissions.
1. **Hypothesis Until Proven**: Every assumption is a hypothesis until validated with evidence. Treat unvalidated ideas as hypotheses, not facts
Provides expert product management guidance on roadmaps, feature prioritization, PRDs, user stories, acceptance criteria, sprint planning, OKRs, discovery, metrics, and stakeholder alignment.
Guides continuous product discovery: weekly rhythms, Opportunity Solution Trees, interview snapshots, solution exploration, assumption tests before engineering commits.
Builds Opportunity Solution Trees (OST) mapping outcomes to customer opportunities, solutions, and experiments. Guides continuous product discovery and prioritization.
Share bugs, ideas, or general feedback.
All product work follows this hierarchy:
Outcome
├── Product Outcome (team-controllable product goals)
│ NSM connects Product Outcome ↔ Business Outcome
└── Business Outcome (business results Product Outcome contributes to)
Product Outcome
└── Opportunity (user problems, needs, desires)
└── Solution (approaches to address the opportunity = feature candidates)
└── Assumption (premises underlying the solution = hypotheses)
└── Experiment (methods to validate the hypothesis)
| Level | Granularity | Artifact | Description |
|---|---|---|---|
| Business Outcome | Largest | docs/product/vision.md | Business results the product contributes to |
| Product Outcome | Large | docs/product/vision.md | Team-controllable product goals |
| Opportunity | Large | docs/discovery/opportunities/ | User problems, needs, desires |
| Solution | Medium | PRD (docs/prd/) | Feature candidates addressing an Opportunity |
| Assumption | Small | docs/discovery/hypotheses/ | Premises underlying a Solution |
| User Story | Smallest | Within PRD | Minimum unit of value with all 4 Risks validated |
A user story is the minimum unit of value. All four risks must be sufficiently validated:
Track confidence per risk dimension (0-10):
| Score | Meaning | Typical Evidence |
|---|---|---|
| 0-2 | Gut feeling / no evidence | Assumption only |
| 3-4 | Structured evaluation | Expert review, competitive analysis, scoring |
| 5-7 | Data-backed | Analytics, surveys, interview patterns |
| 8-10 | Tested and confirmed | Prototype validation, A/B test, beta results |
| Condition | Confidence Needed | Evidence Level |
|---|---|---|
| Low-cost, reversible (feature flag, gradual rollout) | 3-4 | Structured evaluation |
| Medium cost | 5-7 | Data |
| High-cost, irreversible (platform change, pricing change) | 8+ | Test results |
PRDs must show each user story's current confidence and remaining risks. Enable PO/DRI to judge "validated enough for delivery", not just "fully validated".
Knowledge is organized in three tiers to manage context as hypotheses accumulate:
| Tier | Scope | Location | Loading |
|---|---|---|---|
| Tier 1 | Distilled product principles | docs/product/learnings.md | Always (via this skill) |
| Tier 2 | Opportunity-level learnings | Each Opportunity file's "Tier 2 Learnings" section | When working on that Opportunity |
| Tier 3 | Individual hypothesis files | docs/discovery/hypotheses/ | On demand |
Tier 1 learnings are validated patterns derived from 3+ independent hypotheses. Treat them as established principles until re-validated.
Distillation criteria (enforced by knowledge-distiller):
last-validated dates; 6-12 months without re-validation triggers reviewEvery user-facing interaction must account for these states:
| State | Description |
|---|---|
| Loading | Data is being fetched/processed — show progress indicator |
| Empty | No data exists yet — guide user to first action |
| Error | Something went wrong — explain what happened, offer recovery |
| Partial | Some data available, some not — show available, indicate missing |
| Success | Normal state with data — primary design focus |
PRDs should specify behavior for all states in acceptance criteria. Prototypes should demonstrate at minimum: empty, success, and error states.
references/opportunity-template.md for Opportunity file structurereferences/mvp-definition.md for prioritization (MoSCoW/RICE) and scope reduction techniquesThese principles exist to counter natural tendencies in product thinking: