If I had an hour to solve a problem I’d spend 55 minutes thinking about the problem and five minutes thinking about solutions. – Albert Einstein
I don’t know whether Einstein ever used those words. It may be just like the Henry Ford “Faster Horses” quote – something perfectly phrased and also perfectly true that no-one actually ever said.
Whether he said it or not, Einstein believed
the quality of the solution you generate is in direct proportion to your ability to identify the problem you hope to solve.
And of course he was right, you can’t really solve a problem you don’t fully understand. “If you can’t explain it simply, you don’t understand it well enough”. Another quote he (probably) didn’t say.
Either way, 60 years after his death, many of our organisations have still failed to learn his most valuable lesson. So what is so difficult about problem definition?
Many of our organisations have set the climate for
solution focused rather than problem defining behaviours.
A
solution focused culture is exacerbated by the following conditions:
- Leadership putting pressure on finding quick fixes and the realisation of short term goals – rather than long term impact
- Discussing problems, or considering that organisation itself may be part of the problem, is seen as taboo or a sign of weakness
- Management falls in love with a solution too easily even if it’s not solving the problem at hand
- An implicit assumption that leaders have all the answers. “Let managers manage and get on with it”
- A lack of evidence based enquiry – which allows bullshit organisational ‘facts’ to circulate and obfuscate true problem definition
In my work over the past five years, since I’ve given up having any operational responsibilities, I’ve seen how easily we can all lapse into solution focused work.
Unlike Einstein, when given an hour we often spend – at best – 5 minutes on the problem and the remaining 55 minutes solutionizing.
As
Simon Penny writes in a great piece
for Bromford Lab “when we talk about design we are using it as shorthand for 4 key elements of problem solving activity – discovery, definition, development and delivery. That means that at least half of what we do is based on truly understanding and defining the problem we are trying to solve and the other half is based on developing, testing and iterating ideas into a scalable solution. In short, we think about design as a whole end-to-end process”.
So rather than seeing problem definition as a one off activity, it’s now what we do
all the time, objectively helping the organisation to solve the right problems and resist its inbuilt solutionist behaviours.
The five step approach to problem definition
1. Establish the need for a solution
This sounds completely obvious but just because you’ve seen or thought of a solution doesn’t necessarily mean one is actually needed. Starting with a high level question of
“What problem are we trying to solve here?” and being very clear about it is a good starting point. You’ll usually come up with a lot of further questions – so don’t even bother trying to fully define the problem at this point. There may not even be one.
2. Match the problem to organisational strategy
Even if you’ve established the need for a solution – it may not be one your organisation is best placed to provide. No organisation, large or small, can manage more than five or six goals and priorities without becoming unfocused and ineffective. The best organisations don’t try and do everything. They focus on trying to solve fewer problems, in better ways.
That involves finding your ‘irreducible core’ of services and then constantly refining and innovating against it.
It also means saying no to trying to solve
everyone else’s problems.
3. Explore the context to the problem
Often your problem will be one that the organisation has tried to resolve before. We rarely stop to reflect on why our previous efforts failed and what we should avoid this time.
If the problem is industry wide, it’s crucial to understand why the market has failed to address it, and whether it is even feasible.
4. Writing the problem statement
Now you’re ready to write something down. A problem statement should describe the undesirable gap between the current-state and future-state. It should avoid any mention of a solution and be no longer than a tweet.
5. Initial prototype solution
As
Simon Penny also wrote here , prototyping can also be used to test an idea; not by creating a smaller working version of a service or product, but by testing the many different component parts or even thinking abstractedly in order to start to uncover what it might feel like to use the service or product. This can be tested – with people – to help you further refine the problem. Thinking of prototyping as part of the problem definition helps you avoid falling in love with your first idea.
All of this takes time , and
this is why our organisations are bad at it.
Falling in love with the problem , rather than the solution means:
- Accepting your first idea could be the worst idea – and might be wrong
- Being brave enough to pull the plug when you realise you’re not the ones to solve it
- Becoming comfortable with failure – as the only way you’ll ever explore a problem worth solving is through a ‘try, fail, learn and try again’ model.
When you truly fall in love with problems, not solutions, you not only stand a better chance of solving them. You also start unlocking a path to a better, less complicated organisation.
Related:
It’s Time To Rethink Industry Awards
