|
The board members reacted instinctively and negatively when Jim, the organization's director of operations, told them at their strategic planning meeting that “the current situation is unsustainable, we need to immediately cut programs and pull back!” "How could you say that?" asked Claire, the chairman. "It would be unthinkable to people who funded this organization, not to mention all the people depending on our services!" The discussion was rapidly becoming polarized, with Claire and some team members denying that there even was a problem. I quickly got the team to reframe the discussion by asking Jim a sequence of why questions until we identified the organization’s root problem that his radical solution was trying to address. If you frame a conversation around a predetermined solution, you're opening the discussion of needs with a proposed solution rather than the problem the solution's meant to address. In effect, Claire was telling Jim “I don’t like or accept your solution, so I deny the problem.” This phenomenon of mashing up a problem with a proposed solution can not only lead you to inaction or an inappropriate solution, it can also lead to “solution aversion” and polarization. (For more insight on solution aversion, read this article.) Too often a customer -- internal or external -- will tell you exactly what they think they need: “I need an 8.7-ounce, yellow USB digital dongle with 128 gigabytes.” However, what they are telling you is their concept of a solution to a problem that only they know. As a problem-solving vendor, you (and your client) need to understand what the root problem is before committing to a particular solution. Too often a vendor goes on a wild goose chase to shoehorn their capabilities into a customer’s solution conception, without first pinning down the actual problem. Understanding what the actual problem is usually leads to a much better solution, and one that also better matches your capabilities. When presented with “here is what I need,” you need to politely counter with “what do you want / why do you need that?” questions that track back to revealing the actual root problem. Back in the days when I was an application developer, I was asked to build a custom solution requiring over twelve man-months of expensive programming. By repeatedly asking why I was able to identify a root problem that could be solved with an existing, inexpensive piece of software available for overnight delivery from Staples. The customer saved thousands of dollars and was functional within a month. When I became director of development, I put this sign on my desk to communicate our department’s focus: Bring me problems, not solutions.
|
