Feedonomics

The best part about demoing software is watching people’s eyes when you describe different features of a product. Their eyes are much more important than what they say, because they don’t apply the same level of conscious filters that they use in verbal reactions. Even professional investors who pride themselves on their poker faces generally fail to mask the reactions that appear in their eyes. If you hit a nerve or describe something someone wishes they could use, you can see a glint or flash of recognition. This may be where the metaphor of a lightbulb turning on comes from. The trick is to also notice where there is no reaction, and then try to work around that idea until you express it in a way that does trigger a flash. Another useful eye behavior is recognizing when you have caused people to think about something that they don’t quite understand. Their eyes clear from an unfocused “nobody’s home” to a more focused look of concentration, but there is still no flash.

You could use your observations of these behaviors to construct a demo that leads people from one flash moment to another, but that can also be the sign of an overwhelming demo. If they are flooded with one positive reaction after another, they may not remember everything they saw. The way you lead people to these “Aha” moments depends on their relationship to the product. If they are already a user and you want to show them future enhancements, then giving them a demo that is one highlight after another is fine. They don’t remember everything, but know they will be happy when they get the new version. For someone who is new to the product I’d much rather lead with the features I know they will find confusing, and then lead them up to a flash of understanding. They come away proud of themselves for “getting it,” and want to learn more to reinforce that positive feeling.

I clearly saw all of these behaviors when I was demoing GrazrScript last week at Web 2.0, and they taught me a lot about different aspects of the language, and which will lead to stronger adoption. When I described the procedural enhancements we plan, such as an IF command, there were clear “nobody’s home” reactions. I learned that if I quickly followed that up with an example, such as “this will let the developer select a group of feeds to display based on a user’s form entry,” this would usually lead to a moment of concentration, but still no flash. This tells me that I’d probably be better off waiting until I can show this feature in action, rather than trying to describe it. On the other hand, talking about our plans for feed manipulation commands, such as SORT, SELECT, LAST N, FIRST N, and MERGE, always got an immediate flash. This set of features would also trigger more obvious verbal clues, such as suggestions for things they could immediately do with them.

You could say that it isn’t necessary to try to read people’s eyes, since they’ll just tell you what they like and don’t like. That’s true, but they’ll never tell you what they don’t understand. It’s only by probing for those blank moments, and then working around them until you can find the path that brings understanding, that can you learn the “conceptual map” of ideas they bring to the product.

Finally, as if this entire post didn’t seem manipulative enough, what I really love doing is demoing to a competitor. I don’t think I have the social skills to talk somebody into telling me what they are working on, but I can give them a demo and watch for when the wheels start to turn behind their eyes. It is easy to see the “Gee, we never thought of doing it that way” moment. I know I’ve really hit paydirt when they still have that look after the demo is over.