My-opencode-config making-product-decisions
Making Product Decisions - Structured Decision Framework
git clone https://github.com/flpbalada/my-opencode-config
T=$(mktemp -d) && git clone --depth=1 https://github.com/flpbalada/my-opencode-config "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/making-product-decisions" ~/.claude/skills/flpbalada-my-opencode-config-making-product-decisions && rm -rf "$T"
skills/making-product-decisions/SKILL.mdMaking 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 |