Managing Work in Progress as a Product Manager

Speed up by increasing focus

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.

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.

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.

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.

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.

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.

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.

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.

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).

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.

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).

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!

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.



Head of Product at RevenueCat; previously at 8fit, Yammer, BCG.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store