How to prioritize in a complex ecosystem

While the role and boundaries of a Product Manager (PM) is often debated and tends to vary across organizations, almost everyone would agree a PM is responsible for prioritization. PM has the unenviable task of balancing several short and long term objectives to arrive at the what and when for the product team.

To ensure that prioritization is customer and data backed, a PM has to define the structure, identifying the factors that will influence the decisions. This is different for each company and particularly depends on the maturity of the product.

For an early stage product (and in many cases, an early stage company) that is still trying to find the product market fit, the levers for prioritization center around definition of an Minimum Viable Product (MVP), trading off features that are most critical for a narrowly defined target customer against time to market. For instance, if you are building a mobile advertising platform, building the core capabilities to serve a targeted ad is infinitely more critical than building a user authorization framework. This is true even if you have an existing authorization framework that you can easily integrate with and even if it is obvious you will need to build authorization later if you want to scale.

At the other end of the spectrum is a mature product with a large existing base. Several areas of the product and the ecosystem it operates within need constant attention. A PM has to balance the needs of multiple customer segments, respond to competitive moves to maintain differentiation, address persistent product issues from the field, keep sales channels happy, support marketing initiatives, invest for the long term, clear technology debt (e.g. refactoring) and tend to technology refresh items which require you to keep sprinting just to stand still. How do you prioritize in such a complex ecosystem?

Identify product priorities

First step is to identify what areas the product team should focus on and their relative priorities. This is largely determined by business unit or company strategy which is then applied to the product. These priorities of course evolve over time through the product’s lifecycle.

Note that this exercise is as much about deciding what you will focus on as it is about being clear to the entire organization on what you won’t. For instance, while the partnership manager may want an open API so she can onboard partners faster, as a product team, you could decide building an API is not a focus for the next year.

Decide relative investment for each priority

Stack rank your priorities to determine relative investment on each priority. When you are working on an early stage product, your priorities are fewer and resource allocation is then simply a tradeoff between value and effort, where value could be a proxy for customer growth, customer benefit, revenue etc. Plotting initiatives on a simple 2X2 with value on one axis and effort on the other could be sufficient to arrive at a prioritized roadmap.

A mature product is a different beast. For starters, as described earlier, the list of priorities is uncomfortably long. This does not lend itself well to a visual representation that can guide decision making. Given resources are always at a premium, it is a given that you cannot do justice to each priority. Equally, you cannot start allocating resources starting from the top and working your way down because you have minimum requirements even for the lower priority areas. For instance, a product team might decide to deprioritize technology refresh for the upcoming year given significant investment in the preceding year. However, a third-party component (e.g. jdk) in the technology stack is approaching end of life and has to be upgraded. How do you prioritize this over higher priority items?

Layered approach to prioritization

While stack ranking priorities is important, the trick is to realize that each priority has some mandatory requirements that you cannot ignore.

For each priority, identify the following:

  1. Routine: These are activities that you do every year, no questions asked. This could include capacity you typically allocate for bug fixing, regression testing, compliance (e.g. for a payroll or tax product), technology refresh etc. Allocate resources to these initiatives across all priorities first. If these initiatives are not adequately resourced, the product will not have legs to stand on by end of year. So, don’t waste time debating relative priorities of these initiatives.
  2. Minimum: Once you have the bases covered, identify minimum commitments you want make as a product team across each priority. For instance, you could decide that matching a certain competitor gap is a must for next year. However, an enhancement on the same feature that could be a product differentiator is a nice to have or discretionary. We will talk about these shortly. As a PM, you have to be brutal here and think hard before marking something as a minimum, managing expectations of different stakeholders and their pet projects.
  3. Discretionary: A mature product typically consumes bulk of your resourcing only for Routine and Minimum initiatives. At this stage, you should be left with precious little resources which require utmost due diligence in prioritization. The easy part is that prioritization at this stage starts to resemble prioritization for an early stage product, as described earlier. So, you can apply a simple framework such as value vs. effort to identify the handful of initiatives you will fund.

Horses for courses

Mastering prioritization is a key skill for a PM. Your choice of prioritization framework should depend on the circumstances of your product. There is no one size fits all.

Have you applied a different approach that has worked well for you?

Recommend here or share on LinkedIn if you found this useful so I know I should write more.