A major challenge that faces every software product is determining the priority of the oh-so-many suggestions that come to Product Management as requirements for the next release. This is one of those areas that wind up containing a heavy dose of mystery masquerading as rocket science. Requirements get prioritized using a complex formula that is far from formulaic.

The path to well prioritized requirements may be narrow, but it’s not straight by any means.

One thing that even the most consistent and systematic Product Manager faces is the need to adjust his or her method of setting priorities to each individual company. Each company has different technical and business drivers. And each product has its own Development team with its own mindset. You must customize your methods to fit the thinking and personality of the Development managers and other management team members.

Read on for some ideas to consider when blazing your own trail to prioritizing requirements.

[private]

There Is No Shortcut

There are no shortcuts when it comes to judging the priority of a requested capability. There will be plenty of input, however.

Unfortunately, that input may not often be helpful. For many people who come to you with requirements, anything and everything they suggest is high priority. Ever asked someone to prioritize a list of ten suggestions, and they come up with 8 as high priority, and two medium-high? A more objective list would have one or two as high priority.

All this to say that when you have your Product Manager hat on, you won’t get much help setting priorities objectively. It would be wonderful if there were a formula you could plug in. You might, in fact, be able to devise your own formula. But it will be one of your own devising, and you’ll need to think hard to come up with it.

In a past issue called 03039 ROI and ROR: Return on Requirements I propose an example of a formula that can be applied to score the estimated return on a requirement. But it is only one formula among many, and would need tweaking for your company.

Coming up with a systematic way to prioritize requirements will involve plenty of discussion with various members of the management team. Each member has valuable input about the main issues facing the product relative to its competitors.

The hardest part is trying to balance conflicting and shifting opinions about how to set priorities.

A Different Team, a Different Path

Each time you find yourself at a new company or working with a new team or product, you’ll probably have to map out the pathway to prioritizing all over again.

Any scoring and weighting that you try will need to be easily understood by the small set of people you sit down with to finalize the priorities for the next release. In fact, you’re probably better off going with scoring methods and variables proposed by these people, so that you can get their active participation and buy-in to the prioritizing effort.

Setting up a system that the team understands and backs has far more value than trying to impose any system that you used before, however successful it was in another time and place. If you try to impose another system, you end up spending all your time implementing change, and may not get anywhere at all.

Crossed Paths and Crossed Wires

The challenge of prioritizing requirements is that you’re dealing with a multi-dimensional measurement. You can’t just say that something is high priority because it will add such an important capability. Nor can you say that something is high priority just because it would take almost no time to add, and is therefore worth adding if it’s halfway decent functionality.

The other challenge is that a Product Manager is faced with balancing conflicting opinions about a feature’s priority. Not only do the conflicts come from different individuals giving different weight to the same capability, but the advantages of the feature might conflict with each other. The same addition could be good for a partner relationship but bad for cost-cutting, or set you back in terms of the cleanness and openness of your architecture.

All in all, be prepared to find your mind traveling down some twisted and conflicted pathways as you work to come up with a system, and then to set priority.

Logic In the Service of Emotion

While it will help your organization and your product to be logical and systematic, understand that your system to determine priorities is like the system that your own customers used to choose your product: they made an emotional choice and then used logic (RFPs, due diligence, feature comparisons) to back up their decision.

One crucial step that you must pass through, for each capability where you set its priority, is the gut check. At some point, your all-too-human mind needs to use holistic thinking to confirm or override whatever result you obtain from a more systematic and objective calculation.

What’s The Easiest Way To Measure?

Once you decide what factors or variables you are going to measure to help set priority, you need to decide how you will measure each one. The principle rule is to keep it as simple as possible.

It’s particularly easy in an organization with skilled programmers to fall into the trap of concocting some complex scale for measuring, say, a capability’s level of effort or architectural complexity. You wind up with a multi-part formula that involves two decimal places. That’s just too hard, and therefore it won’t succeed.

The problem with measurements that are too complex is that you spend too much time trying to set the exact measurement of each requirement and lose sight of the bigger picture of how requirements measure up compared to each other. It’s easy to wind up with 100 requirements that all score high, or low, or in the middle, and you’re no closer to seeing which ones lead the pack.

