Joining Forces of Product & Service Management
Let’s describe it as “Batman versus Superman”
# Declared variables
Superman = "Service Management"
Batman = "Product Management"In the past few months I got the feeling everybody is talking about Services, with the extremely important focus on customer-centricity, but products and market-orientation are more and more out of focus. “Just a piece of hardware” was a quote I heard. As the skillsets and capabilities to manage products and services are similar but never complete from a business perspective it makes sense to combine the best of both!
Or do you know even one company that is successful without a clear vision and idea of what the central piece of value is? Well that’s the core to Product Management!
Combine for Success
Product Management enables Enterprise Service Management for standardization and scaling. I like to think about the Service Management System as the procedural framework for an organization. Latest (for example with ITIL v4) there are also requirements included in, regarding the strategic framework (e.g. Portfolio Management, Service Definition). For me the discipline Product Management is the right answer to that.
“It shouldn’t be a war but joining forces.”
As a Service is not only one piece of “Doing”, a Product is not only a piece of hardware. In the environment in which I worked in, there always was a minimum grade of abstraction between what a company is offering and the provisioning of a concrete hardware or service. In this respect it is a chicken and egg problem. You may ask “Does the Service include the Product or does the Product include the service?”. From my perspective the answer should be based on the disciplines and methods already existing.
Maturity Levels
Taking a look on services and products, the important step is to differ between the product as the value proposition and the service as the fulfillment of this proposition. To use the outcome of services in other services you now have to stack products in cascades. This leads us to the following maturity levels:
The idea of an abstract definition of the term product is to define a clear interface for service organizations, internally and externally, including a single Definition of delivered values and fulfilled agreements for all components. This definition is working whether you sell service-only products, combinations of hardware and service or hardware only.
Please keep one thing in mind: This is a full definition working for Enterprises, offering highly configurable and scaling Products. Working with this setup requires a high effort in methodology and process development, but then enables you to shorten your Time2Market and scale your business, even when it comes to complex Products, e.g. for B2B.
Also the differentiation between the Product documented in the catalog and the delivered Instance documented in an inventory is key to this abstract concept. The Service in the end is part of the instance or is handled in form of a service request fulfilled on basis of the instance. See the following extended illustration of the third maturity level.
Fulfilling a service
To fulfill the service in the end, classic approaches like service blueprinting and documented/automated workplans and processes are the way to go. By focusing on single service and product components, they can be highly standardized and reused per case.
Definition of Product and Service
In the complex Enterprise world, there’s not only one layer of products and/or services. They include each other, they refer and they cascade in the value chain. in the end this approach can be summarized with the following recommendations:
- You need the Product as the one Value Proposition and the translation from what you sell down to what you deliver. The Product also includes the definition of the service part or especially the abstraction of the service part that is relevant for your customers and then breaks it down to the subordinated deliverables.
- Instancing a Product then means to take inventory of what a specific customer or user ordered.
- You can use Service Blueprinting to describe what has to be delivered based on the basic product definition (also what can be changed and how it is ended). The Service includes all aspects of how to do things.
- If you instantiate the Service Blueprint you start delivering a concrete service based on an instance derived from a product definition.
Notation
There are different approaches to notate and model you Product and Service Designs/Blueprints and also methods to cover aspects of the activities following out of this basic idea. Take a look at OBASHI, Archimate or the bluEDGE method.
Naming may differ
So this is my view on Portfolios, Products, Services and Projects. Of course the naming might be different according to the context, driven by the amount of Services you include and the industry you’re working in! Some talk about Service Offerings instead of Products as they are completely focused on Service-only Products. Others name the Service Instance simply a service.
