Product requirements and requirement prioritization

Requirement prioritization helps you to decide which product requirements to build first. By prioritizing, if you cannot complete the entire list, you will at least be able to complete the most important features.

Your product roadmap defines a theme or date for a product release. When you accumulate all of your product requirements for the release, invariably there will be too many to fit into one release. You will have to decide whether you will be working with a set release date or not (for more information, see the article, The product release and the project triangle: Scope, cost and schedule). If you decide on a set release date, then you must decide which requirements to include.

The following steps will help you create and order your list of product requirements based on the overall priorities of your company.

Step 1: Determine your company’s current primary focus

When prioritizing product requirements, identify your company’s current primary focus from among the ones listed below. This primary focus is usually driven by your stage on the technology adoption curve (for more information, see Prioritizing your product roadmap).

• Do you need to execute your product strategy? (That is, the focus is on product strategy.)
• Do you need new customers? (That is, the focus is on new customers.)
• Do you need to keep existing customers happy? (That is, the focus is on existing customers.)
• Do you need to build technical building blocks for future projects? (That is, the focus is on technical dependencies.)

Your company may be focused on more than one of these at a single time. However, there will be one that drives many of your decisions right now, which makes it the most important. Rank the list above according to your company’s current priority; you may choose to add additional focus areas.

Step 2: Categorize each requirement based on the area of focus

Using the list above, review each of your requirements and decide which area of focus it supports; this will categorize each requirement.

• Product strategy: Determine if the requirement is important for executing your product strategy.
• New customers (revenue): Determine if the requirement will generate revenue or attract new customers.
• Existing customers (maintenance and reference customers): Determine how often customers will use this feature, and how many have requested it.
• Technical dependencies: Determine any technical dependencies of this feature.

Note: You may notice that some requirements will belong to more than one category. This will make the requirement even more important to your business.

Step 3: Rank each requirement within its category

Once you have categorized all your requirements, the next step is to determine how well they support this category (area of focus). The more the requirement supports the category, the more important it is. This evaluation is best done using a ranking of 1 to 10 (lowest to highest). The range of the ranking may vary for your business, but keep it consistent across all categories.

How you determine the requirement’s importance will depend on the category:

• Product strategy: The more it supports the product strategy, the more important it is and the higher it ranks.
• New customers (revenue): More revenue = more important. To create rankings of 1 to 10 for revenue, create a grid (thus $10,000 may be a 1, while $1,000,000 may be a 10).
• Existing customers (maintenance): More customers and more requests = more important.
• Technical dependencies: More dependencies = more important. For example, if a contact entry feature is not delivered for a word-processing tool, then a mail merge is not possible.

Note: This process is not an exact science, but it ensures that you apply a consistent methodology across each requirement.

Step 4: Calculate each requirement’s weighted ranking

Once you have rankings and categories for each requirement, you can create a weighted ranking for each requirement. Weighted rankings result in numbers that are calculated to show the absolute importance of the requirement as compared to others. It does not matter that the requirements might all be very different; this method allows them all to be compared equivalently (apples to apples).

To calculate the weighted rankings:

1. Assign a level of importance to each category. For example, if you decided in step 1 that your primary goal was revenue, then rank this as the most important. This may mean that for you, revenue may be scored at 50, with perhaps strategy coming in at 40, maintenance at 10 and technology at 10.
2. Multiply the category value by the ranking value. (That is, multiply the ranking you determined in step 3 by the category importance.) This method results in one number for every requirement.

Example

Imagine that the following two requirements must be ranked:

1. “Customer import” feature: This has been requested by five prospects, and will win the company approximately $50,000 in new revenue.
2. “Password reminder” feature: Ten customers have requested this.

According to this weighted ranking, although they are very different requirements, the“Customer import” feature ranked much higher than the“Password reminder” feature.

Validating your weighted rankings

Once you have ranked all items, you can see how important they are relative to each other. Rely on your experience to review the list, to determine which features seem to be out of order, to identify flaws in weighting and to understand why an item is important. The system of weighted ranking is not perfect, but it provides a methodology to evaluate each requirement objectively. It can also provide a point of discussion.

Priorities change over time

As you evolve your product over time, your weightings will change. Be sure to regularly revisit your primary area of focus to examine if your priorities have changed. Once you understand the business priorities of your requirements, the next process is to assess the cost to build the solution. This way you decide what to include in your release.

Note: For more information on product requirements, refer to the other five articles in this series:

• Creating product requirements
• Product requirements template
• Validating product requirements
• Understanding the cost of product requirements
• Determining the product release

References

Davis, S. (2008). Requirement Ranking– No, No, No to High, Medium or Low. Retrieved August 9, 2010, from http://www.requirements.net/2008/04/25/requirement-ranking-no-no-no-to-high-medium-or-low/
Murphy, J. (2005). Getting Your Priorities Straight: A Twisted Path. Retrieved August 9, 2010, from http://www.pragmaticmarketing.com/publications/topics/05/0501jm2