Certified: The ITIL Foundation Version 5 Audio Course

In this episode, we take a topic that can feel crowded and make it much easier to hold in your mind. When new learners first hear that Information Technology Infrastructure Library (I T I L) includes 34 management practices, the number alone can make the subject sound heavier than it really is. A long list of practice names can start to blur together, especially if you are trying to remember what each one is for before you understand how they relate to one another. The good news is that the current version gives you a cleaner way to think about them. Instead of treating the practices as one undivided pile of terms, you can understand them through two official groups that make the bigger picture easier to follow. Once that grouping clicks, the practices begin to feel less like memorization and more like a map of how an organization works to create, deliver, support, and improve value. That is why this episode matters so much for a beginner.

Before we continue, a quick note: this audio course is a companion to our course companion books. The first book is about the exam and provides detailed information on how to pass it best. The second book is a Kindle-only eBook that contains 1,000 flashcards that can be used on your mobile device or Kindle. Check them both out at Cyber Author dot me, in the Bare Metal Study Guides Series.

A group, in this context, is not a ranking system and it is not a sign that one type of work matters more than another. It is simply a useful way of organizing the practices so you can see what kind of contribution each one makes to the larger story of value creation. Some practices are broader in nature and help the organization make decisions, manage people and knowledge, shape direction, and coordinate important relationships across many kinds of work. Other practices sit much closer to the daily reality of products and services as they are designed, built, supported, monitored, changed, and improved. If you do not separate those two ideas, the practices can feel mixed together in a way that makes them harder to recall. Once you do separate them, a pattern begins to emerge. One group gives the organization wide support and guidance across the enterprise, while the other group stays closer to the direct lifecycle of the products and services people actually depend on. That is the mental shift that makes the list feel manageable.

In the current ITIL framing, the 34 management practices remain largely in place, but they are now organized into two official groups: product and service management practices, and general management practices. That official wording matters because it tells you how the framework wants you to see the work. It wants you to recognize that some practices are directly tied to the management of products and services across their lifecycle, while others support the organization more broadly through capabilities that matter across many contexts. This change also helps reinforce the bigger theme of ITIL Version 5, which is the tighter integration of product thinking and service thinking rather than treating them as separate worlds. When you hear the two group names, do not rush to memorize them as labels alone. Hear them as a clue about scope. One group is close to the flow of products and services, and the other group helps the organization function well enough to support that flow.

General management practices are the ones that help the organization operate sensibly at a wider level. They are not limited to one support desk, one delivery team, or one service interaction. Instead, they help provide direction, clarity, coordination, capability, and control across many parts of the enterprise. When you think of strategy management, relationship management, risk management, project management, supplier management, knowledge management, architecture management, workforce and talent management, and similar areas, you are thinking about the kinds of capabilities that influence a great deal of work without belonging only to one product or one service interaction. These practices help the organization decide where it is going, how it should organize itself, how it understands uncertainty, how it learns, how it develops people, and how it manages important connections with others. They are general not because they are vague, but because their usefulness reaches across many parts of the organization. They give the broader operating environment shape and coherence.

Product and service management practices, by contrast, sit much closer to the real movement of value through design, transition, delivery, support, and improvement. These are the practices that beginners often picture first because they feel more obviously connected to the everyday experience of a service or product in use. When you think of incident management, problem management, service request management, service desk, monitoring and event management, change enablement, deployment management, release management, service configuration management, service continuity management, service validation and testing, or service design, you are in the neighborhood of work that directly affects how products and services behave in practice. These practices help the organization build, run, support, observe, and refine what people actually use. They stay close to operational reality. That is why the group name matters. It reminds you that the framework now treats products and services as part of one connected management space instead of encouraging a fragmented view where delivery, support, and technical work feel detached from the value journey.

A very common beginner mistake is to hear general and assume executive, then hear product and service and assume operational. That shortcut may seem helpful at first, but it quickly becomes misleading. General management practices are certainly important to leaders, but they are not reserved for the top of the organization. They influence work at many levels because direction, relationships, risk awareness, knowledge use, measurement, and talent development matter everywhere. In the same way, product and service management practices are not only for front-line support or technical specialists. They affect planning, design, readiness, communication, and improvement as much as they affect response and recovery. The current two-group model is useful precisely because it is about scope, not status. It does not divide thinking work from doing work, or leadership from execution. It separates broader organizational capabilities from the practices more directly tied to managing products and services throughout their lifecycle, and that distinction is much more useful than a simple leader-versus-operator split. One way to tell which group a practice belongs to is to ask a very plain question about its center of gravity. Is the practice mainly there to help the organization function well across many contexts, or is it mainly there to help manage the lifecycle and behavior of products and services more directly. If the practice is about shaping strategy, handling organizational change, managing relationships, understanding risk, organizing projects, or building workforce capability, it likely belongs in the general group because its benefit spreads widely across the organization. If the practice is mainly concerned with how a product or service is designed, changed, released, supported, observed, recovered, configured, or kept available, it likely belongs in the product and service group. This simple question works because it focuses on purpose rather than memorized placement. New learners do better when they ask what kind of problem the practice exists to solve. Once that purpose becomes clear, the grouping feels less arbitrary and much easier to remember.

Imagine a university introducing a new online advising platform for students. Before the service ever goes live, general management practices help shape the larger conditions for success. Strategy management helps clarify why the platform matters and how it supports the institution’s goals. Portfolio and project management help decide where the work fits among other priorities and how it will be delivered. Relationship management helps the university stay aligned with student expectations, faculty needs, and outside partners. Workforce and talent management helps ensure the right people and skills are available. Knowledge management helps useful information remain accessible rather than trapped in scattered conversations. None of those practices directly fix a failed login or restore the platform after an outage, but without them the organization is far less prepared to create lasting value. That is what makes them general. They influence the setting in which many kinds of product and service work must succeed.

