How Consultants Solve Problems
The consulting problem-solving method is not intelligence applied harder. It is a repeatable sequence that converts ambiguity into a small number of testable questions, then answers the ones that matter.
Define the question precisely
A well-defined problem statement is specific, measurable, actionable, and time-bound, and it names the decision-maker. Compare: 'improve profitability' against 'identify actions to raise EBITDA margin from 8 to 12 percent within eighteen months, for approval by the board in March'. The second can be worked; the first cannot.
Write the problem statement, then confirm it with the client in writing. Disagreement about the question surfaces later at ten times the cost.
Structure before you analyse
Break the problem into components that do not overlap and together cover the whole (the MECE principle, covered fully in Module 4). Structure first, because unstructured data gathering expands infinitely and produces analysis nobody can assemble into an answer.
The structure is a hypothesis about where the answer lives. It is meant to be revised as evidence arrives, not defended.
Prioritize ruthlessly
Not all branches deserve equal effort. Apply two filters: size of impact and ease of resolution. Branches that are large and quickly testable get attention first. Branches that are small, or that cannot be resolved within the timeline, get explicitly parked and documented as out of scope.
The 80/20 instinct is the single most valuable working habit in the profession. Most engagements have three to five drivers that account for the majority of the outcome.
Work hypothesis-driven
State the answer you currently believe, then design the analysis that would disprove it. This inverts the instinct to gather everything first. It is faster, and it protects against the more dangerous failure: assembling evidence that confirms a belief you never tested.
A hypothesis that survives three genuine attempts to break it is worth presenting. One that was never attacked is an opinion with charts attached.
Synthesize, then communicate
Synthesis is the step most beginners skip. It means answering 'so what' at every level: this analysis shows X, which means Y for the business, which implies action Z. Findings without implications are data dumps.
Then communicate answer-first (Module 9). The client should know your recommendation within the first ninety seconds.
Example: hypothesis-driven versus data-driven
Two teams investigate why a retailer's online conversion fell 20 percent.
Team A requests every dataset available and spends four weeks building a comprehensive analysis of all traffic sources, devices, and product categories.
Team B hypothesizes on day two that the decline is concentrated in mobile checkout following a site update, and asks for exactly two datasets to test it. By day four they have either confirmed the hypothesis or eliminated it and moved to the next.
Team B is not luckier. It is structured to fail fast, which is what makes it fast.
- A usable problem statement is specific, measurable, time-bound, and names the decision-maker.
- Structure the problem before gathering data.
- Prioritize by impact and testability; explicitly park what you will not pursue.
- State a hypothesis and try to disprove it rather than gathering everything first.
- Synthesis means answering 'so what' at every level.
Module quiz
Pass mark 70%1. Which problem statement is workable for a consulting engagement?
2. What does working hypothesis-driven mean in practice?
3. A team presents twelve findings with no implications drawn. What step was skipped?