Introduction to the Product and Service Lifecycle

A bank runs a mobile app that is live for millions of customers, its next release is halfway through design, and an old feature is being retired, all at the same moment and all the same product. ITIL (Version 5) gives that whole picture a single frame: the Product and Service Lifecycle^[1], the overarching, end-to-end model of how one common set of activities applies to every product and service across its entire life, from the first opportunity or idea through to eventual retirement.

Two ideas make the model click, and both are examinable. The first is that it is shared. ITIL treats a digital product and a digital service as two perspectives of one technology-based solution^[1]: they share the same lifecycle and are managed together with a single, integrated approach, not as two separate pipelines. The figure below shows the two perspectives feeding one shared lifecycle applied from opportunity to retirement. The second is that it is whole-life. The activities apply from the initial opportunity all the way through to retirement, so the model manages a product or service consistently for its entire existence rather than covering only the project that first builds it.

Because the same activities run over that whole life, ITIL frames the model as an ecosystem approach rather than a linear or siloed way of working^[1]. That one word, ecosystem, carries the weight: work is not handed down a production line from one team to the next, it lives in a connected environment where many activities are active together. The rest of this page names the eight activities the lifecycle is built from, shows why they are used out of order and repeatedly, and separates the lifecycle from the three concepts candidates most often mistake it for.

The lifecycle is built from eight activities, and naming them is the single most directly tested fact in this topic. The ITIL Foundation (Version 5) What's New guide lists the eight^[2] as: discover, design, acquire, build, transition, operate, deliver, and support. Every product and service is managed through these same eight; there is no separate, shorter list for services or for products.

A convenient way to hold the eight in memory is to group them by what they do to a product or service: four that bring it into being (discover, design, acquire, build), the one that moves it into live use (transition), and three that keep it valuable once live (operate, deliver, support). The figure below arranges the eight in those three groups. Treat that grouping only as a memory aid for the list, not as an order of execution, because the next section explains why the activities are used out of sequence. This page stops at naming and grouping the eight; the purpose of each individual activity^[3] is a separate objective covered on its own page.

The Version 5 value chain is now simplified^[2], and it is built from these same eight activities, so the two lists are identical and only the framing differs. The lifecycle shows how the eight apply across a product or service's whole life, while the value chain arranges the same eight into value streams to respond to demand. That shared list is deliberate, and it is a favourite exam trap that the final section unpacks.

If the eight activities were a checklist you completed top to bottom, the model would just be plan-build-run with more boxes. It is not. ITIL (Version 5) is explicit that the lifecycle is neither prescriptive nor rigid, and any activity can move backwards or forwards to any other activity^[1]. There is no fixed sequence and no straight line: work can move between any two activities in any direction as needs require. (Here 'move' is the general sense of shifting between activities, not the 'transition' activity, which is just one specific step among the eight.)

Two consequences follow, and both show up in exam stems. First, the activities are used iteratively: they are repeated and revisited many times across a product's life, so feedback gathered while a service is live can send work back to design and then forward again. Second, because there is no single moving pipeline, different versions of the same product or service can exist in several activities at once^[1]: one version can be live and being operated while a newer version is still being designed, exactly the bank-app situation from the top of this page.

This is the concrete meaning of the ecosystem word from the first section, and ITIL names what it replaces. The traditional plan-build-run model was linear and inherently siloed^[1]; in the Version 5 model, plan, build and run work happens simultaneously and draws on all teams at once. The figure below contrasts the two, a one-way plan-build-run line against the Version 5 model where the activities connect in every direction and are revisited. So when a stem describes teams collaborating across activities at the same time, or work looping back from a live service to an earlier activity, the lifecycle's non-sequential, iterative nature is the idea being tested.

Nearly every hard question on this topic is one question wearing different clothes: is this description the lifecycle, or one of its three neighbours, the value chain^[2], a value stream, or the continual improvement model? The overview's comparison table sets the four side by side; the exam-room skill is separating them fast by what each one is for. Anchor on the lifecycle as the whole-life model of how the eight activities apply to every product and service, then reject anything that is scoped to a single product, framed as an operating model, or aimed only at improvement work.

The trap has a signature wording. A stem that offers 'a set of interconnected activities arranged into value streams' is describing the value chain, and 'a series of steps for one particular product or service' is a value stream, yet both get dangled as definitions of the lifecycle. The defence is to anchor on 'whole-life model, every product and service' and reject anything scoped to a single product or framed as an operating model or an improvement guide.

Two more distractors come from older or parallel frameworks. If a list of lifecycle activities reads service strategy, service design, service transition, service operation, and continual service improvement, those are the five ITIL v3 lifecycle stages that Version 5 replaced, not the eight activities. If it reads plan, improve, engage, design and transition, obtain or build, deliver and support, that is an ITIL 4 six-activity service value chain, again superseded. Version 5 names eight, and only eight.

Beyond the definition trap, the recall shapes are simple: list the eight activities in any order; pick the one item in a list that is not a lifecycle activity, where the odd one is usually the value chain, a guiding principle, or governance; or a missing-word stem asking that the activities are used 'iteratively' and are 'not sequential nor linear'. All of it sits in the exam's foundational vocabulary, tested across a 40-question, closed-book paper with a 65% pass mark^[3].