The Product and Service Lifecycle

One lifecycle for products and services

Every digital product and service goes through recurring kinds of work: someone notices a need, it gets designed, built and released, and from then on it has to run, reach its users and be supported when something breaks. The Product and Service Lifecycle is ITIL's model of that work: eight activities that together cover a product or service from the first idea until it is retired.

ITIL (Version 5) deliberately puts products and services in one model. In many organizations the product side (what to build: product managers, developers) and the service side (keeping it running for users: operations, the service desk) were managed by separate departments with separate frameworks. Study material for the new version describes the lifecycle as having two faces: in activities such as discover, design and build the focus leans toward product management, while in operate, deliver and support it leans toward service management. It is one lifecycle with a shifting emphasis, not two lifecycles that hand over at go-live.

Our running example in this page: Kestrel Energy wants a new feature in its customer app that notifies customers about power outages in their area, with an estimated time of restoration.

The eight activities

The purposes below are paraphrased; the right column shows what each activity means for the outage-notification feature.

Design outputs: specifications and prototypes

Two design outputs are worth knowing by name. A product specification describes what the product must do and how well: features, constraints, performance and security requirements, and how users will interact with it. A prototype is an early, partial version built to learn something before committing to the full build: a clickable mock-up, a paper sketch or a small working piece of code.

The prototype of the notification screen showed that customers ignored the map and read only the restoration time, so the design moved that to the top. Finding that out cost an afternoon; finding it out after go-live would have cost a release.

Why the activities are not a sequence

The list reads like a production line, but real work does not follow it. A few patterns from the outage-notification feature:

• Iterations. Design, build and transition repeat every two weeks as the team releases small improvements.
• Support feeds discover. Incidents during storms show that customers also want a notification when power is restored, which becomes a new idea on the roadmap.
• Not every activity every time. A bug fix goes from support to build and transition without anything being acquired or redesigned.
• Operate and deliver run all the time, in parallel with everything else, for as long as the service exists.

The value chain

A value chain is the set of activities an organization carries out to turn demand into value. In ITIL (Version 5), the eight lifecycle activities are the value chain: seen from the organization's point of view, they are the building blocks for all its work on products and services. The value chain is one of the five components of the ITIL Value System.

For each activity, the Foundation book lists key success metrics: measures that show whether the activity does its job, such as how often a transition causes an incident, or how quickly support restores service. The page Continual improvement explains how such metrics are chosen.

Value streams

The value chain lists the building blocks; a value stream shows how they are used for one specific purpose. A value stream is the series of steps an organization takes, drawing on value chain activities and management practices, to respond to one kind of demand and create value for a consumer. "Restore a customer's service after an outage", "deliver a laptop to a new employee" and "release a new app feature" are three different value streams at Kestrel, even though they use some of the same activities.

Thinking in value streams makes one thing visible that organization charts hide: the customer experiences the whole stream, not the part a single team owns. A two-minute fix by the app team means little if the ticket waited three days to reach them.

Core and enabling value streams

Value streams are commonly divided into two kinds. A core value stream delivers value directly to the organization's customers: for Kestrel, "customer moves house and gets a working energy contract at the new address", or "customer reports a wrong bill and gets it corrected". An enabling value stream creates or maintains the capabilities the core streams depend on: onboarding a new service desk agent, renewing the colocation contract, or setting up a new test environment. Customers never see enabling streams, but when one is slow, the core streams slow down with it.

Value stream mapping

Value stream mapping is a technique for drawing a value stream step by step, with the time each step takes and the time the work waits between steps, so that delays and waste become visible. It comes from lean manufacturing and is widely used in IT and DevOps. The steps are typically:

1. Identify the value stream: which demand, which trigger, which outcome, for which consumer.
2. Map the current state (as-is): every step, handover and queue, measured, not guessed.
3. Analyze the map: where does work wait, where is it redone, which steps add no value?
4. Map the future state (to-be): the stream as it should work.
5. Plan and implement the improvements, then measure again.

A small mapping example

Two measures matter most on a map. Lead time is the total time from request to result, as the customer experiences it. Process time is the time someone is actually working on it. Their ratio is the flow efficiency. The example below maps a small change to the outage notifications that the customer contact center asked for.

# Current-state map: "customer-facing change to outage notifications".
# Working days per step: wait = queued before the step starts,
# work = someone is actively busy with it.
steps = [
    ("Triage the request", 6.0, 0.5),
    ("Design the change", 5.0, 2.0),
    ("Build and test", 3.0, 4.0),
    ("Approve the change", 7.0, 0.5),
    ("Deploy to production", 2.0, 0.5),
]

process_time = sum(work for _, _, work in steps)
wait_time = sum(wait for _, wait, _ in steps)
lead_time = wait_time + process_time

print(f"{'Step':<22}{'wait':>6}{'work':>6}")
for name, wait, work in steps:
    print(f"{name:<22}{wait:>6.1f}{work:>6.1f}")

print(f"\nProcess time:    {process_time:.1f} days")
print(f"Lead time:       {lead_time:.1f} days")
print(f"Flow efficiency: {process_time / lead_time:.0%}")

name, wait, _ = max(steps, key=lambda step: step[1])
print(f"Longest queue:   before '{name}' ({wait:.1f} days)")

Step                    wait  work
Triage the request       6.0   0.5
Design the change        5.0   2.0
Build and test           3.0   4.0
Approve the change       7.0   0.5
Deploy to production     2.0   0.5

Process time:    7.5 days
Lead time:       30.5 days
Flow efficiency: 25%
Longest queue:   before 'Approve the change' (7.0 days)

Seven and a half days of work take a month to reach the customer. Making developers faster would barely help; the biggest gains are in the queues. The longest wait is for a weekly approval meeting, for a change that is small and low risk. A future-state map might treat this kind of change as pre-approved, as described on Change enablement, and pick up new requests daily instead of once a week.

Value stream management

A map is a snapshot. Value stream management is the ongoing practice of measuring, managing and improving value streams end to end: flow measures such as lead time, throughput and work in progress are tracked continuously, often from the data in the team's tools, and someone is accountable for the whole stream rather than only for one team's part of it.

At Kestrel this means the "customer reports an outage" stream has an owner who looks at the full journey, from the first call or app report to the customer receiving the restoration notice. Value stream identification, mapping and management together form a small exam category in ITIL Foundation (Version 5), weighted at 5%. The DORA metrics (from the DevOps Research and Assessment program) are a related set of flow measures for software delivery.

Complexity thinking

Not all work behaves the same way, and a value stream that suits one kind of work can be wrong for another. Complexity thinking means recognizing what kind of situation you are in before deciding how to work. The Foundation syllabus includes complexity thinking and optimizing workflows for complexity; frameworks such as Cynefin describe the idea in more detail. A simplified version uses three kinds of work:

Two mistakes follow from ignoring this. Treating complex work as clear produces detailed plans that reality overturns. Treating clear work as complex wastes expert time on things a script could do. Optimizing a workflow for complexity therefore often means splitting it: a fast, standardized path for the predictable cases and a separate, more experimental path for the rest.