What 'Product' Really Means

“Product” is used constantly and means different things depending on who is in the room. A gap like that is a risk for any company moving to the Product Operating Model. People in a product team can only execute on what they think the word covers, and so can the people who enable the product organisation.

A note on scope

This article covers tech-enabled products: software, platforms, digital services and, increasingly, physical products with a digital layer. It does not cover purely physical goods. The line is moving, though. The more tech-enabled a physical product becomes, the more of this thinking applies to it.

What a product is not

None of these is, on its own, the product in the sense of the Product Operating Model, and none of them marks the limit of what a product team is responsible for:

• A feature
• A piece of software
• An API
• A dataset

Each can be part of a product. The product is something larger.

Two meanings of the word

From the user’s side, the product is what they interact with and what gives them value: the app, the API, the map they look at. That is the common meaning of the word, and it is correct as far as it goes.

From the product operating model’s side, “product” names a responsibility. It is the work a product manager and a product team take on so that the thing the user interacts with delivers value and keeps doing so, across every angle that work has to cover. The user only experiences the value it creates.

Both meanings are in use at once, and a discussion about “the product” gets confusing when they are mixed. In the rest of this article, product means the responsibility.

What the product responsibility covers

The responsibility covers an interconnected system of all of the following:

• the functionality and features
• the technology that enables them
• the digital user experience that helps users interact with the functionality
• how to monetise them
• how to distribute them, so they attract and acquire users
• any other touchpoint the company engineers to deliver its value proposition

The list follows Marty Cagan’s in INSPIRED (chapter 8), where he calls it the holistic product. The adjective is unnecessary here, because “product” already means all of this.

Two of Cagan’s examples are counterintuitive:

For an e-commerce business, product includes everything except the actual merchandise being sold. For a media company, product is everything except the content.

This is how Cagan separates the product (the tech-enabled part) from the underlying assets.

The nature of a product

1. A product delivers value repeatedly without being rebuilt each time

Melissa Perri, in Escaping the Build Trap, describes a product as something that “delivers value repeatedly to customers and users, without requiring the company to build something new every time.” The same built thing serves the next customer at close to no extra build cost, and the whole product case rests on that. Rebuild it for every customer and you have a services business, which can be a good business and is a different one.

2. A product is a value exchange between two parties

A product is a two-way exchange. Customers have problems, and businesses create products to solve them. The customer realises value only when the problem is solved, and only then do they give sustained value back to the business. Both sides have to work. For the customer: does it solve the problem? For the business: does it work for us?

3. A change in one area ripples through the others

A product is a system of connected parts, so every change has second and third-order effects. Brian Balfour’s four fits describe the loop: market, product, channel and business model each constrain and shape the others.

4. A product is never finished

Projects have endpoints and products do not. A product is discovered continuously through close contact with customers. The useful question is “did the behaviour change, and did the value materialise?”

What else counts as part of the product

Functionality, technology and user experience are usually assumed to belong to the product team. Two more areas need to be named, because decisions in them shape what gets built and how users experience it.

5. The product molds around the business model, and can shape it

You cannot separate a product from how it makes money. Monetisation does not start after the product is built. It is part of how the product gets built: the pricing model, how it is sold, how it is purchased, and whether acquiring customers is economically viable. All of these affect product and technology decisions.

6. The product molds around how it is distributed, and should shape it

How the product reaches customers is a product problem as much as a marketing problem. Products have to be designed, and technically fit, for their distribution channels. A product with aligned distribution and average quality will outperform a beautiful product with broken distribution. Product growth is about distribution, and support for the channels has to be built into the product for them to work. “Build it and they will come” no longer applies.

How to improve the odds of success

7. Start from the customer, not the solution

The market comes first, and so does the problem. Work outside-in: understand the customer’s problem space before you start designing or building, then keep validating with customers as you build more.

8. Measure outcomes, not outputs

An output is what gets shipped: a feature, a release, a line of code. An outcome is what changes in the world because of it: a behaviour, a decision, a business result. A product does not exist because features shipped on time. It exists because something changed for the customer and for the business. If nothing changed, there was activity and no product.

Internal products and platform products

The definition holds for internal products and platform products too. Read “customer” as whoever receives the value, whether that is internal users or a team consuming a platform. Two points are easy to overlook for these products: the business model and how the product is distributed.

What it means to be “a product person”

Someone who calls themselves a product person thinks about all of this at once. They look past the features and the backlog to the whole system: who the customer is, what problem is worth solving, how the solution reaches people, how it creates value for them, and how that value sustains the business.

A product person holds four risks in mind together. Will customers find it valuable? Can users use it? Can engineering build it? Does it work for the business, meaning is it viable? They hold the tension between customer needs and business constraints, between what is desirable and what is viable, and between shipping now and learning more.

“Product person” describes a mindset. An analyst, a product manager, a researcher, an engineer or a designer can each be one.

What it means to be “a product team” in the Product Operating Model

A product team owns the product in this full sense. It receives a problem or an outcome and works out how to solve it, instead of being handed a list of features to build. That means discovery: talking to customers, identifying opportunities and testing assumptions. It also means delivery: building, shipping and measuring whether value was created. Both happen continuously. The team is accountable for outcomes. If everything shipped on time and nothing changed for the customer, the team did not succeed.

A product team wants to build products that work. In the Product Operating Model, a team gets there by learning to handle the four risks above. The methods come from people who lived the alternative, where teams are handed roadmaps and judged on delivery dates. That arrangement manages one risk, the schedule, and treats hitting the date as proof that value was created. An organisation moves to the product model only when its leadership accepts that the other risks are real and that they cost money.

Further reading

• Brian Balfour, “Four Fits for $100M+ Growth”. A series worth reading in full. It defines product as a system of four fits: market/product, product/channel, channel/model and model/market.
• John Cutler, “12 Signs You’re Working in a Feature Factory”. Defines product by contrast. It is easier to explain what a product is by describing what it is not.
• Lenny’s Podcast, “The nature of product” with Marty Cagan. A long conversation on what a product is and how it differs from a feature set.
• Marty Cagan, INSPIRED: How to Create Tech Products Customers Love. The foundational account of product work and the four product risks: value, usability, feasibility and viability.
• Melissa Perri, Escaping the Build Trap. Defines product by contrast with the project and feature-delivery mindset. Particularly strong on outcomes versus outputs, and on sales-led versus product-led.
• Marty Cagan, “Discovery vs. Delivery”. States the requirement plainly: discovery has to produce one solution that works for many customers.
• Marty Cagan, “Charter Customer Programs”. How he puts it into practice: six reference customers from a single target market, and one solution that works for all six.