Do large startups have too many Product Managers ??
This is the second part of a two part article. For part 1, click here
As I covered in my previous article, a majority of Zomato’s revenue seems to go to cover the relatively high employee costs. Hence the question remains, are food aggregators really the technologically driven algorithmic platforms run efficiently with minimal costs that they were envisioned to be or are they giant operational leviathans that operate within the veneer of a technological veil.
Where did it all go wrong? And the answer to this question lies I believe in the provocative headline for this article.
Now let me first put a few caveats or disclaimers here, everything written next is mere speculation on my side and need not reflect any of the current organization that are operational. I do not profess to know or have information that can attribute the below to any current organization and the below speculation is piece of fiction with any resemblance to current players being merely coincidental.
My speculation is that a lot of startups today have large teams looking for problems to solve. This I believe is across teams from Business to Product.
For example, on the business side, an ecommerce company might have a large business team of 15–20 folks working on managing demand for a category with levers that can effectively only move a few percentage points? Can the same be not run on auto-pilot basis with a skeleton crew?
I believe this to be more prominent in the case of product teams where product initiatives are prioritized basis generous assumptions and non-profit metrics like Gross Merchandise Value (GMV) or Customer NPS (Net Promoter Score) where attribution to future profits is speculative.
Let’s take an illustration, today there might be a product team responsible for search experience in a Food aggregator. The product team will be working on various initiatives to improve efficacy of search, primarily the search conversions. Given the maturity of food aggregators, the initiatives might result in an increase in search conversion by 50 bps (This is in fact at the higher side). And assuming search accounts for 70% of all orders, this would translate to 35 bps improvement in overall conversion.
Taking Zomato’s annual report as a Proxy for our hypothetical food aggregator, let us assume annual revenues of ₹20,000 crores and also assume the food aggregator is profitable at a rate of 3% of Gross Order value (15% EBITDA). A 35 bps improvement in conversion translates to ₹2 crores in additional profits. Now the product team might consist of 5 product managers across levels and at least a feature crew of 10–15 engineers. We can easily estimate the cost of this product + engineering team, including the additional costs associated with employment (Desk space, HR, IT support, etc etc). This translates to ₹ 8 crores of cost for running this team which in the best case can generate an additional profit of ₹2 crores.
Now of course this does not reflect the entirety, the employee cost is one-time expense whereas the conversion increment is lifelong and hence it is not apples to apples comparison. But then we would need to calculate the Net Present Values NPV which is a complex exercise. We also have to consider that most Food aggregators are at loss, and they might become potentially profitable in the future. Assuming growth multipliers and cost of capital, the value of NPV will still end up negative in many cases (given the highly discounting nature of future values and high cost of capital).
The larger point is that in mature startups (typically large unicorns or decacorns), the product and engineering teams are currently building features in need of problems to solve rather than the other way round. This entails over optimization a lot of the time, which will not deliver value for the requisite investment in time and resources.
In the initial days of a startup, there are small teams working across the entire breadth of the platform. As everything is being built from scratch, there typically are more problems to solve than available resources. And there are so many low hanging problems that solving each would tremendously bring value to the platform. Think of the first recommendation that is built or search engine that is more than a plain text query match. Hence investing in building features makes perfect sense.
But as startups grow, the platform product functions become increasingly specialized with large teams working on individual functions. As a startup you could have one product manager managing search & recommendations, as it matures, you might have large teams of anywhere between 5–10 working for search function alone. This is especially true as they mature post the unicorn stage where levels and hierarchies are added.
However, the startup would have already optimized a lot in its journey from a small seed funded startup to Series C,D,E one. The obvious inefficiencies have been solved and now the only innovation is highly incremental. Hence you end up in this inverted structure with large teams trying to solve for 10bps improvements on the platform.
Now you could justify that 10 bps today might not be large but, in few years when the firm is 10X in revenue, it would provide value. But that is a flawed argument. To take an analogy, a developing country needs good roads to improve overall logistics efficiency. If a new 6 lane road increased avg. speed from 80 to 120 kmph, then the investment to build it would make sense, but increasing it further to an 8 lane road resulting in increase in avg speed to only 125 kmph(as the vehicles are not equipped for the same) is a sheer waste of investment. There might a time in the future when 8 lane road is justified but not today. Startups need to understand the same.
The problem is that today few startups take a critical thinking approach to their organization structure. Rather than having teams for specific problems that will derive highest value to the organization at that moment of time, problems are sought after from the existing teams and prioritized. The prioritization again is not done critically without uniform metrics. Few features are measured on Revenue or GMV impact, few on NPS, few on margins and few others on other metrics. And these themselves are built on wildly optimistic scenarios.
Additionally, startups by the nature of their growth typically tend to not build modular functional units. This means there are no plug and play functions that other teams could leverage. This results in a dedicated functional team owning that functional stack who needs to build customized solution to each use case from other teams and ensuring no conflicts across different use cases. This need for functional bureaucracy to manage functional complexity is an inefficiency that needs to be tackled but is not in many cases.
Thus a leviathan product bureaucratic organization comes into being. This leviathan is pulled into different directions by the various functional teams chasing minor increments in innovations. The firm struggles to pull of any single focused large innovation that can bring about step change in derived value. And not only that, but the very cost of this leviathan also becomes a drag for the survivability of the startups with outsized impact on profitability. There is a high chance that product organization accounts for 2/3 share of the employee expenses in most of these startups with employee expenses themselves taking a large share like we saw in the case of Zomato.
This is indeed a difficult problem to solve. Mature startups by their very nature have become big, operational, and bureaucratic and large-scale systemic change is exceedingly difficult. Especially where the change entails entire restructuring from the ground up.
Before the Global Financial Crisis (GFC) of 2007–08, there was a bubble in financial jobs. Today we see something similar in product management driven by the large growth of startups. While the long-term potential product management still exists with every business getting technologized but in the short term, there is scope for correction.
