Why Product Managers are often the last to know

If you work in software product delivery I think you might recognise this slightly uncomfortable situation I’ve noticed.

It is very common for the person who stands in front of the board of directors, or in front of the senior leaders in the organisation to demonstrate progress made by their product teams, to often be delivering a message that has been given to them by someone else. And this person would often feel accountable for progress and at the same time a little uncomfortable because they can’t see that progress clearly.


In some cases, at the start, there is an implied trust between the product leader and those giving them progress updates. Sometimes the trust comes later. But in either case the trust is often fragile, breaks at the first miscommunication and can lead to an ineffective long term relationship. That is if the relationship wasn’t bad to begin with. It can be very frustrating for both sides, as if they speak different languages.


From a delivery team point of view it is often difficult to see the significance of the commitments that product managers make. Or the need for setting expectations. Product managers find themselves explaining progress to stakeholders, leadership, and sometimes the board. And in many cases they don’t have sufficient confidence in the updates they provide. But in their desire to be more certain they may ask their delivery teams for details that seem irrelevant or petty. Yes, it is very frustrating for both sides.


Things typically get worse, when delivery goes off track. It is not uncommon for the product managers to be among the last to realise. But that’s usually not on purpose.


In truth people are almost never hiding things. Engineering teams are often optimistic but that’s almost never deliberate. So what is actually going on?


It is easy to point out mistakes in hindsight. It is harder to design a system that makes it easy to see what’s really happening.


The gap between responsibility and visibility

If you speak to product managers, many will tell you they have “visibility”. Dig a little deeper however and you’ll find out, what they mean is that they attend stand-ups, they join reviews, and receive updates, and can open Jira and see what’s in progress.

On the surface, everything is there. But the level of detail is often not right for the product manager. So they still rely on interpretation or a team meeting to write the weekly report.

A feature is “progressing well”.
Another is “a bit more complex than expected”.
Something else is “nearly there”.


All of which might be true but it doesn’t answer a more important question:

Is anything starting to go wrong? Should I be worried?


Why this is harder than it sounds

The natural response is to ask for more (see this article too) In this case more or better reporting.

It’s amazing how similar this can be in many and very different organisations.
“Get me more detailed updates!”
“Use clearer status categories!”
“Let’s have more frequent check-ins!”.

But these suggestions produce more information, waste time and have no effect on clarity.
And one of the reasons usually is because the reaction is a little late. By the time something is clearly off track, the conversation has already shifted into firefighting.

We talk a lot about visibility in our industry. The problem is that what’s typically made visible is  what’s easy to make visible, while the significant signal is buried in the detail.

When delivery teams are looking at tasks, stories, technical steps and logs, product managers are thinking in terms of features, outcomes, timelines. Sadly even when there is a system that’s supposed to tie it all together, product managers end up using something else, like a spreadsheet.

It is not just about transparency

It’s tempting to frame this as a transparency issue and sure enough sometimes it is, but also often it isn’t.

Most teams I’ve encountered are reasonably open about what they’re doing. However, being open about activity is not the same as exposing risk. Especially when it is not one of the very obvious risks.

It is possible to be very informed about work in progress but to never realise that something might be taking longer than usual or is quietly waiting on something else or just beginning to drift away from what’s typical.

That kind of signal is harder to spot, especially if you’re not looking for it directly.

There are, of course, well-established ways of understanding delivery risk. Current best practice would suggest looking at cycle time distributions, system stability and probabilistic forecasting.

The are all useful and personally I am a big fan. However, having spoken to many product managers over the last few months I now understand these tools are not always accessible.

For a product manager, trying to make sense of Monte Carlo simulations or percentile-based forecasts can feel like stepping into someone else’s domain. “And what even is system stability?” one product manager asked me.

Having good data to be able to produce forecasts or look at system stability is one thing and being able to translate it into a simple question like “Should I be concerned about this?” turns out to be very different.


How to think about it as a Product Manager

We spoke to many product managers who had varying degree of appetite to look at delivery forecasts. In all cases though they wanted it linked back to the entities they work with - features, outcomes, initiatives.

So perhaps we shouldn’t be trying to give product managers more data but rather figure out how do we give them clearer signals that sit at the level they actually work at.

For example we could highlight:

•     A feature that has been in progress longer than most others
•     A growing number of features all “in progress” at the same time
•     A team whose delivery pattern has become less consistent over recent work

They would be signals or prompts for a conversation. They would not require deep statistical understanding, but will point to something worth looking into.

If such signals are useful to Product Managers, the interesting part is that they don’t require a completely new method or even a new system.

Most Product managers we’ve spoken to already keep track of things like “when a feature starts”and “when it is delivered” and “how work is grouped at a feature or initiative level”.

If you have tracked these, then over time, that creates a useful history which would be enough to answer questions like:

•     what does “normal” look like for us?
•     when is something taking longer than usual?
•     are we starting too many things at once?

And once you have a sense of what is normal, you can start to notice what isn’t.

Knowing before you’re told

Is it realistic to know before others tell you? I think it is.
And there’s a sort of shift that happens when these signals are available.

Instead of waiting for an update (usually late) that something has slipped, you begin to see it forming and can do something about it before it’s too late.

The signals are not meant to replace conversation with your delivery teams. They give you another reason to talk and the starting point is now much earlier.

e.g. instead of asking “is everything on track?” you can now ask “this looks a bit unusual, what’s going on here?”

Implementing this in practice may not be as simple as talking about it. As is the case with many useful methods that I’ve learned, they often happen to be also difficult to use… And so adoption may not follow swiftly… unless we figure out how to make it very easy. This topic requires more research and more work.

I don’t have a good answer yet, but it’s something I’m exploring in terms of how I think about delivery and product, and in the tools I’m using.


What’s next?

In the next few posts, I’ll try to make this more concrete.

Starting with one of the simplest and most useful signals a product manager can have:

how long a feature has been in progress, and when we should start to raise questions.