Have you ever been in a room where everyone knows what the solution is, but nobody has really described the problem yet?
It happens more often than you think. And it costs more than any poorly implemented software. I catch myself doing it too.
In digitalisation, there is systemic pressure for speed. Projects are measured in sprints. Anyone still analysing while others are already deploying quickly gets labelled as hesitant. The result: we jump into the solution space too early.
The pattern that slows projects down
In my consulting work I see it regularly: a company arrives with a concrete idea. "We need a new CRM." "We want to use AI in customer service." The solution is already decided, and usually the tool recommendations are already in place. The problem behind it is still unclear.
This is not a criticism, just a human pattern. Solutions give us a sense of control and competence. Looking at the problem for longer feels like standing still, chaos or an inability to decide. So we skip the uncomfortable part.
The price:
- We solve symptoms instead of causes
- We miss needs that only become visible through careful observation
- We build on assumptions nobody has ever really questioned
A week of implementation can sometimes be saved by two hours of genuine thinking. This reversal sounds odd. It is true nonetheless.
Two spaces, one boundary
Design Thinking names the problem precisely. The classic Double Diamond distinguishes two worlds: the problem space (discover and define) and the solution space (develop and deliver). The underestimated work happens in the problem space, not the solution space.
The decisive moment is not "Which solution do we choose?" but "Have we found the right problem?"
The Think-First principle follows the same logic. It assumes you understand before you design. "We start studying where others stop." That is not a slogan. It is an invitation to study alongside us.
"But we have no time for long analyses"
I know this objection well. It is legitimate, but rests on a misunderstanding.
Think-First does not take months. Sometimes two hours of structured observation and one more question than expected make all the difference. Design Thinking has lean formats for this: Empathy Maps, "How might we?" framing, short stakeholder interviews, a 5-Why conversation that surfaces assumptions in ten minutes. Or simply: watching the people involved in their actual work before talking about solutions.
It is not about understanding everything. It is about understanding the right things, to take the small steps in the right direction, to learn and tackle the next iteration. Whoever wants to understand everything before starting never starts.
What Think-First delivers in practice
- Fewer corrections: solving the right problem means less rework
- Better buy-in: solutions grounded in real problem understanding are carried by teams
- Shorter alignment cycles: shared problem understanding replaces weeks of clarification
- More lasting impact: addressing causes rather than symptoms
Conclusion
Think-First is not a brake. It is the most efficient way to take the first step in the right direction.
Whoever stays in the problem space longer than it feels necessary gets to the goal faster.