making-product-decisions
Making Product Decisions - Structured Decision Framework
A meta-framework for making and documenting product decisions. Combines decision science principles with practical product management needs to ensure better decisions, stakeholder alignment, and organizational learning.
When to Use This Skill
- Choosing between competing priorities or approaches
- Making irreversible or high-stakes decisions
- Aligning stakeholders with different perspectives
- Documenting decisions for future reference
- Evaluating past decisions for learning
- Delegating decision-making authority
Core Concepts
Decision Types (Bezos Framework)
+------------------+------------------+
| Type 1 | Type 2 |
| (One-way door) | (Two-way door) |
+------------------+------------------+
| Irreversible | Reversible |
| High stakes | Lower stakes |
| Slow, careful | Fast, iterate |
| Senior decision | Delegate widely |
+------------------+------------------+
Decision Quality vs. Outcome
| Good Outcome | Bad Outcome | |
|---|---|---|
| Good Decision | Deserved success | Bad luck |
| Bad Decision | Good luck | Deserved failure |
Judge decisions by process quality, not just outcomes.
Data-Informed vs. Data-Driven
| Approach | When to Use |
|---|---|
| Data-driven | Clear metrics, sufficient data, understood system |
| Data-informed | Incomplete data, novel situations, judgment needed |
| Intuition-led | Time pressure, expert domain, pattern matching |
Most product decisions should be data-informed, not purely data-driven.
Analysis Framework
Step 1: Frame the Decision
| Element | Question |
|---|---|
| What | What exactly are we deciding? |
| Why | Why does this decision matter? |
| Who | Who should be involved? |
| When | When must we decide by? |
| Reversibility | Type 1 or Type 2 door? |
Step 2: Generate Options
Always have at least 3 options:
- Do nothing / status quo
- Option A
- Option B
Avoid binary framing - it limits thinking.
Step 3: Establish Criteria
| Criterion | Weight | Why It Matters |
|---|---|---|
| [Criterion 1] | [1-5] | [Explanation] |
| [Criterion 2] | [1-5] | [Explanation] |
| [Criterion 3] | [1-5] | [Explanation] |
Step 4: Evaluate Options
| Option | Criterion 1 | Criterion 2 | Criterion 3 | Total |
|---|---|---|---|---|
| Status quo | [Score] | [Score] | [Score] | [Sum] |
| Option A | [Score] | [Score] | [Score] | [Sum] |
| Option B | [Score] | [Score] | [Score] | [Sum] |
Step 5: Document and Decide
Record:
- Decision made
- Rationale
- Dissenting views
- Success criteria
- Review date
Output Template
## Product Decision Record
**Decision:** [Clear statement of what was decided] **Date:** [Date] **Decision
maker:** [Name] **Status:** [Proposed/Approved/Implemented]
### Context
**Problem/Opportunity:** [What prompted this decision]
**Constraints:** [Time, resources, dependencies]
**Reversibility:** [Type 1 / Type 2]
### Options Considered
| Option | Description | Pros | Cons |
| ---------- | ----------- | ---- | ---- |
| Status quo | [Desc] | [+] | [-] |
| Option A | [Desc] | [+] | [-] |
| Option B | [Desc] | [+] | [-] |
### Decision Criteria
| Criterion | Weight | Rationale |
| --------- | ------ | --------- |
| [C1] | [1-5] | [Why] |
| [C2] | [1-5] | [Why] |
### Evaluation
| Option | [C1] | [C2] | Weighted Total |
| ------- | ----- | ----- | -------------- |
| [Opt 1] | [x/5] | [x/5] | [Score] |
| [Opt 2] | [x/5] | [x/5] | [Score] |
### Decision
**Chosen option:** [Option name]
**Rationale:** [Why this option best meets criteria]
**Dissenting views:** [Captured disagreements and concerns]
### Success Criteria
| Metric | Current | Target | Measure By |
| ------ | ------- | ------- | ---------- |
| [M1] | [Value] | [Value] | [Date] |
### Review
**Review date:** [Date] **What we'll evaluate:** [Criteria for success/failure]
Real-World Examples
Example 1: Build vs. Buy
Decision: Build custom analytics or use third-party tool?
| Criterion | Weight | Build | Buy |
|---|---|---|---|
| Time to market | 5 | 2 | 5 |
| Customization | 3 | 5 | 2 |
| Long-term cost | 4 | 3 | 4 |
| Maintenance burden | 4 | 2 | 5 |
| Total | 42 | 66 |
Decision: Buy, despite customization limitations.
Example 2: Feature Prioritization
Decision: Next quarter focus - mobile app or API improvements?
Applied decision criteria:
- Revenue impact (weight: 5)
- User retention (weight: 4)
- Strategic positioning (weight: 3)
- Engineering complexity (weight: 2)
Result: Mobile app scored higher on revenue and retention despite higher complexity.
Best Practices
Do
- Make decision criteria explicit before evaluating
- Include "do nothing" as an option
- Document dissenting opinions
- Set review dates for major decisions
- Separate decision quality from outcome
Avoid
- Analysis paralysis on Type 2 decisions
- HiPPO (Highest Paid Person's Opinion) decisions
- Retroactive justification
- Ignoring intuition entirely
- Forgetting to review past decisions
Decision Speed Guidelines
| Type | Approach |
|---|---|
| Type 1, high stakes | Take time, involve stakeholders |
| Type 2, reversible | Decide quickly, iterate |
| Unclear type | Default to faster, can always slow down |
Integration with Other Methods
| Method | Combined Use |
|---|---|
| Hypothesis Tree | Structure analysis of options |
| Jobs-to-be-Done | Ground criteria in user needs |
| Five Whys | Understand decision root causes |
Resources
More from flpbalada/fb-skills
progressive-disclosure
Reduce complexity by revealing information progressively. Use when designing
7discuss-task
Clarify ambiguous tasks before action. Use when goal, scope, success criteria, constraints, or risks are unclear.
4cognitive-fluency-psychology
Apply cognitive fluency principles to improve clarity, trust, and conversion.
4react-useeffect-avoid
Guides when NOT to use useEffect and suggests better alternatives. Use when reviewing React code, troubleshooting performance, or considering useEffect for derived state or form resets.
4discuss-code
Critically discuss code issues with compact findings. Use when code needs review for logic, simplicity, structure, naming, or maintainability.
4learn
Extract reusable patterns from the current session. Use when errors, debugging techniques, workarounds, or project conventions should become skills.
3