9 Ways to Prioritize Your Product Development

In the fast-paced world of software development, it’s prioritize or fail. Alex Adamopoulos, founder and CEO of Emergn, breaks down nine ways companies can gauge value and make difficult decisions about what to focus on first. 

Prioritization is never easy. It often involves painful decisions and difficult trade-offs, and for early and expansion-stage companies, there is the added pressure of trying to accomplish a great deal with limited time and limited resources. In order to achieve growth, both of those crucial commodities need to be directed solely on the things that truly matter and are going to have maximum impact.
It is no surprise then that one of the biggest differentiators between companies that thrive and those that fail is the ability to prioritize effectively. In fact, according to Jeanne Ross and Peter Weill’s research for their book IT Governance, “Companies that manage their IT investments most successfully generate returns that are as much as 40% higher than those of their competitors.”
In a separate article, Jeanne Ross illustrates the stark contrast between that success and failure even further, quoting a leader of a $15 billion retail enterprise as saying, “IT investments are like any other investment. You must make a decent return or you go bust. It just happens faster with IT!”
With stakes that high, the good news is prioritization doesn’t have to be a constant source of pain. With the right method, it can empower your decision making and lead you to vastly improved results. In this article, I will provide you with a high level overview of the nine most commonly used requirement prioritization methods, and offer a list of pros and cons to each.

9 Ways to Prioritize Product Development Based on Value

MoSCoW

The “MUST, SHOULD, COULD, WON’T” method is a technique to help you prioritize using words rather than numbers. It was originally included in the Dynamic Systems Development Method (DSDM) techniques, designed to assist companies adopt Agile methods. Despite this, the tool has become popular in many places — including organizations still wedded to sequential or waterfall development.

MoSCoW analysis requires you to separate all your requirements into four categories: Must, Should, Could and Won’t. Because the process does not enforce a strict order, it enables stakeholders to avoid some of the most difficult questions. It’s all too easy to see the “must” list fill up, while the only items in the “won’t” list might be ones that no one really wanted anyway.

The development team can be equally at fault for misapplying this method, overestimating the difficulty or complexity of implementing certain requirements in order to influence the prioritization process. Jean Tabaka, in her book Collaboration Explained, recommends, “balancing MoSCoW by the Product Owner or customer with technical estimates that clearly bound a timebox scope may help a team better grade its stories or requirements.”

Pros and Cons of MoSCoW

Classes of Service

Classes of service is an extremely simple idea to grasp because it’s one many of us are already used to across different industries. Money doesn’t have to play a part in the decision, although it is very effective. The idea is to ensure that those making the requests take responsibility for the pressure they put on the development process. It recognizes something very simple — that not all work has the same value, or the same time-pressure. David Anderson puts it rather more formally: “Classes of service provide us a convenient way of classifying work to provide acceptable levels of customer satisfaction at an economically optimal cost.”

There should be no more than six classes of service, but generally four is sufficient. The rules for each need to be transparent and clear, including how many requests may be permitted in each class of service at any one time, their impact on work in progress limits, and the estimation requirements involved.

Pros and Cons of Classes of Service

Equity

When business owners are debating who gets to pick the next item to go into development, occasionally a form of “financial equity” is used — essentially, a form of decision-making where those paying 50% of the budget get to make 50% of
the choices.

An extension of this idea is one occasionally found in an organization where IT developers are assigned to the various business units. Perhaps finance is given two dedicated developers, marketing four, and customer services one based on their projected need, size or budget, etc. The idea behind such a split is admirable
 — improve IT’s ability to meet the business unit’s need. It is often popular with the business units, themselves, who are delighted they no longer need to struggle to gain attention for their problem from an overstretched department. Yet equity often causes larger problems to emerge in the medium term.
The Pros and Cons of Equity 

HiPPO Decisions

The acronym (much more attractive than the average management jargon) stands for Highest Paid Person’s Opinion. It reflects a not uncommon de facto decision-making rule — whatever the CEO, CFO, or Operations Manager, etc. thinks is the most important feature gains priority. The HiPPO tends not to be a formal process of prioritization, but rather it happens internally. The team knows that the senior person is pushing for feature x, and so consciously or unconsciously, they move feature x up in priority.

The Pros and Cons of HiPPO Decisions

Value Divided by Effort

