A Product By Any Other Name Would Not Smell as Sweet

Ever since digital tools and experiences became aspects of everyday work life, there’s been a struggle within scaled organizations: How to define and classify “products.” What is a product? What’s not a product? What would it mean for an organization if we had a definition we agreed to?

It may seem like it’s a struggle about semantics, but it is not that simple. In reality, the debate around “What is a product?” is primarily a struggle over finance, ownership, conviction, and who gets a seat at the table. Within various social media posts on LinkedIn, Reddit, or Medium, the debate often manifests as a semantic argument that seems petty and inconsequential to most outside observers. You can’t really blame anyone for thinking of these debates as unproductive nonsense akin to the infamous—and never-ending—“tabs vs. spaces” flame war. After all, we’re all familiar with the reality that IT professionals are often proud to have ludicrous and seemingly endless discussions on minutiae that will both never be settled and never yield any productive value.

Despite any hesitancy you might feel here, I recommend you dive in with me on this one. When you come out on the other side of the conversation, you just might have something immensely valuable to share with your organization. When in doubt, remember the core mantra of Unbundling the Enterprise: The greatest treasures are the ones you didn’t know to look for.

The Partisan Divide Over Product

Over the last decade, two different perspectives have emerged on codifying a definition of the term “product.” On one side, there are professionals from business and technical disciplines that cling tightly to a viewpoint that is simple and clear: “A product is a refined and packaged good that is sold to a customer.” On the other side, there are professionals (again from across business and technical disciplines) with a view that is equally simple and clear, while also being more expansive: “A product is a unit or vehicle of value delivery from a producer to a consumer.”

On the surface, the gap seems to indicate that one side only considers a thing to be a product when an external customer pays for it. On the other, the possibility of a paying customer is a distraction from the essence of the term.

Let’s take a closer look at the stakes involved.

While this compare-and-contrast exercise is not meant to say that it will play out the same way in every organization, it is intended to show where the biases and human behaviors often lead when the default answer on product supports an “adults-table/kids-table” culture that overemphasizes exclusivity and creates a category that is overly limited in scope. It focuses primarily on tangible, physical goods that are produced, packaged, and sold. While this accurately describes many consumer products, it excludes intangible products like services, the wide majority of digital products, and experiences.

On the other hand, the broader and more inclusive “unit of value delivery” definition encompasses both tangible and intangible offerings, recognizing that products can take various forms as long as they deliver value to a consumer. This definition accommodates not only physical goods but also services, software, subscriptions, experiences, and any other offering that provides value to the consumer (regardless of how that offering is monetized).

Additionally, the second definition highlights a product’s essential function, which is to deliver value to the consumer. It acknowledges that a product’s purpose is not merely to be produced and sold but to serve as a means of transferring value from the producer to the consumer. Without this context, the product provider is likely to miss the strategic nature of why an organization produces an offering in the first place.

One of the clearest examples of this concept is in web browsers. All of the major web browsers are free, and they’re free for everyone because the value being exchanged by the users of these browsers isn’t monetary. The browser makers receive other value for making these products freely available. Exactly how the economics of free offerings work isn’t really the point here. The point is: Are you really saying that Google Chrome, Microsoft Edge, Firefox, Safari, Brave, etc. aren’t products?

In today’s diverse and rapidly evolving marketplace, where companies offer a wide range of products (each with its own characteristics of value exchange) beyond just physical goods with a specific price tag, the more comprehensive second definition better captures the essence of what a product is and the role it plays in value delivery.

Concrete Examples Most People Can Agree On (Except for Those Who Don’t)

Is an intranet a product? Is a development platform a product? Are your communication and collaboration platforms (e.g., Slack, Miro, Teams, Google’s productivity suite, etc.) products? Your enterprise search engine? How about your CRM, revenue, and commission management tools that keep salespeople and field organizations operating? Are they products with users that need productive and modern experiences to optimize firm performance?

When looking at the stark examples above, two things come to mind. One, of course, these products would benefit from a product mindset and process that make them effective, efficient, and operationally reliable. Second, it raises an interesting question: “Why are we talking about this anyway? Who’s running around and making a point to exclude non-revenue-generating systems from product conversations?”

This is where it gets a bit strange…it would seem that the most vocal advocates for exclusionary language and behavior come from the technology community themselves. Several API enthusiasts and evangelists seem to have taken an emergent good thing (“API-as-Product”) one step too far. Rather than seeing what was really happening when APIs started to gain traction as the highest efficiency form of value exchange (where global methods of value exchange are migrating to low-friction digital channels, fully explained in the conclusion of Unbundling the Enterprise) as shown below, some well-meaning professionals got all caught up in the unicorn hype and drew an unnecessary (and unproductive) line between “APIs sold for direct revenue” and everything else.

After everyone is tired of arguing and all the debates are done, one thing both sides agree on is that applying a product mindset to APIs regardless of the “for sale” status is a good thing given that having a product mindset, at minimum, will require a development/delivery team to consider the wants and needs of their prospective consumers when working through the process of software concept, design, and delivery.

Building and applying a product mindset during software delivery is a critical step in orienting your teams to the only way to receive value from software investments—by having them adopted and used.

