Certified: The ITIL Foundation Version 5 Audio Course

In this episode, we take one of the most practical ideas in Information Technology Infrastructure Library (I T I L) and place it in the part of service work where people often feel the most pressure to rush. New learners sometimes assume progress means moving quickly toward a large finished result, because that sounds efficient, decisive, and impressive. Yet many service problems become worse when organizations try to solve everything in one giant motion without pausing to learn from what happens along the way. The principle of progressing iteratively with feedback offers a more reliable path, especially in modern digital products and services where user needs, technical realities, and organizational constraints often become clearer only after work begins. It encourages movement, but not blind movement. It encourages learning, but not endless hesitation. It helps organizations improve in manageable steps, gather evidence from real experience, and avoid the kind of expensive rework that happens when teams commit too early to assumptions that were never tested well enough in the first place.

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.

To understand the principle clearly, start with the two key ideas inside it. Progressing iteratively means advancing through smaller, manageable steps instead of betting everything on one large all at once change. Feedback means gathering information from real outcomes, real users, real teams, and real service behavior so that the next step is informed by evidence rather than by hope alone. Together, these ideas create a working style that values learning as part of progress rather than treating learning as a delay that gets in the way of action. That matters because services are rarely improved by perfect foresight. They are improved by thoughtful movement in which each step reveals something that the organization could not fully know at the start. For beginners, this is an important shift in mindset. The goal is not to avoid action until certainty appears, because certainty usually never arrives in full. The goal is to move in a way that keeps learning attached to action so the organization becomes smarter as it goes.

A large part of the value in this principle comes from the fact that rework is one of the most common forms of waste in service environments. Rework appears when an organization has to undo, rebuild, revise, or re-explain work that was already considered done because the original effort was based on weak assumptions, incomplete understanding, or poor coordination. Sometimes the rework is technical, such as redesigning a portal flow that users find confusing. Sometimes it is operational, such as retraining support staff after a rushed rollout left them unprepared. Sometimes it is communicative, such as rewriting notices, clarifying next steps, or rebuilding trust after users feel misled by a change that was not explained properly. Rework is expensive not only because it consumes time and money, but also because it damages momentum and confidence. People begin to feel that effort is being spent twice, or worse, that the organization is changing constantly without actually learning. Progressing iteratively with feedback reduces that waste by making correction part of the path instead of a painful surprise after a large commitment has already been made.

A useful way to hear the principle is to compare it with the opposite approach. The opposite is not simply working in big steps. The opposite is pretending that the organization can understand everything important before real use, real support, and real experience expose what was missed. In that kind of environment, teams often spend months planning a major release, coordinating a huge rollout, and polishing details around a solution they still do not understand deeply enough. When the service finally reaches real users, the feedback arrives all at once and often reveals that the most important assumptions were wrong. The organization then faces a choice between defending the flawed design because too much has already been invested or beginning major rework under the pressure of disappointment. Neither outcome is attractive. The iterative approach is more humble and more practical. It accepts that understanding grows through movement, so it deliberately creates smaller opportunities to learn early, adjust sensibly, and protect the larger service from avoidable disruption.

Imagine a community college trying to improve its digital student services portal before the next registration cycle. Students have reported that deadlines are hard to follow, confirmation messages are inconsistent, and it is often unclear whether a submitted form was received successfully. Leaders want improvement quickly because the portal shapes trust, staff workload, and the overall student experience during stressful moments in the academic year. One option is to redesign the entire portal at once, release a fully reworked experience near the next registration deadline, and hope the new structure solves everything in a single wave of change. Another option is to improve the service iteratively, perhaps by first clarifying the confirmation experience, then improving the deadline view, then refining notification timing, and learning from each step before moving to the next. The second path may sound slower on the surface, but it often produces better results because the organization starts gaining useful feedback much earlier. That earlier learning helps shape later changes more intelligently, which means less rework and more confidence with each improvement cycle.

Suppose the college chooses the large all at once redesign because it seems bold and efficient. Teams spend months discussing features, selecting layouts, coordinating messages, and preparing a major launch for students and staff. The launch arrives, and some things do improve, but students still struggle with one crucial problem the team misunderstood from the beginning. They did not primarily need more information on the screen. They needed clearer sequencing about what to do next and stronger reassurance that tasks were actually complete. Support calls remain high, advisors start inventing workarounds, and the college now has to reopen design decisions that it thought were settled. This is rework in a very real sense. It is not just extra design effort. It is a sign that the organization spent too much time building around assumptions that real feedback could have corrected earlier if the work had moved in smaller, testable steps.

Now imagine the college chooses an iterative path instead. It begins with one narrow but important improvement, which is making submission confirmation clearer and more visible across a few high stress student actions. The college watches what happens, listens to support teams, and gathers feedback from students who now feel more confident that their steps were completed successfully. That does not solve the entire portal experience, but it reveals something important. Confidence and sequencing matter more than the team first believed, and students respond strongly when the service reduces uncertainty instead of merely presenting more content. The next improvement cycle can then focus on deadline clarity and next step guidance with much better understanding of what actually creates value. The college is still moving forward, but it is moving with increasing intelligence. That is what the principle is trying to produce. It is not smaller work for its own sake. It is smarter work through learning attached to action.

