ITIL 5: The Product and Service Lifecycle Model
Part 2 of 5: One lifecycle, many contributors, shared accountability
In the first article in this series, we explored what has changed in ITIL 5 and why it matters for organisations in Aotearoa New Zealand.
One of the most important changes is the introduction of the Product and Service Lifecycle Model.
The model describes eight connected activities that help organisations manage digital products and services across their full lifecycle:
Discover
Design
Acquire
Build
Transition
Operate
Deliver
Support
This is not simply a renamed project lifecycle. Nor is it a set of eight departments waiting to be created.
The lifecycle is a way of seeing how value is identified, created, introduced, operated, delivered, supported and improved. It recognises that modern products and services are rarely delivered by one team, one supplier or one platform. They depend on internal teams, external providers, technology partners, support functions and customers themselves.
For New Zealand organisations, that matters.
Many organisations here operate with lean teams, constrained budgets and significant reliance on vendors, managed service providers, cloud platforms and specialist partners. A lifecycle model is useful only if it helps those organisations connect decisions, clarify accountability and improve outcomes without creating unnecessary process.
The value of the model is not in reproducing it perfectly.
The value is in using it to ask better questions.
From product thinking to service outcomes
Product management and service management have often been treated as separate disciplines.
Product teams may focus on strategy, features, roadmaps, releases and adoption. Service teams may focus on reliability, support, operational performance and continual improvement.
Customers do not experience that separation.
They experience whether the product works, whether the service is easy to use, whether support is effective and whether the outcome is worth the cost and effort.
ITIL 5 responds to this by treating products and services as connected parts of the same value system. A product may provide the capability, but the service determines how that capability is accessed, supported, governed and improved.
A successful release is not enough if it cannot be supported. A stable service is not enough if it no longer meets user needs. A supplier contract is not enough if the end-to-end experience remains fragmented.
The Product and Service Lifecycle Model helps organisations look at the whole system.
Discover: understand the opportunity
Discover begins with understanding the opportunity, problem or demand.
What outcome are we trying to improve? Who experiences the current problem? What evidence do we have? What constraints, risks and dependencies should shape our response?
These questions sound obvious, but organisations often begin with a preferred answer.
A platform is selected before user needs are fully understood. A supplier demonstration becomes an unofficial design decision. A new capability is mistaken for a business requirement.
Discovery creates space to challenge that momentum.
For smaller New Zealand organisations, discovery does not need to become a large research programme. A focused workshop, analysis of recurring support demand, supplier input and conversations with representative users may be enough to expose the real issue.
The objective is not perfect certainty. It is enough shared understanding to make the next decision well.
Design: consider the whole experience
Design is broader than specifying technology.
It considers how the product and service will work together, how people will experience them and what will be required to operate, support, secure and improve them.
This includes usability, resilience, privacy, accessibility, support, data, integration, supplier responsibilities, measurement and feedback.
Service considerations are too often introduced near the end of delivery. A product may be technically complete before anyone asks how incidents will be diagnosed, how support teams will access knowledge or how users will be prepared.
At that point, serviceability becomes remedial work rather than a design choice.
The lifecycle model encourages organisations to design the complete product and service experience from the beginning.
That does not require every stakeholder to attend every meeting. It means the design must account for how the product will be used, operated, supported and improved.
Acquire: make sourcing part of the lifecycle
Acquire reflects the reality that organisations rarely create every capability themselves.
They obtain software, infrastructure, skills, data and services from external providers. They also allocate internal people, funding and other resources.
Acquisition should therefore be treated as a lifecycle decision, not simply a procurement event.
The lowest-priced option may create higher integration, support or operational costs. A strong technical solution may offer poor data portability. A global provider may deliver scale but limited local responsiveness. A specialist partner may provide excellent capability while introducing dependency on a small number of people.
Useful acquisition questions include:
How will the product operate within the wider service?
What information will the provider share?
How will incidents and requests cross organisational boundaries?
Who owns integrations, data and knowledge?
Can the arrangement adapt as needs change?
What happens when the relationship ends?
These questions are especially important in New Zealand, where supplier choice may be narrower and organisations may rely heavily on external expertise.
A contract can allocate responsibility. It cannot guarantee collaboration.
Build: create, configure and integrate
Build includes developing, configuring, integrating and testing the components needed to produce the intended product and service.
For some organisations, this may involve internal development. For others, it may involve configuring a software-as-a-service product, integrating several supplier solutions or validating work delivered by an implementation partner.
Whatever the sourcing model, build should remain connected to discovery and design.
Teams need to retain sight of the intended outcome, test assumptions and respond to what they learn. Testing should extend beyond whether individual features work.
It should consider end-to-end performance, user journeys, accessibility, security, resilience, monitoring, support, integrations and supplier handovers.
A component can pass every technical test and still contribute to a poor service.
Transition: prepare for use
Transition prepares the product and service for use.
This includes more than deploying technology into a live environment. Users, support teams, operations teams, suppliers and other stakeholders must also be ready.
Effective transition may include release planning, operational acceptance, support knowledge, monitoring, training, communications, data migration, early-life support and rollback arrangements.
Poor transition is often treated as an operational failure even when its causes occurred much earlier.
The service desk was not involved in design. Monitoring was excluded from build. Knowledge was promised but never completed. Supplier escalation routes remained unclear. Users received an announcement shortly before launch and were expected to regard this as preparation.
Transition should confirm readiness, not attempt to manufacture it.
Operate: keep the service running
Operate focuses on the activities required to keep products and services functioning in live use.
This includes monitoring, operational control, routine maintenance, resilience, security operations, platform operations and performance management.
In practice, operate is often distributed across several parties. Internal teams may retain accountability while cloud providers, managed service providers, software vendors and network partners perform significant operational work.
That makes visibility essential.
If an organisation does not understand how its service is operated, it will struggle to manage risk, diagnose issues or improve reliability. If suppliers operate in isolation, each may meet its own obligations while the end-to-end service still performs poorly.
Operate is not simply “keeping the lights on”. It is where design decisions, supplier choices and build quality are tested every day.
Deliver: provide value to customers and users
Deliver is about making products and services available in a way that enables value for customers and users.
It includes the fulfilment of service commitments, service interactions, access to products and services, communication, service level performance and the user’s experience of receiving the service.
This is where organisations need to look beyond internal activity.
A service may be technically available but difficult to access. A request may be fulfilled within target while creating unnecessary effort for the customer. A supplier may meet its contractual measure while the user still experiences delay or confusion.
Delivery is where the promise of the service becomes visible.
For New Zealand organisations, delivery often depends on the coordination of several contributors. The customer sees one service, even when the organisation sees multiple platforms, providers and teams.
The lifecycle model helps keep that perspective in view.
Support: help people succeed
Support focuses on helping users, customers and teams when they need assistance.
This includes service desk activity, incident support, request support, knowledge, guidance, communication, escalation and improvement feedback.
Support should not be seen only as the place where problems arrive.
It is also one of the richest sources of insight into how products and services are performing. Recurring incidents, confusing requests, poor knowledge, repeated escalations and user frustration all provide evidence about where the service needs to improve.
In a healthy lifecycle, support insight flows back into discovery, design, acquisition, build and transition.
If it does not, the organisation risks solving the same problems repeatedly while calling it operational demand.
Support is not the end of the lifecycle. It is one of the places where the next cycle of improvement begins.
One lifecycle across many contributors
The strength of the Product and Service Lifecycle Model is that it makes the whole system easier to see.
An internal team may discover the need. A product owner may lead design. A software vendor may provide the platform. An implementation partner may configure it. A managed service provider may operate it. A service desk may support users. Customers may judge the outcome.
To the customer, it remains one service.
That is the point.
The model helps organisations ask who contributes, who decides, what information must flow between parties and who remains accountable for the outcome.
Its value will not come from creating more process around every activity.
It will come from reducing the gaps between decisions.
Eight practical questions
Organisations can use the lifecycle model as a simple diagnostic tool:
Discover: Have we understood the real need, or merely selected a solution?
Design: Have we designed the complete product and service experience?
Acquire: Have we considered the full-life implications of our sourcing choices?
Build: Are we testing the end-to-end service, not just individual components?
Transition: Are users, teams and suppliers genuinely ready?
Operate: Do we have visibility and control across the live service?
Deliver: Are customers and users receiving the value the service promised?
Support: Are we using support insight to improve the product and service?
These questions are deliberately simple.
Good service management does not always require more process. It often requires people to ask the right questions early enough for the answers to matter.
Using the model proportionately
The Product and Service Lifecycle Model should not become another reason for organisations to create unnecessary governance.
Smaller organisations do not need eight lifecycle owners, eight committees or eight maturity assessments before they can improve.
They can start with one important product or service and map how it currently moves through the lifecycle. They can identify where decisions are disconnected, where supplier handovers are weak, where support knowledge arrives too late or where operational insight fails to influence future design.
That is where the model becomes useful.
It turns the lifecycle from a diagram into a conversation about value, accountability and improvement.
In the next article, we will look at how customer, user and employee experience connects with operational measures - and why meeting service levels does not necessarily mean delivering value.
You’ll find your people here.