Minimum Viable Bus Factor for a Product Manager
When you decide to write an article like this, the first existential crisis that you face is “Which term should I explain to the reader first? Bus Factor? or Product Management?”. In this case, since most people have seen a bus before, then I’m gonna start with defining product management:
What do you do as a product manager?
Achieving product/market fit
My job as a product manager is to achieve or ensure product/market fit for one or more technology products that I manage. In other words, building things that people will use that will make them better, and building them collaboratively.
Product/market fit depends on many things, from when we build and release something and how we do it, to where and when we do it and if we’re the right entity to do it, and more. It’s an interesting science.
While as a PM I don’t micromanage or own any of the conditions, it is my job to know who understands each part deeply, and check if every part is in good alignment with the overall direction. That is, the direction that ensures what we build collaboratively will be adopted by its targeted end user, whether it’s an internal product or one that millions of consumers will use.
Bridging teams and departments, for product/market fit
Now, to create that alignment, given that you’re not coming from a position of authority (you’re not anyone’s manager, but a product manager) you probably need to know a bit about everything all the involved parties do, and do what helps to bring them closer. That might require you to rethink processes, address personal relationships, acquire tools, etc.
In 2018, I was doing a product management internship at an AI startup where my manager sent me an article about the existential crisis of life as a product manager. It was quite a hilariously realistic article about the job’s struggles that I could finally appreciate by that point in my internship, and it also introduced me to the term Bus Factor:
“Bus factor is a term used to describe how critical a person is to the team. i.e. If a team member was hit by a bus, how badly would the project suffer? Well, I’ve got some downer news for you… your bus factor [as a PM] is low, it might even be lower than the intern’s.”
PM-less product development
Recently, I joined an engineering team that didn’t have a product manager for about a year but had consistently developed in-house products for our Marketers and Designers. This team had developed products that could multiply our company’s ability to create and test multi-million dollar customer acquisition funnels.
There was just one problem: one year after the development of the product, users had yet to migrate and adopt the product.
I come from a CS background and I have a thing for optimising systems and organisation, whether human systems or computer systems, so this immediately felt like quite an organisational case study, making me wanna look into the docs to see how we develop products and measure success/failure.
Before the bus accident
However, since our state of documentation was a mess, I decided to go on a hyper curious journey of asking people these question instead:
- “Where do product ideas come from?”
- “How do we observe customer behaviour?”
- “How do we define success and failure and track them?”
- “How do we prioritise what we build in each sprint?”
- “How do we communicate requirements and dev release scope?”
- “WHERE ARE THE USER FLOW DIAGRAMS AND WIREFRAMES?” 😱😆 (there weren’t any)
After the bus accident
The fact that it took me quite some time to answer these questions made me think about the bus again.
In fact, it suddenly felt like I was joining a team, after its previous PM was hit by a bus, except the previous PM hadn’t gotten the chance to really minimise her bus factor.
Prior to this, I had a mini vision of how I could be useful to the company, but at this point, after the bus situation, I started rethinking the best ways I could add value. After some advice-seeking and thinking, I concluded I wanted to minimise my bus factor, as I work to successfully discover and manage products from 0 to 100 or infinity.
So here I was, trying to become extremely useful, hoping to then make myself useless over time.
Minimum Viable Bus Factor
If you understand the concept of Minimum Viable Product, then I guess you could probably appreciate a Minimum Viable Bus Factor for product managers, too.
Product managers are aligning people, full time, because alignment is missing. So theoretically if perfect alignment is achieved, then you shouldn’t need a full time glue. Is that a finite game or is it infinite? I don’t know.
The goal is to actively understand what it is that’s bad for alignment, what it is that creates bottlenecks in the way multiple teams and departments work to achieve one amazing product for users, and to create a way to sustainably deal with that bottleneck and its cause.
Sure, sometimes all you can do is fight the fire in the moment, which means you might de-prioritise sustainability, but given the cost that tech debt [or any sort of organisational debt that firefighting] can cause in the long run, I actively think and try learning how to make access to that shared pool of meaning easier, for all parties involved in developing a product.
In the next part, I’ll share what I’m learning about making myself increasingly less needed in how we develop great products as a company :)