Problem Solving Process

Use define → dissect → prioritize → plan → analyze → synthesize to help the user reach an evidence-backed decision. This is adapted from Alexander Lyon's six-stage explanation, which he describes as one version rather than a definitive McKinsey standard.

Default to framing the problem and producing an investigation plan first. Use supplied information and inspect directly relevant supplied sources to ground that plan; do not launch broad independent research during this phase. An explicit request to investigate, analyze, recommend, or continue an existing plan permits the relevant later stages within the requested scope. Do not restart completed stages when adequate prior work is available.

Frame and plan

Define

Identify the desired outcome, observed gap, affected stakeholders, constraints, timeframe, and decision the work should support. Distinguish symptoms, possible causes, and proposed solutions. A preferred solution is something to examine, not proof of the problem or its cause.

Ask focused questions only when missing information materially affects framing. Produce a concise, solution-oriented problem statement, without embedding an unproven diagnosis or predetermined intervention. Label it provisional when essential facts or agreement remain unresolved; do not imply team consensus.

Dissect

Break the problem into useful component questions or testable hypotheses. Keep causes, possible interventions, and investigation tasks distinguishable. Attach available supporting evidence, uncertainty, and plausible alternative explanations. Use a simple text tree when it clarifies the problem.

Consult untangle when deeper decomposition is needed. Apply its relevant guidance within this workflow without requiring every tree mode or returning duplicate deliverables.

Prioritize

Rank questions and controllable actions by their likely importance to the outcome, considering potential impact, influence, uncertainty, and investigation effort. Explain the ranking qualitatively unless defensible estimates exist. A high-priority investigation is not yet a proven high-impact solution.

Treat the source's 80/20 language as a prioritization heuristic, not a numerical promise. Retain consequential external constraints even when the team cannot control them; focus action on what the team can influence without pretending uncontrollable factors are irrelevant.

Develop the investigation plan

For each priority, specify the question or hypothesis; evidence needed and its source or how to locate it; the proposed analysis or test; the expected output and how it informs the decision; and known ownership and dependencies. Label suggested roles and unassigned work explicitly. Do not invent deadlines or assignments.

Give the investigation an actionable starting point while allowing findings to change the framing, priorities, and next questions. Avoid detailed downstream tasks that depend on unresolved findings.

Default deliverable: A concise problem brief, decomposition, ranked priorities, and investigation work plan, ending with material open questions and the next evidence-gathering step. Use a table for the work plan when it improves readability. Recommendations about the underlying solution remain provisional until supported. Finish this phase when the user can see what to investigate, why it matters, and how the result will inform a decision; do not silently proceed into execution.

Continue into analysis and synthesis

When requested, carry out the relevant investigation within the user's authorized scope. If evidence or access is unavailable, report the specific gap and what can still be concluded; do not label a planned analysis as completed work.

Analyze: Assess quantitative or qualitative evidence, alternative explanations, limitations, and implications. Separate observations from causal claims and assumptions. Revisit the problem definition or priorities when findings warrant it; do not select a cause simply because other hypotheses remain unproven.

Synthesize: Recommend an action supported by the analysis, explaining its rationale, tradeoffs, confidence, unresolved uncertainty, and what would change the recommendation. The strength of the recommendation must reflect the strength of the evidence. Preserve contradictory findings rather than telling a one-sided story. If evidence cannot support a solution yet, recommend the next discriminating test instead of inventing certainty.

Use Pyramid Principle when the recommendation needs stronger organization. Use Presentation Structure when presentation preparation is requested. Do not automatically create a deck, assign tasks, contact stakeholders, or execute recommended business changes.

Review existing work

Review supplied problem statements, investigation plans, analyses, or recommendations at their current stage. Identify consequential weaknesses in framing, evidence, prioritization, feasibility, or inference. Revise when requested, distinguishing changes in substance from wording improvements. Honor critique-only requests without rewriting or executing the plan.

Source

Related skills are optional. If a linked sibling skill is not installed, use the guidance in this file rather than treating it as a missing prerequisite.

Read Alexander Lyon's problem-solving source notes for the original examples, stage explanations, or attribution questions. Routine work does not require loading it. Preserve the six-stage version taught in the video even though the linked McKinsey source is titled as a seven-step process. The notes summarize the source teaching; this skill's scope, defaults, and operational safeguards are adaptations.