Why we always start with the problem
Most projects fail before the first line of code, at the moment someone decides what to build.
There's a sentence you hear in almost every project kick-off: "We know what we want to build."
It's almost always false. What's known at that stage is what the solution is imagined to look like. That's a different thing, and the difference is expensive.
The solution arrives too early
By the time an organisation states a need, it has already travelled a long way mentally. Someone noticed friction, interpreted it, imagined a response — and it's that response they present. The original problem never gets said out loud.
The result is a brief that describes a solution in great detail and a problem not at all. So you build exactly what was asked for, and nobody uses it.
This isn't a failure of rigour. It's how minds work: we jump to diagnosis because uncertainty is uncomfortable. An undefined problem stays open; a solution, even a poor one, closes the question.
What reversing the order changes
We impose one constraint: before any discussion of what will be built, we have to be able to write the problem in a single sentence the affected person recognises as their own.
Not a sentence that sounds good in a meeting. A sentence describing a specific situation, experienced by an identifiable person, at an identifiable moment.
The exercise has an unexpected effect. In a meaningful share of cases, the solution imagined at the outset is no longer the right one. Sometimes it's too large — the real problem was one step, not the whole process. Sometimes too small — the visible friction was only a symptom. Sometimes there's nothing to build at all, and an internal rule would do.
Each of those is a project avoided, reduced or redirected. That's money not spent on nothing.
How we do it
Three habits, no elaborate methodology:
We talk to people who live the problem, not people who describe it. They're rarely the same. Whoever commissions a project has the overview; whoever does the task knows the workarounds. Workarounds are the single most valuable piece of information available — they're solutions users have already invented.
We look for what disproves. If every observation confirms our instinct, we've looked badly. We ask explicitly: under what circumstances would what we believe be false?
We write the problem before we write the solution. A short document, dated, shared. If it's hard to write, we haven't understood it — and engineering shouldn't be where that gets discovered.
What it actually demands
This approach requires accepting one uncomfortable stretch: the period where you can't yet answer "so what are we building?".
That stretch is short. Two to three weeks, in our experience. But it's the only one that determines whether the rest was worth doing.
A problem properly understood is already half solved. The rest is discipline.
Category THINK · Reading time 6 minutes