The Power of Reference Customers
Our job in the product organization is to create products that can sustain a business. Make no mistake about it: everything depends on strong products.
Without these strong products, our marketing programs require customer acquisition costs that are too high; our sales organization is forced to get creative which drives up cost of sales, lengthens the sales cycle, and puts downward pressure on price; and our customer service organization is forced to take it on the chin every day with frustrated customers.
The downward spiral continues because the sales organization loses a lot of deals when they try to compete with a weak product. So what do they do? They start yelling at you about all the missing features you don't have and the competitor they lost to does. Which typically just makes the bad situation even worse. And then you start complaining about working at a sales-driven company.
Many of you may be thinking I've just described your company. Sadly I find this to be the state of affairs in far too many companies.
Everything I write about, in one way or another, is intended to prevent or correct this situation. But in this article, I wanted to talk about what I consider the single most powerful tool to ensure and prove we have a strong, viable product, and prevent the situation I've just described.
This is not a new technique, but you may recognize it as the foundation of Customer Discovery and Customer Development.
I'm talking about the power of a happy, reference customer.
First, let's be clear what it means to be a reference customer. This is a real customer (not friends or family), that is running your product in production (not a trial), that has paid real money for the product (it wasn't given away to entice them to use), and most importantly, they are willing to tell others how much they love your product (voluntarily and sincerely).
There are three main contexts when it comes to reference customers: products for businesses, consumers, and developers (building applications using your product's API's). I'll talk about the business context first and then at the end talk about the key differences for consumers and developers).
For each significant target market, we strive to develop at least several reference customers. Less than that and we are worried that what we have may be a special (a special is a product that is custom to just one or a small number of companies). It is not just us that worries about this. Smart prospective customers worry about this as well. The first thing an early majority customer wants to see is that there are other customers like them that are successful with your product.
For products and services aimed at businesses, I argue for six reference customers. This is not meant to be statistically significant, but it is meant to instill confidence.
One of my favorite strategies for pursuing a product vision is to tackle one market after another. As an example, one popular product strategy is to focus on a set of reference customers for each of your target vertical markets (e.g. first develop six for the financial services industry, then six for the manufacturing industry, etc.). Another is to expand geographically in this manner (e.g. first develop six references for the US, then six for Germany, then six for Brazil, etc.).
In fact, I do my best to persuade teams to not actually launch a product in the marketplace until after they have those six referenceable customers. We don't want to turn on the sales or marketing machine until we have evidence that we can help them be successful, and the reference customers are our best evidence.
Ask any sales person the single best tool you can provide him to help him do his job, and he'll say happy referenceable customers.
If you find that you're constantly frustrated by having to react to sales and the latest "big deal" they've managed to bring in, this is how you turn the situation around. Without reference customers, it is very hard for the sales team to know where the real product / market fit is. And remember they have a quota and are paid by commission. So without good examples, they will sell however and whatever they can. Without reference customers, this situation is not their fault, it is your fault.
Instead, put your focus on developing this set of reference customers for your target market, and then make it easy for sales to go after those specific types of customers. While they're doing that, we can move on to the next type of customer.
Your product marketing people can help turn your reference customer into some great sales tools and collateral, but your job is to develop those actual reference customers.
Since we're talking about sales, there is one thing they do that I think we should all start doing in our product organizations. Do you know how they often have a big bell outside the VP Sales office, and they love to ring it when a deal comes in? And of course at company all-hands meetings there's always lots of talk about these new customers. Well, I like the product organization to have a big bell too. Ring it each time you get another live, referenceable customer. I also like to have a way for the entire company to visualize and stay reminded about these reference customers, such as with photos or profiles on the wall. Whatever you do, celebrate these reference customers.
There's no question that it is important to get good at the many Product Discovery techniques we have to rapidly test MVP, and in fact that's where we spend most of our time. However, we always need to keep in mind the ultimate objective of Product Discovery and all the MVP experiments we run, which is to come up with a product that our target customers love.
We prove that to ourselves, to our sales force, and to prospective customers with reference customers.
For developer products the main difference is that we work with the development teams that will use our API's to get them successfully using our product. And the results are the reference applications rather than reference customers. We focus on the successful applications that are created with our API's.
For consumer products the same general concept applies, but rather than focusing on six businesses to work closely with (where we have access to several different users at each company), we instead focus on a somewhat larger number of consumers (on the order of 10-15) that we engage with to get them to the point that they are loving our product.