Leaders and stakeholders in other parts of the organisation want to know what’s being delivered, so they can plan around it, adjust their work, create communication plans…
A common frustration is product managers being forced to provide predictions, and then these predictions not working out. We see constantly slipping delivery dates.
In my last post, I wrote about how a Product Manager can communicate uncertainty around delivery to manage expectations. Yet, what was missing was the role of product culture and organisation in this.
Product teams can only provide informed judgements about the future and give stakeholders a somewhat accurate picture of the future if they control their own destiny. That means that they can control what they’re working on and with who, are able to change direction, and can break things down effectively.
As a product or business leader you must ensure the environment is well designed to give them the necessary freedom to act.
The team’s ability to predict delivery will depend on:
- how many things they’re having to predict
- control over the team and their availability
- how well they understand the task at hand
- having had practice at working in that team, and having done that same/ a similar task in the past
It’s the role of the product leader to ensure conditions in which the team can better control what they work on.
Reduce the number of competing priorities for your team
The more priorities a team has to deliver against, the less able they will be able to effectively control how long it takes them to deliver each feature/epic/thing.
When you multiply the number of tasks, you exponentially increase the uncertainty, which cancels out the ability to predict future developments.
My favourite analogy for that is cooking an English breakfast.
I can easily predict how long it takes me to fry sausages, or how long it takes to heat up beans. But if ask me how long it takes me to prepare an English breakfast, that’s a lot more complex. Not only do I have to predict how long it takes to do each part of the breakfast, I also have to factor in how to do them in parallel.
For example, if I put bread in the toaster at the beginning, it will be done by the time everything else if ready, but it will be cold.
If I made it regularly (and therefore had a profound understanding in which order to do each task), then it might be easy, but it requires practice.
If this is a new problem (and often product teams have a lot more of those), I can give an estimate, sure. But if you insist on me delivering to what I guessed, you’ll probably have a half-burnt half-undercooked breakfast.
In the world of product management, this means reducing to a minimum the number of problems a team is tackling at the same time.
Empower the team to control their team’s availability
Reducing priorities applies also to how many products a given person is assigned to. I have seen a designer working across 5 products at once. Notwithstanding the cost of context switching for that person (and sheer exhaustion), this also created risk on the product side. The product team may suffer from another team needing the designer more urgently.
Someone being part-time in a team means they also can’t create the same trust and ease of communication with the rest of team that is needed to move fast and in a predictive manner.
This means assigning people for a given amount of time to the lowest amount of products necessary. Only in exceptional cases and in full transparency should you make changes to those assignments.
You may think I’m pointing out the obvious, but I’ve had developers reassigned to my team overnight because someone up top thought we weren’t moving fast enough (without talking to me first).
As a general rule, the further team assignment decisions are made from the team itself, the worse they will be. Of course, leaving teams themselves to decide who they need exactly will require a well-experienced team, but for me it’s definitely the ideal scenario:
Fundamentally, people will do what’s best, they are smart and well-intentioned. By vastly underestimating our people’s ability to make good decisions, and expecting them to waste money, we have created atrocious planning processes, that waste even more money.
Think big, but predict small
It’s ok to have big goals, but it’s crucial to help and empower your product teams to break those down into smaller and more predictable chunks.
However, this doesn’t mean that we will start predicting the size of all the chunks. Breaking things down only makes the first one or two chunks more predictable. Anything else we plan to do later is likely to be so full of unknowns that any exact prediction shouldn’t pass a lie detector test.
Even better, we’ll probably learn that things we thought we should do next are not that useful, and instead, we should focus elsewhere.
For complex problems, breaking things down doesn’t make the whole big mission easier to size, it only gives you something to size – which is the beginning.
John Culter drew this diagram, that illustrates this point.
Teams that become better and better teams
I alluded to it above, predicting effort and time is something that is a practice. Product teams will get better at it over time because they learn to work together. Experienced teams will have overcome problems and found solutions together, they know how each other work and how to optimise things so that they can work together. They also learn to develop trust and safety, which means problems can be spotted early, conflicts can be dealt with effectively.
Just like a sports team, a team gets better with practice. So the worst you can do for your teams is rejigging their assignments very frequently.
Of course, give people the opportunity to move across different teams so they can learn and develop by facing new challenges. However when we engage in “resource” planning (cringe), we tend to forget that people aren’t components that we can easily replace with another of the same type.
Conclusion
If we want better functioning teams, then instead of doubling down on control, we have to trust them more. Because it’s control that’s hampering their ability to do what’s best.
Decision-making needs to happen closest to the people implementing the decisions. As product or business leaders we need to trust, while providing the right tools and space for the teams to deliver value.
This isn’t easy, as uncertainty can be scary, especially if the leaders above you don’t embrace it either and want control and predictability from you.
However my sense is that this type of leader is a dying breed, as more and more product managers have the opportunity to see what good product leadership looks like and will be inspired to continue it and evolve it in even better ways.
Book recommendation: My reflections come both from good and bad experiences, but also reflect what I read in the book Reinventing organisations that I highly recommend.
Digital Good 