In a recent post, Tim Kastelle pointed out that "how you define a problem determines if you can solve it."  But even if you start with the right question, how you approach the solution makes the difference between whether you'll up with an innovation or more-of-the-same.

Tim's point is that if you define the problem too narrowly, you over-constrain the solution space.  If you really overdo this, you may end up with no possible solution at all.

Even if we define the problem broadly enough, if you approach every solution in a purely analytical way, you will get unsurprising results.  The analytical approach is to first eliminate all the unknowns to reduce the solution to a series of well-understood steps, that can be completed in a predictable time frame, at an estimable cost.  No surprises allowed and, therefore, no innovation is possible.

Interpretation vs Analysis

To counter-weight this approach and improve our chances to innovate, Lester and Priore propose the interpretive approach.  In their book Innovation, The Missing Dimension, the authors describe the role of the manager during interpretation as having "less to do with solving problems or negotiating between contending interests than with initiating and guiding conversations among individuals and groups."

They are very clear that the aim is not to replace one approach with the other, but rather to integrate the two,

Businesses must strengthen the interpretive approach to a point where it can stand alongside analysis as a tool to cultivate innovation.

White Space

As I was ruminating Tim's post and how it played with the interpretive model championed by Lester and Piore, I read Idris Mootee's post on White Space Mapping.  I liked that Idris describes White Space as "a customer inquiry and discovery process."  That's a pretty good, succinct description of an interpretive process, and very importantly, it puts the customer smack dab in the middle of it.

Connecting the Dots

Putting it all together, this all seems to indicate that to arrive at more innovative solutions,

• Be careful not to define the problem so narrowly as to over-constrain the possible solution space.  You want to leave plenty of room for White Space.
• Facilitate conversations among the stakeholders, across functions, departments and even business boundaries.  This part of the process must include potential customers and users of the final result (whatever that turns out to be).
• Implement the final solution.

Of course, the last two are not separate steps in a serial process.  Rather, they are interacting elements of an ongoing, iterative cycle from which a tangible solution emerges.

UPDATE: The OODA Loop

After I wrote this post, I realized that the the cycle described above is reminiscent of John Boyd's OODA Loop, the granddaddy of all Agile processes.  I could say a lot more about this, but I'll leave that for future posts.