What is a Customer?

I am a great fan of Eric Reiss and the Lean Startup. Among his many important contributions to the lexicon is the term “vanity metric.” These are measurements that make your performance look great, and make you feel good, but don’t really reflect the unvarnished truth about your business. In my mobile location business, for example, counting all the individual mobile devices we see in a day produces heady numbers, but the reality gets more sobering when we count only those devices we see repeatedly and reliably. The numbers are considerably more modest, but it’s only those devices that contribute to the value of our company.

One of the vainest ways to deceive yourself about your business is to declare an entity a customer when, in fact, that is a fantasy. In high price-point enterprise businesses, I hear it all the time applied to certain-to-close prospects. As a product professional, you have to be careful not to get swept into that vortex. It forms when forces of “I just need this one unplanned feature to close the deal” meet “We are trending behind and have to make our number.” To comply with this urgent demand, you will often be put in a position where you have to sacrifice product capabilities you expect will have broad impact, or you might have to put your team on a brief forced march, in order to meet these expectations.

Armed with an understanding of what it means to be a customer may help you participate in a discussion to vet such requests, and you may even surprise your business colleagues with your depth of understanding about why many sure-fire prospects never produce meaningful revenue. Therefore, I am going to present you with acceptance criteria for Customer.

1. The entity being described as a customer must have an identified use case that applies your offer to their business, and they need to understand that use case at least as well as you do. You will often hear from the commercial side of your business that I pitched this prospect and they really thought our stuff is cool. Or I pitched that use case a different customer gave us. Or I explained our offer to them but there is something else they sure wish we could do (surely we can, right?).

If this “customer” can’t explain to you, as opposed to the other way around, how they are going to use your product, in very clear terms, then they won’t. It’s as simple as that. They are not for real until you stop telling them what they can do with your product, and they start telling you what they will do with it.

2. The customer can assign quantitative value for the use case to their business. In other words, there has to be an ROI for the use case, and the customer has to understand and believe it. Sometimes helping a customer understand the ROI takes selling skill, because you often understand the contribution your product and their use case can make to their business. But in the end, they have to own it simply because a deal doesn’t close if the buyer cannot justify the expense of engaging with you.

This ROI almost always takes one of two forms: revenue generation or cost avoidance. Those are the only two ways the benefits of your offer flows to their bottom line. Even if your product is a comedy improv troupe that provides entertainment at corporate gatherings, customers are not going to buy unless they believe that the effect will be revenue generation or cost avoidance (as in possibly improved productivity).

For an enterprise technology product, there better be a genuine number for the ROI, and it has to be related to the time it will take for the improved efficiency or incremental revenue to offset their cost. Key to this is understanding that their cost is not merely what they pay you. They have to do work on their end to get the benefit, which has to be factored into the ROI.

As an extreme case of this, a boss of mine once decided to start giving away a product that we had previously been selling because it wasn’t strategic to us, we were losing out to competitors anyway, and it could serve as a loss-leader for other, more competitive products we sold. The cost to us was a few thousand dollars for each unit we gave away, and my CEO believed that customers would be grateful for our financial sacrifice to provide them with a maybe slightly inferior product than our competitors. The theory was that we would frictionlessly acquire customers who had not yet committed to our competitors. The lesson we learned is simply stated as “Free from us does not mean free to them.” While you might think the ROI on a product that costs zero is infinite and the payback instantaneous, the reality is that every one of our prospects considered the training, adoption, and implementation costs associated with our product, and decided to pass. Oh! And the perception of most customers is that a product is worth no more than what you are asked to pay for it.

3. The customer has a process for adoption of your product that supports the use case and produces the ROI. Ideally, that process already exists; your product is supported by existing business processes. If not, they should at least have a plan to implement one.

I once sold security devices that detected and mitigated network intrusions. They worked, and the benefits to our “customers” were clear. Network downtime was incredibly costly, and the payback-ROI provided by these devices by preventing downtime could be as little as a few weeks. We thought it was a no-brainer.

Oops! Our device was installed in-line on the customer’s network (i.e, their network traffic passed through our device). What we had not considered was that, for some of them, their process for adoption of inline devices involved a burn-in/test period that could last longer than a year. They had no efficient process for adoption for our product, and thus we had an incredibly high barrier to closing a sale. Those who did not have an efficient process for adoption did not become customers.

4. The customer has demonstrated a willingness, and has identified a budget, to pay you, in cash, for your product. Why is this so difficult? Let’s understand that if the customer is not going to pay you for your product, then they are not a customer. Bartering an exchange of their products for yours doesn’t make them a customer. Exchanging your product for future (non-cash) benefits doesn’t make them a customer. Trading them for endorsements, referrals that aren’t guaranteed, or press doesn’t make them a customer. All these non-cash exchanges of value may be useful to your company, but the entity on the other side of the deal is not a customer. Very likely, these types of deals cannot scale to a sustainable business and you should not believe they will.

The desire to believe that these non-cash exchanges of value represent sales, and the other party is customer, is particularly tempting for young companies with newly introduced products. But measuring anything other than cash deals is a vanity metric. It may make you feel good, but (for example) exchanging your product for a press release does not help pay your salary.

In summary, it’s not a customer unless:

• The entity being described as a customer has an identified use case that applies your offer to their business, and they understand that use case at least as well as you do.
• The customer can assign quantitative value for the use case to their business.
• The customer has a process for adoption of your product that supports the use case and produces the ROI.
• The customer has demonstrated a willingness, and has identified a budget, to pay you, in cash, for your product.