By Stephen Balzac
July 11, 2013
“Alright, let’s see it fly.”
“We can’t do that.”
“What do you mean, you can’t do that? It’s a helicopter. Of course it flies!”
“Look at the specs. You didn’t say it had to fly!”
Imagine that you’re in a design contest to build a helicopter. You are being evaluated on various criteria such as efficiency, beauty, cost to build, and so forth. Sounds like a perfectly reasonable contest. In fact, it actually exists, although the details are omitted to protect the guilty.
The second place finishers designed a really quite excellent helicopter. The only reason they didn’t come in first was that their helicopter wasn’t as cheap to build as the winning model. The second place model included an engine.
I wish I could make this stuff up!
The team designing the first place helicopter noticed a minor omission in the criteria: there was no rule that said that the copter actually had to fly! They saved an enormous amount on cost and weight by not including an engine. As a side benefit, their helicopter was also the most fuel efficient and the safest model in the contest.
It didn’t actually work, but that wasn’t an official requirement at the time.
While we might celebrate the team’s ability to think outside the box, there are times when being inside the box isn’t such a bad place to be. Imagine shipping non-working helicopters to the customer-¦ possibly not a problem if the customer ordered scale models for a display or for kids to sit in, but maybe not such a good idea if the customer wants to fly rescue missions. Indeed, when dealing with customers, it’s often a good idea not to get fixated on exactly what the customer says they want: what the customer asks for is often their best guess as to what they want, not something that will actually solve their problem.
Soak Systems, a software vendor, landed a huge contract with a certain major telecommunications company. The telecom provided Soak with a very detailed set of specifications for what they wanted. The company set a team of engineers to work on the contract. Although several people wondered aloud about some of the elements in the spec, no one bothered to go and ask anyone at the telecom. After all, the reasoning went, if they didn’t explicitly say they wanted something, clearly they must not want it. No doubt it would all make sense to the customer.
After all, helicopters don’t really need to fly.
When Soak delivered the product, it was, shall we say, missing the engine.
Confronted with this, everyone at Soak, from the lowest engineer to the VP of engineering to the CEO all responded by saying, “But we gave you what you asked for. And just look at how elegant and efficient our solution is!”
Replied the telecom, “You didn’t solve the problem.”
“But you didn’t say it had to have an engine! And it is what you asked for, so stop complaining.”
Fundamentally, when a customer has a problem, they can really only imagine the solutions they wish you could provide. If you don’t know how to ask them what their problems are and then help them see how your solutions can benefit them you are likely to deliver a helicopter without an engine.
Even worse, most of the time what the customer is actually complaining about is not the problem at all: they are complaining about the symptoms of the problem. They might think that they are solving the problem, but really all they’re doing is treating symptoms. The software the Soak designed did, in fact, address some of the more irritating manifestations of the problem, carefully replacing those manifestations with a different set of irritating manifestations. They no more solved the actual problem than painting a helicopter green, making it soundproof, and providing a really good stereo system will enable it to fly. Only providing an engine will do that.
In other words, it doesn’t matter how elegant and efficient your solution is if it doesn’t work!
Thus, it’s critical to take the time to find out what’s behind what your customer is looking for. What do they really want and why do they want it?
Realizing that the rules don’t specify that the helicopter needs to fly may work fine in a contest, but it doesn’t win you friends in the real world.
The contest rules were subsequently corrected. The cool thing about design competitions is that each year you get a do-over. Soak, on the other hand, did not.
What are you doing to make sure you know how to speak to your customers?
Stephen Balzac is an expert on leadership and organizational development. A consultant, author, and professional speaker, he is president of 7 Steps Ahead, an organizational development firm focused on helping businesses get unstuck. Steve is the author of “The 36-Hour Course in Organizational Development,” published by McGraw-Hill, and a contributing author to volume one of “Ethics and Game Design: Teaching Values Through Play.” For Balzac’s monthly newsletter, visit www.7stepsahead.com, or contact [email protected].
