Feature Prioritization *New*


Back in 2011, I made this blog post on prioritization of product features, and the prioritization template looked like this.

Over the years, I have been updating the format and refining it to ensure it articulates the objective prioritization and shepherds the product towards product-market fit — the latest is here.

In general, features will have to be categorized into three backlogs. The backlogs have been named by lifting NBA terminology for self explanation.

  • Offensive Play — features that aid revenue generation and acquire new customers
  • Defensive Play — features that aid in delighting and retaining existing customers
  • Time out — features that aid cost cutting such as those that reduce product returns, reduce customer service costs, improve operational efficiency, tech deprioritizationbt, etc.

Product Managers will have to ensure appropriate ‘plays’ are adopted depending on business needs, including a mix of features from more than one backlog in a release, for creating customer value, generating competitive advantage, and delivering profitability.

Few takeaways:

  • Strike the right balance between offensive and defensive plays
  • Features that can be implemented in a shorter time are *not* always the ‘right thing’ to do
  • Always look at relative priority and the objective impact a feature will have on customer value, ROI, and overall purpose

Would love to hear what’s on your mind!

Prioritization of Product Features


I have been thinking of doing a post on the topic of prioritizing product features for quite sometime as most product managers do this activity regularly. Product Managers in many companies do the prioritization exercise differently, but I’ve attempted an approach which I believe is comprehensive.

Here’s an approach I’ve followed in my experience — I call it the “Business Value Model”. The prioritization activity involves assigning “weights” (in the form of unit-less points) for each feature in the backlog against a variety of parameters such as the following:

  1. Value: the value of the feature will be a function of Benefits and the associated Effort Estimate.
    • Value = f (benefit, effort estimate)
    • Benefits: assign a number (from 1-10) for each of the benefits the feature provides. The benefits must be from customer requests.
    • Effort Estimate: assign a number (from 1-10) depending on the effort estimate from a look-up table. Something like 1 for 3 days, 2 for a week’s effort, 3 for 2 weeks effort, and so on.
  2. Benefiting Customer Size: a number (from 1-10) depending on what percentage of existing customers would benefit from the feature.
  3. Benefiting Market Size: a number (from 1-10) depending on what percentage of prospects in the open market (i.e. potential customers in the pipeline, general market, etc.) would benefit from the feature.
  4. Competitive Necessity: have just a handful of numbers to choose from depending on what the feature will do to the product with respect to the competition. For example:  2 for closer-to-competition, 5 for competitive-parity, 10 for beats-competition.
  5. Strategic Requirement: assign a number (from 1-10) depending on the alignment of the feature with business strategy, product vision, etc.

The framework is available for download here: PrioritizationTemplate

Remember: Every new feature will need to be looked upon from the angle of tapping new markets. Here’s an excerpt from one of my earlier posts, related to Win-Loss Analysis: Some customers might have unique needs which we might not even be aware already. In such a case, it is essential to profile the customer and research the need in the market place — may be we will end up discovering completely new market segments which we can go after once we have built the required product capabilities.

Would love to hear your thoughts!!!