The SPOF (Single PM of Failure)
and how to avoid it through leadership and collaboration
After returning from a well deserved and much needed three week vacation, an unsuspecting Product Manager opens up slack and sees a message from his product director saying “You’re back today, right? We need you. The super-impactful project is falling apart, people are confused, timelines are all off, leadership is concerned. Please give it some attention as soon as you’re back up to speed.” He’s a little shellshocked as he looks at slack and thinks to himself “maybe I shouldn’t take such long vacations anymore, or if I do, maybe I need to check in now and then.” He reaches out to the different teams involved and starts life after vacation with even more pressure than before. Burnout looms.
There’s a lot wrong with this picture and a lot that went into it. Most notably, nobody should ever feel like they can’t take vacation or that they need to check-in during their time off. He could have followed the initial line of thinking and avoided vacation or never let himself properly disconnect. But inevitably that would lead to increasing levels of stress, burnout and probably poor performance. Sticking with that way of working has only two possible end states. Either collapsing under the pressure, burning out, and eventually taking some sick leave. Or the job stops being fun, poor performance reduces the opportunities, frustration grows, and Option B results in leaving the company. Neither sounds particularly appealing. It’s time for a change in mentality.
Let’s back up. As a Product Manager, you must obsess about a problem, meet with users, absorb context, and learn as much as possible. A Product Manager must synthesise this context into a mission, vision and strategy and then align the organisation broadly around them. Users rely on you to understand their problems and prioritise solutions. Your team relies on you to provide context problems so they can solve them. Your team also relies on you to understand the impact behind every possible problem and to objectively compare them and prioritise. Stakeholders rely on you for project management and communication. Leadership holds you accountable for impact. I have been the PM from earlier, and about a year into this role I was nearly crumbling from the pressure.
It’s a lot! Listing responsibilities and accountabilities like this still scares me a bit. But I know that in my team I’ve got an awesome supporting cast. The job description of a PM may sound like something I’ve described above, but nothing says that the Product Manager must do all of those things alone. In fact, doing so would be irresponsible. Spreading yourself too thin begins a vicious cycle. You don’t have enough time, so you don’t onboard others to work with you. More problems and opportunities come your way but you don’t have time to onboard others, so you spread yourself even thinner. I was irresponsible in doing this and nearly burned out.
There is one notable responsibility left out of the Product Management job description: Leadership. Leadership doesn’t necessarily mean managing people or hiring, but it does imply building a culture and empowering Product Teams to be impactful. An empowered Product Team doesn’t block on a Product Manager to do all of the above, they work together to do so. An empowered team has the context to make good decisions and to communicate effectively with stakeholders too. They also understand the problem they're trying to solve well enough and believe in the strategy such that they could speak on behalf of the PM if necessary.
Rather than continuing down the path of burnout, I chose a different route. That way of working wasn’t sustainable. Rather than doing everything myself I’d need to lead. I need to make sure my Engineering Manager, other PMs I work with, and most importantly, my team have sufficient context to make decisions. It is a mindset shift from ‘I’ to ‘We’.
It was a change in the way of working. In general, I needed to stop doing things on my own. Instead, I try to have a collaboration partner on all the important initiatives that I am responsible for. This partner and I work together on the initiative from the start, such that they know it as well as I do. Concretely, try partnering with an interested engineer on your team to meet with users and stakeholders. Brainstorm ideas with this engineer, and eventually co create a part of your strategy together with them. Do the same for the next problem, but this time with a different engineer. When engineers join you in the problem space they learn invaluable context about the problem and become empowered to make some product decisions in their solutions themselves, without blocking on the PM or misunderstanding the users’ problems.
By working together with a collaboration partner for most of your responsibilities as a PM you make yourself fault-tolerant should you take vacation, get sick, or go on parental leave, but the benefits don’t stop there. You get the power of two brains on the same problem and generally will do a better job together. You create a culture within your team of working with users and have a better chance of building what they really want. And you remove yourself as a blocker or bottleneck in order for your team to make decisions and progress.
I changed my ways of working to be much more collaborative. Fast-forward 18 months later, and I actually broke my leg badly and needed to take sick leave for about a month. There was no preparation and no handover conversations, but to my delight when I returned, it was business as usual. The incredible collaboration partners I’ve been working with managed to cover for me across the board. I made myself redundant.
‘Redundant’ sounds like ‘expendable’, but by working with partners, it becomes possible for a PM to focus where they can provide the most value. It becomes easy and natural to delegate the rest. Do less individually, keep your stress level under control, and together the team will have more impact. So change mindset from ‘I’ to ‘We’. You’re not the only one who can work on the daunting list of Product Management responsibilities. Collaborate with others as much as possible and empower your team. Don’t be a hero, be a leader. Lead.
In last weeks Product Internals podcast, Arvid and I talk what we actually do with our time, as well as how we concretely make use of this way of working. Please have a listen, and reach out to us to discuss or debate on Twitter @productinternal or at firstname.lastname@example.org ! And if you’re enjoying the show so far please follow!
And if you liked this post we’d love to have you join the Product Internals community! Subscribe for a new post every Wednesday. If you find them as valuable as we find writing them please share them with your friends and colleagues!