decision-doc

/decision-doc - Document Strategic Decisions That Stick

When the PM types /decision-doc, create decision documents that get stakeholder alignment, prevent future debates, and create institutional memory.

When to Use

• Making a significant product direction choice
• Evaluating build vs. buy decisions
• Choosing between competing feature approaches
• Deciding on architecture or technical direction
• Resolving team disagreements on strategy
• Making tradeoffs between conflicting goals
• Any decision that will be questioned 3 months from now

How It Works

This is a 4-step process:

Step 1: Frame the Decision

Step 2: Present Options with Tradeoffs

Step 3: Make a Recommendation

Step 4: Document the Decision

Step 1: Frame the Decision

When the PM types /decision-doc, I'll start with:

Let's document this decision so it sticks.

**What decision are you making?**

Frame it as a clear choice:
- "Should we build feature X in-house or integrate with Partner Y?"
- "Should we launch with A/B test or full rollout?"
- "Should we prioritize mobile app or web improvements in Q2?"

**Why does this decision matter?**
- What's the impact if we get it right?
- What's the cost if we get it wrong?
- Who else needs to be involved?

**What's your timeline?**
- When do you need to decide?
- What forces the decision? (deadline, customer commitment, etc.)
- What happens if we delay?

Tell me about the decision and I'll help structure the document.

What Makes a Good Decision to Document

Do document:

• ✅ Decisions with significant resource commitment
• ✅ Decisions with long-term consequences
• ✅ Decisions where reasonable people disagree
• ✅ Decisions that will be questioned later
• ✅ Decisions that set precedent for future choices
• ✅ Decisions involving multiple stakeholders

Don't document:

• ❌ Trivial tactical choices
• ❌ Decisions that can be easily reversed
• ❌ Decisions only affecting one person
• ❌ Decisions that are obvious/uncontroversial

Step 2: Present Options with Tradeoffs

Once I understand the decision:

Great. Now let's map out your options.

**How many options are you considering?**
(Usually 2-4 options. More than 4 means you need to narrow first)

For each option, I need to understand:
- What it is (clear description)
- Why it's appealing (upsides)
- Why it's risky (downsides)
- What it costs (time, money, opportunity cost)
- What assumptions it requires

You can either:
- Tell me about each option
- Upload analysis you've already done
- Let me help you brainstorm options you might have missed

I'll structure this into a clear comparison framework.

The Options Framework

For each option, I'll create:

## Option [1/2/3]: [Name of Option]

### Description

[Clear, jargon-free explanation of what this option means]

**One-sentence summary:** [What this is in plain language]

### Pros (Why This Could Work)

- **[Pro 1]:** [Explanation and impact]
- **[Pro 2]:** [Explanation and impact]
- **[Pro 3]:** [Explanation and impact]

### Cons (Why This Could Fail)

- **[Con 1]:** [Explanation and risk]
- **[Con 2]:** [Explanation and risk]
- **[Con 3]:** [Explanation and risk]

### Costs & Resources Required

**Engineering:** [X weeks/people]
**Design:** [X weeks/people]
**Other Teams:** [Who else needs to be involved]
**Timeline:** [How long until we see results]
**Budget:** [Any direct costs - tools, services, licenses]

### Key Assumptions

[What needs to be true for this to work]

**Example assumptions:**

- "Assumes customers will adopt new workflow within 30 days"
- "Assumes partner API is stable and well-documented"
- "Assumes we can hire 2 senior engineers by Q2"

### Success Criteria

[How we'll know this option worked]

**Example criteria:**

- "Adoption >60% within first month"
- "Implementation completed in <8 weeks"
- "No degradation in core metrics"

### Risks & Mitigation

| Risk     | Likelihood   | Impact       | Mitigation            |
| -------- | ------------ | ------------ | --------------------- |
| [Risk 1] | High/Med/Low | High/Med/Low | [How we'd address it] |
| [Risk 2] | High/Med/Low | High/Med/Low | [How we'd address it] |

### Dependencies

- [Other team/project that must happen first]
- [External factor we can't control]
- [Technical prerequisite]

### Example: Mobile App vs Web

**Option 1: Build Native Mobile App**

- **Pro:** Better performance, offline support, push notifications
- **Con:** 6 month build time, need to hire mobile engineers, maintenance overhead
- **Cost:** 2 iOS engineers + 2 Android engineers for 6 months ($500K+)
- **Assumption:** 40% of usage will shift to mobile within 6 months
- **Risk:** Mobile engineers are hard to hire, could delay 3+ months

Step 3: Make a Recommendation

After laying out options:

You've mapped the options clearly. Now it's time to make a call.

**What's your recommendation?**

Remember: The goal isn't to make everyone happy. It's to make the right
decision for the business and clearly explain why.

A strong recommendation includes:
- **The choice:** Which option you're choosing
- **The why:** Your reasoning (data + logic)
- **The confidence level:** How certain you are (high/medium/low)
- **The failure mode:** What you'd do if you're wrong

Don't hedge. Make a clear call, even if you're not 100% certain.

I'll help you structure a compelling recommendation.

Recommendation Structure

## Recommendation: [Option Name]

### The Decision

I recommend we **[clear statement of choice]**.

**Example:** "I recommend we build a native mobile app starting Q2,
rather than continuing to improve the mobile web experience."

### Rationale

**Why this option wins:**

1. **[Primary reason]** - [Data or logic supporting this]
2. **[Secondary reason]** - [Data or logic supporting this]
3. **[Tertiary reason]** - [Data or logic supporting this]

**Why alternatives fall short:**

- **[Alternative 1]** - [Specific reason it's not as good]
- **[Alternative 2]** - [Specific reason it's not as good]

**Key tradeoffs we're accepting:**

- We're trading [X] for [Y] because [reason]
- We're deprioritizing [A] to focus on [B] because [reason]

**Example:**

- We're trading faster time-to-market for better performance because
  our user research shows performance is the #1 complaint
- We're deprioritizing web improvements to focus on mobile because
  45% of usage is now mobile and growing 15% QoQ

### Confidence Level

**Confidence:** [High / Medium / Low]

**What would increase confidence:**

- [Test/data that would make you more certain]
- [Validation that's still needed]

**Example:**

- **Confidence:** Medium-High (75%)
- **Would increase to High if:** We validate mobile engineers can be
  hired within 6 weeks, and tech lead confirms 6-month timeline is realistic

### What If We're Wrong?

**How we'll know:**

- [Leading indicator that this isn't working]
- [Timeline for when we should see results]

**Pivot plan:**

- [What we'd do if this fails]
- [How easily we could reverse course]

**Example:**

- **How we'll know:** If after 2 months we haven't hired mobile engineers,
  or if recruitment timeline slips past 12 weeks
- **Pivot plan:** Pause mobile app, redirect resources to mobile web
  improvements as interim solution

### What This Unlocks

**Positive outcomes if we're right:**

- [Business impact]
- [User impact]
- [Strategic advantage]

**Example:**

- Unlock 45% of our user base who prefer native apps
- Enable offline mode, which is #2 feature request
- Position us competitively against Competitor X who just launched mobile

Step 4: Document the Decision

Finally, I'll create the complete decision document:

I'll create your decision document in the format that works best for
your culture and stakeholders.

**Choose format:**
1. **Standard** - Comprehensive doc for important decisions
2. **DACI** - When you need clear roles and accountability
3. **One-W