Here are some examples of simple scales that people can relate to. High, medium, and low. Medium is the default. High if you think it’s really valuable. Low if you don’t see the need to address it any time soon.

A scale of 1 to 10, with 10 the highest, is usually intuitive for everyone. Everybody has some practice scoring things on such a scale. This is good for assigning the value of a proposed capability.

A scale of 1 to 5 is also pretty understandable. It’s nice because it includes a neutral value in the middle, 3, unlike the 1 to 10 scale.

“Yes”, “maybe”, and “no” isn’t bad. It’s like the system people use to sort incoming resumes. The “no” pile gives you the opportunity to clear away distracting entries. “Yes” means you want to consider it, and “maybe” means that some items in that category will get bumped up to “yes” if there turns out to be a need to consider them. “Maybe” can always be left for consideration in the next release.

High Priority? That Depends

Another key difficulty with priority is that it’s not a direct measurement, at least not if you want to assign in a more objective way. Instead, a feature’s priority is a combination of two or more measurements that interact and influence each other.

For example, a capability may have a high value-add to the product, but it suddenly doesn’t seem so important if the effort to develop it is one man-year. One man-year devoted to that requirement means three other requirements have to drop off the list. You find yourself saying “Hmmm, maybe I don’t want it that much after all.”

Priority will never simply be about value, because you don’t have infinite development resources at your disposal. Five medium value requirements may take priority over one or two high value ones.

So if nothing else, you will set priorities by measuring two separate variables: value and effort.

The Measure of Value

It’s important to measure value in complete isolation from effort required or any other considerations. Create a score that tells you only one thing: how valuable is this feature to the product? How much value will it bring?

Value is definitely relative. This means that if you use a scale of 1 – 10, you should expect no more than a handful of 10s, twice that many 9s, and three times that many 8s. Most of the requirements should fall between 1 and 5.

Value is a judgment call.

What Value Do You Mean?

In the issue 03028 Clarifying the Why of Requirements I talk about how different requirements have different advantages or positives. For example, sales appeal is one value that a capability can bring. Cost cutting is another one entirely.

Unless your product sells effortlessly against the competition, or your company isn’t interested in the least in controlling costs, you’ll want to double-check your value scores to ensure that there is some balance between different types of value. If the only features that score 10 are those that add sales appeal, you’re probably skewing your value assignment. It’s rare that a product doesn’t need a balance of value in its new features, from feature leadership, to sales appeal, to partner appeal, to technical upgrade, to cost cutting.

Estimating Effort

Effort is the other major variable that you want to measure at the very least, along with value. Effort is the level of effort it takes to develop a feature.

Effort is absolute. Effort doesn’t fall along a curve. It’s possible that all requirements proposed involve a high level of effort.

Effort is also objective. While creative thinking is required to come up with ways to reduce the effort it takes to develop something, once you have defined a feature, it’s a pretty objective process to add up the days or weeks required to design, code, and test.

On the other hand, like value is a judgment call, effort is an estimate, not a sure thing.

People Predict the Weather, Too

One thing that often paralyzes people at some point in the scoring process is the question: “What if I’m wrong?” The answer is that your assignment of value, effort, and priority are all based on certain assumptions and choices, and based on the information you have at the time. All of which is subject to change in the future.

So just like the weather, you can predict priority, but won’t wind up being right 100% of the time. The fact that you can’t be absolutely certain is not a reason to be less rigorous.

All Roads Lead to Priorities

In the end, the team must balance the scores for value and effort, and other variables they choose to incorporate, to set the priorities for the next release. So if there are three 10s, you might choose two that are an average level of effort. But you’ll skip the third one that scores a 10, because it’s too much effort, and you can do three of the 9s in that same time. Overall, you’ve decided that five requirements take high priority (instead of three), and that one of your most potentially valuable features is just going to have to wait for now.

Hopefully you will find that you are able to accommodate all but the most time consuming of your 10s and 9s, and throw in a decent smattering of 8s to round out the release. And you’ll find yourself satisfied with how you were able to take into account a number of considerations to help the team converge on and agree to your upcoming product priorities.

— Jacques Murphy, Product Management Challenges

ProductManagementChallenges.com
[/private]