Skip to content

My all-in-one product operations process improvement tool

Diagnose, visualize, and prototype changes with process maps

I had just wrapped up a discovery sprint, digging into how my client’s product team was currently operating. I understood why they wanted my help – there were avoidable crises, duplicative work, and an overall sense of confusion.

But I was stuck on how to move forward. The team faced interdependent challenges, and untangling them was going to take a big change. I needed to get a high level of buy-in for our path forward.

Simply explaining the issues to my key stakeholders took nearly twenty minutes – I doubted the product team would be willing to listen to me talk at them for that long. I needed a way to convincingly communicate what I learned and get their commitment to change. 

I pulled out a tool from the operations world: process mapping, also known as workflow diagramming. I mapped out the way that team was building products today. I shared that illustration and invited people to join in workshops to talk about what they saw in the process map. 

Rather than explain what I saw in my research, the challenges the team was facing became apparent to everyone. 

The first process map I made to show how convoluted things were.

Change hearts, then minds

People are used to their own ways of working. All the oddities, inefficiencies, and points of friction start to feel normal. Once that happens, it’s hard to see a better way of doing things and the team becomes more resistant to change. 

To get the team unstuck, I focus on getting them to see their current situation with new eyes, to feel the pain again. That emotional “ah-ha” moment is when I’ve changed their hearts. 

Once their hearts are changed, it becomes much easier to change their minds. If I’ve done my job right, they’re now much more receptive to trying something new.

The process map is a great way to help people look at their current work with fresh eyes. 

Drawing out the process map

A process map displays how work travels through the product organization. It points out some of the organizational idiosyncrasies identified in interviews and surveys. 

It communicates the current state of the team in a visual manner. John Cutler shared a different example where one team went deep on what it took to get a particular feature out the door. 

It serves as a key tool to align on where the largest opportunities for improvement lie. Later, as solutions get developed, it will become the prototype of future improvements.

To create a process map, you need to understand who is doing what and when. Then you run an analysis on the map to gain insights into where you should focus your attention.

Define the teams and key players

Set the scope of your map. Usually I draft it considering the flow of work from when an idea is generated until that idea is shipped. It’s up to you about how detailed you get for each step, and how much of other teams’ work you include in the flows. Sometimes it makes sense to include GTM activities, other times it is better to leave that out. 

List out the teams you’ll be mapping. Once you have the scope set, you’ll want to map out the teams or roles you’ll be mapping. Generally this should be functional – product, design, product analyst, engineer, engineering manager, etc. Sometimes you will choose something departmental such as sales, customer success, or marketing.

Color code your teams. Each team or role should have a distinct color and initial. You’ll be using those later.

An example of how to color-code teams and indicate multiple teams working together.
An example of how to color-code teams and indicate multiple teams working together.

Sketch out the flow of work

Map out the work at a high level. Using the information you gathered through user research, map out how work actually flows throughout the organization. Create a square for each step that work goes through and place them chronologically, from left to right. 

As a general rule of thumb, if the task takes less than a day, it shouldn’t be it’s own item. If it takes more than a few weeks, it should be broken down into smaller pieces. If it falls in the middle of that, it should be up to your discretion.  

Meetings. Call out critical meetings that are part of the process – major presentations, kickoffs, etc. It’s up to you if you map the regular recurring meetings that are part of the product development flow. Give meetings their own shape.

Documentation. Similarly to meetings, highlight key documentation that gets generated throughout the process – PRDs, problem briefs, epics, journey maps, roadmaps, etc. Give documents their own shape.

Decisions. Document critical decisions. Is there a gated go/no-go decision that gets made at some point, or a moment when the launch date gets set? Highlight the major decisions in the product development lifecycle with their own shape.

A segment of the workflow diagram with the activities, documents, meetings, and decisions marked with their own shapes.
A segment of the process mapwith the activities, documents, meetings, and decisions marked with their own shapes.

Confirm and validate

Return to your users. Once you’ve gotten the map drafted, return to your information sources to confirm that you’ve hit the 80% accuracy for 80% of the people threshold. Ask them to highlight spots you got wrong and to think about steps you might have missed. Don’t try to get everything right for every case – it is more important to get things mostly correct than getting every edge case covered. 

Run analysis 

Look for dead ends. The map might show work that doesn’t go anywhere. One company I worked with had a team doing strategy and opportunity research. But their reports didn’t connect back into the main flow of work. As a result, very few of their ideas were making it into production. That team was frustrated that their work wasn’t being used for anything, and the company wasn’t able to take advantage of the value that team was creating. The map helped us identify that this wasn’t just a feeling they were having, but a reality. 

Dead ends look like a place where someone’s work doesn’t connect anywhere down the flow. The arrows simply stop and work picks up elsewhere.

Highlight excessive back-and-forths. The color-coding should make it easy to see if work is shuttling back and forth between certain teams or roles. If those roles work closely together (product and design on one squad, for instance), it might not be a problem. But if those groups are not working on overlapping goals, those may be points of friction.

This looks like a few teams alternating turns through a workflow. The colors will form an almost striped pattern.

Look for handoffs in flow. There may be places where the bulk of the work shifts from one group to the next and everyone has to context switch. These are potential areas of opportunity. 

This will show a big chunk of color from one team transitioning to another color without a collaborative step that includes both colors in the middle.

Dead ends, back-and-forths, and handoffs all indicate places where the expected workflow can potentially be streamlined. They each show ways in which communication is slowing down and work not being well used.

A tool for organizational prototyping

One of the best parts about having the process map is that it also works as a great prototyping tool. As I started to talk about solutions with my client, we could pull up the map, make changes, and see how they looked.

The prototype we used to test a new, streamlined process for the team.

The process map helps you understand how the team is working today, and creates a visual tool to help communicate that to the company more broadly. Over time, it will become a tool that helps you prototype process changes. It can even be used as documentation of the current product development process to help get everyone on the same page regarding expectations for the product development team.

To summarize:

  • Scope the work to the areas that you need to influence
  • Sketch it out before you try to get everything right
  • Solicit feedback from the team to confirm correctness
  • Aim for 80% accuracy for 80% of the team
  • Use collaboration on the map as a way to create buy-in on future changes

While it can be used as a standalone tool, it becomes an even more powerful product operations tool when combined with continuous user research and roadmapping. It can become a way to communicate the vision of how the product team should run in the future and the path to get there. 

The process map is a living document that will grow and evolve with your team. As a visual communication tool, it becomes a powerful asset that you can use to continually improve, iterate, and onboard your product team. 

Thank you for the generous edits from Michelle Harris and Adam Kecskes. As always, the outside set of eyes helps me tremendously. 

Process maps are my product operations process improvement multitool. Explain the situation, generate buy-in, and explore new solutions.

RELATED ARTICLES