There was once a skit on the television show “Saturday Night Live” where a long time nuclear power plant manager was attending his retirement party. One of his younger coworkers asked him to share his secret for having a perfect safety record during his many years as a plant manager. He replied to the group, “It’s very simple. I follow one rule. You can never have too much heavy water.” All of the coworkers nodded in agreement at these words of wisdom.
The next day, with the seasoned veteran away beginning his retirement, the new plant manager decided to put the wisdom learned the previous evening to work. He ordered an increase in the reactor’s heavy water levels. Immediately, others piped in, questioning what was going on. “No. No. No.” said someone. “You can NEVER have too much heavy water. You need to LOWER the levels, not raise them.” Others then joined the debate, each providing their own personal interpretation of what needed to be done. Some argued for increasing levels, others argued for decreasing levels. In the end, the new plant manager conceded that his interpretation had been wrong and ordered significant reductions in the reactor’s heavy water levels. Needless to say, disaster ensued.
I like this story because I’ve seen similar situations in companies many times, and, as a product manager, I’ve seen this specifically when discussing requirements during product planning. Everyone who had even the smallest amount of anecdotal customer information became the expert on customer or market needs and thus what should or shouldn’t go into the next release of the product. Personal interpretation would trump hard analysis and emotional arguments would replace logical thought.
How many “product managers” do you have?
Try this. Count the number of people in your company who presume to have or assume some part of the product management role. I’m not talking about people who influence product direction, but about people who actively take on tasks and/or decisions that rightfully belong to product management. I’m pretty sure the number is significantly larger than the actual number of people in your product management team. This group probably includes, among other people, software development managers, product architects, product marketing managers, members of the executive team, and in some companies, shockingly enough, even sales people and sales engineers.
Why does this happen? From a positive perspective, everyone wants to make sure that the planned product is the best it can be (it’s easy to be idealistic in the planning stages of any project) and they want to make sure their input is heard and accommodated into the plan. From a negative perspective, it may be because of many reasons such as company culture, personalities, egos, etc. But with respect to product management, it is usually because product managers have not made their case with sufficient hard data, examples and supporting information to ensure that emotion and unsubstantiated opinion have no place at the discussion table. If the justifications that are presented by product management are weak and open to debate, they will be challenged, and in many cases attacked, by other stakeholders in the product.
And why can’t product management make a strong enough case? Assuming they are competent product managers, the primary reason is that there are not enough product management resources to get the job done. In most companies I’ve seen, not only are there too few product managers, but the very nature of the role requires them to spread their time over multiple tasks and priorities. Product managers are called upon to work with marketing as product evangelists, to help sales reps working on strategic deals, to manage internal cross-functional processes, to provide competitive information, to demonstrate software in highly competitive situations and much more. Not that product managers shouldn’t be involved in these areas, but when defining the necessary number of product managers to adequately manage a given product, these tasks need to be taken into account. Additionally, product management needs to be staffed to be proactive and forward looking in their work.
It’s about optimization
The work of product management is really about solving an optimization problem. In short, how to optimize a finite set of engineering resources to implement the optimal set of product features that best solve the diverse needs of the target audience. In addition, product managers must also be instrumental in shepherding the product through the development and release cycle, working with downstream groups such as marketing, sales and technical support to transfer information and knowledge to them so they can be optimal in their jobs. This is clearly an important role, and certainly one that needs to be properly staffed to ensure work is done with the right levels of depth, detail and diligence.
I’ve seen (and in fact worked in) organizations where there was one, or perhaps two product managers working with multiple development teams. In one case there were six software architects and five large engineering teams (development, QA and documentation) totaling about 100 people in all. Additionally, a large number of the developers were based off-shore, significantly increasing the demand for time and information from product management. Now look at those numbers: 100 technical people distributed globally, working with and relying on 2 product managers. Where do you think the bottleneck was? What do you think the most common complaint was from engineering? If you said “We don’t have sufficient requirements from product management.” you win a prize, though not a big one, because it was an easy question. By the way, have you ever heard a complaint like that before? Many times I’m sure.
So, here we have 100 trained technical people, whose efficiency is being hampered because of a lack of sufficient requirements. Granted, engineering doesn’t just sit still. They are busy trying to fill the gaps in the requirements and meet their deadlines; but the more assumptions they must make when specific customer requirements aren’t available, then the less likely it will be that the final product will directly address customer needs. In many cases, because of the uncertainty, unnecessary features (and thus complexity) are introduced because “a customer might need it,” or necessary features are not implemented because the understanding of the real customer use cases do not exist. Then, once the software is shipped, customers will need to use workarounds or spend more time to get the tasks they need done with the released software. In effect, the lack of resources in the original product management staff has been translated into additional work and resource requirements for the end customers. And how many customers is that? Well it depends of course on the company, it’s market and customer base, but for enterprise software, which is the market I currently work in, the direct impact is on many thousands, if not many tens of thousands of direct users. The indirect impact is of course, significantly greater.
The problem does not end here. Finally, and most importantly, poorly defined and implemented functionality increases the sales cycle (thus reducing revenues), increases customer support load (thus increasing expenses), and increases the workload of engineering who must go back and fix the deficient functionality in future releases (thus reducing capacity to innovate and address new concerns). This is far from an optimal situation.
Think value, not simply headcount
I’ve seen this happen time and time again in companies who didn’t truly understand the role and value that product management brings to the table. In the example I gave above, about 100 people in an engineering team were relying on 2 product managers. That is a ratio of 50:1. How did it get that way? Using traditional thinking, as the company grew, and in an effort to build more product sooner, the headcount for software engineers and quality assurance staff was increased over time. This happens in most companies. It is very clear what a software engineer does. You can measure their value by the amount of solid code they write or new functionality they implement. What does a product manager do? Well, they write requirements, don’t they? They help marketing and engineering and sales, correct? They are “cross-functional leaders.” They are the “hub of the wheel.” I’ve heard the last phrase many times, but what does it actually mean? Well, in every wheel I know, there is only one hub, regardless of how big it is or how many spokes it has. And what does the hub do? It connects the wheel to the axle. People care about wheels and they care about axles, but I don’t know anyone who actively cares about the hubs. They just expect them to keep the wheels and axles connected. You see where this leads?
The role and real value of product management is ill-defined and ill-understood in most companies. Yes, every software company has product managers, but very few could actually answer the question, “how much additional value can one additional product manager bring?” Now if you replaced the role “product manager” with the role of “engineer” or “salesperson” in the question above, there is no doubt that companies could answer those questions very easily.
What is the optimum ratio for engineers and product managers? The answer depends on many factors, such as company size, the product maturity, the amount of innovation needed in the product, and the level of competition the company is facing. The answer also depends on the maturity of the development teams and capabilities of senior members of those teams to guide the engineering effort forward and make the right decisions when necessary. Additionally, working with offshore development groups requires more effort, more coordination, and more upfront information than does working onshore.
Unfortunately, I’ve seen companies shift large development teams offshore yet never change the headcount of their product management group, who remained onshore. The additional work required to coordinate the offshore effort takes so much time that the product management group can effectively become program managers and have little or no time to actually perform forward looking product management duties such as requirements gathering and roadmap planning.
Getting back to the ratios, for a mature product without much competition and which doesn’t require much innovation, perhaps 50:1 is the right ratio. But for companies who are looking to innovate, have aggressive development plans, or face stiff competition, this is clearly insufficient. In my experience, I’d say a ratio of 10:1 or 20:1 at the most is a reasonable ratio. Keep in mind that this is not simply a ratio of software developers to product managers, but includes associated QA and documentation headcount as well. The impact of ill-defined requirements is not limited only to software engineers, but also affects the ability of QA to accurate create and verify test cases. Additional functionality added by engineering (“just in case”) must be tested and documented by the QA and documentation teams respectively.
As a sanity check, this means that for the 100 member development organization, the recommendation is to raise the number of product managers from 2 up to somewhere between 5 and 10. In my opinion, this is not a lot, but not all people may agree. If you don’t agree, think about the impact these few people will have on the entire downstream chain that are dependant on product management. The 100 member engineering group will have their efforts optimized, the entire sales team, probably twice as big as the engineering group, will be able to shorten the sales cycle and generate revenue sooner, the support organization, under decreased load with be able to reduce new hiring, and finally the customer base, who get their jobs done faster and are increasingly happy with the vendor, may decide to purchase more of that vendors product sooner than previously planned.
In short, even if you don’t take customer numbers into account, a small increase in product management of, in this case, less than 10 people will optimize the efforts of several hundred individuals, will increase revenue and decrease overall expenses. From a pure business perspective, there is no doubt in my mind that the return on investment would make even the most aggressive investors quite happy.
