How to build and implement process as service

It’s quite common to see product operations, change management and design acting separately as different transformational agents, but if these three forces can work together, the potential for effective change is great.

This article seeks to shed some light on how we can approach organizational changes through these three factors. Although I will not be giving the smallest details on how to execute each of these disciplines, I will leave references on how to leverage them and why they are important.

Let’s begin with a short story…

… about Breno, who’s a dear friend of mine who I’ve worked with in the past. Breno wanted to implement a new process for briefing capture within his team, and although it was a simple change, he would often have to go after the task requesters to get additional information before delegating it to someone - it demanded time to make sense of what was written in the briefing and to correct it.

He wouldn't have it anymore - after 2 weeks of giving things a good amount of thought, Breno planned a new process in a visual collaboration tool and finally moved to program the solution via templates, task management system adjustment and e-mail comms. With that in place, not only would he have better quality of information, but it would allow the team to perform faster.

And everything was going to be perfect... or so he thought.

The first issues came from within the team:

Since Breno didn’t give a heads up about the process change, the team didn’t know exactly how to act.
Should they enforce his new way of working, or is that something Breno should do?
What happens to the ones that are currently under approval, do they reject it or accept it for the time being?
Some fields didn’t seem to make sense to the team and they told Breno they felt the new process didn’t take into account several important points in the briefing, like technical requirements and due dates.
Ultimately, although the team didn’t tell Breno, they felt their opinions were dismissed.

But wait, it gets worse:

The process created a whole new set of problems, due to the fact it didn’t quite link well with the other systems within the company. Multiple errors started to occur once the new requests started to arrive.
The requesters got really mad with the fact they now have much more fields to write - as if the others weren’t enough already - and some of them made no sense to them.
An important field was taken off by Breno because he deemed it unnecessary for him and his team - but it was very important for the PMO... who was also mad when he found out the requests were no longer feeding him the necessary data for Portfolio Management.

Breno was in big trouble.

System thinking

What Breno did was try to change a system or subsystem. But what is that?

Systems, by definition, is a concept that involves elements, the interconnection between those elements and a purpose. And one system can have multiple subsystems that can interact with one another (they rarely don’t).

When we deal with an organization, we’re dealing with multiple systems, with visible and, most often, invisible interactions between themselves. Given our limited mental processing capacity, we tend to isolate those systems to ourselves and solve the problems within those systems only. Even worse, we tend to look at them as linear - increasing input will produce the same proportional output (ever heard about the joke about 9 mothers will produce one baby per month?).

Observing and understanding a system goes way beyond understanding the output it yields. It’s easier because it’s visible, but outputs don’t let you anticipate problems regarding adaptation, resilience and interconnections. To change any system effectively, we have to understand their behaviors, elements and sustainability.

And we do that with mapping and research.

Mapping and research

It’s important to understand how the systems interact with each other and what patterns we can observe. Does a system overflow easily? Why? What causes that? What are the underlying causes? How to make sense of it?

Understanding the elements is quite important as well, like software, processes, structures and even people. People are the most complex and important element to understand within systems because they are generally the ones who enable a system's work. For that reason, that’s one of the “why” we observed an increase in user-centered design methodologies rising in the last 10-20 years.

Within those methodologies, there are several ways to extract useful information from the people element in the systems, like:

Interviews
Cultural probing
“Safari”
Over even having a freaking conversation over a cup of coffee (virtual or not)

During the pandemic, this is a bit harder to do, but given the chance, get out of your chair and go talk to people. Even better, go observe them and learn what makes them tick. You’d be amazed what you can learn from a bit of observation.

In this story, Breno didn’t understand that changing a sub-system within a larger one would wreak havoc on his peers. By considering only the desired output and not talking to people, he didn’t map important relationships, interactions and elements - if that system that Breno changed was a human body, it would probably be dead by now.

Enter service design

What could Breno do, instead?

Remember when I talked about the increase of user-centered design methodologies, in order to take the “human” element into account more effectively? Great, we’re going to use one of them, called Service Design. Why? Here’s some reasons:

