The importance of knowing ITIL and ITSM at the Product Management

For decades when technology advanced as the new driving engine for companies and global evolution, the separation of the world of projects (PMI, PMBOK, PRINCE, etc.) and the operation of IT services (ITOPS) were visible. Both under the ITSM umbrellas, acting as a conglomerate of governance, processes, and good practices mainly sought and still seeks the best performance, quality, and resilience in what is “delivered” to customers as a technology service.

With the popularity of the agile manifesto, DevOps practices, and continuous project management (technology as a product and no longer a project), it has become essential to merge software development practices with IT Service Operation’s practices. After all, if you manage products, you take care of the incidents your product causes to your customers, right?

The answer is yes. The DevOps model has as a small part of its approaches the responsibility of the team that makes the features the same as solving incidents (you build it, you run it). In this context, how can a Product Manager manage your backlog and roadmap now that in addition to features and innovation we have incidents, problems, and knowledge bases?

That’s the reason that I wrote this article, my dear friend.

The Product Manager needs to understand incident management and knowledge base and some other processes present in ITIL if he or she wants to have a team capable of supporting the product throughout its life cycle.

With each known error, addicted behavior, or failure that follows a pattern, it is important that the squad can create a direction for the first levels of support. So when the customer has a problem, his frontline team can guide the customer. Whether during the tests, in a pilot, or even in production, there is always room to create a knowledge base.

And how do you do that? Using empathy, processes, and a lot of sweat

• Chat with our service desk team; they can show you how customers describe their pains, and how you should drive the creation of your article or KB (Knowledge Base). If possible, provide training sessions on new features and/or take an onboarding with the new crew coming in.
• If you have a digital product downloaded via Apple Store or Google Store, read and classify all the user’s feedback from there. It’s a very important input for the part of the backlog which is dedicated to Ops improvement.
• If you have the chance, listen and talk to customers straight, understand what are the main characteristics of each error, how they see the problem, and how you can differentiate between operational failures and system errors. Feeding your knowledge articles with new ways to describe a symptom improves assertiveness when providing a contour solution or an FCR (resolution at the first calk from users).
• Chat with intermediate levels of support, try to pass on actions that can be performed operationally or with simple commands, so that the incident does not always depend on developers.
• Always have a space in your development cycle to take care of your product’s “OPS”. Whether to deal with incidents or problems, do training, documentation, and conversations with customers.

With these actions, you start some fundamental processes:

1. Creating a knowledge base means empowering the service desk team, which is great for the fastest and lowest cost resolution for the basic issues.
2. Autonomy and driven solutions provided to Service Desk should result in a reduction in the TTR (time to resolution) and this helps a lot in the health of tech teams once they have more time to focus on solving the most complex issue, which doesn’t yet have an alternate solution for it.
3. Fewer calls in your queue mean fewer interruptions during the product delivery cycle, and that is more time and quality on your deliveries.

Once these processes KB * and GI ** begin, all the incidents that you did not kill the root will generate a problem. A problem in ITIL is when you have a system error, it is happening with a high frequency, and/or you have a palliative solution to the incidents.

An analogy:

There is a leaking pipe wetting the kitchen in your restaurant.

An incident solution is to dry the floor every time it starts to get wet, as you cannot close the water now (the restaurant is open and you can’t simply close the water valve).

3,452 Leaking Pipe Illustrations & Clip Art — iStock

The problem’s resolution has the objective of finding the root cause so the pipe stops leaking definitely. And as it’s a longer and more accurate process: it will list, organize and execute all tasks to prevent other pipes from leaking, especially during business hours.
An example also using the pipe: instead of cleaning the floor, the responsible staff will open the wall, search for the leaking spot, fix it, look around to find for possible new breaking points and already replace pipe parts if needed.

Once you find a workaround (cleaning the floor regularly), it’s time to get back with your squad and evaluate what problemas you'll prioritize along with the product features that you have at your backlog.

Now that you undestand a little bit more about:

• avoid incident backlog by providing workaround for known issues;
• prioritize at your product backlog problems that are impacting costumers along with product features that business are asking for it`s crutial for product health (SafeOPS);
• Share knowledge and provide constant feedback to your first level support teams will give your space at your backlog while they provide a faster response to your costumers.

If you want to know more about ITIL and ITSM.

https://www.axelos.com/best-practice-solutions/itil
https://www.servicenow.com.br/products/itsm/what-is-itsm.html
what-is-it-service-management