So you have done your research – met with customers, talked to sales, studied the competition, read analysts’ reports, brainstormed with engineering, etc. etc. You now have a comprehensive list of requirements (or features) which you can justify based on all the legwork you’ve done.  Surprise! Your product development team simply can’t implement them all…

A seasoned program manager once told me: “The three main attributes of any product release are Content, Schedule and Quality. With a given set of resources, you can only set two out of the three. The third one you just have to accept.”

For example: if you define a threshold for product release quality, and you select a minimum set of features, then you have to accept whatever schedule is dictated by quality and content. Or, if you choose minimum functionality, and set in stone the release date, then you need to accept whatever quality comes out (hint: be careful about compromising quality).

Since resources are always finite, and schedules are often determined by other considerations (e.g. we need a release in Q4 to boost sales…), then “content” is usually the biggest decision dilemma. What features should be included in any particular product release is probably the biggest element of contention a product manager has to deal with. The best way to tackle that challenge is through careful prioritization. Note that prioritization is time dependent, since market conditions and customer needs change over time.

I have come across and personally tried many prioritization systems. Personally I believe that any ranking system that has more than 3 levels may simply create too much “noise”. Dividing requirements into Priority 1/2/3 lists is hard enough. You don’t need Priority 4/5/6… A simple way to define those categories is:

  • P1: these features must be part of the release. You will hold the release till their completion.
  • P2: these are highly desirable. You will not “hold the release” without them.
  • P3: these features are nice to have. Should be implemented if there are extra time resources.

How do you go decide which requirement falls into what priority level? This is a process that involves some quantitative analysis, some qualitative analysis and a healthy dose of intuition. There typically several parameters that can be considered for each requirement. Some of them are:

  • Revenue impact: try to put a monetary value on each specific feature. Ask yourself the following questions: Are there new revenues that will be driven by this feature? Any potential lost revenues if the feature doesn’t get implemented? Is there a large deal the company might win, or lose based on this feature? Some of these questions may hard or impossible to answer for a given feature. However doing the “revenue impact” exercise will prove to be very valuable during the ranking process.
  • Strategic customers: list the main customers who expressed a need, or specifically asked for a given feature.  Each company has “must win” (or “must retain”) customers it considers strategic. Satisfying their key requirements takes precedence.  
  • Customer commitment: is there a commitment made to specific customers about implementing this feature? Was it a hard commitment or just a vague promise? What are the implications of not meeting that commitment?
  • Competitive positioning: what do competitors offer with regards to this feature? How will implementing it, or not, impact our advantages/disadvantages vs. key competitors?  
  • Implementation cost: this is a tricky one to assess at times. But if you can gather such information from your engineering counter parts, it can become extremely useful during the ranking order. As said, resources are always finite. And you want to avoid situations where too many of these resources are tied down with implementing a single feature.

The above list of parameters is not cast in stone. Each company business is different, and there may very well be other parameters to consider as part of the prioritization process. It is highly advisable however to adopt a “process” for ranking features. It enables product managers to justify the priority assigned to a feature, and makes the release content negotiation more productive and less contentious.

There are various tools that can be used for requirement tracking and prioritization. Some organizations adopt a “requirement tracking system” which includes a database and a set of tools for creating and tracing requirements. Clearly, for large projects and hundreds or thousands of requirements you definitely need a tool like that. However for most products, a properly constructed spreadsheet will suffice. You may start with a simple table that lists each feature, the associated ranking parameters (as listed above) and the assigned priority. This can evolve to include formulas that calculate “scores” for each feature based on values assigned to the different parameters, and so on.

I stated above that a healthy dose of intuition is also required. Let me elaborate: prioritizing requirements isn’t just a mechanical process – plug in the values and the desired release content comes out. Like Wayne Gretzky, the famous ice hockey player once said: “I skate to where the puck is going to be, not where it has been”. A product manager needs to make an “educated guess” about how the product will fair in a future market condition. In making that guess, there is certainly room for personal experience and intuition.