The problem with solutions is that answers stop thinking, as Chuck Frey says in a good post today.
When trying to solve a problem, often the best thing to do is to leave the question open for a while. This is tough, because most people have a natural tendency to want to solve the problem as quickly as possible.
I’ve noticed this tendency again working with our MBA teams on the Wharton Global Consulting Practicum (which I mentioned earlier here).
We’ve moved into the problem-solving part of these projects now that we have our scopes defined. However, now that the problem is defined, it has been difficult to battle this tendency to jump straight to finding answers.
I’ve been stressing with the teams the need to keep our options open for a while. Chuck has some good suggestions for doing this in his post. Another way to do this is to use the divergence/convergence strategy discussed in Gamestorming, which I outlined in more detail previously.
That first figure outlines the general process. Of course, the actual path that you take in problem-solving ends up looking more like this:
The problem with jumping straight to answers is that you reduce the amount of effort put into the first step, idea generation, and you put no time at all into the second step – experimenting, thinking and prototyping.
When these two steps aren’t fully explored, you end up putting all of your effort into developing conclusions and planning actions for only one answer. You may do this extremely well, but the problem is that it might not be the best answer.
People like jumping to answers because it reduces uncertainty. When you are expanding the range of options to consider, and then test out these ideas, you are increasing ambiguity. This makes many people uncomfortable.
But if you’re disciplined enough to be able to live with that ambiguity for a while, you usually end up with a better answer to your problem.
It’s natural to want to have an answer to a problem as quickly as possible – this is the way you make the problem go away. However, if you are able to hold off for a while, and make sure that you generate and test out a wide variety of possible answers, the odds of finding a good one improve.
So the best way to solve a problem is to not solve it. At least for a little while.
Very interesting post, Tim!
I think it’s similar to what I was trying to say in my previous post:
http://timkastelle.org/blog/2011/01/innovation-a-new-match-between-need-and-solution/
If you engage in solutions too early instead of staying focussed on the needs (=problem) for a while, you will likely end up in incremental improvement and suboptimal solutions. This seems also valid for customer integration.
Cheers, Ralph
Well, that does it. I’ve enlarged the second sketch, printed it, and pinned it up in my cube. It seems like I’m always coming back over here to find it so I can show it to someone. No more!
And this post addresses the psychological component of innovation – the subconscious desire to solve problems – and jumping to conclusions.
Thanks, Tim!
I think you’re right Ralph – one thing that I find with blogging is that there is real value in finding ways to restate the key ideas. Something that doesn’t click with people in one approach ends up working in another. So it helps to have different angles (and different people!) on the same problem. I guess it’s another way of keeping the problems open for a while!
Sorry to hear you won’t be coming back as often Brian. 😀 Actually, I’m glad that the sketch is useful – I like it a lot, it’s one that I end up recreating on whiteboards fairly regularly. The book that it came from, Gamestorming, is a pretty good one.
Hi Tim, (found your blog via http://www.johnniemoore.com/blog/archives/002790.php )
I experienced something like this last week in a ‘Motivational Design’ session lead by Kes Sampanthar (of Cynergy).
Instead of jumping right into use-cases in Act 2, we went through a structured brainstorming exercise using Kes’ ThinkCube ( http://www.metamemes.com/products.php ).
It was fantastic – very fruitful for both short-term and long-term idea generation, as well as helping prioritize the initial requirements.
Cheers,
-Ron
Thanks for stopping by Ron, and thanks for the practical example. It’s always good to hear about these ideas working in other contexts.