ITIL Foundation Version 5: Managing Digital Products and Services

Digital products and services often form a single experience for their customers. A bank's mobile application, for instance, is not just software supported by an IT department: its features, security controls, operations, customer communication and continual evolution jointly determine whether people can manage their finances reliably. ITIL Foundation (Version 5) reflects this integrated view by emphasizing digital product and service management through the lifecycle. It continues ITIL's service value orientation while expanding the vocabulary for product-centered decisions and the experience of people using digital services.

PeopleCert currently offers ITIL Foundation (Version 5) as its current new Foundation entry point. Its official examination lists 40 closed-book multiple-choice questions, 60 minutes and a 65% passing score. The same provider still lists ITIL 4 Foundation, which is a separate syllabus and qualification from Version 5. PeopleCert also offers an ITIL Foundation Bridge (Version 5) route for people who already hold ITIL 4 Foundation. Candidates should use the requirements and learning materials for the exact exam they purchase; a foundation credential alone does not make every later specialist module interchangeable.

Think in terms of products, services and their lifecycles

A digital product can contain capabilities that evolve over time, such as a payment application's authentication, ledger access or notifications. A service is the means through which the provider helps a consumer achieve an outcome. In practice, the same capability may be both part of a product roadmap and part of an operational service experience. The Version 5 perspective encourages coordination rather than a transfer of responsibility from a product team to an operations team at a fictional finishing line. Discovery, design, construction, transition, operation, delivery and support are connected concerns, with feedback circulating among them.

An organization should not judge product management exclusively by the number of features shipped. A new search feature may produce a faster application but poor results; a security control may be robust yet prevent legitimate users from completing a task. Customer experience, reliability, responsible use of data, cost and sustainability can all affect the value delivered. Teams need to define the intended outcome before selecting a release metric. If the outcome is faster customer issue resolution, the relevant measures may include task completion, accuracy and customer effort, not only deployments per month.

Lifecycle thinking recognizes that maintenance and retirement are design responsibilities. A new service should have clear ownership of security updates, dependencies, capacity, recovery, documentation and eventual migration. Product decisions can have multi-year operational consequences. A team selecting a proprietary integration without an exit plan may accelerate launch but increase long-term supplier dependence. The exam's conceptual material should be interpreted through these trade-offs rather than as permission to treat every application as a self-contained product independent of its users and supporting services.

Explore value co-creation and the service relationship

Value emerges from interactions between providers, consumers and other stakeholders. The provider supplies capabilities, but the consumer contributes information, decisions, work and context. An online university may deliver a learning platform; students still need accessible devices, suitable connectivity and guidance. The provider must make those dependencies visible and avoid claiming that a system is valuable merely because it is available. Service relationships include consumption, provision and ongoing management of expectations, costs and risks.

Utility and warranty remain useful distinctions. Utility concerns the functions and outcomes a product or service makes possible. Warranty covers assurances such as security, reliability, capacity and availability. A sophisticated AI-based customer assistant has poor utility if it cannot resolve a common request accurately. It has inadequate warranty if service access collapses during peak demand or customer data can be disclosed. A sensible design balances functionality and dependability instead of treating quality as an afterthought. The same balance applies when teams negotiate service levels and decide which experiences matter most.

Risk is not owned solely by a security team. Product choices may expose users to privacy, accessibility, financial or operational harms. Decision-makers should understand which risks are retained by the consumer, which are handled by the provider and where partner dependencies create shared work. Sustainability also affects longer-term choices, from infrastructure consumption to maintainability. This broader view is useful when selecting between superficially similar solutions: the cheapest immediate output may not provide the greatest sustained outcome.

Apply the four dimensions and the value system together

ITIL Version 5 retains a holistic view through four dimensions: organizations and people; information and technology; partners and suppliers; and value streams and processes. A change in product direction may require staff to acquire new skills, a supplier agreement to be revised, data handling to be redesigned and an operating workflow to be updated. None of these consequences can be solved by merely rewriting a diagram. The dimensions help teams ask whose work changes, what information is needed and what services or dependencies could fail during transition.

