Of the hundreds of companies I’ve worked with, the vast majority were product companies. What does that mean? If you ask people to define what they mean by “product” (as I have, many times), you will hear many different takes. Some of the things people say product is:
- What we make
- A tangible output
- The value we create
- Desired or needed
- People will pay for it
- A solution to a problem
These definitions may mostly be true most of the time, but they’re not very helpful when it comes to answering questions such as “Should we continue with this?”, “How should we set our pricing?”, “Why are our profit margins so low?” or “What is our company worth?”
A more recent term is “product-led”, a term I’m wary of because it means different things every time I hear it used. It’s sometimes interpreted as “Product Management makes all the decisions now”, which brings to mind the final scene from Animal Farm: “The colleagues outside looked from PdM to CxO, and from CxO to PdM, and from PdM to CxO again; but already it was impossible to say which was which.” It’s sometimes used in the context of “product-led growth”, a more clearly defined model which is IMO relevant only to agile single-product startups, or large portfolio companies with a highly developed agile culture (and there aren’t many of those, trust me).
One way of thinking about product is the Augmented Product model, which posits three levels: The Core product is the central value proposition, the benefit that your customers need or desire. The Actual product is the features and attributes you have created that deliver this benefit, and the Augmented product encompasses differentiating characteristics that motivate people to buy your product. This adds some theoretical structure, but it doesn’t really help you to answer the questions I posed above.
I’ve encountered various other frameworks designed to help with classification of the things that companies do to create value for their customers, a couple of which I’ll describe here.
Brand Architecture deals with the relationship between a company’s brand and its product lines (referred to as “Branded House”), or between a company and its various brands (“House of Brands”). The first time I saw this implemented in an enterprise software company, there were six levels to the architecture IIRC: Industry, Product, Application Area, Module, Solution, and Additional Option. In truth, the company sold a single product into a single industry. “Application Area” was an arbitrary division based on how the industry operated, “Module” was used to describe ‘big’ things, and ‘Solution’ was a catch-all for something big enough to warrant a product flyer, but not big enough to be a Module. On one occasion, the Financial Controller vetoed a business case on the grounds that nobody would pay more than £25K for a “Solution”. The Head of Sales and I decided to rename it a “Module”, and voilà - veto lifted.
Product Taxonomy is used in ecommerce settings to describe the categorisation of and relationships between products sold online, used to help the customer find what they’re looking for or discover new products. It’s also sometimes used within product companies to describe the operational nomenclature, defining what’s meant by terms such as “platform”, “product”, “component” or “service”.
Why is this important? Am I just being pedantic with my semantics? Truthfully, this stuff can dramatically affect your ability to deliver customer outcomes, profitability, growth potential and resilience.
One of my favourite clients describes themselves as a product company. It’s true that they own a substantial portfolio of software IP, which delivers customer value. However, a typical contract is around 80% services and 20% licences. Recurring revenue is a percentage of licence fees, so overall the proportion of their revenue from licences is small. One could argue that their “product” is the outcome that they generate for their customer; you can use that definition if you want and that’s nice, but the company is getting by with low recurring revenues and slim margins.
For me, there’s little point talking about “product” unless it carries distinct implications for your business model. I’ll explain this using an analogy.
Imagine you went to a hair salon, and as you sat in the chair the hairdresser said “Hi, just to let you know that we do only one haircut here. It’s a Mohican crossed with a French bob. OK?” I imagine you’d be somewhat perturbed. That’s because when you get a haircut, you expect a bespoke service, something that requires effort, skill and time, and done especially for you.
Now imagine that you’re in a convenience store and you pick up a well-known chocolate bar containing chocolate, peanuts, caramel and nougat. You find a shop assistant and say to them “Excuse me, I’d like this chocolate bar, but could you please customise it by swapping the peanuts for pecans?” What reaction do you think you’d receive? Of course, a S***kers bar is a product, and unless you’re extremely rich you won’t be able to get one customised for you by your local store. Crucially, the makers of S***kers enjoy very high margins compared to any hair salon.
So then, the definition of product I use is “The elements of repeatable value in our proposition”. Products have low marginal cost, because you don’t have to design the solution each time - you can just stamp out another copy (or a million copies). In contrast, services involve consumption at the point of delivery. When we say “services companies” we normally mean collections of humans that perform skill-based tasks. The marginal cost is high because every day that you sell requires you to pay someone.
What about the concept of “-as-a-service?” Is Software-as-a-Service (Saas) a product, or a service? Well, it’s both. When you launch (e.g.) Notion, you’re running software code that belongs to Notion Labs, Inc., which is a product because they can sell licences to use the code many times. However the code is running on a computer in datacentre somewhere, consuming power, CPU time, memory and storage that can’t be sold to someone else because you’re using it. This is a service. So really, SaaS should stand for “Software and a Service”.
OK so how do you maximise the resalable bit of what you do? Well that’s the topic of my next article…
Share