| name | decision |
| description | Use this skill when the user asks to "help me decide", "think through this decision", "weigh options", "what should I do about", "analyze trade-offs", "should we do X or Y", or needs a thought partner for product micro-decisions in their daily work.
|
| version | 1.0.0 |
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:
- Recommendation: "Go with Option B."
- Primary reason: Single most important reason (1-2 sentences)
- Supporting reasons: 2-3 additional factors
- Watch out for: Biggest risk and mitigation
- 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:"
- Best counter-argument: The single most compelling reason to choose differently (2-3 sentences, steel-man the opposing view)
- What you'd need to believe: "This recommendation is wrong IF [assumption] turns out to be false"
- 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.