Changing a process means changing a kind of system people use to gain some benefit from. It’s basically an internal service we explore to have a specific experience while and after interacting with it.
Service design takes into account the interaction with other systems, elements (read people as well) and dependencies, meaning it has a better possibility of avoiding isolation.
It’s an iterative process, meaning it doesn’t stop at one attempt - you learn as you go, improving as you find the opportunities to do so.

The main advantage of service design is the possibility of leveraging the knowledge of other people and co-creating with them to achieve a more inclusive and efficient result. If Breno involved the team and stakeholders during the construction of the process, he probably would’ve had far fewer problems.

There are several interesting tools to be used in that methodology, like the stakeholder mapping and service blueprint. Let’s start with the first one.

Stakeholder mapping

Very commonly used in change management, stakeholder mapping is a tool that allows the understanding of the position an individual/group has towards a specific subject (in favor, neutral, or against), needs and interaction with other individuals/groups. It can be a visual representation, by interlinking different elements within a system or it can be a detailed spreadsheet, with extra notes.

A lot of people find it unnecessary to come up with this kind of data, but understanding the relationship between different factors and what their expectations are is one of the most important pieces of information to have when designing/changing a complex system.

Service blueprint

This tool is a kind of x-ray of a service or process. After the research, it’s a good way to evaluate the perspective of the involved elements within a system and how it interacts with others.

There are many other useful tools that can be applied in this kind of scenario and it’s well worth it to study a bit more about service design. I recommend this book called “This is Service Design Doing”, by Mark Stickdorn.

What does process resilience mean?

Let’s say Breno did go through the service design methodology this time - had a workshop, made interviews and came up with a process.

“Awesome, let’s implement it right”. Result?

Sure, you could argue that the iterations within service design could make it better... but what does better mean? What’s the criteria? Knowing what you need to measure to deal with the right problems, at the right time.

Say that after Breno implemented the process, the first finding he has is that even though he’s able to get better details for the briefings, requesters are still complaining about the velocity the team is taking to reply with a proposition. Now what?

Every system behaves according to two factors: stock, which are the elements of the system that can be accounted for at any given time; and flow, which is the change of stock over time. In Breno’s case, the stock would be the number of briefings, people in the team, available useful working hours and others. What about flow? It would mean the number of briefings over time.

In the ideal world, these stocks would stay at a certain constant number, meaning there’s always work to be done and the quantity is under control. A constantly decreasing number, however, might mean that Breno’s team could be overstaffed and someone will be empty-handed in the future; constantly increasing, the team is probably understaffed and will face an avalanche in time.

From this case, you probably can already guess some interesting criteria or metrics to start figuring out if the process (or system) is healthy or not:

Team velocity;
Quantity of briefings incoming over x time (system input);
Quantity of briefings delivered over x time (system output);
Average development briefing time;
Team size;

There are many other possible KPIs, but looking into these will give some insights on what to act on and adapt in order to make the system strive towards its purpose. Agile frameworks provide some interesting metrics to gather team insights and possible solutions. However, like any framework, those should be adapted to the team reality, rather than being enforced as a rule.

There are some great references about operations management, metrics and product operations:

“Matching Supply with Demand: an introduction to operations management”, by Gerard Cachon, or this Coursera course.
“Measure what matters”, John Doerr.
The Product Ops Portal

What does a healthy system look like?

When we think about systems, one book comes to mind - “System Thinking: a Primer”, by Donella Meadows. In her book, she describes what a healthy system should be like:

Resilience - there can be times when your system will have greater input and will need to have a strategy to deal with it. Does the system break when under heavier stress? That’s one of the moments when you find out if your proposed process is resilient or not;
Self-organization - if Breno went out for a vacation, would the system work by itself? Can people adapt and self-organize? If the system breaks easily or can’t adapt itself when an element is missing, it might mean it needs to improve its adaptation.
Hierarchy - are they solving the problem in the right stream? If something that should be a manager’s responsibility goes to the team, are they able to identify it and say no? If the system is solving problems too small or too big for it, it will probably present problems sooner or later.