The most common “number” method for prioritization is Benefit Cost Ratio (BCR). It is designed to help balance out the relative priority between differently-sized tasks. Ex: Is it better to finish a short task that will produce a low amount of revenue or embark on a major piece of work that will take several months but has far greater potential payback?

Those wishing to sound less formal in their estimation sometimes refer to the figure as “bang for your buck” — the more value you yield for less cost, the higher the bang for your buck. To calculate Return On Investment (ROI) simply take the net value and divide it by the cost.

The calculation is nice and simple: you simply divide value by cost and then express the result as an index or a percentage — take your pick. This at least gives you relative figures to compare features and decide on the priority. When the product launches, you can then compare actual value divided by actual cost to see how well your estimation process worked. Cost is only one measure — you could also express it as effort or time taken.

As a ratio, the idea of relative importance based on value and effort does not have to involve actual figures. A common tool to help decide on value and effort is to gain input from the whole team in an exercise sometimes known as planning poker.

The Pros and Cons of Value Divided by Effort

Cost Benefit Analysis (Financial Measures)

A full cost benefit analysis is a traditional process associated with launching new products or major projects, and forms part of the original business case. The prioritization measure associated with this is “tangible discounted cash-flow,” a phrase that really trips off the tongue. This impacts on the point at which the project breaks even and how long the payback period is — both crucial measures in gaining approval for and measuring the success of any development project.

The Pros and Cons of Cost Benefit Analysis

Incremental Funding Model

Mark Denne and Jane Cleland-Huang point out in their book, Software by Numbers, “financial return is usually the enduring metric of success in software development.” Denne recalls the breakthrough they made when instead of planning their project work to minimize cost and risk, they re-prioritized to maximize early delivery of value to the customer. Such re-prioritization required the marriage of financial measures like ROI with incremental delivery. Despite the validity of the caveats discussed above, the principle of optimizing financial value and being able to see that we are doing so remains sound.

The authors describe their application of traditional financial analysis to incremental delivery as the Incremental Funding Model, or IFM.

The Pros and Cons of Incremental Funding Model

Weighted Look Ahead Approach

Denne and Cleland-Huang consider all the different net present values (NPV) that could be generated by any sequencing path through the minimal marketable features (MMFs), described as a strand. If we have MMFs from A to E that can be combined in any order, then you would have 120 permutations.

Fortunately, or perhaps unfortunately, since several MMFs will be dependent on a preceding MMF (which Deene and Cleland-Huang call a precursor), this number reduces depending on the relationships. Without wishing to go through a slightly tedious worked example, take it on trust that you can come up with a number of strands, depending upon these relationships.

Rather than simply selecting the strand with the maximum NPV as the end result, you can improve your selection further by taking into account development time and use a calculation “negatively weighting each strand according to the number of time periods required to develop it.”

The Pros and Cons of Weighted Look Ahead Approach

Weighted Shortest Job First (CD3)

Don Reinertsen summarizes decision principles as three simple rules:

1. When delay costs are homogeneous, do the shortest job first.
2. When job durations are homogeneous, do the highest-cost-of-delay job first.
3. When job durations and delay costs are not homogeneous, use weighted shortest job first (WSJF).

If both jobs have the same cost of delay then do the shortest first, because the shorter the job, then the sooner you can release the value it represents. If both jobs take the same amount of time, then you should do the one with the highest cost of delay first (even if this job is of lower value). The third rule is the tricky one — and it’s also the most common. Normally every variable is different: your two jobs have different values, take a different amount of time to complete, and have different time sensitivity (Cost of Delay). You are (to return to that favorite cliché) trying to compare apples and oranges.
Weighing the priority is a simple calculation. Priority is based on the cost of delay divided by the length of time it takes to do the job.
The Pros and Cons of Weighted Shortest Job First

In Closing: 4 Keys to Effective Decision Making

Great prioritization relies on having the right selection of ingredients. Using one of the methods discussed in this article or a combination of them will help you develop the right approach that is specific to your organization. Regardless of which method(s) you choose, the right selection ingredients are:

1. Knowing exactly what “the best business value” means. This is not only financial.
2. Objective methods — in other words, every idea or project is judged fairly.
3. Transparent methods that are visible across the whole organization.
4. A timely manner. Spending too long on making the perfect decision could diminish your chance of getting the right outcome.

Editor’s note: This article is an extract from the Emergn Value, Flow, Quality^® Education Program and is part of the session module titled Prioritization.
Image by Seattle Municipal Activities