I am excited!! I am about to hit the road and go talk to a bunch of customers.
As I typed the above sentence, I just remembered of a funny episode. When I was at BEA one of the product managers in the team said something along the same lines “I am going to go talk to a bunch of customers in preparation of planning our next release”. Adam (Bosworth that is) was in the room, looked at him and went “Talking to customers is fine, but the question is: are you going to listen to them?”
This is indeed the point: listening to customers.
Listening, not that Simple
But how do you listen to customers? When? How often? Which customers?
There is no simple answer. It depends on the product (Saas or Enterprise, Application or infrastructure…), the stage of a product (product idea, beta version, 1.0 version, mature product, disruptive technology, …)
Web-based applications (well, most of the ones worth using at least) have spoiled us end-users over the last few years by listening to us and evolving their services quickly to meet or sometimes exceed our expectations. The ones who didn’t, are not here with us anymore (check out this great talk about this very topic from Adam).
SaaS type of applications have an advantage over traditional enterprise applications and infrastructure products. Once an SaaS application provider makes a bet and launches the app, they can closely measure what customers use, what they like and dislike and they constantly improve the application or service. They can deploy a new version quickly, sometime weekly. A great model.
If a company has a reasonably low cost way to get a prototype out there, it it a great way to get started, measure what customers do with it and improve the product. But there is always the risk of making a bad first impression and damage the company brand. Focus groups can help but again it is not that simple. I heard (but I am not sure if it is true) that when Apple did focus group around the iPhone concept, the feedback was not very good. If true, this is a case where the customers didn’t know what they wanted until they saw it. This is what startups and people working on brand new products try to do. Go figure out what customers need but they don’t know it is possible or don’t know it is coming. The good ones listen carefully, discover the pain, understand technology trends (sometimes they create them) and intimately know the type of talent they have in the R&D lab. They project the pain one year out, make a bet and go. They walk a fine line between innovation, intuition and… yes, arrogance. We all have our share of failed arrogant bets…
Enterprise Applications and Infrastructure
Enterprise applications and infrastructure products on the other end have a harder time learning from customers and improving rapidly (emphasis on rapidly). This is mostly due to the development-sell-deploy-upgrade cycle that is typical of enterprise software. It may take years from when a product is first conceived to when a customer deploys it in the real world. Even worst, even when enterprise software companies do a good job listening to their customers and make improvements to their products, it takes time for customers to uptake new releases. Software development companies can make the upgrade process easier and minimize disruption by keeping the software backward compatible, but still…
In my experience enterprise customers want predictability, support and compatibility.
- Predictability: customers want to know that they can rely on a new release being available at given interval of time. 12-18 months is typically fine for enterprise software.
- Support: they need to have their problem fixed on the release they are on. The DO NOT want features (even small ones) in service packs.
- Compatibility: 100% compatibility for patches and service packs is a must. 100% backward compatibility on minor releases is also a must. 100% backward compatibility for major releases is ideal but costly.
Unfortunately, it is hard for disruptive technologies and products to satisfy the above requirements (isn’t that why they are called disruptive??).
Even when evolving mature products the requirements above are costly to meet. But mind you, history is full of product failures due to taking shortcuts on these important issues.
These considerations are relevant to the topic at hand, because one has to take into account the stage a product is in when listening to customer requirements. If you are building a brand new product you can be more aggressive about number and size of features, disruption (as long as you let the customer know in advance that things are bound to change). You can make bets and do things the customer may not have asked for. They may not know what’s possible with your engineering talent. After shipping, go find the early adopters and listen to them. Go find people who did not buy the product. Listen them them too. Carefully.
Quality is a feature. A big one. Taking shortcuts on quality is the sub-prime mortgage of software development… and the bailouts are costly. Very costly. Foreclosure a definite possibility.
Choose Your Customers, Choose When to Listen
Is it always a good idea to listen to your customers?
Mostly. There are exceptions.
For example, after you have gather enough requirements and you think you know what you want to build, it is ok to stay inbound focused for a while, develop the product util you reach some sort of end-to-end milestone. Then you can hit the road again and go show it to customers and get early feedback. Talking to customers in the middle of a developent cycle maybe defocussing unless you are doing scrum, in which case you are supposed to be able to show a fully running product every 2-3 weeks.
Another example is when you keep going back to the same customers or to the same group of people within a customer IT organization. For example, say you built a development platform and you keep going back to developers for more requirements. You may be just marginally improve the product by adding more developer-oriented features while you are missing out on a great market opportunity by not adding management features targeted at the operational staff. Go find who else uses your product maybe in different stages of the product life-cycle at the customer site. Listen to them too.
Also, if you are trying to disrupt a given market and you listen to the people who have been traditionally involved with it (analysts, system integrators and customers) they may stir you into build yesterday’s product. Not tomorrow’s.
Eat the Dog Food
There is a great way to shortcut the time it takes from building a product and getting customer feedback. Use the product yourself internally. Some companies do this very well. Amongst the companies I worked at, Oracle and VMware do it very well. BEA did it to a lesser extent. Listen to your internal customers with the understanding that they may to be an exact representation of your actual customers (e.g. you have a number of hard core system developers in your staff, while your customers are higher level application developers, your internal customer have better access to your team resources, your customer don’t).
If you are not using the product yourself, why not????? You better have a great answer for this question, or go back and DO use your product!
Support and professional Service
The support and professional service organizations are great proxy for customers. Listening to support people will give you a great idea about trends, quality, release adoption, customer satisfaction as well as great requirements for better product supportability.
Your colleagues in the professional service are the ones to know how customers use the product in the real world. they keep it real. They keep you honest.
Sales and System Engineers
If you have a direct sales force, account managers and systems engineers are your customers too. They feel the pain when the product does not sell and have often have great insight into why it is not selling. Listen to them but not too closely. Sometimes they require you to disrupt product plans to chase short term quarterly revenue. It is not always a good idea to do so.
Ah! What a great topic. I just realized that I still have to explain why I am going to talk to… sorry, I mean listen to 😉 some VMware customers. It is actually not about gathering product requirements (although it is inevitable that I will stumble on some). It is for a different and very interesting purpose.