Product Management Principles
Core Philosophy
- Hypothesis Until Proven: Every assumption is a hypothesis until validated with evidence. Treat unvalidated ideas as hypotheses, not facts
- Value Traceability: From hypothesis to validation to user story to PRD to implementation to test — maintain traceability across the entire chain
- Feedback Accumulation: Preserve conclusions and evidence that can change a current or plausible future decision, including invalidated hypotheses
- Validated Enough: Use cost x risk x reversibility to determine the sufficient confidence threshold
- Artifacts Over Notes: Intermediate analysis (market research, competitive landscape, brainstorming) is conducted within the conversation and synthesized into the designated artifact. Each recipe defines its output locations
Opportunity Solution Tree (OST) Hierarchy
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 Definitions
| 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 |
4 Risks (Authoritative Definition)
A user story is the minimum unit of value. All four risks must be sufficiently validated:
- Value — Will users use/buy this? Does it solve their problem?
- Usability — Can users figure out how to use it? Does the UX work?
- Feasibility — Can we build it technically? Is the effort realistic?
- Viability — Does it work as a business? Can we explain why we're building it?
Confidence Meter (Authoritative Definition)
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 |
Threshold by Cost x Risk x Reversibility
| Condition |
Calibration Guide |
Typical Evidence |
| 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 show each user story's current confidence and remaining risks. The table calibrates judgment rather than imposing a numeric gate; the required evidence follows cost, risk, reversibility, and the decision at stake.
Knowledge Pyramid (Authoritative Definition)
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 supported by independent evidence across the contexts in which the principle claims to hold. Treat them as established only within those recorded conditions.
Distillation criteria (enforced by knowledge-distiller):
- Independent evidence: Promotion requires more than one retelling of the same observation; evidence independence and quality matter more than a fixed count
- Context coverage: Evidence must cover the segments or conditions named by the proposed learning; additional segment research requires a current decision it can change
- Contradiction handling: Conflicting evidence remains recorded with its conditions
- Freshness tags: Tier 1 learnings record
last-validated; re-check when a changed environment or current decision makes staleness consequential, not merely because a timer elapsed
State Design (Authoritative Definition)
For each user-facing interaction, specify the states whose occurrence or recovery changes observable behavior or verification. Use these standard states as a coverage prompt, not a required five-row output:
| 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 specify behavior for each applicable state. Record not_applicable only when omitting a plausibly relevant standard state would leave the downstream behavior ambiguous. Prototypes implement the states needed to distinguish the hypothesis's success, failure, or inconclusive criteria.
Key Principles for Daily Decisions
- Solution-Framing Check: Seek meaningfully different solution classes to test whether an Opportunity is solution-shaped. Stop when further alternatives cannot change that framing judgment. See
references/opportunity-template.md for Opportunity file structure
- Outcome Connection: Preserve the connection to business outcomes while using NSM to balance pure metric-chasing pressure
- Design is a Perspective, Not a Phase: Design thinking applies across all processes — discovery, validation, definition, delivery, and reflection
- Cycle, Not Phases: Discovery → Validation → Definition → Delivery → Reflection is a continuous cycle. Start from anywhere
- MVP Scoping: When transitioning validated hypotheses to a PRD or blueprint, use
references/mvp-definition.md for the inclusion boundary, explicit exclusions, observable proof, and scope reduction. Use an optional ranking aid only when direct boundary analysis leaves credible candidates tied
1---2name: product-principles-23description: 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.4---56# Product Management Principles78## Core Philosophy9101. **Hypothesis Until Proven**: Every assumption is a hypothesis until validated with evidence. Treat unvalidated ideas as hypotheses, not facts112. **Value Traceability**: From hypothesis to validation to user story to PRD to implementation to test — maintain traceability across the entire chain123. **Feedback Accumulation**: Preserve conclusions and evidence that can change a current or plausible future decision, including invalidated hypotheses134. **Validated Enough**: Use cost x risk x reversibility to determine the sufficient confidence threshold145. **Artifacts Over Notes**: Intermediate analysis (market research, competitive landscape, brainstorming) is conducted within the conversation and synthesized into the designated artifact. Each recipe defines its output locations1516## Opportunity Solution Tree (OST) Hierarchy1718All product work follows this hierarchy:1920```21Outcome22 ├── Product Outcome (team-controllable product goals)23 │ NSM connects Product Outcome ↔ Business Outcome24 └── Business Outcome (business results Product Outcome contributes to)2526Product Outcome27 └── Opportunity (user problems, needs, desires)28 └── Solution (approaches to address the opportunity = feature candidates)29 └── Assumption (premises underlying the solution = hypotheses)30 └── Experiment (methods to validate the hypothesis)31```3233### Level Definitions3435| Level | Granularity | Artifact | Description |36|-------|-------------|----------|-------------|37| Business Outcome | Largest | `docs/product/vision.md` | Business results the product contributes to |38| Product Outcome | Large | `docs/product/vision.md` | Team-controllable product goals |39| Opportunity | Large | `docs/discovery/opportunities/` | User problems, needs, desires |40| Solution | Medium | PRD (`docs/prd/`) | Feature candidates addressing an Opportunity |41| Assumption | Small | `docs/discovery/hypotheses/` | Premises underlying a Solution |42| User Story | Smallest | Within PRD | Minimum unit of value with all 4 Risks validated |4344## 4 Risks (Authoritative Definition)4546A user story is the **minimum unit of value**. All four risks must be **sufficiently validated**:4748- **Value** — Will users use/buy this? Does it solve their problem?49- **Usability** — Can users figure out how to use it? Does the UX work?50- **Feasibility** — Can we build it technically? Is the effort realistic?51- **Viability** — Does it work as a business? Can we explain why we're building it?5253## Confidence Meter (Authoritative Definition)5455Track confidence per risk dimension (0-10):5657| Score | Meaning | Typical Evidence |58|-------|---------|------------------|59| 0-2 | Gut feeling / no evidence | Assumption only |60| 3-4 | Structured evaluation | Expert review, competitive analysis, scoring |61| 5-7 | Data-backed | Analytics, surveys, interview patterns |62| 8-10 | Tested and confirmed | Prototype validation, A/B test, beta results |6364### Threshold by Cost x Risk x Reversibility6566| Condition | Calibration Guide | Typical Evidence |67|-----------|-------------------|----------------|68| Low-cost, reversible (feature flag, gradual rollout) | 3-4 | Structured evaluation |69| Medium cost | 5-7 | Data |70| High-cost, irreversible (platform change, pricing change) | 8+ | Test results |7172PRDs show each user story's **current confidence and remaining risks**. The table calibrates judgment rather than imposing a numeric gate; the required evidence follows cost, risk, reversibility, and the decision at stake.7374## Knowledge Pyramid (Authoritative Definition)7576Knowledge is organized in three tiers to manage context as hypotheses accumulate:7778| Tier | Scope | Location | Loading |79|------|-------|----------|---------|80| **Tier 1** | Distilled product principles | `docs/product/learnings.md` | Always (via this skill) |81| **Tier 2** | Opportunity-level learnings | Each Opportunity file's "Tier 2 Learnings" section | When working on that Opportunity |82| **Tier 3** | Individual hypothesis files | `docs/discovery/hypotheses/` | On demand |8384Tier 1 learnings are validated patterns supported by independent evidence across the contexts in which the principle claims to hold. Treat them as established only within those recorded conditions.8586Distillation criteria (enforced by knowledge-distiller):87- **Independent evidence**: Promotion requires more than one retelling of the same observation; evidence independence and quality matter more than a fixed count88- **Context coverage**: Evidence must cover the segments or conditions named by the proposed learning; additional segment research requires a current decision it can change89- **Contradiction handling**: Conflicting evidence remains recorded with its conditions90- **Freshness tags**: Tier 1 learnings record `last-validated`; re-check when a changed environment or current decision makes staleness consequential, not merely because a timer elapsed9192## State Design (Authoritative Definition)9394For each user-facing interaction, specify the states whose occurrence or recovery changes observable behavior or verification. Use these standard states as a coverage prompt, not a required five-row output:9596| State | Description |97|-------|-------------|98| **Loading** | Data is being fetched/processed — show progress indicator |99| **Empty** | No data exists yet — guide user to first action |100| **Error** | Something went wrong — explain what happened, offer recovery |101| **Partial** | Some data available, some not — show available, indicate missing |102| **Success** | Normal state with data — primary design focus |103104PRDs specify behavior for each applicable state. Record `not_applicable` only when omitting a plausibly relevant standard state would leave the downstream behavior ambiguous. Prototypes implement the states needed to distinguish the hypothesis's success, failure, or inconclusive criteria.105106## Key Principles for Daily Decisions107108- **Solution-Framing Check**: Seek meaningfully different solution classes to test whether an Opportunity is solution-shaped. Stop when further alternatives cannot change that framing judgment. See `references/opportunity-template.md` for Opportunity file structure109- **Outcome Connection**: Preserve the connection to business outcomes while using NSM to balance pure metric-chasing pressure110- **Design is a Perspective, Not a Phase**: Design thinking applies across all processes — discovery, validation, definition, delivery, and reflection111- **Cycle, Not Phases**: Discovery → Validation → Definition → Delivery → Reflection is a continuous cycle. Start from anywhere112- **MVP Scoping**: When transitioning validated hypotheses to a PRD or blueprint, use `references/mvp-definition.md` for the inclusion boundary, explicit exclusions, observable proof, and scope reduction. Use an optional ranking aid only when direct boundary analysis leaves credible candidates tied