Mckinsey problem solving
Skill succtorlin/mckinsey-problem-solving-skill/skills/mckinsey-problem-solving
A Manus Agent Skill that encodes McKinsey & Company's complete problem-solving methodology — MECE, Issue Trees, Pyramid Principle, SCQA, So What Test, and the 7-Step Process.
npx -y skills add succtorlin/mckinsey-problem-solving-skill --skill mckinsey-problem-solvingAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Apply McKinsey & Company's methodology for critical thinking and structured problem solving. Use for: analyzing complex business problems, structuring arguments, building issue trees, applying MECE, writing recommendations, structuring presentations with the Pyramid Principle, crafting SCQA narratives, synthesizing findings with the So What test, and thinking like a management consultant.
SKILL.md
5.1 KB, as published. Nobody here has run it
Overview
This skill encodes McKinsey's complete problem-solving methodology — the same approach used on multi-billion dollar client engagements. It covers structured thinking, communication, and analytical frameworks.
Read reference files when needed:
references/frameworks.md— All 10 core frameworks in detail (MECE, Issue Trees, Pyramid Principle, SCQA, So What, Ghost Deck, etc.)references/seven_step_process.md— The full 7-step process with step-by-step guidancereferences/applied_examples.md— Worked examples for business problems, strategy questions, presentations, and meeting responses
Core Philosophy
McKinsey's edge is not intelligence — it is process. The methodology forces clarity at every step:
- Define before analyzing. Most teams solve the wrong problem because they skip problem definition. Spend disproportionate time here.
- Structure before data. Build the issue tree before collecting data. The structure reveals where the answer is likely to be.
- Hypothesize before analyzing. Form a hypothesis, then design the minimum analysis to prove or disprove it. Never "boil the ocean."
- Synthesize, don't summarize. Clients pay for insight, not data. Every finding must answer "So what does this mean for the decision?"
- Lead with the answer. Always communicate top-down: recommendation first, then supporting arguments, then evidence.
The 7-Step Process (Quick Reference)
| Step | Goal | Key Tool |
|---|---|---|
| 1. Define the problem | Precise, agreed-upon problem statement | Problem statement template |
| 2. Structure the problem | MECE issue tree mapping all possible causes/solutions | Issue tree |
| 3. Prioritize the issues | Identify the 2–3 branches most worth investigating | Impact × movability matrix |
| 4. Plan the work | Design minimum analyses needed; align on the story | Ghost deck |
| 5. Conduct analyses | Execute, update hypothesis as evidence emerges | 80/20 rule |
| 6. Synthesize findings | Convert data into insight; apply So What test | Pyramid Principle |
| 7. Communicate | Lead with answer; use SCQA to open; action-oriented close | SCQA + Pyramid |
For full step-by-step guidance, read references/seven_step_process.md.
When Applying This Skill
For problem analysis tasks:
- Start with Step 1: write a precise problem statement before anything else.
- Build an issue tree (Step 2) — draw it out, ensure each level is MECE.
- State your initial hypothesis explicitly before looking at data.
- Apply the 80/20 rule: identify the 2–3 analyses that will answer 80% of the question.
- Synthesize findings using the So What test before writing any output.
For communication and writing tasks:
- Identify the governing thought (the single most important message).
- Build the pyramid: governing thought → 3 key arguments → supporting evidence.
- Open with SCQA: Situation → Complication → Question → Answer.
- Write every section/slide title as a complete sentence with the insight (not a topic label).
- End with specific, prioritized next steps.
For structuring any breakdown or list:
- Apply MECE: check for overlaps (ME) and gaps (CE).
- Use the ME test: "Can I change one element independently of the others?"
- Use the CE test: "Are there any other conditions that must be true?"
- Prefer process-based, component-based, or hypothesis-based structures over random lists.
Key Principles at a Glance
| Principle | Rule |
|---|---|
| MECE | No overlaps, no gaps — in every breakdown |
| Hypothesis-driven | Form a view first, then test it |
| 80/20 | Do the minimum analysis to reach a defensible answer |
| So What | Every finding must state its implication for the decision maker |
| Pyramid | Lead with the answer, support with arguments, back with evidence |
| SCQA | Open with Situation → Complication → Question → Answer |
| Ghost deck | Outline the story before building the slides |
| Problem definition | Spend 20–30% of total effort here — it is the highest-leverage step |
Common Mistakes to Avoid
- Jumping to analysis before defining the problem precisely.
- Building non-MECE lists (overlapping or incomplete categories).
- Summarizing instead of synthesizing — presenting data without the "So what."
- Burying the answer at the end of a presentation instead of leading with it.
- Boiling the ocean — analyzing everything instead of prioritizing the critical path.
- Confusing observations with hypotheses — "Revenue declined" is an observation; "Revenue declined because of pricing pressure" is a hypothesis.
- Skipping the ghost deck — building slides before aligning on the story.