The ITIL Value System connects opportunities and demand to outcomes through guiding principles, governance, value chain activities, management practices and continual improvement. Governance gives direction and oversight; teams use practices and activities to carry out work. Value streams are practical combinations of activities appropriate to the situation. A service recovery flow differs from the discovery and launch of a digital product, even if both need engagement and improvement. Candidates should understand how flexible combinations work rather than search for a single mandatory sequence.

Guiding principles provide guardrails: focus on value, start where you are, progress iteratively with feedback, collaborate and promote visibility, think and work holistically, keep it simple and practical, and optimize and automate. For a public agency modernizing a citizen portal, starting where you are means evaluating successful existing interactions and the constraints of legacy identities. Progressing iteratively may mean piloting a simpler claim submission with one user group before broad rollout. Collaboration and visibility ensure policy owners, accessibility specialists and engineers can identify conflicts early. Automation should follow an understanding of the real process, not replace that understanding.

Read a product-and-service lifecycle as a series of decisions

Discovery asks which needs deserve investment and what evidence supports them. Design determines how the proposed capability can meet those needs within constraints. Transition must prepare people, services and control arrangements for change. Operation and support keep the experience dependable while capturing insights for further development. Delivery connects the product's capabilities with stakeholder outcomes. The lifecycle is not simply the traditional linear handoff from analyst to developer to support operator. Good feedback may send teams back to discovery when user behavior reveals a misunderstood need.

Value stream mapping can expose the actual time and effort required to move from demand to outcome. Suppose a customer opens a digital bank account in ten minutes but must wait five days for a manual verification step. Optimizing the app's form from ten minutes to eight minutes will barely affect the total wait. The value stream perspective identifies the controlling constraint. The improvement effort may require better information, a revised risk decision or changes to partner interactions. It could also reveal that some manual verification is necessary and should be made clearer to users rather than eliminated at the expense of security.

This approach is also relevant to incident response. When a product fails, the provider needs monitoring, well-understood dependencies and meaningful communication. If the login feature is unavailable, the team should distinguish a product defect from identity-provider failure, respond to affected users and improve the recovery design. The same product people who decide new features should understand recurring incidents, while service teams should contribute evidence about the cost and reliability of proposed changes.

Work with management practices rather than around them

Practices such as incident management, problem management, service request management, change enablement, service level management and continual improvement provide operational capability. They are not interchangeable. A user request for a permitted account role is routine fulfillment; an unexpected outage is an incident; repeated outages may point toward a problem requiring analysis. A new deployment needs risk-proportionate change consideration and a dependable transition. Combining these practices thoughtfully creates a better experience than a rigid ticket process that fails to reflect the type of work being done.

Service level management is effective when it describes outcomes customers recognize. For a telehealth service, average platform uptime may be less informative than whether scheduled consultations start on time, connections remain stable, and affected patients receive timely alternatives. Information security and supplier management influence these measures because user experience depends on trusted information and external services. A good governance decision recognizes that measures are proxies and investigates whether they encourage undesirable behavior.

The Version 5 learner should therefore practice following a scenario across the lifecycle. Identify the users, the intended product or service value, the four-dimensional dependencies, the activities contributing to the value stream and the management practices needed for reliable operation. Revisit what an improvement would change for the user, not simply for the dashboard. For holders of ITIL 4, the official Bridge route can focus study on the changed material; for new candidates, Version 5 Foundation supplies the complete framing from the outset.

Prepare for the specified Version 5 outcomes

Use PeopleCert's official current Foundation (Version 5) materials and mock examination rather than assuming an ITIL 4 question bank covers every objective. Study the product-and-service lifecycle, service relationship concepts, four dimensions, the Value System, guiding principles, practices, value stream mapping and continual improvement as connected ideas. Build examples from a mobile app, a cloud service and a public-facing service to see how the same principles lead to different practical choices.

The goal is not to replace professional judgment with terminology. A useful foundation graduate can ask what outcome the consumer seeks, who must collaborate to deliver it, how the organization can detect failure, and what evidence would demonstrate improvement. That is the difference between learning names for activities and learning to manage digital products and services responsibly.