Product Management Essentials: Corporate vs. Startup Prioritization

Ido Yablonka, Vice President of product management, search, and general manager of the Oath Engineering | Reading Time: 5 min.

While Israel has been blessed with a remarkable engineering talent pool, surprisingly, it is only in recent years that the local software industry succeeded in bridging a significant gap regarding product management. This gap resulted, inter alia, from conceptual reasons - lack of managerial familiarity with this function, and as a result, non-recognition of its importance, as well as manpower constraints given the scarcity of experienced local talent. The impressive speed at which this need was met was mostly achieved through practical, on-the-job-training and self-study, understandably sometimes compromising structured methodology. In this short article, I will analyze one fundamental product management technique, then try to explain how its derivatives differently affect the strategic conduct of corporations and startups.

 The Role of the Product Manager

The profession of the product manager is quite new, its invention commonly and anecdotally attributed to a memo written by Neil H. McElroy of Procter & Gamble in the early 1930s. At the time, Procter owned a large consumer goods product portfolio (as is still the case today) which were typically managed in groups; McElroy identified the need for a "Brand Man" to oversee distribution and marketing in the context of a single product. In current terms, these areas of responsibility fall exclusively under 'outbound' product management, as the role envisioned had no involvement with research and development ('inbound').

While this distinction may work for the typical Procter product (e.g., branded laundry detergent or toothpaste), it is rarely practical in the modern software industry - iterations are too rapid1, the separation between business/market and technology is often fuzzy or downright non-existent, and the company-internal common language simply has to be technical - to the extent a product manager, for the most part, must have at least an engineering background to remain effective. The insight that between the business-oriented and technological skill-sets, the latter is the rarer one - meaning it would actually be easier to supplement - led Marissa Mayer to establish the APM program2 at Google and then Yahoo, essentially equipping fresh-out-of-college engineers with the business chops required to become holistic product managers; the eventual success of the program leading to the establishment of parallel programs in various other companies.

Personally, I find that the most appropriate definition for product management is functional/teleological: the basic responsibility of a product manager is the success of the product, and a good product manager ships successful products, and then maximizes their success over time; everything else, impressive or challenging as it may be, is tactical. Any capability, by itself, is insufficient - you also need to be right, as judged solely by the market.

How to Make a Product Successful

Unfortunately, there's no deterministic way to make a product succeed - it is impossible to force anything down the market's throat - indeed, most new products end in failure. Visions and prophecies, even among the very best, are not much better than the flip of a coin; even great product managers quite often fail. Contrary to common belief, romanticized in the Steve Jobs prototype, the advantage of great product managers does not originate from possessing superior intuition, but rather the speed, efficiency, and perfected method in which they are able to reach a valid conclusion, one way or the other, and adjust their subsequent steps accordingly.

In an attempt to avoid oversimplification, one underlying technique of approaching this ideal is the effective prioritization of possible tasks. The principle is simple: we want maximal value at a minimal cost.

'Value' naturally ought to be defined uniquely per each product, and can be expressed in various continuously measurable metrics, e.g. the number of monthly active users, annual revenue or the new user acquisition cost, but also in terms of de-risking benefits, especially in the early stages of the product life-cycle, e.g. proof or refutation for different critical assumptions in the 'customer discovery'3 stage of the start-up.

'Cost' can be expressed in financial or equivalent required investment, in time cost, in employee capacity; potentially measured as a fraction of all the resources at our disposal, or in "story points" in Agile development methodologies.

If we translate 'value' and 'cost' into a uniform numerical scale, their ratio (or product) is interesting - one could consider it analogous to the Sharpe ratio in finance, or the composite risk index in risk management. Specifically, this ratio provides a highly effective default prioritization. While this is a clearly naive model (not taking into account, for example, task interdependencies, the likelihood of success, non-substitutive costs, the significance of results etc.), it is nevertheless sufficient to demonstrate some immediate conclusions:

  • Any task of value, which cost is zero, must be performed immediately.
  • Between two tasks of identical value, one should always prefer the one with the lower cost, and therefore each task must be structured in advance so as to achieve its goals at the absolute minimal cost.
  • Modularity allows for better resource utilization, and increases as costs decrease; hence, as long as overall efficiency (value-cost) is preserved, and certainly, if it improves, it pays to break tasks into sub-tasks.
  • Between two tasks of the same cost, the one with the higher value should be preferred.

BigCo vs. Startup

Interestingly, these initial conclusions, while applicable in both cases, differently impact startups and corporations:

  • Tasks with an actual cost of zero are nonexistent, but small tasks, sometimes completed in but a few minutes, are very much a reality, at least for startups; for example, a startup product manager may devise a particularly simple experiment and just execute immediately - he may have all the authority and knowledge to do so. On the other hand, a corporate product executive, however senior, must consult with other stakeholders, legal, involved individual contributors, and so on; the decentralization of authority creates a high base cost for each corporate task, a limitation that does not exist for startups, at least in their early stages. 
  • Both corporate and startup product managers can, and should, plan the tasks to achieve their goals at a minimal cost, but for the corporate one, aforementioned base cost increases the cost for every task, and every sub-task, negatively impacting modularity as a result. Instead of being a no-brainer ‘free lunch’, modularity becomes a debatable trade-off between flexibility and overall cost.
  • Let us dwell on the implications of the seemingly trivial fourth conclusion. If we manage a mature corporate product, for the sake of discussion with $3B in annual revenue, the value of a relatively straightforward optimization task that results in a modest 5% improvement in revenue is $150M a year, at an absolute low cost, and a very low cost relative to the company's resources. This task represents a superb value-cost ratio, which will get even better if we weigh in the high likelihood of success.
  • If we run a product for a start-up with next to no revenue, the value of that task is appropriately close to zero. While the absolute cost is identical, the start-up resources are typically very limited, and so the relative cost is high, and the overall value-cost ratio poor.
The point isn’t that it's worthwhile making $3B a year (it is), but rather that under the assumption of optimal prioritization, for both the startup and the corporation, the value of the underlying asset for the latter, or lack thereof for the former, completely changes the result. While there are clear advantages in the corporation’s situation, they come at a heavy price, namely that of being effectively locked-in to a local maximum; any alternative task that is less reliant on the underlying asset will require a higher cost, for a lower value, at a higher risk.

It is precisely because the startup has so little to lose that it is free to strive for the global maximum.

Ido Yablonka is vice president of product management, search, and general manager of the Oath Engineering Center in Tel Aviv. Previously, he co-founded the SigmaLabs accelerator in collaboration with Entree Capital and was the CEO/co-founder of ClarityRay, acquired by Yahoo. He's a graduate of Ofek, the Israeli Air Force's technological unit.

1 How many versions come out each year for Crest toothpaste? How many for Yahoo Mail?
2 Associate Product Managers

Corona Corner