What is process improvement?

Process improvement is exactly what it sounds like: the practice of evaluating a company's procedures, identifying bottlenecks and inefficiencies, and then designing improved versions of those workflows.
Unlike regular problem-solving, process improvement is usually a continuous, iterative effort. Instead of reacting to problems as they arise, the person tasked with process improvements (usually an operations manager, program manager, or similar) proactively evaluates existing processes and identifies opportunities for optimization.
For example: let's say your design handoff process feels unnecessarily complex. Your main problem is that developers consistently find themselves working off of old designs because they can't reliably find the most recent final version of each screen. If you're looking to solve the problem, you might talk to your design and development teams about practicing clearer communication. But if you're a process improvement manager, you'll look for a better way to structure and organize your entire handoff workflow that will not only solve the problem but will increase efficiency across the board.
A table comparing the difference between problem solving and process improvement

The importance of "zooming out"

It's fair to assume that just about everyone tries to do their job in the best way possible. When given the opportunity to eliminate redundancies or do things in a more effective way, the majority of people will choose the most efficient option.
The issue is that not all improvement opportunities can be seen from the ground. In process improvement, we "zoom out" to take a look at operations as a whole and make sure we're addressing the root cause of the problem, instead of trying to fix what are really just symptoms of a larger issue.

How to tackle process improvement on a product team

Every team's process improvement technique is a little different, and they all incorporate at least a little bit of a DIY approach that's custom to the team's specific needs. As you build out your process improvement method, keep these tips in mind.

Design for repeatability

A set of steps isn't a process unless it's designed to be repeated. Your processes shouldn't be tied to a current process with a particular set of steps, product parameters, or specs that could (and probably will) change. Of course, all processes will need to be updated and improved (or else we wouldn't be having this conversation!) but the core methodology should be one that can be applied to multiple different scenarios.

Track the right metrics

It's impossible to evaluate or build upon your process improvements without measuring how much things actually improved. But be careful — many (most, even) of the metrics available to you won't actually reveal anything valuable to your process improvement project. Choose metrics that capture the most basic and essential measurements for your project — what we call "North Star" metrics.
Be careful not to confuse actionable metrics with those that measure business goals. Sure, everyone wants what they do to increase profitability, but measuring dollars won't give you any feedback on whether your process redesign helped decrease missed shipping targets.
One of the frameworks we’ve been using successfully at Zeplin is outcome-based roadmapping, which can also be applied to internal processes. Here, outcomes are defined as some behavior we are able to measure and change. While intended for product management, the approach is applicable to internal processes and teams as well (if you approach your team’s efficiency as a product).
A graphic defining North Star metrics, secondary metrics, and irrelevant metrics

Keep it lightweight

In more traditional industries, a process improvement audit usually involves complex process mapping and ends with pages and pages of reporting and new process documentation. In product development, people don't have the time to slog through pages of reading and learn entirely new systems. For a solution to be effective, it has to be easy to implement. Highly visual, intuitive process documentation — simple flowcharts and Kanban boards, for example — is preferred over long-form written instructions.

Collaborate early and often

In product development especially, it's essential to get all of your team members invested in your improvement initiative early on. Working with the people who are closest to the problem will help you get to the most effective solutions more quickly. This will also make it easier to implement changes without tons of instructions and training. If everyone was involved in creating the solution, you won't need to dedicate tons of time to teaching them how to implement it.

3 key process improvement approaches

In the product industry, finding the right process improvement framework can be tricky. The development cycle evolves so often that it's difficult to find one existing framework that will map perfectly to your team's needs.
Most product development teams will need to create a process improvement approach that's custom-built for their organization. However, most DIY approaches will still incorporate elements of these tried-and-true frameworks.

Plan, Do, Check, Act (PDCA)

Used for: Keeping your processes lightweight and nimble
Plan, Do, Check, Act, or PDCA, is an acronym often used with the Kaizen principles to streamline teams’ processes as much as possible. PDCA purposefully uses more direct, action-oriented verbs like "do," and "check" as opposed to more complex frameworks like DMAIC (Define, Measure, Analyze, Improve, and Control).
PDCA places the emphasis on the importance of getting things done. You don't implement or facilitate, you simply do. You don't analyze, scrutinize, or examine; you check and move on to taking action. PDCA acknowledges how easy it is for even the most efficient, experienced managers to let their processes become more complicated than they need to be, and it provides a framework to keep those workflows on track.

The 5 Whys

Used for: Quickly identifying the root causes of problems
Keeping processes efficient is important, but it's just as essential to make sure that your processes are addressing the right issues. The 5 Whys is a process improvement framework designed to evaluate whether the problem your process solves is actually the root issue or just a symptom.
Using the 5 Whys is simple: working collaboratively with all of the stakeholders in a project, the team lead starts by asking why a problem occurred. When the team answers with an explanation, the lead follows up by asking why the explanation happened. Typically, it takes about five rounds of "why's" to get to the root cause. Here's an example:
Process improvement lead: Why have we missed our last three target ship dates?
Team: Because we set the target dates based on time estimates that turned out to be inaccurate.
Lead: Why were the time estimates inaccurate?
Team: Because the scope of the project changed while we worked on it.
Lead: Why did the scope of the project change?
Team: Because the initial product specs weren't specific enough.
Lead: Why weren't the specs more specific?
Team: Because the product requirements document didn't include all of the relevant parameters.
In this example, the surface problem — missed target dates — was just a symptom. It's not possible to fix the missed deadlines without digging down to the underlying causes. By drilling all the way down, we uncover the real issue: the product requirements document template the team has been using doesn't include enough information.


Used for: Improving the way your team solves problems
Kaizen is Japanese for "change for goodness," and is often considered the "original" continuous process improvement methodology.
Process improvement has evolved quite a bit since Kaizen first appeared several decades ago, so it's rarely used as an organization's main improvement methodology. But the methods that are used today all have their roots in Kaizen principles, so it's important to understand it as the foundation of modern process improvement.
According to Kaizen, a team's problem-solving process should:
Address problems as they arise, not at pre-designated problem-solving intervals.
Incorporate the whole team collaboratively, soliciting potential solutions from members of all experience levels and areas of expertise.
Aim to make small changes more frequently instead of planning fewer big, significant changes.
The Kaizen principles ensure that a team's problem-solving process generates continuous improvement and remains compatible with the iterative nature of the product development process.
In a fast-paced industry with almost countless moving parts, process is more important than ever to keep your product operation from devolving into chaos. Collaborating early and often, maintaining strong communication, and using tools that allow you to codify collaboration into your process permanently are the keys to running a smooth, efficient product powerhouse.