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.
Live near Brisbane, Australia. Software developer currently focused on iOS and Android. Avid Google Local Guide
Red Circle Blog 
Simple but insightful.
Thanks for sharing!
Jeff, this is a great write-up & summary. I think it helps justify the thinking that we should do more to release beta versions of various Citrix projects and observe the feedback. This certainly is the trend of the industry, however at Citrix we need to overcome the objections such as support expectations and release commitments. While these may be reasonable objections, we lose too much time and opportunity by not taking advantage of watching how a customer would use a new product/feature.
Nice info Jeff,
It illuminates the classic 80/20 rule around what features the users use in Office.
Dave
Agreed!
The more this idea is thought about, the more it seems to be true.
Customers do not always know what they want but they do know what they want when they see makes sense.
Many ideas/inventions only find a market once a initial group has tried it and realized that it was what they were looking for without knowing it.
It’s the classic “Why didn’t I think of that?”.
Michael’s point about prototyping is that it is only through many different iterations and feedback (watching) will you get close to your goal of providing a successful project.
The cleverness is that you have to realize that you don’t know the answer when you start. It is also clever to realize that ideas by themselves are worthless.
Many companies put more value in ideas and innovation than they do observing how customers use their existing products. In fact, many approaches in prototyping are often neglected or completely ignored.
Sometimes a prize idea will gain full funding but flop dreadfully when it hits the market. It is like the company ego is strong enough to fund a loser and even sometimes fund trying to patch the loser instead of realizing that the funding would be better spent on other programs to make sure flops like this are much lesser in scale and something would actually be learned from them.
Jeff,
I have to FIGHT to observe end users. IT folks often stay in their cubicles and do not venture out into the real world.
They look at me like I am a nut when I say “I just want to hang out and watch users work for a couple hours.” However I ALWAYS give them insight into how folks are REALLY using their systems.
We are geeks and are much more comfortable being alone with our machines. We make a difference only when we venture into the world our customers are living in.
Awesome post. Thanks.