decision-frameworks
Decision Frameworks
Make better decisions faster by knowing what kind of decision you're making.
How to use
/decision-frameworksApply decision framework constraints to this conversation./decision-frameworks <decision>Apply the right framework to the described decision.
Constraints
Decision Typing
Classify every decision before making it:
- One-way door (irreversible): pricing model, platform migration, market positioning. Take more time.
- Two-way door (reversible): feature design, copy, UI layout. Decide fast, iterate based on data.
- MUST match analysis effort to decision type. Don't spend a week on a two-way door.
- SHOULD default to treating decisions as two-way doors unless proven otherwise
- NEVER treat a reversible decision like an irreversible one. Speed matters.
Decision Quality
- MUST define the decision clearly: what exactly are we choosing between?
- MUST identify the criteria: what matters most in this decision?
- SHOULD list options with pros, cons, and unknowns for each
- MUST set a deadline. Decisions without deadlines never get made.
- SHOULD designate one decision-maker. Consensus is slow and often produces mediocre outcomes.
Information Sufficiency
- MUST decide how much information is enough before gathering more
- For most product decisions, 70% confidence is sufficient to act
- SHOULD ask: "what additional information would change my decision?" If nothing, stop analyzing.
- MUST distinguish between information that reduces risk and information that delays action
- NEVER use "we need more data" as a way to avoid making a hard call
Decision Communication
- MUST document: what was decided, why, what alternatives were considered, and who was involved
- SHOULD share decisions with affected teams promptly
- MUST create space for disagreement before the decision, not after
- Once decided: disagree and commit. NEVER undermine a decision you were part of making.
- MUST be willing to revisit decisions when new information fundamentally changes the context
Anti-Patterns
- Analysis Paralysis: endlessly gathering data to avoid committing
- Decision by Committee: requiring consensus on everything, getting mediocrity
- The Redo: making the same decision three times because it was never properly committed to
- HiPPO Decisions: highest paid person's opinion always wins regardless of evidence
- The Non-Decision: not deciding and letting the default happen by inaction
More from dragoon0x/product-skills
prd-writing
Write product requirement documents that engineers want to read and can actually build from. Covers structure, scope discipline, and the balance between clarity and over-specification. Use when writing PRDs, reviewing spec quality, or when engineering keeps asking clarifying questions.
1freemium-vs-paid-gate
Decide whether a product should offer a free tier, free trial, or go straight to paid. Structured decision framework based on economics, distribution model, and competitive landscape. Use when launching a new product or reconsidering your pricing model.
1error-recovery
When things break, guide people forward instead of leaving them stranded. Error message copy, retry patterns, graceful degradation, and recovery flows. Use when building error handling or failed state UIs.
1cta-patterns
Design calls-to-action that people actually click. Covers button copy, placement logic, urgency without manipulation, and progressive commitment. Use when reviewing pages for conversion potential or when CTA copy feels generic.
1onboarding-flow
Design first-run experiences that create the aha moment fast. Reduces time-to-value by sequencing actions, progressive disclosure, and contextual guidance. Use when building signup flows, product tours, or empty states.
1user-psychology
Apply motivation, friction, and trust patterns to product decisions. Maps cognitive biases and behavioral triggers to specific UI and copy choices. Use when reviewing flows for drop-off points or when something feels right but doesn't convert.
1