What’s In A Name? “Product” Versus “Service”

“What’s in a name? That which we call a rose By any other name would smell as sweet.” — William Shakespeare, Romeo and Juliet, Act 2, Scene 2 One conversation I’ve found myself in over the past 20 years is the debate over IT portfolio terminology: Application Service Product Platform Why is this important?

Source: What’s In A Name? “Product” Versus “Service”

Because organizations use these terms to understand and manage IT investments and group them in ways that reflect their contribution to organizational objectives.

If I am relying on a list of “applications” or “products” to drive organizational processes (e.g., supporting digital systems, ensuring adequate risk management, or facilitating cost transfers between departments), that list becomes key master data for the organization.¹

Master data requires clear, broadly accepted definitions and ongoing management for quality. How, for example, can we support a given digital product if we don’t even agree that our organization relies on (and needs to manage) “digital products”? Master data entries must be specific and identifiable as well. Vague boundaries don’t cut it.

These are not new conversations. Mainframe systems decades ago developed lists of “application IDs,” which served as the naming basis for various technical components (e.g., batch jobs). This form of identification continued into the age of distributed systems. IT portfolio management used such master lists to determine total cost of ownership, and service management used them to categorize incidents and changes and route support activity.

About 20 years ago, industry practices in this area were strongly affected by ITIL^TM, which proposed that “IT service” should be the primary portfolio construct and that IT services were separate and distinct from applications. As both a practitioner and analyst throughout this time, my belief is that the ITIL view was more accepted in Europe and less accepted in the US, although some US companies did adopt it. Many (at least 50%) of my customers to this day come with inquiries on their “application portfolio” and report not having a “service portfolio” by that name.

This mixed state of affairs has continued for some time and is now further complicated by the emergence of product-centricity in the modern IT/digital organization. Organizational areas that strongly lean into agile and DevOps are inclined to the term “product.” Product managers, product owners, and product teams are the new wave. As individuals oriented to this world gain seniority and authority over portfolios, the questions inevitably arise:

• What is the relationship of a “product” to an “application”?
• What is the relationship of a “product” to a “service”?
• Can or should “product” become a primary portfolio concept?
• If so, is it possible/advisable to replace previous terminology?

These are significant questions when we realize that large IT portfolios easily represent ongoing expenditures in the hundreds of millions or billions of dollars. If we are going to use a word to characterize and inventory enterprise resources of material significance, we should define it carefully. (Accountants certainly take their language seriously.) In particular, I recently received an inquiry in which the client indicated they were going to restructure their entire IT portfolio on the definition that “IT services produce products,” which I don’t think is advisable at a foundational level.

To partly answer these questions, I recently fielded a LinkedIn survey. I admit that such surveys are a little annoying, and I ignore many of them. But this one clicked and is probably my most interacted-with social media survey:

Original Postrodvsvc.png" alt=""/>

Notice that I did not frame this as mutually exclusive. I can think of plausible examples of all three. But what I was testing for was greatest applicability, for the usage that people felt most comfortable with. (A much smaller Twitter survey gave almost identical results.)

If either the first or the second alternative had won, this would be evidence that distinguishing “service” versus “product” is important. In information management terms, they would probably need to be two distinct entities. But with the third option clearly being the most preferred, we know that a “product” entity can contain “services.” Furthermore, we may be able to use common processes for either. This is important in terms of how we approach IT/digital operating model issues and related tooling.

Almost as interesting as the survey were the comments. Beyond discussion of the alternatives, there were two major challenges:

1. Why do we care?
2. None of these are “correct.”

The first challenge — why do we care? — I have answered throughout this blog. These terms are the basis of information management for IT portfolios. Without clear definitions, core IT operational management is at risk.

The trouble with response number two is that these are very fuzzy terms, and you can argue them indefinitely. (See Essentially Contested Concept.) “Correctness” is therefore not a useful or realistic criteria as it’s endlessly debatable.

I’m less interested in the (often self-proclaimed) superiority of someone’s “correct,” logical, idealistic analysis. Such analyses are a dime a dozen, too often contradictory, and mostly irrelevant. I’m more interested in the usage patterns we can empirically document and measure — how are people, in the real world, using these terms when they talk and manage? For example, several folks argued that “products” must be tangible (they are “goods”). The counterexample I always use comes from my three years at AT&T, where I saw that AT&T’s offerings are 1) mostly intangible and 2) internally called “products” — not services. (They do use “services” in marketing literature.)

So, although I avoid saying whether a given usage is “correct,” I will say that when the largest telco in the world makes a terminology choice, it’s notable. It would have been interesting if the survey had trended in a different direction than AT&T’s usage, but ultimately, the survey was aligned to the AT&T usage, and the below definition on the right seems to have decisive support:

See also the Shostack Continuum.

There is far more to the problem than these findings. For example, I did not explore the issue of “application,” in the interest of scope. There is also a rich discussion to be had about the various aspects of the overloaded word “service” (Mark Smalley has good thoughts.). Ancillary terms such as “solution” also crop up. I hope to dig further into these issues in future writing.

=========

¹ Managing master data is a subdiscipline of the general area of data and information management, which is an important discipline that crosses business and technology boundaries. The Data Management Association is the preeminent professional organization in this area. They publish the Data Management Body of Knowledge, or DMBOK. Reference and Master Data is a primary section within the DMBOK.

Product Managers Must Become “Masters of Product”