Help me build a practical problem-solving framework for this situation. Problem statement: [PROBLEM] Desired outcome and success measures: [OUTCOME AND METRICS] Constraints: [CONSTRAINTS] Stakeholders and decision owner: [STAKEHOLDERS] What I know, what I have tried, and available data: [CURRENT EVIDENCE] Start by separating the stated problem from possible root causes, symptoms, assumptions, and unknowns. Do not assume the first explanation is the cause. Then produce a framework in six parts: 1. Scope: what decision is in and out of scope, with a one-sentence decision question. 2. Diagnosis: 3–5 testable hypotheses ranked by expected impact and uncertainty; name the evidence that would confirm or weaken each. 3. Options: 3 materially different approaches, including a low-cost reversible option where possible. 4. Decision criteria: weighted criteria totaling 100%, with definitions tied to my outcome and constraints. 5. Action plan: the next 14 days of work, owner, dependency, decision point, and smallest useful experiment for each major uncertainty. 6. Decision log: a compact template for recording assumptions, evidence, choices, and review date. Give a recommendation only if the current evidence supports one; otherwise recommend the next decision-reducing experiment. Surface tradeoffs explicitly, including cost, delay, operational load, risk, and effects on stakeholders. Do not invent data, stakeholder views, budgets, or authority. Before answering, check that the success measures are observable and that the proposed experiment can change a decision rather than merely generate activity. Ask up to 3 clarifying questions only if a required outcome, constraint, or decision owner is missing.
Fill in
| Placeholder | What to enter | Example |
|---|---|---|
| [PROBLEM] | Describe the problem, its scope, and why it needs a decision now. | Our eight-person product team misses its two-week release target about half the time, and customer-reported defects rise after rushed releases. |
| [OUTCOME AND METRICS] | State the desired result and measurable signals that would indicate success or failure. | Within 90 days, ship 80% of planned sprint commitments and reduce post-release P1/P2 defects by 30%; measure committed versus completed tickets and defects within 14 days of release. |
| [CONSTRAINTS] | List budget, time, staffing, technical, legal, or other limits that cannot be ignored. | No new hires this quarter; engineering cannot pause feature work for more than two days; releases must remain biweekly. |
| [STAKEHOLDERS] | Name affected groups, people whose input matters, and the person who makes the final decision. | Engineering, product, support, and enterprise customers are affected. VP Product makes the process decision. |
| [CURRENT EVIDENCE] | Summarize available data, assumptions, prior attempts, and known unknowns. | Last six sprints show carryover concentrated in integration work. Engineers report late requirement changes. We tried adding a daily standup, with no measured improvement. We do not yet know how much work is unplanned. |
How to use
- Describe the decision you need, not just the frustration; a framework cannot choose intelligently without a decision boundary.
- Use metrics with a baseline and review date, then remove metrics you cannot actually observe.
- Check the ranked hypotheses against available evidence before treating any one as the root cause.
- For follow-up, send: “Convert the top two hypotheses into a one-page experiment brief with sample size, owner, stop rule, and decision rule.”
Variations
Root-cause analysis
Use this when a recurring failure has several plausible causes.
Run a root-cause analysis for [PROBLEM]. Evidence: [EVIDENCE]. Process map or timeline: [PROCESS]. Constraints: [CONSTRAINTS]. Produce a causal tree separating observations, contributing factors, and root-cause hypotheses. For each hypothesis, list a discriminating test, data source, owner, and what result would rule it out. Identify where a five-whys chain becomes speculation. Do not assign blame or invent evidence. End with the smallest test to run this week. Check that each proposed cause can plausibly produce the observed failure. Ask up to 3 questions only if a key timeline or outcome is missing.
Decision matrix
Use this when you have several viable choices and need a transparent comparison.
Create a decision matrix for [DECISION]. Options: [OPTIONS]. Objectives and constraints: [OBJECTIVES]. Stakeholder priorities: [STAKEHOLDER INPUT]. Score each option against 5–7 criteria with weights totaling 100%, define every score, and show a sensitivity check for the two most influential weights. Include non-negotiable constraints separately so a high score cannot override them. State what evidence is missing and avoid inventing scores; use “unscored” where inputs do not support a rating. Ask up to 3 questions only if needed.
Pre-mortem plan
Use this before committing to a plan with meaningful delivery or operational risk.
Conduct a pre-mortem for [PLAN]. Goal and deadline: [GOAL]. Constraints: [CONSTRAINTS]. Stakeholders: [STAKEHOLDERS]. Assume the plan failed six months from now. List 8 plausible failure modes, their early warning signals, preventive action, contingency, owner, and review cadence. Include failures from adoption, dependencies, incentives, capacity, quality, and external changes where relevant. Do not fabricate known risks or certainty. Prioritize the top five by impact and likelihood based only on my inputs. Ask up to 3 questions only if required context is absent.
Tips
- Phrase the decision as a choice with a deadline, such as “Which support model should we pilot by November?” rather than “How can support improve?”
- A hypothesis is useful only when a result could change your next action. Replace broad claims like “communication is poor” with observable possibilities such as “requirements change after implementation begins.”
- Keep non-negotiable constraints outside a weighted scorecard; legal requirements, hard budget caps, and safety thresholds are gates, not preferences.
- Use reversible pilots when uncertainty is high, but define the metric and stop rule before starting so a pilot does not become permanent by inertia.
FAQ
Which framework should I use: SWOT, five whys, or a decision matrix?
Use a causal framework when you do not understand the problem, and a decision matrix when you already have options. SWOT is useful for broad context but rarely enough to make the decision itself.
Can AI identify the root cause from a short description?
It can propose hypotheses, not establish a root cause. Ask it to name the evidence that would distinguish competing explanations.
What if stakeholders disagree on the criteria?
Record the disagreement rather than averaging it away. The decision owner can set weights, or the team can compare how different weightings change the recommended option.