The Business Sensei

It Was Supposed to Fly?

“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. There was 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?

Future Retrospective

Once upon a time there was a staircase. Although it wound its way up from floor to floor in the manner traditionally associated with staircases, this was no ordinary staircase. Although it stood in a courthouse in Franklin, Ohio, in a fashion much like other staircases, yet it was not like the other staircases. With most staircases, those who look down see stairs beneath their feet. With this staircase, however, those who looked down saw the floor below and those people walking up the stairs. They saw those who stood at the bottom of the staircase, for this staircase, you see, was made of clear glass. While we have no information as to whether those climbing the staircase felt a sense of vertigo when they looked down, we do have definitive information about what they said when they looked down: “Hey, those people at the bottom of the stairs are staring up my dress.”

Although the news report was slightly vague on this point, we may safely assume that this comment was made only by those who were, in fact, wearing a dress.

But yes, it seems that people on the staircase made an observation that had eluded the architects who designed the staircase: that if you can look down through the glass, you can look up through it as well.

When questioned on this point, the architects responded by saying that they had naturally assumed that no one would be so inappropriate as to stand at the bottom of a glass staircase in a courthouse and look up women’s dresses.

When this insightful observation was relayed to the judge, he replied that, “If people always exercised good judgment and decorum, we wouldn’t need this building.”

The architects had carefully considered their building material. They had thought about how to make the glass durable and resilient. They had considered the problems involved in building a glass staircase in such a way that it would continue to look good even after having hundreds of people walking up and down it each day. They had, in fact, solved each one of these problems.

What they had not considered was how the customer, to wit, the people in the courthouse, would actually use the product. They were so fixated on the concept that a staircase is for walking on, not staring through, that they failed to consider the ramifications of their architectural decisions. To be fair, architects are hardly unique in making this type of mistake. It can be very easy to let your assumptions about how something should work or how it will be used to blind you to how it will actually work or be used. Consider the example of the business school competition to design a helicopter. The contest was judged on a number of factors, including the weight of the finished product. The winner was the helicopter without an engine. Apparently, no one had included “able to fly” in the criteria for success. The assumption that, of course, a helicopter should fly was so taken for granted that no one thought to see if it was included in the rules.

On the bright side, it had considerably less severe consequences than the situation involving the helicopter that flipped upside down while in flight. Or the data analysis software package that looked like it had crashed the computer, causing users to reboot shortly before the calculations were complete. Or the organizational improvements that led to a massive talent exodus.

In each situation, the people designing the end result honestly believed they were giving the customers, including the employees in the final case, what the customers had requested and that belief prevented them from considering any other possibilities.

“We asked!” the designers protested. “That’s what they said they wanted.”

Were the customers really asking for a helicopter that flipped upside down or an expensive glass staircase that had to be subsequently covered? Of course not. But somehow, that’s what the designers heard.

The problem was that they asked the wrong questions, further leading them into their one, narrow, view of the result. Thus, no one ever stopped to imagine how the end product, be it staircase, contest rules, helicopter, software, or organizational procedures would actually be used.

In each situation, rather than seeking information, the people asking the questions sought validation. They already had an idea in their heads, and any inquiries they made were aimed at confirming that idea, not testing it.

When you say, “This is what you wanted, right?” or “What do you think of this approach?” odds are you aren’t requesting information; you are requesting validation. Indeed, even if you are seriously trying to get information, such questions usually get you validation instead. This is because the client assumes that you, as the expert, know what you’re talking about.

So how do you ask for information? One answer is to change the time frame. Instead of asking them to imagine the future, pretend it’s the future and imagine the past: “If we went with this approach, and six months from now you weren’t happy, what would have gone wrong? If you were happy, what would have gone right?”

This small change causes people to actually imagine using the product or living with the new procedures. Now, instead of validation, you’ll get information. That information may shake up your carefully constructed vision of the future, but that’s fine. Better now than after the sightseers congregate at the bottom of that glass staircase. A future retrospective also forces you to more honest with yourself and address the issues in front of you.

What challenges are you facing? If, six months from now, you had successfully addressed your most persistent problems, what would you have done to make that happen?