Prioritizing Product Requirements using T

By Subraya Mallya - November 2013 | Topics - Product Management

Product Management teams have always had to deal with competing priorities when it came to defining the roadmap and what goes into it. A product roadmap is fluid and evolves as the customer base expands or based on larger market demands. It is easy to get into a product features’ arm race with the competition in an effort to check all the boxes.

Requirements come in all shapes and forms. They could be Executive whim, one-upmanship with the competition and if nothing else there is always the Gartner “magic” quadrant that compels teams to build things that in hindsight would look stupid.

With all the barrage of requests for new features/enhancements, how does a Product Manager prioritize?  The budget implications and schedules of people come later. First thing that has to be decided is what makes it to the train. We have all had this quandary. Back when we were building large enterprise products, we used to spend hours arguing the merits (or lack thereof) of one feature vis-a-vis another. Finally settle for something only to hear back from the field that some critical deal is getting delayed due to lack of that other feature we left out.

A simple yet powerful technique that I have used in my teams to prioritize features is the T. Yes the same T we were taught while learning the basics of Accounting. Only instead of using Debits and Credits on either side, we use Creates Revenue  and Saves additional Cost

Looking differently, I am looking at the economic outcomes that customers are seeking and prioritizing capabilities that will help them achieve those.

I contend that all product requirements should fall into one of these two sides. They either generate new revenue for your customers or deliver new cost savings. Or they don’t make the cut. All other whimsical criteria like “my CEO thinks this is cool”, “my VP thinks this should go” or “my CEO has seen this happen in his past life” need to be shot down.

I would also suggest that as Product Managers you arrive at this in your discussion with customers when they suggest/request new enhancements or features. Most of them might not know right off the top how a particular feature would bring new revenue or save cost. They are in most cases living in their own realm. The requirement could come in the form of “I can request and get paid faster” or “I can finish processing these claims faster” or “I could get through more orders in a day”. Hidden in each of them would be the real driver – Additional Revenue or Additional cost savings. Until (at least in your mind) you arrive at that, keep drilling down into the need.

Besides helping in prioritizing the requirements, the “T” also gives

  • Marketing,  ammunition to write new collateral, positioning and other marketing messages. New PR could be generated with content like “Our new product version will increase revenue for our customers in the areas of ……”
  • Sales, new ways to pitch your product (think “Our new version generated $M revenue for customer X)
  • Product Team, a clear understanding of how their product contributes to the success of their customers.

While there maybe initial resistance from the been-there-done-that product managers, eventually they do see the merit of using this criteria to weed out non-essential feature creep.

Back to Top