As a key part of providing requirements to Development, Product Managers must justify and prioritize their requests for new capabilities for the software. There are always more items on the wish list than there is time, people, or money to do them. This means that hard choices are inevitable.

This is where measuring ROI, or Return on Investment, plays a vital role. ROI guides you in selecting those requirements that are most needed and most helpful out of all the requirements which you and many other teammates and customers have dreamed up.

In a world and a company with limited resources, a Product Manager wants to push the specific requirements which will provide the most benefit to the product and the company. By measuring ROI or ROR (Return on Requirements), you have a consistent scale or score by which to compare and select requirements.

Read on below for some pointers on measuring Return on Requirements.

[private]

Past Issues On Requirements

The issues listed below discuss various aspects of requirements. You can request them by sending an email to jacquesm@epix.net indicating the applicable issue number(s).

02002 – Requirements: From Hype-ful to Helpful

03002 – Requirements: How Much Is Enough?

03011 – Requirements 101: The Requirements Document

03012 – Requirements 201: The Requirements Process

03027 – Requirements: Envisioning the Product

03028 – Clarifying the Why of Requirements

03037 – Requirements: Like Lambs to the Slaughter

It Ain’t Easy

While the notion of an objective and consistent ROI measurement for each requirement sounds great, the reality is that it can be difficult if not impossible to achieve. There are a number of factors at work. First and foremost is the fact that ROI is an estimate or a forecast, prone to the same problems as all forecasts.

As with all forecasts, it becomes necessary to make assumptions. For example, you can make the assumption that every time you cross-sell to an existing customer a new feature that is the subject of a requirement, it will sell for x dollars. Another assumption could be that keeping up with the latest database version is more important than any other factor – future sales appeal, cutting costs, appeal to partners, etc.

If you make assumptions, you must document them, however succinctly, and explain them, and never fail to keep them in mind when you review the resulting ROI figures or scores that you obtain. After determining the ROI for all the requirements, you’ll need to run the list through a final review to make sure that each item passes the “common sense” test, or the “gut check.” A specific capability may wind up with a very high ROI, yet you know in your heart that it isn’t all that vital compared to others.

Hard vs. Soft Roi

There are two basic types of ROI. Hard ROI is a dollar amount, consisting of a dollar estimate of the benefit minus a dollar estimate of the cost. It’s the ROI that sells best in the boardroom. Dollar figures for every requirement gives you an apples-to-apples comparison.

The second type of ROI is Soft ROI. This can best be described as the impact or benefit of a capability. This isn’t expressed in dollar terms. Since different features have different types of impact (cut costs, maintain partner relations), you wind up with an apples-to-oranges comparison. This is a harder sell to the people holding the purse strings.

Bean Counting

Ideally, a Product Manager would be able to attach a dollar figure to every requirement. This figure would be based on the expected revenue and/or cost benefits from the added functionality, minus the expense of building it.

Recent accounting guidelines for software companies (2000 and later) make the dollar figure a useful number that your company’s Finance department can use to recognize revenue and assign costs should you decide to move forward on development of a capability.

If you’re going to go for developing dollar figures, the first step is to recognize that you need help. Go to the bean counters, the people in Finance and Accounting who shape and build numbers all day long. They can help you with assumptions and suggestions for realistic and consistent dollar figures.

Significant Other

For Soft ROI, you’ll face less of a problem defining and specifying the return, and more of a problem justifying and defending it. CEOs who make decisions by the numbers are going to have a hard time weighing the significance of apple against oranges.

Yet customers everywhere, your customers included, are folks just like you and me. That means that their purchasing decisions are the same mixture of emotional and rational decisions we’re familiar with in our own behavior. That means that the Soft ROI plays an important role in buying decisions.

While managers and decision makers may have a hard time quantifying Soft ROI justifications for a requirement, they understand the significance of these justifications. It’s easy to measure the dollar impact of cost cutting. But managers also understand the significance of such things as improved customer loyalty, even if they can’t assign a dollar amount to it. They know how important loyalty is to the success of the company.

Here are some examples of Soft ROI justifications:

Cut implementation costs

Improve appeal to partners

Compete with Competitor X

Become the market leader in Y

Remain up to date on technical platform

Sales appeal

Meet market expectations

Estimating Sales Dollars

If you build Hard ROI numbers, you’ll be called upon to estimate the positive impact on sales of a feature. Here’s an example of the reasoning you can use:

“Each sale is $100K. We forecast 30 sales this year (1% of a market population of 3,000 companies). Adding Feature X will be a deciding factor in 2 of those sales. It will be one of 4 deciding factors against the competition, so it will count for 1 quarter of the sale, or $25K, times 2 sales, or $50K. Therefore this feature will lead to $50K in additional sales this year.”

At What Cost Victory?

Another important component of ROI is the cost to you to add a capability. Be sure to subtract the forecast cost from the forecast increase in sales. If you are using Soft ROI, you can at the very least create a separate Cost column to track against the soft benefit in the ROI column.

Cost includes development hours times fully loaded hourly cost for developers. It also includes developer time for any training, as well as the cost of software and hardware tools required to add the capability.

Scoring

If neither the dollar amounts nor a relatively vague Soft ROI are satisfactory, consider creating a scoring system. Here’s an example:

Add 3 if a requirement is architecturally required (latest database version, new hardware compatibility)

Add 1 if the requirement will bring in under $500K in additional sales revenue, or

Add 2 if it will bring in over $500K

Add 1 if a requirement will increase the appeal to partners

Add 1 if a capability will cut costs by under $250K, or

Add 2 if a it will cut costs by over $250K

Add 1 if a feature will compete with your top competitor(s)

Add 1 for a feature that will give you a leg up over the competition

Each capability will have a potential maximum score of 10, and a potential minimum of 0. There will be far fewer 10’s than 1’s.

As with any other methods of measuring ROI, it’s essential to document your assumptions and keep them in mind. For example, the above scoring system gives a lot of weight to architectural requirements. This could skew priorities toward technical benefits rather than business improvements.

So you still need to run the score past the gut check.

Other Options

If your company has a relatively large customer base, you can prioritize requirements by having the customers vote on proposed features. However, if there is no extra charge to existing customers for a new feature, you can easily spend money on something that brings no significant dollar return. Even in this situation, you still face assumptions that can skew the results.

One way to balance out the non-monetary nature of customer votes is to attach a cost to requirements and give customers a fictitious credit of, say, $100K, which they must spend on their choices.

Another method of prioritizing is to assign ROI to overall categories in the requirements (sales appeal, partner appeal, cost cutting), and then prioritize within each category without using dollar figures.

As you can see, there are a number of ways to approach a consistent estimate of the importance of requirements.

Looking Back

Finally, since no ROI method is perfect, you judge the true accuracy of your ROI calculations using 20/20 hindsight. Review actual ROI for the year that follows the introduction of a new requirement.

You may be surprised by the difference between predictions and reality, and hopefully a pattern will emerge to guide you in future ROI calculations. A pattern such as: “It turns out technical improvements count for a whole lot more than I gave them credit for.” Or “Features with demo appeal led to more new sales than the robust new features we put in.”

I guarantee you that if you come to the CEO and management team with a consistent ROI for each proposed capability, they’ll be mightily impressed. This is the software industry, after all!

— Jacques Murphy, Product Management Challenges

ProductManagementChallenges.com
[/private]