What 'Product' Really Means

“Product” is one of those words that is used often but means different things to different people in a room, depending on their experience and training. When someone steeped in product thinking says “product,” they are referring to something much larger and more interconnected than the software solution itself. When someone else hears it, they might think the app, the features, the thing engineering builds.

That gap of understanding is a risk in the sense of being able to move to the Product Operating Model. It might limit the possibilities to execute within the Product Operating Model for those involved in a product team, or for those enabling the product organisation. This article aims to explain what Product is, in the Product Operating Model.

A note on scope

This article describes product in the context of tech-enabled products: software, platforms, digital services, and increasingly, physical products with a digital layer. It does not cover purely physical goods. But the line is moving: as physical products become more tech-enabled, the thinking here applies to more of them.

What Product is not

None of these things are, on their own, a product:

• A feature
• A piece of software
• An API
• A backlog
• A roadmap
• A release
• A dataset
• A platform without users

They can all be parts of a product. But a product is something larger.

What Product is

An interconnected system of many things: the features and the technology that enables them, the user experience, the business model that monetises them, the growth model that distributes them, and every customer touchpoint, digital or human, that shapes the value delivered. These are described in the following 10 points:

1. Product starts from the customer, not from the solution

The market comes first. The problem comes first. Product works outside-in, understanding the customer’s problem space before starting product design.

2. Product is a vehicle for value, not the value itself

A product has no value sitting on a shelf or running on a server. A product is not defined by what it contains, the features, the code, the architecture, but by the value it creates when used. The artifact is the vehicle; value is the destination.

3. Product is a value exchange between two parts

Product is not a one-way delivery. Customers have problems. Businesses create products to solve them. The customer realises value only when their problem is solved, and only then do they provide sustained value back to the business. Both sides must work. Customer value: does it solve the problem? Business value: does it work for the business?

4. Product includes the business model

You cannot separate the product from how it makes money. Monetisation is not something that happens after the product is built. It is part of the product. This extends beyond pricing, it includes whether the product fits its go-to-market, and whether customer acquisition is economically viable. The product must also be built in a way that supports how the customer wants or needs to pay for it.

5. Product includes commercial fit

A product also lives within contractual, legal, and operational constraints. It must be sold in a way that makes it possible to scale growth sustainably given the technical and operational limits of the company. Just because you can sell a customised version of your product to a possible new customer, doesn’t mean you should.

6. Product includes the growth model

How the product reaches customers is a product problem, as much as a marketing problem. Products must be designed for their distribution channels. Product quality in isolation means nothing, 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 distribution channels needs to be built into the product to work.

7. Product is the entire customer experience

The product is not only what engineering builds or designers design. It is what the customer experiences. How you design, build, document, support, educate, market, and sell, all of this is part of the product. The customer does not experience your org chart. They experience a single, continuous interaction with your company. Sometimes through interfaces and APIs, sometimes through human interaction. The more you know about the customer journey and the user journeys happening within customer accounts, the better you can design the customer experience and build it in a way that supports sustainable business and growth for the company.

8. Product is a system with interconnected parts

Product is not a collection of independent components. It is a system where every change creates second and third-order effects. Market, product, channels, and business model form a loop, each constraining and shaping the others. A change in one part ripples through the rest and ultimately affects the customer and user experience.

9. Product is never finished

A product is not a project. Projects have endpoints. Products do not. A product is continuously discovered through close contact with customers. The question is never “did we build it?”, it’s “did the behaviour change? did the value materialise?“

10. Product is measured by 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 were delivered on time. It exists because something changed for the customer and for the business. If nothing changed, there is no product, only activity.

Internal products and platform products

This definition holds also for internal products and platform products. Read “customer” as whoever receives the value: internal users or a team consuming a platform. Three points that can be overlooked for internal and platform products are usually business model (#4), commercial fit (#5), and growth model (#6).

What it means to be “a product person”

When someone says they are a product person, they mean they think about all of this at once. Not just the features or the backlog, but 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 at once: whether customers will find the product valuable, whether users can actually use it, whether engineering can build it, and whether it works for the business (is viable). They hold the tension between customer needs and business constraints, between what is desirable and what is viable, between shipping now and learning more. It is not a role. It is a way of thinking about the work.

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

A product team is a team that owns the product in this full sense. They do not receive a list of features to build. They receive a problem or an outcome, and they figure out how to solve it. That means they do discovery: they talk to customers, they identify opportunities, they test assumptions. And they do delivery: they build, ship, and measure whether value was actually created. Both, continuously. A product team is accountable for outcomes, not output. If they shipped everything on time but nothing changed for the customer, they did not succeed.

Food for thought: Marty Cagan on “holistic product”

In INSPIRED (chapter 8, Key Concepts #1), Marty Cagan lands on a very similar holistic definition. In his framing, product includes the features, the technology behind them, the user experience design, how you monetise, how you attract and acquire users, and any offline experiences essential to delivering the product’s value. Two of his examples are worth holding onto, because they are counterintuitive to most people:

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

Further Reading

• Brian Balfour, “Four Fits for $100M+ Growth”. Can’t recommend this series enough, it is well written and thought through. Defines product as a system: market/product, product/channel, channel/model, model/market fits.
• John Cutler, “12 Signs You’re Working in a Feature Factory”. Defines product by contrasting it. It is easier to explain what product is by describing what it is not.
• Lenny’s Podcast, “The nature of product” with Marty Cagan. A long conversation on what product actually is and how it differs from a feature set.
• Marty Cagan, INSPIRED: How to Create Tech Products Customers Love. The foundational articulation of product work and the four product risks: value, usability, feasibility, viability.
• Melissa Perri, Escaping the Build Trap. Defines product by contrast with the project and feature-delivery mindset. Particularly strong on outcomes vs. outputs.