Remember, a system has a purpose. We need to be able to measure if that purpose is being achieved and what factors are influencing that. KPIs and Metrics are an important way to understand if it’s doing so and provide insights for the right adjustments.

Change management... or empower your leaders

Change management is about this: your brain is a jerk. It’ll do whatever it can to save energy and give us that sweet feeling of “comfort.”

So Breno now has a process that he co-designed with his peers and team. He’s also able to measure it through established KPIs and metrics, after some trial and error. He presented a beautiful dashboard to his director he made on Klipfolio and it even sends automated reports via email.

So now everything is perfect, right? Nope - some requesters downright refused to use the new process, saying they didn’t agree to this. Also, some of his team members weren’t using it, since they didn’t understand why it changed so much, and are sticking to the old ways of working.

Implementing change is tricky - most people will only accept change if they understand the value of it, for themselves and for the company’s purpose. You could say that people directly involved in the co-creation will support it, but what if you can’t involve everyone, quite common in big organizations? Did you ever try to make your son or significant other do something they don’t want or agree to? Most people, in those situations, try to impose it, threaten and even apply penalties in order to achieve the necessary outcome.

Seeing that scenario, researchers and specialized companies have been working on a discipline called change management, which is about giving leaders and employees the necessary tools to be able to navigate through transitions occurring within organizations. It’s not a way to force something down people’s throats with sugar, but a way to help people cope and manage the consequences of a transition.

There are several methodologies and frameworks for change management - most of them created for corporate environments and very well structured - that propose several step-by-step ways to lead the transition within your organization. Although worthwhile to learn and even do some training, most change management frameworks go a bit like this (extracted from Harvard Business School):

Prepare the organization for change

People need to understand what’s happening in the current context to realize the need for change. Awareness and buy-in are the most important parts of transition - most of the time, leaders are included as well and you might need help from higher places.

Craft a vision and plan for change

Sure, it can be downright simpler to just yank the change into our software and call it a day - but the reality is more complex than that. There will be implications and consequences we might not be aware of. Who should be involved? Do leaders know their role? What do we do when roadblocks arise? Planning ahead and setting small steps towards a change, so we can have a better width of adaptation is easier than dealing with a whole sea of problems all at once.

Implement the changes

This means giving the employees the means and power to take the necessary steps to achieve the end state of change. The organization’s role, with its leaders, is to communicate, assist and guide their teams during this transition. Change is done and executed by the teams, not its leaders.

Embed change within company culture and practices

It is normal for us, humans and animals, to go back to things as they were. Our brain is lazy and hates to change things. For that reason, we need to be able to start incorporating these changes into the company culture and reinforce them for some time, until they become natural. Some even recommend using a reward system, changing the organizational structure and other ways to incentivize the transition.

Review progress and analyze

More metrics! Some change management frameworks propose a way to measure if the change itself is going well and it is successful, like adoption rate and velocity. Just don’t forget the important metrics which are if the change is actually achieving the proposed goal.

Who’s responsible for change management and how do you get good at it?

Changes need to be led by the organization's leaders, it’s better by small steps and resistance is natural. You can even do it through iterations and experimentation, but don’t try to do it alone. There are some great reads about that kind of discipline like:

Any Prosci book about change management. “ADKAR: A model for change management”, by Jeff Hiat is a great start.
“Switch: when change is hard”, by Chip & Dan Heath
“Leading Change”, by John Kotter
“Lean Change Management”, by Jason Little.

Last considerations

In a very visual way, what I mean is this:

You set your mind to understand that you are working within a system that probably interacts with several others.
Do your homework to understand its elements, interactions, people and what it’s trying to achieve.
Co-create, through design methodologies (I recommend service design), taking into account any process or internal system is actually a service that people use to gain some benefit from it.
Measure the right things and understand how well your system is resilient and flexible.
Implement by understanding our brains are natural lazy jerks and help people transit/lead through change.

Developing and implementing processes is hard work and something you won’t figure out by yourself. Be sure to involve the people this service will benefit and work together to refine it to a point of maturity.

Looking for more inspiration and insights on all-things product operations? The Product Ops Portal is where you need to be.