When a company hires us, it usually arrives with a brief: here is the problem, here is roughly what we think the solution looks like, please go and build it. The first thing we do is refuse to solve it.
Not out of arrogance. Out of experience. The problem written in the brief is almost never the real one. It is the symptom that became impossible to ignore, dressed up as a diagnosis. Solve it as written and you ship a faster version of the wrong thing.
The clean slate
We arrive with nothing assumed. No template, no pre-baked methodology waiting for a place to land. A framework built for someone else's company is a comfortable thing to sell and a dangerous thing to buy. We would rather start empty and earn the answer.
Then we go to the floor. We do not study the problem from a deck or a data room; we go and live it, inside the operation, until we understand it better than the brief ever could. That is where the real problem usually reveals itself, and it is rarely the one we were hired to fix.
Solve the brief as written and you ship a faster version of the wrong thing.
An example of the shape
A connectivity issue in stores looked like an IT ticket. Lived on the floor, it was a revenue problem, and fixing it properly added millions a year and changed a global IT policy. Had we solved the ticket in the brief, we would have closed a ticket. Nobody would have found the rest.
Why this is the whole game
Finding the real problem is not a phase that precedes the work. It is the work. Everything downstream, the build, the rollout, the adoption, is only as good as the problem you chose to solve. Choose wrong and execution speed just gets you to the wrong place faster.
So we refuse the brief, on purpose, every time. Then we find the problem underneath it, and we build the answer to that one.