Managing Work in Progress as a Product Manager

Speed up by increasing focus

Product managers are continuously inundated with requests and ideas from all sides. Even when being very careful with prioritization, it can happen that the team ends up with too many projects being worked on in parallel — a large amount of work in progress.

High work in progress (WIP) is not desirable — this article explains why, under which circumstances more WIP is acceptable, and how to reduce WIP.

Please note: in this article I am using “project” as a shorthand for the various work items a team could be working on. It doesn’t really matter if the team is working on projects, missions, topics, themes, or tasks — if there are too many of them active at the same time, it’s high WIP.

Why high Work in Progress is bad

Bad for morale

Even if it was the case that high WIP would have no other negative effects, e.g., on shipping velocity, it would still be bad for morale. Consider the example of a six people team that has six projects, each taking six person months to deliver (this is hypothetical, of course in reality there is no such thing as a person month). The low WIP version of delivering this workload is starting and finishing one project per month. The high WIP version is working on all six projects in parallel, and delivering each project after six months.

While in both cases the average frequency of shipping is one project per month, the high WIP version will feel much slower, because each project has been going on for six months when it ships. Shipping a project after a month feels great. Shipping it after half a year just causes a feeling of “thankfully this is finally over”.

So even in the ideal scenario in which the overall workload takes the same time to deliver whether you have high WIP or low WIP, team morale will still be negatively impacted by high WIP. In reality, of course, high WIP has several other

Context switching

High WIP causes some very real costs. First and foremost, there is the overhead cost of context switching. A team that works on multiple projects at the same time will constantly have to context switch between the different projects. This context switching time is lost time — meaning each individual project will in effect take even longer to deliver.

Worse collaboration and quality

In teams that have too many projects going on at the same time, naturally different team members will start working on different and unrelated work items. This means that collaboration takes a toll. If a team member wants advice, a code review, a pair programming session, or something similar, they will either not find someone, get much worse advice than they would have from someone who is working on a similar topic, or incur additional context switching costs on the side of the person that they asked.

The result is lower velocity, worse team morale (because collaboration improves morale), and also lower quality (because team members get worse support).

Environment changes

Since with high WIP, each individual project takes longer, there is also a higher risk that there are relevant changes in the environment that are relevant to the projects. The factors that drove the priority, scope, and specification of a given project when it was started might shift over time. As an example: a project might have been kicked off because it was considered a sales blocker for some important prospects, and by the time the project is finished, the prospects have already been lost. This can happen in all cases, of course, but the longer a project takes, the higher the risks are of this happening.

Not all environment changes mean that a project is no longer relevant, they could also change the scope and specification of a project, which will in turn prolong the implementation of an already elongated development cycle.

Slower learning

Taking longer to ship projects also means you are slower to collect feedback, learn, and adjust. In the hypothetical case of the team with six projects, perhaps if you worked on them one after the other, you would have learned something from the first project that would have made projects four through six obsolete, or no longer the highest priority.

You might learn from the first project that the approach didn’t deliver the hypothesized impact yet, and instead of one of the original projects, you decide to give another idea for the first project a shot. Or, conversely, the first project overdelivered vis-a-vis the expectations you had, and you decide to double down on the opportunity. All of this is not possible (or takes much longer) with higher WIP.

When Work in Progress is good

Hopefully by now it is clear that high WIP in general is a thing to avoid. However, it’s not always bad (otherwise we would probably never end up in the situation where we have too much WIP). Here are some legitimate reasons to have some amount of WIP.

Parallelizing fast and slow

Sometimes, a team has very big and long projects that they need to work on, that can’t be broken down much into shippable chunks. Of course, you should always try to break down work into small, shippable bits and continuously integrate and ship, but there are some projects where at least the end result can’t be shipped to customers until the whole project is complete. It can be hard for the team to stay motivated for a long time in these projects.

In these cases, it can be good to occasionally pause work on the big project to ship some small improvements, just to create small moments of success. You should be very deliberate about this, and time-box it so it doesn’t become an ongoing parallel commitment, but this tool can help keep up team morale for bigger projects.

Parallelizing discovery and delivery

This perhaps goes without saying, but most modern product teams are responsible both for figuring out what to build (discovery) and for building it (delivery). Regardless of how exactly the team does discovery, there will always be a certain amount of parallelization, where the next thing to be worked on is being discovered while the current thing is being delivered. Best in class teams ensure that they start discovery work together and build up shared context about the “why” of the next thing that will be delivered, but especially while all the details are being ironed out of the specific solution, there will be delivery work on the previous project in parallel.

Being responsive

The most double-edged sword of the reasons for high WIP is being responsive. There are many reasons for why a team might have to change plans on short notice — bugs, production incidents, urgent requests, etc. It is a delicate balance to strike between getting bogged down in reactive work and telling people that their requests will go to the bottom of the backlog.

