Products, Customers, and Value

Do I need to keep saying this is a first draft?

From here out I’ll refer to “product” in the generic sense; something the customer uses, whether it’s a product or a service. But while I simplify that, I need to expand on who exactly this “customer” is and what value they get from the product.

Customers (Plural)

Rarely do you sell a product directly to the person that will use it. Let’s say your company makes cellular phones. When you think of a “cell phone customer,” you think of people on the street, you and me, chatting away on their phone. But who’s actually buying the phones from your company? Usually it’s the cellular carrier. The carrier, in turn, sells the phones to end users.

So who’s your customer, the end user or the carrier? The answer is both. If you don’t make a cool phone that the end user (you and me) can do cool stuff with, there won’t be much market demand for the phone. But if you don’t make the phone attractive to the carrier, they won’t buy it, and at that point it doesn’t really matter how cool the phone is—you have no sales channel to get it to end users.

This leads to a heap of trouble when the different customers have competing interests. It all comes down to what value they’re looking to get out of the product.


Programmers tend to have a myopic view of value: is the product cool? That’s one way a product can have value, but there’s lots of others as well:

  • Distribution: Taking Amazon as an example—and not counting their technology side yet—they sell stuff on the web and ship it to you. A lot of people decided the convenience of buying on the web outweighed the ability to leaf through the book in the store, and a viable business was born. Amazon wasn’t selling better books, they revamped the distribution.

  • Sales Model: Now let’s count Amazon’s technology arm, Amazon Web Services. They let you rent virtual private servers on demand, you pay for the CPU/hour. Because the cost scales directly with your demand—hence their term Elastic Compute Cloud—customers can skip building data centers to handle occasional peak demand, instead they can build to average demand and rent Amazon’s servers for peaks. Amazon didn’t invent virtual servers, but their sales model is changing the face of enterprise computing.

  • Service: When Red Hat decided to sell a distribution of Linux, people thought they were crazy. Sell something that’s free? But what is Red Hat really selling? They’re selling service—assurance that they’ll be there if you have a problem. The people running big data centers can’t afford to support everything themselves, so they’ll buy service contracts and, in industry parlance, have “a throat to choke” when something fails.

  • Industrial Design: Programmers may mock industrial design as frivolity, but let’s face it, people want the product to look and feel right. Apple is an obvious leader in design, but design can have a practical side as well. Consider the XO laptop from One Laptop Per Child. Its iconic “ears” are not just frills; they are wifi antennas, they latch the screen shut, and they provide a dust seal for several connectors. Far from frills, those frivolous-looking ears are essential to a laptop operating in dusty environments.

  • Technology: Here’s a value programmers can appreciate. Products do sometimes win on technology. As of this writing, Sun is having tremendous success with their “Open Storage” products because of its superior filesystem, ZFS. ZFS provides a number of features like snapshots, data integrity checking, and other data protection options—all with extremely simple ease of use. ZFS won’t take over the world tomorrow, but it has enabled a product line whole revenue is growing rapidly year over year.

Adding It All Together

“Who’s your daddy?” isn’t quite as simple as it seemed, huh? But the better you understand the customer(s) in the chain and what they value in your product, the better decisions you can make day-to-day.

Let’s say you’ve got the menial task of adding logging to a software product, just generating lines in a file to say what the system is doing. Could you add something that detected abnormal logs and flagged those for the support team? A simple change could make it far easier to detect and diagnose problems—now your logging mechanism adds value to the product because customers can get problems resolved faster.

Frankly, most programmers don’t think about the product with a holistic view. Here’s an opportunity for you to shine.