In product development, we often use the words, “user” and “customer” interchangeably. But they mean different things depending on the type of product you create. I wonder if it’s time to stop talking about “customers” altogether. It's time to clarify who we want to satisfy, so we can make better product decisions.
Here are my definitions:
- Buyers have the money to make a purchase decision for a product. Because they have the money, they might ask you for features.
- Users use the product. When the User is also the Buyer, as in a mass-market product, they might ask you for features. (Not all mass-market Buyers are also users. Think of a children's game, where the child is the User, but an adult is the Buyer.
- Customers might be Buyers if they integrate your product into theirs. But these Customers might not be Users, unless they also use the product.
Decades ago, I worked for a company that created and sold voicemail products to telecommunications companies. The telco product/program managers were our Customers, because they bought our products to integrate into their products and services. But my company and I had little insight into their Users or access to their Users.
When We Might Have Access to Users
As a program manager, I worked closely with their program manager, to integrate our product into their product. I called that program manager my Customer. While we didn't collaborate on the product design, we did collaborate on when to ship which features. (We did not overcommit features to specific dates.) That program manager used our dates to trigger his program's work.
The telco's Customers were not our Customers—those people were end users. As a result, we created features the Buyers and the program managers (my Customer) wanted. We never talked to end Users directly and never built the product for them. See the Decision Implications for Types of Customer in the image above.
I only had to satisfy my Customer, the program manager, not my Customer's Users. That led to some interesting mismatches between what my Customer wanted and what their Users wanted.
If you create a mass-market product, you can choose when and as much access as you want. As the producer, you decide which systems you will create and use for Buyer or User feedback.
It's a little different when you sell to a Buyer who is not your User. (Consultants do this all the time when they sell workshops. Often, senior management is the Buyer. But senior management is rarely the User. And sometimes, the Buyer delegates the content of the workshop to the Customer.)
Enterprise product developers often have “preferred” or ideal Buyers. Those developers seek the opinion of the ideal Buyers. (In my experience, those Buyers tend to either be or have close relationships with Users.)
But the Custom- or Integrated Product-based product development organizations may not have any access to the Users. There are too many layers, such as Buyers and what I called Customers above, to learn what the Users want.
Clarify What User or Customer Means to You
You might not like my ideas about the different words. Do consider these ideas:
- Who buys your product?
- Who uses your product?
- Are there middlepeople who separate the Buyers from the Users?
- Who do you need to satisfy and when?
As you consider these ideas, you can decide how to test your product decisions and when. That's how to satisfy the Buyer, the Customer, and maybe the Users.