How product processes fail and what to do about it (with Miro's Head of Product Ops)

Product decisions always regress to the 'average' level of an org, so its culture and processes set the whole org for success or failure. How do we ensure that product processes actually work?

I have avoided a lot of product processes in the companies where I worked. These were the processes that someone spent their time designing, implementing and enabling with the hopes of achieving org-wide outcomes. 

Now, as a product leader who leads (and manages) PMs and people in other roles and introduces new product processes (and removes old ones), I feel the dilemma. Here I am, designing a process to solve an issue or help us build a lacking capability. And no matter what, some processes would decay as days go by. Compliance with a process or quality of process completion would decrease with time. 

Trying to understand the why, the how and the “what to do about it” led me to a few crucial conclusions. 

When product processes fail

A basic supposition is that a process needs to be followed. When a process is followed, it should lead to an expected outcome. 

The process failure is, then:

1. When it is not followed

2. When it is followed, but the actual outcome differs from the expected outcome

An outcome being ‘good’ or ‘bad’ solely depends on whether it deviates from the expected outcome. If it does, then it is ‘bad’. If it does not, it is ‘good’. Yet, I don’t think that applies to product management and product processes. 

Let’s examine why either can happen and why product management is ‘different’. We’ll start with the second failure type and then move on to the first one (which is more practically oriented). 

Just enough processes

The rise of the Product Operations function (heavily criticised by product titans such as Marty Cagan) led to a new wave of process-related work in many product-led organisations. 

On one side of the spectrum, there is a belief that if we had processes for every part of the product work, we would have a strong product organisation. On the other side, there is a belief that no process is useful, some are harmless or a necessary evil, and true achievements are related to product teams that find their own way. As always, neither absolute is true. 

Have you ever had to follow a process in your product organisation? Unless you work in a two-person startup, you had to. But is it the right word to use?

I avoid the word “process” because it is still perceived as a heavy burden that slows progress. The current economic climate calls for high velocity and efficiency. Companies want to streamline the work and ensure that internal processes are efficient and effective, and excessive standardisation is rarely helpful there as it often leads to bottlenecks. 

Instead, I use “ways of working” or “freedom within a frame” to describe how we do certain things in our company. It sets the right tone – there is an expectation for how you work that aligns with the company’s needs but removes the focus from utilising a standardised, generic approach with many steps. For “freedom within a frame”, it is also important to define both “freedom” and “frame”, but this naming communicates a very similar principle – we provide guidance and expectation, yet ultimately you can adapt based on circumstances.

Ilia Tregubov, Head of Product Operations @ Miro.com

Product processes ARE NOT for standardisation

Processes (and process optimisation or operational excellence) were popularised due to improvements on the manufacturing floor. One of the earliest ‘classical’ examples of a process was written by Adam Smith (an 18th-century economist), who described the production of a pin as a sequence of steps that have to be carried out by different people doing different types of work. 

When discussing processes in the product management context, we use manufacturing processes as an analogy and seek opportunities to ‘standardise’. After all, standardised, error-free work on a factory floor leads to a fast delivery cycle and minimal waste, or so it goes.  

Yet, in product management, optimising product work (including discovery work) through a set of mandatory steps to achieve faster delivery or minimised waste sounds wild. While a pin factory produces precisely the same pins day after day, product people make unique decisions at the same pace as pins are created. 

The difference between junior and senior product people is their ability to adapt to circumstances and context and find a way to solve a novel problem. When working on a product, both will go through delivery and discovery. Still, the nature of discovery and delivery work will depend on the type of problem they are addressing, the kind of product they are working on, their goals, the time available, and other factors. 

Both junior and senior people will follow the same process, but they will make different decisions. A truly standardised approach means that there’ll be no difference in the outcome, yet there is. 

Process anarchy, then? Not so fast. 

Why do we need product processes if not for standardisation?

Let's work backwards from existing processes to understand their value instead of generalising why, how, and when product processes are useful. As the same process can be extremely valuable in one organisation and completely dysfunctional in another, let’s simulate both situations. 

Product Requirements Documents and PRD review process

One of the most common and (when done right) beneficial practices is writing PRDs and getting them reviewed by different people in the organisation. PRDs typically contain information about feature context, problems/needs/opportunities, solution design, implementation and launch plans. PMs and teams must crystallise their thoughts and logic behind each decision. 

Both lists are not meant to be exhaustive. 

To summarise... A good PRD review process leads to higher-quality decisions, more robust logic and evidence behind each product experience, and significant inter-team and leadership alignment. A bad PRD review process leads to ownership diffusion, low motivation, and experiences that resemble Frankenstein’s monster through compromising and “uninformed exec” decisions. 

Where does the difference come from?

In a PRD review process, we have:

1. Process itself 

2. Artefact (PRD) and its template

3. PRD writer

4. PRD reviewers

   1. Peers

   2. Leadership

All of these could explain the differences in the cases above. Let’s quickly jump back to the manufacturing example. In it, working on a particular detail (e.g., a car part) requires a set of steps that have to be repeated. Within these steps, there is no variation (painting a door will take the same steps each time, leading to the same painted door unless an execution mistake is made). 

In a PRD review process, we similarly have a set of steps. Following these steps will formally lead to the same outcome – let’s say, an accepted/rejected PRD. The variation in the quality of PRDs (and the resulting impact on the product experiences you build) will be huge, though. What we want to achieve with the PRD process (as outlined and compared above) is better decisions, not formalised documents (or even go/no-go decisions). 

You could argue that the PRD review process (including writing PRD) is a high-level process and should be broken down into sub-processes. We can jump to lower and lower levels. At some point, we should hit a level where a consistent set of steps leads to consistently similar (in terms of quality and impact) output, such as ‘validated problems’. No matter how many books were written and courses recorded, no one could create a set of activities that could guarantee a specific result. Some companies do it better than others because of their culture, the people they hire (highly skilled in particular areas), internal development opportunities, internal knowledge bases and ability to quickly run any initiative, yet it is far from universal.  

OK, let’s return to the four components I outlined above when questioning where the difference between good and bad PRD processes arises. 

So, the process itself could be a problem. You can specify who reviews PRDs, who has decision-making power within each PRD, how comments are collected, what the SLA is to provide opinions, etc. The complexity of the process will grow with each introduced parameter, and cumbersome processes will be the least adopted. The process itself is rarely a problem because there is so much expertise to copy that most inefficient processes rarely proliferate. Unless an inexperienced person created the process or copied it from a structure that doesn’t resemble yours (e.g., big tech processes in 100-person startups).  

The artefact template can similarly be broken down into multiple templates: a template for big initiatives, a template for small ones, a template for technical features, a template for growth experiments, a template for NPD initiatives, a template for UX initiatives, a template for… 

It sounds way too prescriptive, even when you have tens of thousands of employees or more. You are making a centralised decision on how to do things that are best done as adaptations to each situation. You’ll never have all these templates that cover all situations and lead to the best possible outcome. These templates are still helpful for mature organisations – it is much easier to start something in a new area when you have some guidelines to rely on. The guidelines should not replace thinking, though. Spoiler: that’s exactly what “processes” are in tech product management. They are guidelines. 

The people (writer and reviewers) create significant variations in the success of the PRD review process (or, instead, the success of the experiences that arise from these PRDs). 

Someone who creates crisp PRD where each decision can be clearly traced back to some kind of evidence (from direct insights of user research/data analysis to strong logical argumentation), and someone who writes bland, chaotic rumbles will have completely different outcomes from the PRD review process. 

Reviewers, including leadership, point out and prioritise certain things in the PRD. They provide opinions, guidance, and advice based on their perceptions, insights, and data. Some reviewers exclusively use their judgement or credentials of ‘knowing how things work due to extensive experience’, while others rely on the underlying logic of the decision and dissect arguments and evidence. These comments will also significantly impact how PRDs are written and edited.

The last point is also related to organisational resilience. The PRD process we use as an example prevents outputs below the average level. The problem is that even if you adopt Miro’s PRD review workflow and Intercom’s PRD template, neither will set the average level. The average level of outputs will be defined by the skills and the approach of PRD writers and reviewers. 

Product processes reflect the culture

Company culture, product org maturity, skill level of product people and leadership, personal motivation and mindset of each person will have an outsized impact on any process, not only the PRD review process example above. 

Strong cultures can prevail over individualistic differences. A functioning culture with expectations for solid evidence and low acceptance of ‘personal opinions’ (vs. data/insights/logic) will penalise people who don’t fit that description until they change their ways or leave. And if the culture has neither, a PRD section related to problem/opportunity validation will be gamed to no end and reviewed mindlessly. 

Strong-willed individuals with extensive experience working in these cultures will be able to drive the process on their backs, but not for the whole company. This is a good start, yet there needs to be a systematic solution (getting enough of these strong-willed individuals could help remake the culture). 

You can judge a company by its product processes. If a company talks about innovation, speed and efficiency as its values but expects its product people to produce detailed step-by-step requirements, build waterfall timelines or discuss executives’ opinions on mockups, there is a clear conflict. 

How fast do people move at the company with their initiatives? How focused are people on solving customer problems? How concise are internal documents, such as PRDs? These questions not only outline the organisation's current maturity level but also give you a glimpse of how much internal inertia you will need to overcome to build modern, outcome-based ways of working.

When there isn’t a lot of inertia to overcome and the culture is not resistant to change, improving product processes is similar to building a product: discover problems, brainstorm and iterate solutions, run beta programs, enable the commercial part of the org, set clear targets, and do a post-launch analysis. When you do that collaboratively and transparently, you get stronger buy-in and a desire to contribute from all product teams.  

Ilia Tregubov, Head of Product Operations @ Miro.com

The company or product org culture comes from leadership. While organisations evolve and adapt, they are still an extension of leadership’s mindset and culture. In the simplest form, a company’s culture reflects what is prioritised most often and the behaviour the most visible people exhibit. 

At the outset, I operationalised product process failure as either the process not being followed or the process being followed but leading to outcomes different from expected ones. 

The second failure type is not necessarily a failure but rather a feature. As the product work can’t be standardised to the degree required to hit expected outcomes with minimal variations, the actual value of product processes is not in standardisation. It is in raising the bar on the quality of decisions through transparency, alignment, and feedback cycles. All of that is highly dependent on the product organisation’s culture, leadership mindset, and individual skill levels. 

The conclusion and consequences are simple:

1. If you are an IC, you must work in a strong culture / with solid leadership. You are damaging your learning and career when you don’t. “Solid” is a fuzzy word, but you can use indicators from the cases above to differentiate strong from weak. 

2. If you are a leader, you must carefully weigh each sentence you say and how you say it. You must carefully weigh what you prioritise, what you provide feedback on, and what behaviours you show publicly. Build a culture people want to work in and support this culture with processes and people decisions. 

I have not yet covered the first failure type – processes not being followed. Let’s do that next.

Why product people don’t always follow processes

All systems evolve and become more complicated as time passes. Unless someone proactively keeps that organisational complexity at bay (by removing unnecessary parts), it will just increase and become even more prominent. Like cancer, organisational complexity doesn’t suddenly stop by itself. In a more practical sense, it means that someone should be removing or simplifying processes as time goes by, and these tend to accumulate regardless of whether we need them or not. 

Let’s analyse why the processes may not be followed through a simple lens:

1. Know – people need to know about the process and what needs to be done to follow it

2. Can – people need to be able to follow the process (skills, access, time, etc)

3. Want – people need to have enough desire/motivation to follow the process (see it as beneficial or fear negative consequences for not following it)

4. Do – people need to actually follow it (this category is not applicable in our case)

The scheme above isn’t meant to be exhaustive. The specific items that most influence compliance with product processes are bolded. 

Know – lead periodical enablement sessions

People need to know about the process and how to follow it to actually follow it. Yet, as more people join our organisation, we often expect them to ‘get it’ naturally or pick it up by emulating others. Enablement during onboarding and periodic re-enablement is essential to ensure that people know enough to follow the process. It also allows the process owner to collect feedback on the necessity and design of the process. 

Can – simplify and enhance the easiness of the process

Ability and friction, which could be merged under one term, relate to what helps people follow the process and what prevents them from doing it. Simple templates and shortcuts to utilise them are the most basic form of enhancing the ability level to follow the process. 

Factors like time investment and stakeholder involvement reduce process compliance and create a risk for errors within that process. Like with product experiences, any friction is a barrier that must be overcome. Sometimes, the person might not have enough motivation to overcome that friction, so removing unnecessary steps, approvals, touchpoints and updates will make it easier to comply with the process entirely. 

Want – focus on negative consequences

Without going deeper into motivation, consider two key components: benefits a person will get for following the process and punishment for not following it. 

It is difficult to influence the positive part. You can highlight existing benefits or create new ones. Typically, processes help the whole organisation or a subset of people, so direct benefits to one person in one particular situation may be minuscule. On a scale, though, they will generate extensive value. That is not easy to translate into how it helps the person right in the moment.

The negative consequences, though, are interesting to consider. The “broken windows theory” speculates that people tend to engage in crime and antisocial behaviour when they see visible signs of it in their environment. A classic example is New York’s Tube, where the local government continuously invested significant resources to remove graffiti from trains. The theory attracted spectacular debates and research, with some institutions finding empirical support for the main proposition. 

If the theory is transferable from crime to other aspects of life (and true), we could speculate that when people around us don’t follow processes and do not get negative consequences for it, we start thinking that it is fine not to follow the process. Humans grow, learn, and live by imitation. 

Managers must support the processes, spearhead their adoption, act like shepherds and reiterate the collective benefit. Failure to follow processes should result in negative consequences (at the very least in the form of warnings), and the importance of specific processes should be highlighted publicly. However, a manager can’t pick and choose which particular processes are must-have and which are nice-to-have because it will create organisational chaos. Instead, “nice to haves” should be provided as additional guidelines. 

Managers and leaders (who set expectations by exhibiting specific behaviours) must also follow the same processes to signal their importance. 

It's important to remember that even if your operational teams are driving new ways of working, the positive outcomes will only materialise when leadership is accountable for these changes. 

The classic dilemma (and resulting tension) exists in many tech companies because of misaligned incentives. A simple but illustrative example starts with an operational team (think: PMO, Product Ops, Ops Excellence) driving changes in “how” product org works. Product teams adopt these new guidelines and rules. Yet, the leaders often try to bypass the new rules and approaches for various reasons, such as saving time by avoiding something the whole organisation considers important. The motivation of a leader in that situation is easy to understand – you’d rather get what you want earlier than later. However, it shows the teams that leadership doesn’t consider the process important. People imitate their leaders and take cues on what’s important and what isn’t from leaders’ behaviour. An obvious breakdown of the process follows. 

The same problem appears when only a part of the leadership team adheres to the rules. This sends mixed signals to other teams and leads to internal conflict. Making leaders accountable and responsible for driving change and guarding new ways of working is critical in achieving adoption of new ways of working.

Ilia Tregubov, Head of Product Operations @ Miro.com

Do – focus on triggers and forcing functions 

All activities are triggered by something. Behaviour can be triggered by internal desire (hunger triggers us to go into the kitchen and check the refrigerator) and external stimuli (someone asking us to send a specific document).

When we design a system or a process, we are responsible for ensuring it is followed and used. The same goes for building the product for users. We don’t blame users for not using our latest feature. We blame ourselves for creating something they don’t need or in a way they can’t use or understand. 

Similarly, saying that “people don’t follow that great process that I designed” is a glaring red flag for a lazy manager or operations person who tries to push responsibility from themselves. 

Triggers and forcing functions are your two best options when it comes to the “Do” part of our scheme. Given that triggers were explained above, let’s review examples:

1. Notifications as proactive triggers. For example, an automated Slack message “Send your updates today by 12:00 pm” that tags the specific group responsible for the updates.

2. Statuses as reactive triggers. For example, the status “needs review by XYZ by DATE” in the table of all initiatives can trigger a person to start the review process if there are negative consequences for missing the date. 

These are just two examples of possible triggers. 

Forcing functions are similar to triggers and can be considered just a sub-type. The forcing function is a mechanism that prevents the process from not being followed. 

Soft approvals. For example, a product team can’t start working on a product experience unless explicit approval on a PRD is granted. This doesn’t actually prevent the team from starting; it just says that it is not advisable (as rejection means waste). Hence, “soft.” 

Hard approvals. For example, automatically cancelling a meeting that doesn’t have an agenda or fulfilled agreements. As it happens automatically, it is the “hard” form. In this example, though, there should be clear negative consequences for the meeting cancellation. 

Follow-throughs. When the output of one process is used as input by another process or person, it adds additional pressure on the person responsible for the first person. For example, a team needs to provide async updates in their area, and these updates are then used by someone else to build an internal weekly letter. 

Building product processes the way we build product experiences

We must design, implement, enable and support product processes as we do with product experiences. When working with or designing processes, many people assume that a written process has to be followed and will be followed. 

This assumption often doesn’t hold. Just as product users need to discover and understand new product experiences and their value, product people need to discover and understand new product processes and how they will benefit them. As mentioned above, this is, too, the responsibility of a process owner. 

Product processes are less glamorous than direct product work. In many organisations, they become an afterthought. Only a rare organisation has a product leader who deeply considers these processes or a separate Product Operations team that takes care of them. Still, even in these organisations, some anti-patterns can arise. 

Process design

Processes are often designed without considering the limitations, priorities, and motivations of the people who are supposed to follow them. A process designer, be it a product leader or product operations manager, thinks of the ideal flow to achieve a specific output or outcome. Yet, this approach can be far from ‘the ground’ and may lead to alienation, inefficient processes, and other negative consequences. 

There are reasons to push through. For example, if you are building a new or lacking capability in product managers, pushing a specific process that addresses it directly makes sense for the organisation, even though it is not something that ‘people need’. Maintaining that balance and deciding how to approach process design will take another post to outline. 

Process implementation, enablement and support

Ideally, you should get feedback and identify the potential consequences of a new process before proceeding to this stage. It’s OK to accept the process's downsides, but it’s not OK to not understand them. The decision to start implementation must be made with a full view of consequences, including negative ones. 

Typically, implementation starts strong – kickoffs go smoothly, you quickly identify and solve minor issues, and product people seem to share in the fun. After the initial wave passes, the regular routine takes place. The attention the process initially gets fades away, and it becomes part of the new normal. Yet, quite often, it doesn’t, or it becomes so but in an unexpected form. 

Leaders responsible for processes must continuously evangelise and advocate for these processes. Making them part of the onboarding, providing office hours and advice on their implementation, and proactively reaching out to people following these processes is not a nice-to-have; it’s a must-have. And it is much more work than just designing a process—as it should be.

As in the product lifecycle, processes can (and should) also reach maturity, where they are maintained but no longer improved. Enablement is still essential. However, other options are present and should be considered. Should the process still exist, given the changes that have happened since its introduction? Should it be changed to address new challenges or skill gaps in a new way or form? 

These and other similar questions are not being asked enough. The more processes we build, the more legacy we carry with ourselves. A process implemented three years ago to plug a relevant gap at that time may not be relevant now, yet people are still going through the motions. 

TL;DR

1. I defined a product process failure as either:

   1. A process not being followed

   2. A process being followed, but the actual outcome is different from the expected outcome

2. As product processes are not similar to manufacturing processes, the second type of failure may not be a problem but rather a feature of product work

3. There are many reasons for having product processes, such as alignment, raising the bar and ensuring certain things are taken care of, but standardisation is not one of them

4. Product processes are directly linked to and reflect leadership culture 

5. Product people don’t follow processes when:

   1. They don’t know about the process or how to do it

   2. They can’t do it because of their abilities or the friction that the process has

   3. They don’t want to do it because there is no value in following it and no negative consequences for not following it

   4. They don’t do it because there are no triggers or forcing functions to initiate the process

6. Designing and implementing product processes is similar to building a product. And it’s implementator’s responsibility to ensure its success.  

Thanks, Ilia, for sharing the gems on how to make product org more effective and efficient.