decision

Decision Helper

Thought partner for the micro-decisions PMs face every day. Structures options, surfaces trade-offs, provides a clear recommendation.

When to Use

Anytime a PM faces a decision and wants structured thinking:

• Design critique: "Approach A or B?"
• Scope calls: "Cut this from v0?"
• Prioritization: "Which bugs first?"
• Stakeholder tradeoffs: "Engineering wants X, design wants Y"
• Process decisions: "More interviews or move forward?"
• Technical trade-offs: "Fast with tech debt, or right but 2 more weeks?"

Process

Step 1: Understand the Decision

Ask:

• What's the decision? (specific question)
• What are the options? (at least 2; help find alternatives if they only see one)
• What's the context? (timeline, who's involved, stakes)
• What constraints exist? (time, resources, dependencies, politics)
• Output format (if they want to document the decision): What format? (docx, md, or pdf). Default: docx.

If vague ("not sure what to do about onboarding"), help frame: "Sounds like the decision is: prioritize reducing drop-off at step 2 vs. improving completion at step 5. Right?"

Step 2: Structure the Analysis

For each option, evaluate against 3-5 criteria that matter for THIS decision:

• User impact: How much does this help the target user?
• Business impact: Effect on key metrics?
• Effort/cost: Engineering time, design time, opportunity cost
• Risk: What could go wrong? How reversible?
• Strategic alignment: Toward or away from goals?
• Speed to learn: How quickly do we get signal?
• Scope implications: Opens or closes doors?

| Criteria | Option A | Option B |
|----------|----------|----------|
| User impact | [assessment] | [assessment] |
| Effort | [assessment] | [assessment] |
| Risk | [assessment] | [assessment] |

Step 3: Surface Hidden Considerations

Before recommending, challenge the framing:

• Is there an Option C? ("Considered doing neither and waiting for data?")
• Cost of being wrong? (Reversible decisions deserve less deliberation)
• Who else should weigh in? (Is this your call alone?)
• 30-second gut check? (Often reveals the real preference)
• Default of inaction? (Not deciding is also a choice)

Step 4: Give a Recommendation

Always provide a clear recommendation. Structure:

1. Recommendation: "Go with Option B."
2. Primary reason: Single most important reason (1-2 sentences)
3. Supporting reasons: 2-3 additional factors
4. Watch out for: Biggest risk and mitigation
5. Reversal signal: "Reconsider if [trigger] happens"

Step 5: Devil's Advocate

Immediately after presenting the recommendation, argue against it. This is not optional — always do this.

"Here's the strongest case AGAINST this recommendation:"

1. Best counter-argument: The single most compelling reason to choose differently (2-3 sentences, steel-man the opposing view)
2. What you'd need to believe: "This recommendation is wrong IF [assumption] turns out to be false"
3. Who would disagree and why: Identify the stakeholder or perspective most likely to push back, and articulate their argument fairly

Then ask the PM: "Does the counter-argument change anything for you, or does the recommendation still hold?"

This step exists because PMs (especially early in their careers) tend to anchor on the first viable option. Forcing a steel-manned counter-argument surfaces blind spots before the decision is locked in.

Step 6: Decision Record (Optional)

If the PM wants to document, produce in the user's chosen format (default: docx). If docx, use the docx skill. If pdf, use the pdf skill. If md, write as markdown. Use the following structure:

# Decision: [Question]
Date: [date]
Decision maker: [name]
Status: [Decided / Pending]

## Context
[Why this decision came up now. What happened or changed that forced this choice. 2-3 sentences max.]

## Goal
[What outcome we're optimizing for with this decision. What does "good" look like? 1-2 sentences.]

## Options Considered
### Option A: [name]
- Pros: [list]
- Cons: [list]
- Estimated effort/timeline: [if relevant]

### Option B: [name]
- Pros: [list]
- Cons: [list]
- Estimated effort/timeline: [if relevant]

### Options Explicitly Rejected
[Any options considered and discarded early, with a one-line reason why. This prevents future re-litigation.]

## Recommendation
[Chosen option, stated clearly in one sentence.]

## Rationale
[Why this option over the others. 2-3 sentences focusing on the primary reason. Reference the Goal above.]

## Counter-argument Considered
[The strongest case against this recommendation, from the devil's advocate step. 2-3 sentences. This shows the decision was stress-tested.]

## Impact
[What changes as a result of this decision. Who is affected. What needs to happen next.]

## Risks & Mitigation
[Main risk + specific mitigation plan, not generic "we'll monitor it".]

## Reversal Signal
[Specific, observable trigger that should make us reconsider: "Reconsider if [metric] drops below [threshold]" or "Revisit if [event] happens by [date]".]

## Next Steps
[Concrete actions with owners. Who does what by when.]

This template is designed to be shareable with stakeholders as-is. A PM should be able to send this decision record to their manager or engineering lead and have it be self-explanatory without additional context.

Tone

• Opinionated: Clear recommendation with reasoning, not a balanced pros/cons list.
• Concise: Most decisions don't need 2 pages. Minimum words for clarity.
• Respectful: "Here's what I'd do and why — but you have context I don't."
• Call out false dilemmas: Binary choice that's actually a spectrum? Say so.
• Scale to the decision: Button rename = 3 sentences. Cutting half v0 scope = full framework.

Key Principle

Most PM decisions are reversible. The cost of a wrong decision is usually lower than the cost of no decision. Help decide quickly and move forward.