Ideally, all incoming requests are properly triaged, compared against the team’s priorities, and sized. Teams should plan some slack for such reactive work, but it generally shouldn’t be more than 10–20% of the team’s workload (unless the team is dedicated to such reactive work), or the team won’t make progress on the main goals.

Reducing Work in Progress

Reducing WIP can be hard. Here are some ideas to tackle the problem:

Have a clear product strategy

Reducing WIP requires strong prioritization and narrow focus, and both of that requires a clear product strategy to be in place first. Prioritization frameworks alone are not sufficient — you need a clear vision and direction, and then goals that are derived from that direction.

Ideally, this product strategy comes from leadership, but as a product manager on an individual team, you can still develop a vision and strategy for your product area if there isn’t one org-wide, and then socialize it with leadership.

Relentlessly focus

Once a clear strategy is in place, you need relentless focus. Often, high WIP stems from trying to achieve too many goals at the same time, and feeling like progress needs to be made on all the goals in parallel. It’s best if each team pursues only one goal at a time, even better if multiple teams pursue the same goal. This minimizes the risk of teams being pulled in multiple directions and believing they have to work on two goals at the same time.

As a product manager on an individual team, you should push your leadership for as few as possible clear and unambiguous goals. If they won’t give that to you, come up with them and try to get buy-in.

Say no to good ideas

Once you have a relentless focus established, you need to say “no” (or at least “not now”) to a lot of good areas — the ones that are outside of that area of focus, but even the ones within the area of focus that aren’t as good as the ones currently being worked on (especially considering the progress already made on the ideas that are currently WIP).

Of course, saying no to good ideas is the core of prioritization, and one of the most important (and tricky) topics for product managers in general.

Proactively plan capacity

One reason for high WIP in teams with engineers of different functions (e.g., backend, frontend, mobile) is that certain functions are backlogged while others are idle. For instance, your backend engineer may have completed all the API endpoints for a project, but the frontend isn’t built yet, so the backend engineer gets started on the next project. Especially if there is a slight imbalance between the team capacity and what a “typical” project needs, this can continue building up — suddenly the backend work is done for five upcoming projects while the frontend engineers are still busy with the first project.

There are a few good ways to address this issue. Firstly, of course, if this is a systemic imbalance, it may have to be addressed through staffing (moving people between teams, or hiring additional team members). Secondly, it can be good to figure out if (some) team members can operate across broader parts of the stack (e.g., backend engineers writing frontend code). Thirdly, and this is the biggest point of this section, try to consider this upfront. Work with engineering manager / tech lead to identify potential future bottlenecks, and try to prioritize work such that the utilization of the different functions is more balanced. In the above example, consider if there is a more backend-heavy project that could be tackled next, or if backend engineers could tackle some technical debt instead of letting WIP pile up.

Be okay with slack

Expanding somewhat on the point above, one important piece of advice is to be okay with a certain degree of slack or unutilized engineering capacity. Often, high WIP stems from trying to play “planning Tetris”, where you try to pack as many projects as possible into the time available, leaving no headroom. Not only does this hurt reactiveness, it also means that the team will in the end slow down due to all the factors mentioned above (and probably end up slower than if the plan hadn’t been so packed).

Engineers that are empowered, product-focused, and that understand the goals and direction of the team will always find something useful to do even if they don’t have the next project to jump on, from paying down technical debt to fixing bugs and usability issues.

Defer even critical projects

One major factor that increases WIP is time critical projects and requests that get added to a team’s plate. Sometimes, these truly cannot wait (that’s the “being responsive” part above). However, especially for bigger projects that are critical, it might still be good to defer them until the team’s plate is clear, and the team can focus entirely on the new project. Again, consider an example: the team is working on a project that would require another month to complete. An urgent request comes in that would also take the team a month to complete. If the team now does both projects in parallel, they will take at least two months, possibly more due to the additional overhead. If they complete the current project first before tackling the new request, the current project will be done in a month, and the new request the month after. In other words, the urgent request gets done as quickly or quicker when waiting to tackle it!

Of course, this is a toy example, and in reality, things are hardly this easy. However, the bigger the incoming request, the more strongly should you consider deferring it until the team can fully focus on it.

Stop (or back burner) work

The last resort to reduce is obviously to stop work entirely, or to put it on hold. It can be hard to make this tough call — we often fall pray to the sunk cost fallacy, where we are reluctant to stop something that we’ve invested significant effort into, even if it is no longer the most important thing. It’s worth checking that bias, and re-evaluating if the benefits of a project weighed against the remaining effort (disregarding the previously invested effort) still make the project worth it.

If the team has too much WIP and none of it can be stopped, it can make sense to put something on hold — not just for a week or two, but until some of the work has been wrapped up. This way, you minimize context switching and speed up delivery of the (fewer) things that remain in progress.

I hope you found this article useful. If you did, feel free to follow me on Twitter where I share thoughts and articles on product management and leadership.