Technically correct, strategically useless
Why the best analysis fails when it's aimed at the wrong kind of problem, and how to read which one you're standing in.
A few years ago, my team built the best deck of my career.
A client needed to make a big platform decision. Six weeks of analysis went into it. Three options, properly costed. Every risk quantified. A recommendation that survived every test we threw at it. I was proud of that work, and I still think it was the best pure analysis my team ever produced.
We presented it. The room was polite. Someone called it “really helpful”. Then they asked for another meeting.
I found out what was actually going on in a corridor conversation afterwards. Two of the executives in that room had been fighting about this decision for over a year. Everyone already knew what the answer was. They just had not agreed to want it. Our beautiful deck had not brought analysis to a decision. It had brought ammunition to an argument, and every extra page made things worse.
The method we all learned
Every big consulting firm teaches the same way of working. Break the problem into pieces. Analyse each piece. Put it back together as a recommendation. Present it well.
It is a genuinely good method, and I am not here to mock it. It also made my career possible. The trouble is what we were taught alongside it: that it works on everything.
It works brilliantly on one kind of problem. And the problems clients bring come in four kinds.
It does not. It works brilliantly on one kind of problem. And in my experience, the problems clients actually bring come in four kinds.
The four kinds of problems
Kind one, the diagnostic problem: “We don’t understand what’s happening.” Margin is leaking somewhere in the European business and nobody can explain why. This problem needs patience. You have to keep it open until you truly understand the mechanism underneath. What the standard method does instead is pick a suspect in week one and spend five weeks building the case against it. It feels rigorous. It is actually a guess with a paper trail. Research on decision-making backs this up: failure is about four times more likely when leaders run with the first idea they meet.
Kind two, the decision problem: “We must choose between options.” Three acquisition targets, one cheque. This is the problem our method was built for, and here it genuinely shines. Honest analysis across real options is exactly the right treatment.
There is one catch, and it is the most useful research finding I know. Paul Nutt, a professor at Ohio State, spent two decades studying how organisations make big decisions. He looked at over four hundred of them. About half failed. And the failures were concentrated in one pattern: the boss had already decided, and the analysis was commissioned to defend the choice. Those imposed decisions took around 22 months to land, and only half of them stuck. When leaders genuinely searched for options instead, decisions landed in around 14 months and about 85% stuck. Analysis that dresses up a done deal is not a decision process. It is theatre with exhibits.
Kind three, the design problem: “We must create something that doesn’t exist.” A new operating model. A business the market has not seen yet. This problem needs you to spread out before you narrow down: generate lots of ideas first, choose later. The standard method cannot wait. It benchmarks what competitors already do, builds a scoring matrix over three options, and picks a winner. The answer comes out neat, defensible, and built for yesterday.
Kind four, the alignment problem: “The parties haven’t agreed to want the same thing.” This is my deck story. Two executives at war, and a brief that says “give us the analysis.” What this problem actually needs is the disagreement worked: get the real interests on the table, find out what each side would need in order to say yes, and build the agreement person by person. What the method does instead is stack more evidence onto one side of an argument. And here is the thing I learned in that corridor: when the problem is a disagreement, every extra page of analysis reads as pressure. You cannot analyse your way out of a disagreement.
You cannot analyse your way out of a disagreement.
The reference card
Diagnostic: "We don't understand what's happening." Needs: patience until the mechanism is clear. Dies when: a suspect is chosen early and proven at length.
Decision: "We must choose between options." Needs: honest analysis across real options. Dies when: the choice was already made and the analysis is decoration.
Design: "We must create something new." Needs: many ideas before any choosing. Dies when: the team benchmarks yesterday and picks from three.
Alignment: "We haven't agreed to want the same thing." Needs: the disagreement worked, person by person. Dies when: rigour is used as ammunition.
How to tell which type of problem you’re standing in
Nobody taught me this part. I learned it from getting it wrong, and it now takes me four questions in the first meeting.
Last year, a client asked us to run a vendor selection. Three software vendors, one recommendation needed. On paper, the cleanest possible job: a genuine choice between options. Before scoping it, I asked the sponsor one question.
“Imagine our analysis shows a clear winner. What happens the next morning?”
He paused. Then he told me about the COO and the CIO, who had each been backing a different vendor for the best part of a year, and how the last attempt at this decision had ended.
So we did not sell six weeks of analysis. We spent two weeks having one-to-one conversations, found out what each executive actually needed to feel safe saying yes, and wrote a one-page memo. The selection meeting took 20 minutes. The big deck they originally asked for would have been beautiful. It would also have been filed, achieving no outcomes.
The four questions, in the order I use them:
“If the analysis lands clean, who acts, and what stops them?” If the honest answer includes a name and a grudge, you are in an alignment problem, whatever the brief says.
“Do the options exist yet, or do we need to invent them?” Choosing is a decision problem. Inventing is a design problem. Each one dies under the other’s treatment.
“Do we understand why this is happening, or only that it is happening?” A symptom without a mechanism means a diagnostic problem, however loudly the room asks for recommendations.
“Would you fund experiments that might fail?” If the answer is no, the room wants something new invented at the price of a simple choice, and someone should say so out loud.
"We need an analysis to prove who is right" means the fight came before the facts.
And there is one sentence that gives the game away every time: “we need an analysis to prove who is right.” Nobody who says that has a decision problem. They have a fight, and they are shopping for a weapon.
Two honest warnings before you use any of this.
First, real projects move between the four kinds. A margin question turns into a redesign, which turns into a turf war. So you re-ask the questions at every big gate, not just at kickoff.
Second, I understand exactly why the standard method gets used on everything: it can be taught to a twenty-four-year-old, it scales across a big team, and its output is defensible in front of a board.
A method that fits one problem in four but can be taught will always outsell judgement that cannot be staffed. That is precisely why the fix is not a new method. It is one meeting and four questions before the machine switches on. Asking them costs nothing. It just needs someone senior enough to ask.
It all depends where you are in your consulting career
Somewhere between Senior Manager and Director, the thing you are being graded on quietly changes. Below that line, you are graded on running the analysis well. Above it, you are graded on knowing what work the situation actually needs. The two skills are almost unrelated, and nobody sends a memo about the switch.
Rigour can be delegated. Reading the problem cannot.
Misreading the problem is how strong analysts stall. The work stays excellent. The client stays unmoved. And your credibility drains without anyone saying a word, because clients can always feel when the work missed the problem, even when they cannot explain how. Rigour can be delegated. Reading the problem cannot.
There is also a money angle to this, and it is the most senior thing in this letter. Reading the problem correctly will sometimes argue against the big analytical project your firm would love to sell. The consultant who walks in with the smaller, better-aimed piece of work is trading margin for trust. In my experience it is the fastest trust trade in this profession, because the client has met a hundred people who sold them analysis, and very few who told them what their problem actually was. Make that call visibly, once or twice, and it becomes the reason the people above the room start saying you are ready to sit with a client alone.
One last thing. The mismatched engagements are the exhausting ones. Six weeks of rigour that nobody wanted takes something out of a team that a well-aimed fortnight never does. Reading the problem first is not just better advice. It is how this job stays survivable.
Analysis is graded on rigour. Advice is graded on fit.
Reply to this email and tell me about the time your best work changed nothing, and what the problem turned out to be. I read every reply, and the next issues get built from what comes back.
Roman