Why ITIL 5 does not simply rename a word but demands a different way of thinking. And why IT organisations fail when they swap the door sign before they understand the term.
Many IT organisations are swapping a door sign right now. The "service manager" becomes the "product owner", the "service catalogue" becomes the "product portfolio". The intent is good: it follows the direction ITIL 5 sets. But one step is often skipped: almost no one has clarified what actually distinguishes a product from a service. And without that clarification, the new title is not a role shift. It is a label on the old work.
1. Two terms people love to confuse
In everyday language, product and service sound almost interchangeable. In ITIL they are not, and the distinction is not a technicality for the exam.
According to ITIL, a service is a means by which a provider co-creates value with the customer. The key word is "co": the provider stays involved. The relationship runs in both directions; it does not end with delivery. A product, by contrast, is a configured bundle of resources: technology, people, information and processes, assembled into something capable of delivering value. The product is the foundation that services sit on. A customer rarely sees the product. They see the services it produces.
An example from our own line of work: the collaboration platform is the product. "Set up an email mailbox", "reset access" or "fix an incident" are the services that come from it. Someone who only manages the services deals with what is being asked for today. Someone who owns the product also thinks about where the platform needs to go so that it still delivers value in two years.
2. What ITIL 5 actually changes
ITIL 4 already used both terms but put the service at the centre. ITIL 5 shifts the perspective. The guiding idea of the new version is, roughly, "where product meets service": product and service belong in one shared lifecycle, not in separate areas of responsibility.
PeopleCert states this unusually plainly for a framework. The traditional separation of product and service silos, it argues, has become a burden for organisations that need to adapt quickly. And for the first time, the digital product lifecycle gets its own fixed place in the ITIL model, from discovery through build and transition to operate and support.
That is more than an addition. It is a statement about how IT should be thought of going forward: not as a catalogue of on-demand offerings, but as products that are managed and developed across their entire lifespan.
3. The consequence for governance and lifecycle
When the product moves to the centre, what governance actually steers shifts too.
The service view asks: "Is the service running stably, are we meeting the agreed times?" Legitimate questions, but they stop at the edge of the individual offering. The product view asks further: "Is our product moving in the direction the customer needs?" That is a governance question spanning the whole lifecycle, not just one phase.
This becomes concrete at three points that ITIL 5 explicitly names. First, support tickets flow back into product development: what hurts in operations belongs in the backlog, not just in the incident statistics. Second, operability has to be considered at design time, or you pay for it later as an expensive rebuild. Third, and this is the most uncomfortable one, prioritisation raises itself as a new question. ITIL 5 puts it bluntly: how do you choose when everything is a priority for someone? A service catalogue does not answer that. A product owner has to answer it, every day.
4. The role shift: from administrator to owner
This brings us to the core of it. The shift from service thinking to product thinking is not a new title. It is a different attitude to your own work.
The classic service owner is an administrator: they keep what is defined running and are measured on stability. The product owner is a shaper: they own the outcome, not the output. They decide what gets built next, weigh benefit against effort, and are accountable for the product becoming more valuable over time. That is a shift from responsibility for one phase to ownership of the whole.
A note on honesty: ITIL 5 does not certify a title called "Digital Product Owner". The framework is deliberately role-agnostic and describes a responsibility that touches many roles, from team leads to architects to developers. "Digital Product Owner" is our own shorthand for what ITIL 5 demands, not an exam term. That is exactly why the title change alone falls short: you can appoint someone Product Owner and still have them manage services as before. The sign changes nothing about the perspective.
How to tell the label change is only that:
- The "product owner" is still measured on availability and ticket times, not on business outcomes.
- There is a "product portfolio", but no backlog and no roadmap.
- Prioritisation follows how loudly a request is made, not its contribution to value.
5. Why this matters especially for smaller organisations
You might think product thinking is something for large IT departments with dedicated product teams. The opposite is true. In smaller organisations, which make up the majority in Switzerland, the same person is often responsible for operations, development and customer contact. That is exactly where a missing product view does the most damage, and where having one delivers the most benefit.
Scarce resources force choices. Someone working off the service catalogue processes whatever comes in, and the loudest request wins. Someone thinking in products has a yardstick for saying no: does this work contribute to the product's value, or does it just keep someone quiet? That single question is the practical core of the entire role shift. It costs nothing but discipline, and it works just as well in a team of three.
Conclusion: the term first, then the role
ITIL 5 puts the product at the centre, and that is the right direction. But the order decides whether you get change or cosmetics. Swap the door sign first and fill the term with meaning later, and you get a product owner who manages services. Clarify first what distinguishes a product from a service, then align the role, and you get an actual shift.
Clarifying the term is not an academic exercise. It is the precondition for a new word becoming a new way of working.
Our practical tip: Take one of your "services" and check whether a product is being thought behind it. Who decides on its future development? Is there a roadmap, or only an incident history? What is success measured against: availability, or the outcome for the customer? If you cannot answer those three questions, you are managing a service. Only once you can answer them are you running a product.
Request a no-obligation conversation
Florian Nitz is a Consultant at Qudits AG and an ITIL 4 Managing Professional. He is responsible for technical and digital projects — from IT service management to the further development of digital platforms — and combines strategic clarity with pragmatic execution.
Thomas is Executive Partner at Qudits AG and an ITIL V3 Expert. His focus lies in managing complex IT programmes and projects — particularly in the life sciences — as well as in building and continuously improving IT service management organisations. He develops teams and people with passion.