Recently I attended a very compelling lecture by Michael Schrage in Sydney. Michael has a very diverse experience within the world of computing but perhaps the most interesting (for me) is his observations about innovation.
He said something very important for me that has helped to clear up something that has baffled me for some time. It is the mantra of most product development cycles that you must ask the customer what they want. This is supposed to happen at the beginning of a product cycle and is usually incorporated into the requirements which lead to all the other stages.
What Michael said that changed my thinking was that asking the customers is not always the best thing to do.
This would be considered heresy in most corporations. It would probably even upset a few customers out there.
My interpretation of what Michael said is that it is okay to ask about desired features but the real understanding comes from observing what features a customer used.
Michael gave an example of how Microsoft spends millions of dollars collecting information about what new features should be included in Office. In this case, customers did ask for new features. The surprising result is that 80% of these new feature requests are already incorporated into Office.
Most people would assume that the people had not just read the manual or taken the time to explore the software. It seems to go beyond both of those assumptions. If a user is not using something, the user is either not really interested in that feature or thinks it is not worth finding.
This makes sense. Don’t ask the customer to create items out of thin air. It is not like Boeing is going to ask passengers what features they would prefer (I’m sure they do but it must be a fairly limited scale). Customers might come back with requests to make the flight times much faster or reduce the amount of turbulence or increase the seating area per passenger. The point is that the customer is likely to ask for the moon but not be willing to pay a fortune to get it.
In software is it easy to make mistakes with customer demands. Some requests are fairly trivial but can actually lead to confusion to a great number of existing customers. It becomes a bit of a balancing act.
Michael’s view is that it is far better to produce prototypes and find a way to observe how these prototypes are used. This leads to insight into what features customers really want.
His view is correct based on my experience. I just didn’t see it as clearly as him. Now that he has illuminated the issue, it has become much more transparent.
The old saying goes something like “Do as I do, not as I say”. This concept explains why requested features do not always succeed.
I have one more story to share based on a previous post (the one just before this one).
When I was struggling with English 101 at the University of Arizona, I learned a valuable lesson that was not taught in class. It was okay to ask the Teaching Assistant what was wrong with a paper revision. It was always important to take note of the feedback, especially if it was painful or confusing. The next step for revision needed to include this feedback in order to increase the chances for success. However, stopping there was a mistake.
A TA (Teaching Assistant) would only state what would match their expectations. Once I heard a TA explain that if you only did what a TA said, you could only be guaranteed an average rating (C grade). This was pivotal.
In order to get an above average grade, a student would need to surpass the expectation of the TA and this could only be done by finding fault and improvement for the sake of revision. In other words, you needed to surprise the TA with the better than expected results that you came up on your own.
This is the bigger secret of software development as well. You cannot just do what the customer asks for. You need to surpass this expectation as if you know the customer better than themselves. You need to know what your customer does and find ways to surprise them (pleasantly of course).
This is when your customers will become your fans. This is when momentum will move forward as the evolutionary cycle continues with the progress of new ideas.
It is key to allow prototype failures to occur. Without failure you will never learn what will lead eventually to success.
