One of the biggest challenges I’ve faced as a product manager is attempting to arrive at a consensus when identifying what enhancements, bug fixes and other development items should be included in the product roadmap. Perhaps you, too, will identify with a few of the themes in this *mostly* fictional dramatization…

Bob, a product manager at Ultramegadyn, spent the last week combing emails, Excel spreadsheets, defect tracking systems and post-it notes accumulating all the product ideas that have been sent his way over the last year.

The result can be summed up in one word. Whoa.

Bob’s got way more ideas for things to be done than could possibly be addressed in the next several hundred, if not thousand years.  So as a good product manager, he starts whittling down the list. He’d like to grow revenues by expanding into a new market, so he includes these capabilities. He also includes some tweaks to existing functionality to respond to competitive pressures. Sprinkle in some 24×7 availability and he’s done in time for lunch.

Bob’s still feeling pretty good about himself when he starts circulating his roadmap presentation with other parts of the organization. Only then does he realize the extent of his troubles as the sales team starts asking what he’s going to do about the laundry list of enhancements they need to placate a certain large customer. Next, the Director of Product Development starts mumbling about man-years and hardware costs just before she falls out of her chair. Bob get’s back to his desk and finds a voice mail from the VP of Technical Support. He’s complaining that product management never includes his team in any product strategy decisions and that they need a number of enhancements to make the product easier to support. Bob sits back and thinks to himself, “Wow that was fast – if only our case resolution times were that quick.”

So what is Bob going to do to salvage his once promising career in product management?

Well, selecting the right development investments to be included in a product roadmap is an exercise in multiple-objective decision making. Difficulty occurs because seldom is one investment best in every dimension. For instance, a given enhancement may translate into increased revenues, but may be very expensive for the organization to develop, may not align with strategic objectives or your own product strategy.

The best way to sort through all the alternatives is by creating a scoring system to help you (and the rest of the organization) understand how each investment decision ranks when evaluated against key organizational objectives.

Not only does a scoring system make it easier to determine which enhancements should be included in the roadmap (by picking those with the highest scores), it provides a platform for collaborating with other groups and achieving organizational consensus. This is because the decision criteria are set out for everyone to see. Instead of having a subjective debate over pet projects, which will only lead to the parties entrenching positions, feedback will come in the form of new or modified objectives, weights and scores. The following four steps will guide you through the process:

Step 1: Identify Objectives

A good way to start is by reviewing your own product strategy, along with departmental and corporate objectives. If you’re doing it right, your roadmap items should have an impact on these things. For example, product investments will better differentiate your company, grow revenue or market share, reduce support costs, or help win XYZ account. You’ll also want to include objectives from other parts of the organization so that their interests are represented. Lastly, try not to double count by including redundant objectives. You would not want to include an objective that counts revenue and another one that counts incremental sales.

Step 2: Measure Investment Candidates Against Each Objective

For each candidate feature, you’ll want to assign a score for each objective. In the example above, I’ve used a range of 0 to 10, with 10 being the best. In this way, you can see that Feature 1 is expected to contribute to High Revenue Growth, but since it has a score of 2 for Low Development Cost, we can assume that it must be a fairly expensive project to complete. Obviously, score ranges must be calibrated using values that make sense for your organization – for instance, a company with $500 million in revenue may find a range of $0 to $100 million appropriate for the High Revenue Growth objective, but this range is likely too small for a company with $15 billion in sales. Also, be sure to include this information in a scoring key to guide those that will be working with the model.

Right about now you may be asking the question, “What about business cases?” and I’m glad you did. Roadmaps help you plan and articulate your product strategy for the next three to five years. The farther we look down the road, the greater the inherent uncertainty; thus, roadmaps must be somewhat fluid in order to appropriately respond to changing market dynamics. Thus, we need a system to quickly evaluate interesting opportunities for inclusion in the roadmap. Some may argue that the business case should be used for this task. However, I find that while business cases are a great tool for assessing the appropriateness of near-term investments, they are too time-consuming and assumption-laden to be useful for road-mapping. Using the 10 point scale is a good way to ballpark our expectations and is an acceptable proxy for the business case.

Step 3: Determine Objective Weights

Next you need to determine the objective weights so that they reflect the priorities of the organization. All the weights, when summed, should total 1.0 and reflect the importance of the objective relative to all the others. Our example weights High Revenue Growth at 0.40, which means that the organization values revenue 4 times more than it does Supports Product Line Integration which is weighted at only 0.10.

It is often helpful to tie objective weights to those of the larger organization, since taking a corporate position will help reduce the squabbling that may occur among stakeholders. If your company practices management-by-objective (MBO), you may have already been handed a framework to start with.  Review the five or so corporate-level objectives – they’re probably on that little card next to your computer monitor. Chances are successfully achieving these objectives is rewarded by funding a certain percentage share of an annual bonus pool. These percentages are actually implicit weights, which you can then leverage for use in your scoring system.

Step 4: Apply Scoring System

Once you have all the scores and weights, you can tabulate the total score for each feature. This is done by calculating the weighted average.

Feature 1:           10 x 0.40 + 2 x 0.30 + 3 x 0.15 + 8 x 0.10 + 5 x 0.05 = 6.1

Do this for all your features and then sort descending by Total Score. Presto! The candidates at the top of your list are the best ones for inclusion in your roadmap.

Do your results square with your intuition? With stakeholder expectations?

If they don’t you might have a poor analytical model on your hands, but don’t worry; you’ll probably need to take your model through a few iterations to get it just right.

Here are some things to look out for. For one, you need to mercilessly eliminate redundant objectives. As I mentioned before, this will cause double counting and throw off your results. Secondly, you want to make sure that your weights accurately reflect an objective’s relative importance. Over or under valuing an objective will also throw off the score. Lastly, it’s easy to focus on objectives that lend themselves to being quantified, but don’t overlook “soft” objectives that may be important to the organization. Your model will also benefit from the input of others who may help you identify missing objectives and weighting problems. At the conclusion, all parties should understand and agree with the model – even if they don’t like the all the results.

Using this technique for roadmap planning can make the process a whole lot more efficient and collaborative while getting the best product possible out. It is also a way for stakeholder to be part of the process and champion your product in their respective departments.  Not to mention it’s a lot more effective than looking angrily in the rear-view mirror and yelling, “You all are cruising for a bruising; don’t make me come back there!”