Feedback itself deserves careful attention, because beginners sometimes hear the word and imagine it means asking for opinions after something is already done. Feedback is broader and more valuable than that. It can come from user experience, support interactions, service performance, repeated confusion, missed outcomes, team observations, and changes in demand that reveal the service is not landing the way the organization expected. Good feedback is not just noise from whoever happens to speak first. It is information that helps the organization understand whether the current step created value, where friction remains, and what should happen next. In the student portal story, feedback might include support trends showing fewer calls about missing forms but continuing confusion around deadlines. It might include student comments that confirmation feels better but reminder timing still causes anxiety. It might include staff observations that certain messages reduce uncertainty while others generate repeated clarification requests. All of that can shape the next step, making the service stronger through informed adjustment rather than through guesswork.

One reason this principle helps organizations learn faster is that smaller steps shorten the distance between action and evidence. When a team makes a huge change, the amount of new information arriving afterward can become overwhelming and hard to interpret. It becomes difficult to tell which part of the redesign improved the experience, which part confused users, and which part had little effect at all. Smaller steps create a clearer relationship between a change and the feedback that follows it. That makes learning more specific and more useful. The organization can see more quickly whether a choice actually reduced confusion, improved flow, or created unexpected side effects. This faster learning does not mean thoughtless experimentation. It means that the service evolves through manageable cycles of change and observation rather than through long periods of isolated work followed by one giant and risky moment of truth. In practical terms, faster learning is often the difference between a service that becomes steadily more useful and one that spends months moving in the wrong direction before anyone can prove it.

Reducing rework also depends on the willingness to treat early steps as learning opportunities rather than as final statements of perfection. This can be uncomfortable for organizations that prefer certainty, because iterative work requires humility. It asks teams to admit that the first useful version of an improvement may not be the final one, and that this is not a sign of weakness if the approach is intentional and value focused. In the student portal example, the first improvement to confirmations may reveal new questions about reminder wording, advisor communication, or how deadlines are grouped visually. That is not failure. That is the service teaching the organization what matters next. Rework becomes destructive when it comes from pretending certainty existed when it did not. Iteration becomes productive when it accepts that partial understanding is normal and builds a responsible way to increase understanding with each cycle. This is why the principle is so often linked to better learning and less waste. It does not eliminate correction. It makes correction smaller, earlier, and more useful.

A common misunderstanding is that iterative progress means moving slowly or accepting weak results. That is not what the principle is asking for. Iterative progress can actually create momentum more effectively than giant redesigns because it allows people to see useful improvements earlier and build confidence through visible learning. Another misunderstanding is that feedback means giving every opinion equal weight, as if service design should be driven by whichever voice is loudest. Good service management still requires judgment. Feedback is not a replacement for direction, governance, or strategic priorities. It is evidence that helps refine those decisions and keep them connected to reality. There is also a mistaken idea that iterative work is only for technical teams building software. In reality, the principle applies just as much to communication improvements, support model changes, service transitions, workflow redesign, and almost any effort where the organization benefits from learning before it commits too much too soon.

The principle also works closely with several other guiding principles, which makes it easier to see why it matters inside the broader service value system. Focusing on value helps the organization decide which small step matters most instead of making change simply because change feels energetic. Starting where you are helps teams learn from the current state before deciding what should be tested or improved first. Collaborating and promoting visibility make feedback richer because more of the service reality becomes visible across teams rather than remaining trapped in separate groups. Thinking and working holistically prevents the organization from improving one local area while accidentally creating more work or confusion elsewhere in the service journey. Keeping it simple and practical supports iteration by encouraging manageable changes that can be understood and evaluated clearly. Even optimizing and automating benefit from this principle, because automation is far safer and more valuable when it follows learning instead of racing ahead of it.

Consider a second example in a neighborhood health clinic that wants to reduce missed appointments and repeated patient phone calls. Leaders could launch a major overhaul of scheduling, reminders, follow-up messaging, and patient communication all at once, but that would bundle too many assumptions into one large and risky change. An iterative approach might begin by improving reminder timing and wording for one category of appointments, then reviewing whether missed visits drop and whether patients still call with the same questions. The clinic might then refine confirmation messages, then improve instructions for follow-up care, learning from staff and patient experience at each stage. That approach teaches the clinic which changes genuinely reduce uncertainty and which changes merely make the system look busier. It also reduces rework because the clinic is not rebuilding every part of the service at once on the basis of incomplete understanding. Instead, it is strengthening the service through a series of connected improvements that grow more informed over time.

For a beginner, one of the most useful mental habits is to stop asking how the organization can get everything right in one motion and start asking what the next valuable, learnable step should be. That question changes the tone of service work immediately. It does not lower standards or excuse careless design. It simply recognizes that progress becomes stronger when each step teaches the organization something real and useful. If a service team can identify the next improvement that reduces uncertainty, produces meaningful feedback, and supports a better experience without overcommitting to untested assumptions, it is already following the principle well. This is part of what makes ITIL practical rather than merely theoretical. It acknowledges that real services live in uncertainty, and it offers a disciplined response to that uncertainty by combining movement with learning instead of pretending one can exist safely without the other.

By the end of this discussion, progressing iteratively with feedback should feel less like a technical slogan and more like a disciplined method for creating value in uncertain conditions. It encourages organizations to move in manageable steps, gather evidence from real experience, and use that learning to shape what happens next. That makes learning faster because action and insight stay close together. It reduces rework because fewer decisions are locked in before the organization understands whether they actually support the service outcome. Most importantly, it helps services improve with humility, clarity, and stronger connection to the people who depend on them. In modern digital products and services, where needs shift and assumptions often break under real use, that is not a minor advantage. It is one of the clearest ways to protect value while still moving forward. When you hear the principle that way, it becomes much easier to understand why it matters so much in ITIL and why thoughtful organizations rely on it to improve without wasting effort.