Now picture the same advising platform once it is moving toward live use. Service design helps shape the experience so it is usable and fit for purpose. Service validation and testing help confirm that the platform works as intended before students depend on it during registration periods. Change enablement, release management, and deployment management help new or changed elements move into the environment in a controlled way. Monitoring and event management helps the organization detect important signals once the platform is live. Service desk and service request management help students and staff get help when they need it, and incident management helps restore normal operation when something breaks unexpectedly. Problem management helps investigate underlying causes when issues repeat. These practices are much closer to the product and service itself as it moves through planning, launch, support, and improvement. That is why they belong together in one official group. Their center of gravity is the managed product and service lifecycle.

This two-group structure also helps explain something important about modern ITIL thinking. The framework is pushing learners to stop imagining that products, services, and technical activities live in separate tribes that barely touch one another. Instead, the emphasis is on a joined-up model where the work of designing, building, deploying, supporting, and improving is understood as part of one connected value story. That is one reason the product and service group is so helpful. It tells you to look at those practices together because they contribute directly to the quality, resilience, usability, and changeability of what stakeholders actually experience. The general group still matters deeply, but it supports that value story from a broader angle. It gives the organization its larger capabilities for direction, coordination, learning, and control. When you see the groups that way, they stop feeling like filing categories and start feeling like two views of the same organization doing different but connected kinds of work.

Another misconception worth removing is the idea that the general group is somehow more abstract and therefore less practical. In real organizations, weak general management practices create very practical damage. Poor relationship management leads to misunderstandings and mistrust. Weak risk management leads to avoidable surprises and shaky decisions. Poor project management creates delays, unclear ownership, and strained resources. Weak knowledge management means staff repeat the same mistakes because information is hard to find or difficult to trust. Workforce and talent problems can undermine every other practice because the right skills are missing at the wrong moment. These are not distant concerns. They are everyday sources of friction that shape whether product and service work can succeed consistently. So when you separate the practices into the two official groups, do not turn that into a false contrast between concrete work and conceptual work. Both groups are practical. They are practical in different ways and at different distances from the live product or service experience. The opposite misunderstanding can happen too. Some learners hear product and service management practices and assume they are only relevant after something is already live. That is also too narrow. These practices certainly matter during live operation and support, but they are just as important before launch and during change. Service design influences whether the offering will be fit for purpose. Service validation and testing influence whether important problems are caught before users depend on the service. Release, deployment, and configuration-related practices shape whether change enters the environment with enough control and visibility. Continuity and monitoring influence how prepared the organization is for disruption or signal detection once the service is in use. These practices are not merely reactive. They help the organization prepare, deliver, protect, and evolve products and services across time. Hearing the group name product and service management should therefore make you think of the full lifecycle, not just the moment an incident ticket appears or a request arrives at the desk.

What matters most is not memorizing the groups as two separate piles, but understanding how they work together. A change to a customer-facing service may fail because the release process was weak, which points to a product and service practice issue. Yet the deeper reason may include poor project coordination, unclear risk treatment, weak supplier communication, or limited workforce readiness, which points to general management practice weaknesses. In the same way, a strong service desk experience may depend not only on good request handling, but also on good knowledge management, healthy relationship management, and effective measurement. Real organizations do not suffer from one group while the other group remains untouched. The groups interact constantly. Separating them helps you understand their primary focus, but the real lesson is how they combine to create or weaken value. Once you grasp that interaction, the framework feels far less fragmented. The groups help you classify the practices, but they also help you see the organization as an interconnected whole.

For exam learning, this topic becomes much easier when you stop trying to memorize all 34 names in one flat sequence. Flat memorization makes every practice compete for the same small space in your memory. Grouping gives you structure. You can first ask whether the practice belongs mainly to the wider organizational capability side or to the more direct product and service lifecycle side. After that, the individual practice names have somewhere sensible to live in your mind. This improves recall because memory works better when ideas are connected by meaning instead of stored as random items. It also improves understanding, which matters more than recall by itself. If a question describes a practice concerned with strategic direction, risk, relationships, projects, or people capability, you should feel the pull of the general group. If a question describes the design, deployment, support, continuity, or restoration of products and services, you should feel the pull of the product and service group.

A helpful way to rehearse this mentally is to imagine two connected neighborhoods inside the same city of value creation. One neighborhood contains the practices that help the whole city function wisely, coordinate resources, learn, manage relationships, and make sound decisions across many situations. The other neighborhood contains the practices that stay closer to the roads, buildings, services, and daily operations people directly use and experience. The neighborhoods are different, but they are not isolated. People, information, and decisions move back and forth between them constantly. That image works well because it prevents two common errors at once. It stops you from mixing everything into one undifferentiated mass, and it also stops you from treating the groups as enemies or silos. The city only works when both neighborhoods are healthy and connected. In the same way, the organization only creates dependable value when both official groups of practices are understood and allowed to reinforce one another.

By the end of this discussion, the list of 34 practices should feel less intimidating than it did at the beginning. The current official grouping gives you a simple but powerful lens: some practices are best understood as general management practices that strengthen the organization broadly, while others are best understood as product and service management practices that stay closer to the lifecycle and lived behavior of products and services. That distinction does not reduce the practices to memorization tricks. It gives you a way to understand why they are there and how they contribute to dependable value. Once that pattern becomes familiar, individual practice names stop floating around without context. You begin to sense their natural home, their purpose, and the kinds of problems they are meant to address. That is the real win for a beginner. You are not just learning two official groups. You are learning how to see the framework as an organized, connected system rather than a crowded list of terms.