According to the Merriam-Webster dictionary, an oxymoron is a “combination of contradictory or incongruous words.” Some famous examples include “deafening silence” or “bittersweet.” The juxtaposition of two opposing concepts doesn’t usually make sense, but context makes the two work together to produce something that bridges two extremes.
It’s fair to say that product service management is an oxymoron. As technology blurred the lines between physical and digital, it did the same to the traditional conceptions of product and service. The distinction between tangible products and intangible services blurs when they can be consumed simultaneously within the same software or app.
This reflection, that seems semantic, actually holds the key to unraveling a very important feature from product management that often gets overlooked by literature. The product operating model is usually portrayed as a framework for selling digital goods, and people just assume it works the same way for digital services.
You can’t copy and paste practices between product and service, and that’s why it’s important to discuss service product management.
In this article, you will learn how it is different from regular product management and some key mindset changes you must make in order to set your service for success.
Product service management, or service productization, as it’s sometimes referred to, stands for the extension of the product operating model to a service business. That means that the customer centric approach to value delivery, usually applied to digital products, gets spun off to uplift services.
People who work in product service management usually don’t have a specific title. They are either regular product managers or product owners, and their only differentiator is the context that they find themselves in: a service company.
Squads are less common in service companies, but product managers still collaborate with engineers, designers, and business stakeholders like those in sales or marketing. The differences are less about structure and more about how each branch of product management deals with common challenges between both types of businesses.
Before we keep moving forward, I should say what I mean by the “product operating model.”
The term fills an old gap left by a lack of definition on what product management means when we speak of a cohesive set of practices. It’s not a synonym to agility, to marketing, or to business, it’s something else.
Relatively interchangeable with “product-led,” the product operating model involves bundling everything we understand as indispensable to perform good product management: discovery and experimentation, data-driven decision making, lean and iterative thinking, customer-centric thought, etc.
From now on, when I mention the “product operating model,” understand that I’m referring to the best practices in product management, as demonstrated by successful tech companies like Amazon, Apple, Stripe, and Spotify.
The main gap between product and service is that the first, even if digital, is dependent on the user only as the human aspect of the value delivery. The latter is dependent on at least two people: one providing and another one consuming.
Think of the difference between a book and a teacher: even though there are a lot of people involved in manufacturing a book, the reader is the one responsible for reading it, understanding it and extracting the value from it in the form of learning. A teacher, on the other hand, provides the same value as a book, but the “user” receives it passively. The first is a product; the latter is a service.
Not every service is so reliant on people. Some value deliveries that are heavily reliant on processes, such as banking or public services, are considered services although they can be heavily automated and therefore people-independent. Those are not the services we are talking about.
This difference in the amount of people involved in the value exchange is the cornerstone of a series of differences between service product management and regular product management. Without trying to be exhaustive, here are some discrepancies between the two types:
While regular product led companies have their core value supported by their tech, service companies have their core value built on top of providers’ expertise. Teachers, doctors, organizers, creatives, engineers… Those are the people that will earn the company’s money.
A hypothetical virtual doctor appointment product that has a killer app, but a poor clinical body will fall flat. The opposite is not necessarily true.
That’s not to say that technology and user experience are irrelevant for service delivery, however the user tolerance with those is greater if the service compensates for the difference.
A lot of regular products have people involved in the mix of their delivery. E-commerce platforms or real estate apps are some examples. Internal collaborators aren’t in between the user and the value delivery though, and as a result, their needs are often overlooked in favor of external users’.
The same is not true for service organizations. A provider that isn’t happy will walk away, the same way a user would. If you lose providers, you have nothing to deliver to your user, meaning that you can’t close the value delivery loop anymore.
Without providers, there aren’t users. Thus, the needs of providers are equally significant as those of users, eliminating any disparity in prioritization.
The economy of scale that translates to a startup’s ability to reach out to millions of users with a relatively slim team does not work very well in services. You can only scale a human being so much.
Regular growth strategies revolve around acquiring ludicrous amounts of potential users and converting as many prospects as possible. You can do it because if your cloud software is dealing with 10 or 10,000 users, the only impact is cost. Humans don’t scale the same way, and if you stretch your providers too thin, you might lose your capacity to deliver value all together.
User growth must always be in tandem with either provider growth or an increase in provider efficiency.
Discovery, incremental value delivery, and data driven decision making are several commonplace concepts from regular product management that can be applied to grow a service, but in order for that fusion to be successful, a service must usually undergo three key changes:
Services can only become subject to product rules when they have a concrete, observable manifestation. An architecture office that charges customized amounts for each project without object criteria cannot become a product. Alternatively, a counseling platform that charges fixed amounts by a standard amount of sessions can easily be put under the product operating model.
You can only measure the impact of your efforts if your object of study remains the same over time. For that reason, come up with bundles or packages that can abstract all the customization your service proposal can encompass.
It’s impossible to apply digital product practices to a service that has nothing to do with digital technology. It’s becoming progressively harder to be completely physical in our ever greater digitalized world, but digital transformation is not just about using software. It’s about putting tech at the center of your strategy, and making the business revolve around it.
A digitally transformed service business is still not selling tech, it’s selling services, but it embraces data and technology as its main delivery medium and competitive differentiator.
The active user base can be composed by any combination of subscription users, renewable client contracts, or a structured pipeline of one-shot consumers. The point is not so much that you need a specific type of sales model, but that you must have an observable mass to be able to measure the success of your service iterations.
An artist that paints commissions once in a while can’t assert that a service iteration was responsible for increasing customer satisfaction, but an EdTech company that has several recurring students can.
In short, those changes serve to adapt your service to a lean mentality. If you are unable to iterate and learn with experimentation, you won’t be able to make the best decisions when it comes to maximizing value delivery.
Saying that something is bittersweet does not mean it’s bitter and sweet at the same time. As with many other oxymorons, when two different concepts collide, you are left with something new, something greater in meaning than the original parts.
Product service management follows that same rule. Bridging the gap between modern product and traditional service, you create a people first tech business that is poised to succeed in an increasingly digital world.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Great PMs design strategy as a living process. Explore how to plan for 2026 while balancing alignment with adaptability.
Learn practical strategies PMs can use to spread ideas, improve collaboration, and shape stronger, more connected product outcomes.
Discover how to run a growth workshop that equips your product team to map key drivers, identify levers, and plan experiments that matter.
Streamline your product stack with a six step guide to tool consolidation. Cut costs, reduce silos, and boost team efficiency.
Learn more →