A Compromise in Case

Not specific to the product nomenclature debate, there is an organizational communications tactic that could sidestep the need for a messy conflict. What if we said, “A product is a unit or vehicle of value delivery from a producer to a consumer. When referring to systems and offerings that are sold to generate revenue directly, we’ll call those Products with a capital P to make sure they have the appropriate level of focus.”

Adopting a convention of using uppercase “Products” and lowercase “products” to differentiate between their core revenue-generating offerings and other value-delivery mechanisms lets both groups have what they want. For the revenue-minded person, this capitalization approach provides a clear visual cue and hierarchy within an organization’s portfolio. While the person who wants to ensure that the lowercase “p” products still have the ability to request product resources, approaches, and methodologies without being laughed out of the room

With this new communications tool in hand, here’s how the product landscape looks:

• Products with a capital “P” refer to the flagship goods or services that a company formally sells and generates direct revenue from. These are the primary drivers of the business’s income streams and are typically the focus of sales, marketing, and strategic efforts. Examples could include a software company’s subscription-based application suite, a manufacturer’s line of kitchen appliances, or an insurance provider’s bundled policy packages.

• In contrast, lowercase “products” encompass other offerings, tools, or complementary value-delivery vehicles that may not directly generate revenue but enhance the overall customer experience, support the core Products, enable employees in their day-to-day operations, or provide financial benefit outside of directly driving top-line revenue. These can take many forms, such as enterprise applications, free downloadable resources, educational content, community platforms, or supplementary services. For instance, a software company may offer free mobile apps, tutorial videos, or developer tools to augment their paid Product offerings.

Organizations can maintain a clear delineation between their formal revenue streams and ancillary value drivers by maintaining this uppercase and lowercase differentiation. It allows for effective prioritization of resources and investment toward the capital “P” Products while still recognizing the importance of cultivating a comprehensive ecosystem of lowercase “products” that deliver holistic value to customers.

While this communications hack might be easily dismissed as too clever, let’s take a moment to understand our goals in landing on a model that a scaled enterprise can align with.

1. Reduce unproductive debate that distracts teams from achieving organizational objectives (i.e., no more “tabs vs. spaces” diatribes).
2. Preserve focus on revenue growth while maintaining balance for operational priorities.
3. Create and preserve support for a product mindset approach with strategic capabilities and assets.

The case-based nomenclature hack may not be your first idea when trying to overcome the organizational structure issues that come from typical corporate hierarchies and kingdom-building behaviors, but when looking at the alternatives it may end up being the solution that is both easy to put in place and effective in the right way because it can act as the cultural backstop to suboptimal behaviors and attitudes that inevitably emerge from bureaucratic cultures.

All this exploration points back to an interchange and quote from one of our most important interviewees, David Rice, Senior Vice President, Engineering at Cox Automotive Inc.

”All org designs suck, and really all you’re doing with an org design is you’re focusing your org design, whether it’s centralized or decentralized or connected, to the product. You’re focusing it on a set of problems that you have in this moment. But what is more important than your org design is the remediations you put in place to deal with the fact that the org design is suboptimal in a bunch of other cases.”

—David Rice, Senior Vice President, Engineering at Cox Automotive Inc.

In chapter 6 of Unbundling the Enterprise, we (with a little help from Rice) layout the framing devices organizations use to categorize and organize around cost centers and value centers. When we take our original question (“What is a product?”) in the context of organization design, this difference in framing puts everything in the appropriate context.

What we’re really looking for is a low-effort, low-complexity way to compensate for an organizational structure that inevitably creates suboptimal work culture (e.g., “Products are the domain of business teams because ‘we own the what.’ Technology teams and leaders ‘own the how.’ We’ll let you know when we have something for you to build.”).

The upper/lower-case conventions might not solve all your organizational problems, but they can be the start of a dialogue to help all your product teams align to adoption-driven methodologies (rather than just the ones who have a current and direct connection to today’s top-line).

When considering this tactic in the context of your enterprise, remember the lessons from chapters 7 and 8 of Unbundling the Enterprise: The most successful organizations in the world (like the ones we profile in our book—Coca-Cola, Cox Enterprises, Anderson Holdings, Amazon, Lowe’s, L Brands) understand how the “back office” activities of today will create the asymmetric opportunities of tomorrow.

- About The Authors

Stephen Fishman

Stephen Fishman (Fish) is the NA Field CTO for Boomi. He is a practicing technologist who brings creativity, rigor, and a human-centric lens to problem-solving. Known as an expert in aligning technology and business strategy, Stephen places a premium on pushing business and technology leaders to embrace iteration and the critical need to collaborate across disciplines. Throughout his career, Stephen has consulted with organizations desiring to transform their technology-based offerings to better meet the needs of organizations and the people they serve. In addition to consulting with large organizations, Stephen is an in-demand speaker and advisor. Stephen has led multidisciplinary teams to deliver amazing results at Salesforce, MuleSoft, Cox Automotive, Sapient, Macy's, and multiple public sector institutions including the US Federal Reserve and the CDC. He lives in Atlanta with his family and when he's not working can be found biking on the many trails in Georgia.

Follow Stephen on Social Media

•