Steven Haines, author of the definitive guide on product management, The Product Manager’s Desk Reference, defines a product as “anything that is sold, tangible or intangible.” This broad definition covers anything from a bar of soap, a tangible product used to wash something, to a home security service, and intangible product that offers the peace of mind that your family and property are well-protected. This works well for commercial products sold to consumers or in a B2B market. Oddly enough, this definition does not include much of the custom software that is written to support important internal operations of many medium to large businesses. We will come back to this in a moment…
What makes a product special is its ability to repeatedly delivers benefits to the customer without requiring the organization to build something new and\or unique each time. This is an important distinction for a product. For example, Monopoly is a board game product which offers me the opportunity to spend time with family and friends and have positive interactions with them, i.e. fun. As long as I own that product, I have the potential to have fun with people I care about.
In contrast, a service uses human labor as the primary mechanism of delivering value to the customers and\or end users. If you take away the human element in a service, the customer receives no benefit. For example, LegacyBox, a professional digitizing service, relies on the labor of over two hundred people to convert your analog home movies and photos into a digital format and returns the originals along with the new digital assets. If you take away the human element at LegacyBox, the customer receives zero benefit from the enterprise.
So, if product = no human intervention and service = human intervention, where does custom software developed to support internal business operations reside? It is clearly not sold, so that does not make it a product according to Haines definition. However, it is clearly not a service because it does not require human intervention to deliver value. Once compiled and installed, custom software repeatedly delivers benefits.
For me, I would call custom software a system or an application (what word you use depends on the scope of the work). Because it is not sold, the people who use it are not customers, but users. For me this is important because if the user does not have the choice to use the system, or the opportunity to select from competing alternatives, they are not a customer. These distinctions could be a bit esoteric to some but they are important when we think about how to collect information to better understand the jobs, pains and gains of potentials users of a system or custom application. In any event, that is where I landed on this topic today.