In the race for progress, we often rush for the first solution that presents itself, and rarely spend enough time thinking about the problem itself.
Charles Kettering – a man who counted the electric motor, automobile paint, the modern fridge, and the first aerial missile among his inventions – said ‘a problem well-defined is a problem half-solved’. It’s a statement that has an inherent logic: breaking a problem down into its component parts provides clarity, context, and the structure for a possible solution.
Some people like to explore all possible permutations of a solution before selecting a course of action (and often never make the leap from analysis to action), some people put progress above all other considerations, and don’t really care about the solution, particularly if they’re too busy/important to get involved in the detail.
Most people fall in between the two. Even so – for all but the most academically rigorous the temptation to jump to a solution based on a known result in the past is sometimes overwhelming. To borrow a phrase from military history, this is ‘fighting the last war’ – basing action on historical lessons, rather than on the current situation (ideally with knowledge of the historical context).
In the epically successful Story Seminar, on the essence and structure of story in film (but equally applicable to any storytelling medium) Robert McKee teaches a number of profound points, one of them being ‘research is the key to originality’. He makes the point that if a writer solves a plot problem with the first thing that comes to mind, it is inevitable that this will be derivative of another story – it may a previous story by the writer, or worse: a plot device used by another writer.
If our aim is to create a new solution to a perceived problem in a marketplace then this is a fundamental lesson, but even if our aim is just to deploy a working element of a system, research into a problem is never a bad thing, and if we’re not solving a problem, is there a point to what we’re doing?
We’ve come up with a simple little illustration to show the difference in method between the ‘Jump to It’ and the ‘Think about it’ approach.
In the ‘Think about it’ approach, there’s a more scientific process, predicated on thought and hypotheses, testing potential solutions with people who might make use of the end product, and iteration.
Sometimes a simple problem has an obvious solution, and you need the ‘Jump to it’ approach. More often a problem is more complex than it appears on the surface, and it needs a different perspectives to triangulate the problem, and more than one solution tested.
The bigger the problem, the more involved the thinking-testing cycle required – in this way we can be clearer on the true nature of the problem, and we’re giving ourselves the best chance of a solution that resolves it in a satisfying way.