Why too much (in) progress breaks product commitments

From flow point of view, one of the worst statements you can make is “at least everything is being progressed”, yet I’ve heard that so many times from both inexperienced delivery leads and product people alike.

In my previous article, I explored feature ageing and discussed why it can be a useful signal for product managers. When you observe the ageing of features over time, you may notice a strange phenomenon with some late deliveries.

What I mean is that sometimes features that seem well understood and simple enough, and nobody expects them to become problematic, end up taking longer and becoming a risk.


Work on the feature continues but it just isn’t getting finished. Why?
Sometimes the answer is complexity that we could’t foresee before. Or a dependency appears that nobody could reasonably have predicted.

But occasionally, or perhaps most commonly, it is neither. Having watched delivery teams for a long time, I believe the most common reason is that there is simply too much going on at once.


The seduction of seeing things move

Moving work is not the same as completing work. If you are reading this post, you probably don’t need convincing about this statement.


But in organisations we often see that teams and often their bosses want to demonstrate that things are happening and they insist to start work on a feature so they can declare it as a win in their weekly reports.


People are also remarkably keen on starting new work. I get it, our brains like novelty, new ideas are exciting and new initiatives create momentum.

Anyone who’s spent a few years at big organisations will tell you that they change directions, sometimes too often, and what seemed important yesterday is no longer the top priority today. The decision to start on a new initiative usually feels reasonable. The issue only becomes visible when you step back and look at the whole picture.


From flow perspective starting without finishing is just about the worst thing you can do. Every feature that enters delivery joins a queue for attention. It competes for the same conversations, the same decisions, the same specialists, and the same organisational energy as everything else already in progress.

If we were on the manufacturing floor the queues might be too obvious to ignore. But in knowledge work, this accumulation is often invisible. It is the responsibility of the delivery leader and the product manager to make the queues visible.



The product manager’s view

In a typical organisation most people try to make things look good. It is somehow assumed that working on 4 initiatives instead of 3 is better. You are showing that you are working harder and it seems that you are getting more done. Your stakeholders look happy.
And as you follow this logic and new, urgent changes arrive, you soon end up working on 7 initiatives while your team’s only able to comfortably handle 3. You are getting so much more done.


But now things seem to be different. Attention of your key people is more fragmented and they “drop the ball” occasionally. Everything slows down because there are competing priorities, impediments take longer to resolve, people start to look and act overworked.

And soon enough some initiatives are beginning to look like they will be late. Your options are limited. Either make people work longer hours or drop something. Neither option seems attractive.

That’s the product manager’s dilemma.

How did we end up here? We wanted to show more progress. But work in progress is very different from work completed.


Why product commitments become fragile

Our senior leaders often demand commitments. And it makes sense, they invest in our teams and they want to see returns.


I think that when they first come across commitments most product managers are not ready for it. But the job demands it and so they often begin with a set of reasonable assumptions.

e.g. If Feature A takes approximately eight weeks, and Feature B takes approximately eight weeks, then we can make sensible plans when both will be done.

Of course these assumptions don’t survive first contact with reality. They breaks down when several features are competing for the same capacity at the same time or when an unforeseen work becomes urgent.
There are so many ways in which work streams can affect each other. In most cases work streams are not completely isolated. And so a delayed decision on one initiative can consumes attention that was needed elsewhere. Or a dependency on one feature creates waiting time for another. Or a critical specialist gets pulled between multiple work streams due to changing priorities.

The result is that the overall system becomes less stable and so delivery becomes less predictable.

Depending on what you report on, it can look as though the team has become slower while in reality, the system has just become busier.


What feature ageing is really telling you

In my previous article on feature aging I concluded that a simple signal can tell you what to pay attention to.

And I stand by that, it is a useful signal and it can help you uncover and resolve blockers, technical challenges, and delivery concerns earlier.

But while that’s a useful action to take right now, you should also be aware that feature aging could be hinting at longer term issues with your broader system.

It could be highlighting the cumulative effect of having too many things in progress at once. And this isn’t a straight forward signal because knowing what is a good work in progress limit isn’t possible without observing your flow of work for a while. And things get more complicated when the organisational structure changes often.

Being able to optimise your work in progress can have profound effects on your productivity but unfortunately it isn’t something you are likely to get right by using your gut feel. In fact in most cases the right number turns out to be a complete surprise to those inside the system.


The roadmap tension

There is a big problem with the traditional roadmap and I’ve seen organisations ignore it time and time again. Features are visualised on a timeline typically because that view makes sense to the senior leaders. Then the “rough dates’ Product managers use to create the picture quickly become expected dates.


Explaining why fixed dates are a problem is a whole different matter. if you need convincing go and check my Kanban series.

In short, if you use fixed dates, often these dates will slip and you will be asked to explain why.

It seems like Product managers are rewarded for identifying opportunities and then punished for not being able to predict the future in a world that works in probabilities, not in fixed dates.


As a side note, some organisations adopt a Now/Next/Later approach. This often seems different on the surface before you discover that they silently assign timeframes -e.g. Now is this month, Next is within 3 months, etc. Visualising your features on a Now/Next/Later board has its benefits but it doesn’t do much to introduce realistic forecasting so you can communicate only what you know with reasonably certainty.


A simple experiment

If you are not sold on this idea perhaps you can test it with data. You would not need sophisticated tooling, just a simple spreadsheet.

Keep track of the features you have in progress - e.g. every week write down how many features are in progress.

Then look at how many features start and how many features complete per given period e.g. monthly or weekly. It would be useful to have data over several months.

At this point you may be surprised by what you find. When you get updates from your teams it probably feels good to see things progressing. But from this higher level you may discover that the more activity you have (more features in progress) the fewer features get completed.



What Product Managers Need

This series is meant for Product managers so let’s focus back on them.

I believe Product managers need help to be able to recognise patterns that influence delivery outcomes when it is not too late.

We looked at feature aging first and now work in progress. Too much work in progress is one of those patterns.

As many very useful things, tracking work in progress does not require advanced analytics to notice it, just a way of seeing the relationship between active work and completed work.

Once that relationship becomes visible, many delivery problems start making more sense. And more importantly you have a chance to intervene.


What Comes Next

There is one further pattern that’s worth exploring in more detail.

You must have seen this. Some features seem to spend far longer in progress than others, regardless of how much work is happening around them.

When you investigate you may find out that the reason is simple. The feature itself was larger than anyone realised.

And that is where we’ll go with the next post.