McKinsey did not build its reputation on clever slides alone. The firm trained generations of consultants to define the question tightly enough that a team could actually solve it.

Start with a tighter question

Most weak problem solving starts with a vague brief. Revenue is down. Hiring is hard. Customers seem unhappy. A usable question adds scope, a group, and a measurable issue.

That is the practical value inside the mckinsey problem solving framework. You translate noise into a question that excludes distractions. "Why did repeat purchase fall among UK subscribers in Q1" is a better starting point than "why is growth slowing."

Break the problem into parts

Once the question is clean, split it into non-overlapping parts. Structured decomposition stops teams from discussing the same issue in five disguises.

A retailer such as Marks & Spencer might break margin decline into price, mix, markdowns, and returns. A software company such as Atlassian might break retention into onboarding, team invite rate, and weekly workflow depth.

Test causes before solutions

Teams often jump from symptom to fix. McKinsey-style work asks for evidence first. Which branch explains most of the problem, and what data would weaken that belief?

That habit protects you from expensive confidence. In healthcare, logistics, and SaaS, the first obvious cause often explains only part of the story.

Recommend one move, not five

A crowded recommendation sounds busy, not sharp. Choose one move that fits the evidence and one small test that can falsify your view. Senior leaders want to know where to act next, not how many slides you prepared.

The best part of the mckinsey problem solving framework is discipline. You define the question, separate the pieces, test the causes, and make a recommendation that can survive reality. Sparks helps you rehearse that habit with daily exercises in reframing and alternative paths.