Suppose your family is in the market for a new house. Your plan is to interview three builders and then choose one to build your new home. You meet with Acme Builders first. The salesperson, Ann, asks some questions about what you have in mind and you describe your ideas. Ann tells you that Acme’s Bainbridge model would be perfect for you. You reply, “Sound good. Let’s take a look.”
Ann says, “Here is the description of the Bainbridge model complete with all available upgrades and options” while handing you a two-foot tall stack of printed materials. You leave—Acme, Ann and the printed materials.
Next you meet Kim at Kelly & Sons. After learning about your house ideas, Kim says that the
“We don’t know how to read technical schematics and I don’t see why we should learn how!” you say to yourself as you walk out. “That salesperson wasn’t listening to us,” your spouse says in the car. “We don’t want elevators.”
Then you meet with Harry at Homes ‘R Us. Harry asks what you like in a home. He listens and says, “The Upton model sounds like it might work for you. Would you like to go through one?”
“Finally,” you say, “something we can understand!” as you are walking through the
Decision Time
Which of these three builders do you think has earned the right to build your new home? Right, Homes ‘R Us. Looking at the discussions with the three builders, probably without even being aware of it, your family interacted with them via several mediums. All three builders presented the house they believed would meet the needs of your family, albeit in quite different ways.
What does all this have to do with software, you ask? Well, just as you wouldn’t buy a new home based on written descriptions or technical diagrams why would you expect business stakeholders to buy applications that way? Especially since there is a huge difference in complexity between static houses and dynamic applications that change behavior based on user actions, data values, rules and current state.
Simply stated, we are using the wrong medium to communicate. We need to give stakeholders an experience of the proposed application that they can validate, i.e., place them inside the application so they can directly experience how the application will meet their needs—before coding starts. (And maybe along the way even help stakeholders discover something dramatic—an innovation—when it costs the least to implement it.)
Getting Buy In
Each builder presented a specific house model, the goods, as it were. You do in fact want the goods. You planned these three interactions because you do want a new house. However, wanting goods and being presented goods was not sufficient with at least two of the builders. You needed something more to make an informed decision.
Sophisticated providers of goods realize that people do not usually become customers just because they want the goods they have. Customers buy because they want more than just the goods. They want experiences. Frequently, potential customers are not consciously aware of the experiences they want. They cannot articulate the experience that will sway them to buy the goods they want from a provider.
The first two builders only presented the goods. All they did was describe the goods they wanted to provide. Homes ‘R Us provided an experience—a full-sized
In any case, as far as you were concerned Homes ‘R Us was by far the best presentation. You experienced yourselves in an