In recognizing that many of our company's developers had been committed to important engineering tasks unrelated to advancing product features, I decided to clearly illustrate our true capacity for product innovation.
The pressure on a Product Manager can be intense at times. On the one hand, you are responsible for answering the deceptively simple question, "what are we planning to do next?" All eyes are turned to you for long term product strategy and the product roadmap. And as the owner of the product roadmap, you will have no shortage of helpful suggestions streaming in, from many strong voices, constantly weighing in on what they think should be done.
Perhaps just as stressful though, is having to address the related but more nagging question, "why can't we get more done?" This was a recurring question in my company as many stakeholders were eager to see us move faster.
These are fair questions from well-meaning people but it didn't take long for me to realize that there was a fundamental misunderstanding at the senior leadership level about our true capacity for product development.
What drove this decision
If you are not directly attached in some way to the software development machinery in your company, then chances are you don't have a good appreciation for all that goes into building solid product features. The decisions that are made by Designers, Engineers, QA, and Operations are just as foreign to other groups as the inner workings of Sales, Marketing, and Finance are to us software types. In our company, though, there was growing frustration with the lack of progress being made on the product side.
The software team I joined had indeed struggled, missing targets, dropping features right before a big release, and generally falling victim to interruptions and emergencies. We have a strong Engineering team but a good number of them were being assigned to tasks that, while important to the company, were not contributing to product innovation.
In my new role as PM, I had a plan to begin a new chapter for product development at our company. Success would depend on building credibility early with stakeholders and a big part of that meant resetting some expectations. Specifically, I would need to explain why I would not be able to achieve as much as they had been expecting. I would have to justify why we weren’t able to accomplish more.
The decision: Publish a straightforward model that would clarify our actual capacity.
Through a number of internal meetings, I learned that members of our talented engineering team had been assigned to work on internal projects such as scaling our core software platform and optimizing our development process. Other team members were allocated to team management or committed to rotating assignments with Customer Support.
The net impact was that the size of our Engineering team had been reduced. The remaining developers were available to work with my Product team on new features but would also have to address bugs that cropped up. Then there were research tasks that did not directly yield new software but would certainly benefit future development. And finally, we had to plan around holidays, vacation days, sick days, and any scheduled technical training.
All in all, there are far fewer available cycles in a Release than one might think.
To clarify our true output capacity to our senior management team, I built a simple scoreboard of sorts for each release that showed how many FTEs were available for product development.
Plan of attack
Normally, I'd relish an opportunity to build some elaborate model but in this case there was no need for fancy diagrams. Instead, I created a simple picture using PowerPoint, similar to the image at the top of this post.
I started by using squares to represent each engineering resource making it easy to visually determine the total number of Engineers on staff. Then, using different colors for each bucket, I identified how many engineers were being assigned to non-product initiatives and labeled each initiative appropriately. I chose to omit specific names in the diagram, even when it was obvious (e.g. team leads).
The result? A clear model that illustrated our company's actual product development capacity.
You could disparage this approach and claim that I had prematurely adopted a defensive posture or taken a pre-emptive CYA step. But our senior leadership team was overdue for a reset. In the weeks that followed, in conversation after conversation I used the diagram to remind everyone exactly why we could NOT move faster.
This led to more productive discussions about resource allocation, hiring decisions, and generally rearranging priorities. And to me, those are the right kind of questions to debate.