The job of product operations is, as I put it, “PM the PM experience.” This means we need to understand the problems of our community, the outcomes they need and start making interventions to fix them. Often cited projects by the product ops teams include better user research systems, common tools and established feedback mechanisms.
What is often forgotten is which processes and meetings we need to kill to increase our productivity. Sometimes taking something away can provide more ability to move faster.
When I first started as the head of product operations for Cognizant we realized that there were processes that shouldn’t be done anymore. These were accepted processes and meetings that had been around for a while but with dubious value.
In this post, we will talk about why we have processes, how to kill (or modify) one, and finally how we avoid creating bad processes in the first place.
Innovation and product ops
Creative destruction is a term used to talk about the process of economic innovation. All organizations need to allow for the change of their systems to stay resilient and dynamic in an ever changing world. Without this creative destruction we become stuck in a place that doesn’t allow our organizations to grow. We need to continuously reinvent ourselves which requires the dismantling of structures that no longer work.
In the last article, I wrote about making “learning look more like work,” (and the related presentation) we had the council meeting that was meant to provide updates and warnings to management. It had devolved into a status meeting with little discussion. After changing the meeting to be focused on challenges we turned around the value of the meeting for those attending.
To do this we had to blow up the current way of doing the meeting. We had to break apart the different reasons for doing the meeting: feedback, status updates, escalation warnings, and client expansion opportunity discovery.
When we got down to it the real value for associates was to get feedback and help from the leadership team so we simplified the meeting structure to only cover that. There is still a need for the other aspects but we are taking those on individually rather than jamming them all into the same process/meeting.
What are processes good for?
The reason why people create processes is that they want to reduce errors, increase predictability within a system, and make sure the “right” people are involved in a decision. These can be great goals for an organization but they can also stifle the ability for a team to ship really important work.
When you have the wrong process in place it can cause problems inside the organization, for example:
- They slow down teams by making them do something when it may not be necessary.
- They increase silo’ing between different organizations because of process differences.
- They increase burnout of team members by increasing the amount of work.
- They can stifle creative or novel ideas by stopping work on them that doesn’t fit into the process.
The most insidious problem is the last, when the bureaucracy of the org starts to filter out new and novel ideas.
This is often referred to as Dominant Logic or an organization which C. K. Prahalad and Richard A. Bettis outlines in their first paper in 1986:
“The Dominant Logic: a New Linkage Between Diversity and Performance:”
“...dominant logic can be considered as both a knowledge structure and a set of elicited management processes.”
In a later paper by Richard Bettis “The Iron Cage is Emptying, The Dominant Logic No Longer Dominates” he states:
“The dominant logic will likely no longer be appropriate, but managers have a hard time recognizing this. In many cases, if failure is to be avoided, a difficult process on unlearning the old dominant logic must proceed, before developing or learning a new one. In sum the dominant logic is clearly a mechanism of variance suppression oriented toward equilibrium.”
Every process you create can potentially stop a good idea from being executed by the team. This is why for a high-performing team you should always be taking a hard look at which processes are helping rather than hindering the team.
Which processes to kill?
A great example of a large organization finding success in reducing processes is captured in a HBR article about “responsabilisation” at Michelin. They looked at ways to dismantle the bureaucracy that has already been built. Not just for the reasons above but to put the responsibility back into the hands of the people that are directly impacted by the process. They are the ones that are most likely to know what needs a process or doesn’t.
When a product ops person first comes into a team there will most likely be a bunch of processes already there. These processes could have come from the team itself or from the org as a whole.
Deciding where to pick your battles in this case is incredibly important. The level at which you can make change will be directly related to your own ownership over a process and level in the organization (or who you can convince at some level in an org).
You may have a gut feeling that a particular process or meeting is no longer beneficial overall. They can eventually morph into something burdensome even if they were originally helpful.
Asking important questions about how the process fits into the larger organization is the right place to start. Below is a list of questions and answers that should make you consider whether the process (or meeting) is one that is helpful (or not):
As you can see we need to start considering the processes that don’t serve the people doing the work. It is our jobs as product ops people to be the champion of good process for the team.
When considering these processes we should always consider they may come from a genuine place of concern or need. We should approach all of this with curiosity and not judgement. Fear of the future and bad outcomes is what drives most people to create new processes.
Analysis of a process’ parts
Pulling apart a process is important. The times that a process or meeting becomes cumbersome can be when too many needs are attached to it. It tends to water down all of the needs at the same time.
To see the different parts you should ask the following questions:
- What are all of the different goals of this? Could we stack rank them?
- Which of these goals is it currently meeting?
- How would you know if this process or meeting was a success?
- How do you know when it fails?
You should ask these questions not only to leadership but to all of the people on the team. Process should always be about both the benefit to a hierarchy as well as the team. Processes that are only there for leadership will usually be subverted or avoided as much as possible by the team.
Ship a simplified process - or don’t
Once you have identified a process or meeting that should be revised you have two options:
- Pull apart the process or meeting and ship the key part.
- Stop the process or meeting altogether.
Both options will seem very scary to people because we may be missing something or not being as effective as we could be. Stopping the process altogether makes people feel like we aren’t doing the best thing possible. What you need to try is a time without the process. Sometimes simply allowing the team to deal with the problem organically rather than through some process is the best action.
Relaunching a process or meeting with a better defined (and smaller) scope can be a huge help while reducing the risk. When doing this, start small with one team and frame it as an experiment. This allows you to gain proof a new process works or meeting format is helpful. If it doesn’t you can use this opportunity to iterate the process or meeting.
What if you can’t kill a process?
There are some cases where a process exists that isn’t easily removable. They can be corporate policies or requirements due to some type of regulation.
The key to these processes is not removing them but building better preparation for people that are about to embark on those processes.
For example, a real issue for our team today is to get certifications expensed because they require so much additional information in the expensing process. These requirements are documented but not easily accessible. We hope to avoid the pain of constantly rejected expense reports by providing a preparation list so that everyone isn’t caught by the same issues over and over.
There may be times that a process exists to check a box as part of the larger organization. This is where we need to know what the difference between A and C graded work is. If there is no way around a process (for now) you should set lower expectations with everyone that may interact with that process on your team.
For example, we need to provide some amount of performance evaluation or goal setting data to the larger org since that is how everyone is judged. It isn’t fully in alignment with the processes we are using for our own community’s performance evaluation.
In that case we are very clear with the team on what they need to put into each system, which includes reducing the expectations down to documentation of successes in one system vs. building evidence for performance evaluation in another.
The best process is the one that doesn’t have to be defined
As a product ops person, you should continue to be on the lookout for new processes that are being proposed. They can sneak up on a team through a leader asking for a new report or putting a new meeting on the calendar because there is a near-term need.
It is important to stop a new process from being implemented without a clear need for it to be established. You can detect this by a new section of a meeting being added or a document that outlines a new set of steps to get something done.
When you do notice this it is time to slow down the team. Ask the questions you would ask about the outcomes, value, and problems that a great product manager would ask of their customers. We don’t just implement new features when a customer asks for it and we shouldn’t just allow a new process (or meeting) to start with a real need.
A team’s current set of processes and meetings are not set in stone. They are constructed by people like you and me. We should always be considering whether a process or meeting is still meeting the goals that it originally had.
If it does not, we should be ruthless in removing or changing it. As product ops people we need to be very protective of the time that the product people on our team have.
Go forth and destroy!