home / skills / flpbalada / my-opencode-config / making-product-decisions

making-product-decisions skill

safe

This skill helps you structure and document product decisions using a framework that improves alignment, traceability, and learning across teams.

npx playbooks add skill flpbalada/my-opencode-config --skill making-product-decisions

Review the files below or copy the command above to add this skill to your agents.

Files (1)

SKILL.md

6.8 KB

---
name: making-product-decisions
description:
  Framework for structured product decision-making. Use when facing complex
  tradeoffs, aligning stakeholders, documenting decisions, or choosing between
  multiple valid approaches.
---

# 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:

1. Do nothing / status quo
2. Option A
3. 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

```markdown
## 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

- [Thinking in Bets - Annie Duke](https://www.amazon.com/Thinking-Bets-Making-Smarter-Decisions/dp/0735216355)
- [Decisive - Chip & Dan Heath](https://www.amazon.com/Decisive-Make-Better-Choices-Life/dp/0307956393)

Overview

This skill is a structured framework for making and documenting product decisions that balances decision science with practical product management. It helps teams handle complex tradeoffs, align stakeholders, and capture rationale so decisions are auditable and learnable. Use it to reduce bias, speed reversible choices, and ensure senior attention for irreversible ones.

How this skill works

The framework guides you through five steps: frame the decision, generate at least three options (including do-nothing), establish weighted criteria, evaluate options against those criteria, and document the final decision with success metrics and review dates. It emphasizes distinguishing Type 1 (one-way door) versus Type 2 (two-way door) decisions, judging decision quality by process rather than outcome, and choosing a data-informed approach when data is incomplete. Outputs include a concise decision record capturing rationale, dissent, and review cadence.

When to use it

Choosing between competing priorities or major product approaches
Making irreversible or high-stakes architecture/business choices
Aligning cross-functional stakeholders with different perspectives
Documenting decisions for future audits or learning
Delegating decisions while keeping accountability

Best practices

Always include a ‘do nothing’ / status quo option to avoid false binaries
Define decision criteria and weights before scoring options
Limit analysis on reversible (Type 2) decisions to avoid paralysis
Capture dissenting views and set a review date for follow-up
Treat outcomes separately from process quality — evaluate how the decision was made, not just results

Example use cases

Build vs buy analysis for analytics tooling with weighted criteria and cost/time tradeoffs
Quarterly roadmapping choice between mobile features and API platform work
Deciding whether to sunset an underused product area vs invest in revitalization
Assigning decision authority: senior-only for irreversible choices, broad delegation for reversible experiments

FAQ

How many options should we consider?

At least three: status quo, Option A, and Option B. Avoid binary framing to surface creative alternatives.

When do we use data-driven vs data-informed?

Use data-driven when metrics are clear and the system is well-understood. Use data-informed when data is incomplete or the context is novel; apply judgment and expert input.