Digital Products - replace or complement apps and services?

[Miklos Palfi]

Currently we are working on introducing the digital products concept into our data model. There are some very valuable contents out there on the topic including the recent Digital Services Forum meeting Digital Product Management & Foundational Data - Recorded April 11th 2024 

Our main question is the change from services and applications to digital products.

IT4IT v2.1, ITIL4 and TBM - in our opinion - all build heavily on the service portfolio and hierarchy. IT4IT v3.0 tries to make a step in the agile / DevOps direction (and comes with that closer to DevOps / SAFe world) by replacing the services and applications with products. (This was also well discussed in a previous Digital Services Forum session: 

IT Operating Models of Tomorrow - Presented on May 23 2022 

But how can we keep compatibility to the current models and frameworks? Shouldn't we keep the services and applications layer (not only the offers/service offerings) as a second view? What about putting the services and applications under the products as child-objects/tables? Actually we also sync many of our applications into the service table, because that's what customers (and the business users) know and name for the servicedesk.

So the question is replace or complement apps and services with digital products in the data model?

[Miklos Palfi]

Absolutely agree with the difficulty of naming. We have also renamed "the thing" (currently Application Services) multiple times to better describe what we mean with it. None of the names was (and is) perfect, but where the CSDM helped us a lot is the communication with other organisations (like provider/outsourcer companies), because it acts like a common modeling language.

But IMO there are some few very important characteristics, which make an object different from the others. Applications have no service level. Services may contain absolutely no applications. Applications are provided via services often in different stages (dev, test, prod), with different SLAs.

Digital Products are for me an abstraction layer, which represents a bundle of different other objects. But they are not the same as the included represented objects. Digital Products are not only applications as they are not only services. (Some of them may only contain the one or the other, but defintiely not all of them like that.)

I really like the Digital Product Portfolio Management as presented in Digital Product Portfolios Session.

[Miklos Palfi]

The naming question is maybe only a symptom, not the root cause. In CSDM 5.0 draft it seems to be Service Instance instead of System.

What we evaluate now is a combination of a core and a service part plus instances of this core+service. Maybe this is what many call as a Digital Product.

Digital Product Core could be an application or a physical item (like mobile phone or laptop). If this is provided with a service, then a service offering would be connected. This Product could have 0..x Instances. (0 if a product is still in planning or is retired, in case of applications it could be dev/test/prod or in case of mobile devices as many as employees the company have) Let's call these Digital Product Instances.

It is important, that the linked service offering has not always a 1:1 relation to the Digital Product (DP). DP can be a module of an application or a customer journey, which uses a part of a service or parts of multiple services.

There are always extremes: the core could be inmaterial (think about a consulting service or other management services) in which case the core is empty, and there is also no instance of it. But it could be a full application, with the service around it, in which case the product owner is the application owner and the service owner in one person.

I am still very much for keeping the applications and services separate and complement them with the digital product layer, with references to the apps and services and instances.

What is your opinion about this?

[HY2]

I see where you're coming from and I completely agree with your point.

I would raise you with that internal products (such as IT services, cloud platforms, or internal tools) can—and often should—focus on delivering value and ensuring internal customer satisfaction, much like a product sold to external customers. In fact, there’s a massive overlap between product management practices and the management of internal services today.

Reframing the distinction as almost: Service Management = Internal Product Management

I think the real sticking point is this: service management frameworks (like VERISM or ITIL) may be rooted in traditional service delivery, but in today’s world of digital transformation, they inevitably overlap with product management principles—especially when it comes to internal services or internal tools.

This overlap isn't just theoretical; it's becoming increasingly practical in how organizations run their IT and other operational services.

Here's why product management practices apply to internal services:

1. Internal Products Can Be Managed Like External Products:
   - Internal services (like a company’s internal cloud platform, HR software, or helpdesk systems) should absolutely be treated like products.
   - These services are delivered to customers—in this case, internal teams or departments—and they must satisfy the needs of those customers just as a commercial product must satisfy external users.
   - Product management focuses on aligning the product roadmap to meet user needs, ensuring continuous improvement based on feedback, and prioritizing features that bring the most value. The same applies to internal services. The product manager might be working on an internal platform, but they are still ensuring that the platform aligns with business goals, user satisfaction, and continuous improvement—all core tenets of product management.
   - Internal service catalogs are like product catalogs for internal products—they need to be continually optimized to deliver more value to internal users, whether it’s IT, HR, or other departments. This brings us to the heart of the issue: internal services should be managed as products, even if they are not sold externally.
2. Customer-Centric Focus for Internal Products:
   - In product management, the central focus is always the customer. Whether the customer is external (a paying user) or internal (a colleague or department), the principles don’t change: you need to understand their pain points, gather feedback, and deliver continuous value.
   - The same principles apply to internal services. You might manage an internal tool (e.g., an employee-facing self-service portal, or a cloud platform for internal teams), but internal customers are just as important as external ones. You need to optimize for their experience, deliver features they value, and ensure the service meets their evolving needs.
3. Iterative Improvement and Continuous Feedback Loops:
   - Agile product management is about iterating based on feedback. This approach works just as well for internal services as it does for external products.
   - If you’re managing an internal IT service (e.g., cloud storage or an internal helpdesk system), you need to continually improve the service based on user feedback. This includes things like:
   - Gathering feedback from internal teams or departments.
   - Prioritizing enhancements or bug fixes.
   - Rolling out new features based on real-time demand.
   - These are the same iterative practices that product managers use when managing a commercial product.
4. Ownership of the Service/Product Lifecycle:
   - Product managers are responsible for the full lifecycle of their product: from the initial concept, through development, to deployment, and eventual sunsetting or retirement.
   - Internal service managers who work within a VERISM or ITSM framework often perform very similar tasks: they manage the lifecycle of services, which may include:
   - Defining service requirements.
   - Building and deploying internal services.
   - Iterating based on feedback from the users (internal customers).
   - Retiring or updating services as technology and business needs evolve.
   - In this sense, service managers are practicing many of the same lifecycle management activities as product managers—they just do it within the context of internal services.

So, Why Doesn’t ITIL Just Call It “Product Management”?

ITIL (or any service management framework) could simply acknowledge that internal service management is a form of product management—because, in practice, it often is. Here's why ITIL may not explicitly frame it as such:

1. 1. Service vs. Product Distinction (Historical Legacy):
   - Historically, frameworks like ITIL and VERISM have been focused on managing IT services that were not directly viewed as products. Instead, they were seen as operational services that provided business support—things like email, network access, and data storage—without the need for the full product management lifecycle that’s applied to customer-facing products.
   - This legacy created the distinction between service management (which was seen as a more operational, cost-focused practice) and product management (which was more about delivering customer value and competitive differentiation).
   
    2. Service Management Is Not Just About Features, But Governance:
   - While product management emphasizes features and user satisfaction, service management traditionally places a stronger emphasis on governance, security, and reliability. This is especially true for internal services that support business-critical functions.
   - But this doesn’t mean service management isn’t about user satisfaction or value delivery—it absolutely should be! Internal services, whether IT services or internal tools, need to be designed with customer needs in mind, and it makes sense to apply the product management mindset to these services.
2. 3. Operational vs. Customer-Facing Focus:
   - VERISM and ITIL frameworks have traditionally focused on the operational excellence of internal services. These frameworks have been focused on areas like:
   - Incident management (response to internal service failures)
   - Problem management (long-term solutions to recurring issues)
   - Service catalog management (ensuring availability of services)
   - Change management (controlling service updates)
   - While these concepts are crucial to product management in a commercial sense (for things like bug fixes, new features, and scaling infrastructure), the focus in IT service management is often on maintaining continuity and efficiency—ensuring internal customers get the resources they need on time and securely, rather than focusing on external market pressures or competitive differentiation.

Acknowledging the Shift in Today’s World

That said, the lines between internal service management and product management are increasingly blurred in the modern business world. This is especially true with the rise of internal platforms and digital transformation where internal services (like cloud platforms, HR systems, or knowledge management systems) need to be continuously improved just like any external-facing product.

 What This Means for ITIL & Product Managers:
- Product managers working on internal tools or services should absolutely be applying product management techniques (such as user feedback loops, iterative development, and prioritization) to these internal services.
- Service managers, particularly in ITSM frameworks like ITIL, need to recognize that internal service delivery is increasingly about delivering value and ensuring internal customer satisfaction, not just operational excellence. If they adopt a product management mindset, they’ll see that internal service management and product management are more aligned than ever.

Final Thought:

In summary, internal services are products in their own right, and service managers are already practicing many of the same techniques that product managers use. The distinction between service management and product management is increasingly blurry—especially for internal products or tools—and ITIL could indeed embrace this shift and frame its practices more explicitly as internal product management.

Essentially, the key takeaway is that service management is increasingly becoming a form of internal product management. ITIL—and frameworks like it—could benefit from explicitly recognizing this evolution, as the core practices of both disciplines are incredibly similar. It's not so much that services need to "accept" that they’re becoming products; it's that service management frameworks can evolve to acknowledge the crossover, ultimately recognizing that whether it's a commercial product or an internal service, the principles of value delivery, iteration, and customer satisfaction are universal.

[dwightpstewart]

Extremely insightful into a fundamental area for shifting thinking.  Couldn't find a "heart" emoji to show how much I appreciate your thoughts.  

[mikesisson]

I'm looking for the documentation where the table of Business Application is changing to Digital Product.  Any help?