Customer Development must be tailored to what type of business you are and where you are as a business. All businesses, not just Internet-based ones, can benefit from customer development principles, but the ease/difficulty varies quite a bit depending on product, business model, and your knowledge of the market, etc.
Clearly an Internet based product has advantages both in terms of customer development and fast-iteration product development, over software applications. I’ll go out on a limb here and rank difficulty based on product type this way:
b2c internet -> b2b internet -> b2c software -> b2b software -> hardware
No great revelation here. I’m going out another limb and say the significance of customer development increases as you go from left to right, while the significance of fast-iteration product development runs from right to left. This is not to diminish applying both principles as much as possible in all cases, but that the nature of the product determines which will predominate.
Products toward the left are less expensive to develop and deploy and customer learning is more inherent in their nature. The cost/failure is lower. If you haven’t practiced customer development principles, e.g., interviewing customers about a particular issue’s pain level, you will learn soon enough whether your product solves a real problem. Practicing Eric Ries’ lean startup principles can serve in lieu of practicing some of the customer development steps. Further, many assumptions are actually facts. IMVU‘s customers are online. They can be reached online, they use web sites to learn about products, they reference online users who are similar to themselves, and they buy online. You don’t have to interview your online customers to determine those basic facts as you must for other product types.
Products on the right may require large investments to produce. The cost/failure is high, so knowing what customers will buy prior to development is more important. You also must determine all the factors that influence how customers will buy.
Customer development practices also vary by company stage and are related directly to the business objective of that particular stage.
1. Pre-funded, Pre-product
Your objective at this stage is to determine whether or not to go into business.
Bootstrapped companies, whether seeking funds or not, should practice customer development in order to validate basic assumptions, including most importantly, the vision. This is not an exercise is making the case, i.e., finding analysts who say the market is worth $4B (though that kind of market research is good), but rather more fundamental — will anyone buy?
Tools include market research, customer surveys, and customer interviews.
The number of people you survey and interview is impossible to predict, but should be based on your market segment size. Obviously if you hope to sell to thousands you need to interview fewer than if your goal is to sell to millions. It’s important that the people you interview represent the early adopters of your assumed market segment. (It may take a whole lot of interviews merely to gauge who your early adopters really are.) One rule of thumb is you interview a minimum subset and then continue until the distribution of the answers doesn’t change. I’m sure statistical analysis can better define this.
Say market research says size is x. Early adopters is y, where y = some % of, assumed to be some part ( 2.1%?) — (3 standard deviations?) left of a normal distribution. The number of early adopters you need to interview is some % of y that represents a valid sample size. (Maybe someone can help me out here?)
Vision is tough to validate. Investors want to change your vision based on their experience. Most customers view your vision based on what they need today, i.e. they may request a feature based on what’s available today that provides an incremental benefit vs. a new product that has a much larger impact later.
2. Pre-funded, Product underway
Your objective at this stage is to determine whether you’re building the right product.
If you haven’t already, you should validate the vision as discussed in (1). I will leave to Eric Ries the specific steps you can take to validate product using lean start-up principles. Steve Blank’s SuperMac stories provide specific customer development practices for a hardware company.
If you are planning on seeking investment capital in this day and age, you must be able to demonstrate your business model. Demonstrating business model includes generating revenue from customers that exceed the cost of their acquisition. Sean Ellis and Andrew Chen have covered this topic well.
Have you defined Minimum Viable Product? How did you come to this definition, i.e., did you include customers in the discussions?
Have you implemented iterative development processes?
Have you planned for measuring your customer’s response to your product and their buying process?
Here you can see that the further you get away from the Internet, the closer you need to be to do the customer. Whereas split testing can provide you real-time feedback on a new feature exposed on the Web, you will likely need to provide a direct means for your customers to run non-production software, in order to test a set of features for an enterprise software product. This implies a long-term, direct relationship with a set of customers who have bought into what you’re trying to accomplish. This isn’t meant to imply that agile, iterative development processes aren’t the right way to go, but rather how the interaction occurs between Engineering and Customer is different. And whereas I believe product management is a good vehicle for managing the interaction, this isn’t to say that the process is driven by traditional feature requirements gathering.
Really the point is that you have a whole set of assumptions about the life-cycle of your customer, from first interaction, through purchase, and around again to upgrades, other products, etc. Your product iteration is inside that life-cycle. You must learn, through customer development, everything about that life-cycle, including where product learning is and how it fits together with the other parts of the cycle.
I will tackle later stages in a follow-up post. As always, comments welcome.