How to Use a Scorecard to Prioritize Features

Prioritizing features is at the core of the Product Manager’s job. And yet many PMs prioritize based on gut feel, or on the needs of the loudest person at the table. In this post, I explain how to use a scorecard to align all stakeholders on which features to prioritize in your next release. This scorecard approach ensures you remain focused on your customer satisfaction and company strategy, while reducing risk.

Okay, let’s say you already have a clear strategy that has been validated by users. You’ve done customer development, and you have a set of features that were derived from validated hypotheses. Now it’s time to prioritize the features for the next release. So what is your prioritization criteria?

A common mistake many of us make is to “take a stab” at the priorities using our gut and then release them to the development team. After all, we’ve put all that work in learning about our customers, so we know what’s right for them, right? Well, maybe. But no so fast. You still need to get buy-in from your Executive team.

It is true that we are the ones who propose the contents of the release, but we still need to get buy-in from others. After all, you are not the CEO of the product (but more about that in a future post).

You may be concerned that as soon as you start collecting buy-in from others, your original prioritization will go out the window. We’ve all been there. Everybody has different ideas on what the next release should look like. Sales, Marketing, Engineering, and Support all have great arguments for why their features should be the ones to make it in.

Having strong voice of customer behind your prioritization will increase your chances, but you still have to defend your feature set. To make a strong case and get consensus, I recommend using a scorecard framework. It’s easy to use, understand, and implement. A few of the top Product Management tools (like Aha! and ProductPlan) already support this approach, but the good thing is you can also use a simple spreadsheet.

How to use a scorecard

1. Make sure you have a solid strategy and a defined theme for the next release.

2. Agree with your stakeholders on what the scorecard criteria should be for that release, way before the prioritization starts. When defining a scorecard, I suggest you come to the table with your proposed list of parameters and weights, and then work with Executives to fine tune them. If you start the meeting with a blank sheet of paper, then the process will take much longer. At that point, you are asking them to drive, as opposed to you leading your own process.

For example, here’a a scorecard with some possible categories and weights.

In the example above, features that impact Operational Efficiency have been given the highest weight, because the theme of the release is related to improving that area.

3. Identify the most relevant features related to that theme. If you apply the scorecard criteria to every possible feature in your backlog, you run the risk of losing focus and not driving towards your strategic goals. So first group together features are good candidates for the release theme, and only apply the scorecard to those features.

4. For each of those features, assign a score (1-100) for each of the categories on the scorecard. A score of 100 means the feature will have an extremely high impact on that category.

Here is an example:

The first feature, Monthly Report, has been assigned a score of 90 under the Customer Engagement category, because its release will have a very high impact on customer engagement. The total priority level for the Monthly Report feature is then calculated as follows: Monthly report = 90*20% + 90*10% + 50*30% + 20*40% = 50.

After you complete this calculation for all relevant features, the result will be a prioritized list that is tied to the company strategy.

Pro tip: You can assign a negative weight to a particular category if you want a higher score there to reduce priority. For example, a “Risk of implementation” category could have a negative weight (-20%). Therefore, when you calculate the score, this category subtracts from the total. The result is a prioritized list where riskier features are lower in priority.

Now, keep in mind that the scorecard can change often, even at every release. The scorecard categories and weights should adapt to what’s going on in your company, to ensure you are always focusing on the most important items for that release’s theme.

When creating the scorecard categories, consider other departments’ needs.

Now, notice that in the scorecard example, I’m representing several groups within the organization (sales, UX, operations, etc). I agree that our responsibility is to look after the customer’s needs, but often, Product Managers forget that what the customers need is not only new features or more “innovation.” Sometimes your product is lacking on usability, performance, or stability. Those are “hidden” areas of a product, but they affect the customer as well.

At other times, your product is lacking on internal operational efficiency, meaning that your internal team lacks the tools to manage and support your infrastructure. All those internal tools are very much needed, but because they are not often seen by the customer, it is sometimes difficult to convince executives or others that we need to invest in that functionality.

It is our job as Product Managers to surface those needs and prioritize them accordingly. A scorecard with the right categories and weights can be a great tool to support the short-term direction of a release, without loosing focus of the long-term strategy.

For example, let’s assume that you are really lacking on internal tools. Then you can agree with your Execs that operational efficiency should be the theme of the next release, and therefore your scorecard should support this direction. On the table above, notice the values for the “Health monitor” feature. It scores low on all categories except operational efficiency. But because that is the theme of the release, then this feature immediately gets the highest priority.

On the other hand, sometimes you might need to throw features into the scorecard that are highly desired by your colleagues in other departments, but which do not match the current release’s theme. Using the scorecard approach will show them you are truly considering their needs and bringing them to the prioritization table…but there are currently competing priorities that better support the strategy.

In Summary

It’s up to you, the Product Manager, to lead feature prioritization for each release, to make sure you are using your development resources in the best way possible, and to keep both your customers and Executives happy.

i like the idea of scorecards to some degree, but the real trick is to make sure it’s measuring what you want it to. As you say, it needs to align with the organization’s strategy, which itself is driven by the market opportunity, among other things. My goal is to come up with a score for the “value” of a feature, with respect to the current strategy (which could change every release, and which is likely to consist of multiple goals, which may or may not be in conflict).

When I have a score for the value, I can then compare it to the cost (unlike Bruce I don’t combine these!). Normally high value things are expensive, but what you’re hoping for is a valuable feature that’s nonetheless inexpensive. It happens sometimes.

I also like to have risk and competitive position as separate scores from the value. What competitors are doing with a particular feature has very little to do with its intrinsic value.

One of the values of using a scorecard is that it can validate – or invalidate – the product manager’s own gut feeling and intuition. A score that seems off might mean your intuition is wrong… or that your model is wrong.

I’ve seen this sort of approach in many different companies, and it’s always failed.

The temptation to use a scorecard usually indicates larger cultural and communication issues. Product teams and executives need to be aligned around the larger product strategy and see how the roadmap aligns with that strategy. Alignment comes with frequent communication about prospect interviews and conducted, experiment and market data collected, the principles of product strategy, and connecting the dots to the roadmap. Numbers on a spreadsheet don’t address the issue.

My suggestion for a scorecard: one or two columns. The first column is the extent to which the product enhancement supports the unique value proposition that every executive and member of the product team agrees is the best hypothesis at the time. The second column is the cost of implementing it.

Hi Roger, I’m not sure I agree with your comment. You seem to imply that using a scorecard is a replacement for frequent communication or that it implies lack of “right-brain thinking” throughout the whole product lifecycle. I don’t think that’s the case. You also mention that the act of using a scorecard is a symptom of a bigger cultural issue, and I disagree there as well. Every product manager should understand the cultural and political intricacies of their company and propose the approach that works best for all stakeholders. In many cases, a scorecard can help bridge the communication gap. It’s a tool, an depending on how the PM uses it, it can yield great results.

For example, many companies in regulated industries (like Energy or Healthcare) tend to have more left-brain executives that are used to the process-oriented approach of scorecards. This is true regardless of the company size or stage of maturity. Many of these executives come from big corporations or even from management consulting jobs. So for them, having a scorecard is actually the first step towards starting a conversations in a setting that is familiar.

That doesn’t mean that the PM should just create a spreadsheet and sent it via email. The scorecard in this case, becomes an artifact to promote communication, and not the other way around. Notice that in my article, I focus on using a scorecard as a tool to get alignment, and not as the silver-bullet prioritization method. It’s still the role of the PM to ensure alignment through Diplomacy, as Bruce would say =)

“I focus on using a scorecard as a tool to get alignment, and not as the silver-bullet prioritization method.”

If you can’t talk to your executives and product team about the competitive landscape and your hypotheses regarding the product’s unique value proposition, and a scorecard is the only way to engage with them, you’re dealing with a fundamentally broken organization.

If my wife and I disagree on a life decision, spreadsheet scoring is unlikely resolve the disagreement, no matter how analytical either one of us is.

I think a scorecard can be helpful in very limited circumstances. Whenever I’ve witnessed product managers using it, however, it’s been a desperate attempt to resolve much more fundamental organizational problems, and it didn’t work.

Hey Roger, I think that if a PM approaches scorecards as their only tool for prioritization, then I agree with you that it will fail. I’ve seen scorecards work and I’ve seen them fail, so I know that they can be useful in certain situations. At the end of the day, scorecards are just another tool in our toolbox. PMs need to figure out which tool is the right one for the job and what other tools need to be paired-up with it to get the job done. That’s what makes our job fun.

Love the scorecard approach, Daniel, and particularly the notion of considering other department’s needs. Not only will this help align teams across the organization, but this concept gets at the often-overlokked role of the PM as the owner of the overall customer experience. It’s about making the customer successful (and thereby the company), not just about the code.

I don’t advocate using weights (unless you really have to). Weights complicate the model and make it hard for your stakeholders to easily see the math of your scores at a glance. They add nuance but at the cost of clarity and in practice I find they aren’t worth it (most of the time).

I advocate a simpler scale than 1-100 for scores. In fact, I like 0, 1, 2 (none, some, a lot). Remember, all you are trying to do is establish priority, not capture a precise estimate of anything.

I use negative scores for goals that are at odds as well, but I find most PMs are confused by negative scores and I use them sparingly.

I think it’s critical to incorporate some notion of level of effort into the scorecard so you can calculate a rough ROI. I’m not talking dollars and cents literally, but if two ideas with similar value take 1 week and 1 year respectively to develop, which one should we do first?

I use something I call “confidence” as a fudge factor, to adjust for when I am more or less certain about my scores.

Most important, though, I set the goals (the columns for the Scorecard) to represent the business outcomes I am looking for with the product over time. I am not focused on one release only, but on the reason we are working on this product in the first place. I focus those goals on the value we hope to deliver to the customer and the business, and judge every proposed feature or other sort of work against that.

Hi Bruce, Thanks for your thoughtful comment and for sharing those extra resources. They are great, and as you know, I’m a big fan of your content =)

I agree with the points you make. I think it’s also important to consider the maturity state of your product. I often hear PMs say that roadmaps and prioritization work best at bigger companies or established products. You don’t need that when you are starting out, you just need to be “Lean”. I think the Lean movement is sometimes misunderstood as just focusing on the immediate needs and don’t plan ahead for the future. We can always pivot, right?

I think the opposite is true. I think that startups and new products need to be even more diligent with prioritizing features and ensuring successful outcomes. Just like you say, the ROI needs to be there. Small companies can run out of funding very quickly and it only takes a couple of bad releases to drive them to the ground. When resources are scarce, then the effort to carefully prioritize how you’ll use those resources is equally important.

Kind of a tangent, but your comment made think of that aspect as well. What do you think?

I love this score card. In particular, the weighted categories. We recently began using a score card for prioritizing features, but I was struggling with how to weight the categories we use, which are : “benefit (to have)”, “penalty (to not have)”, “cost”, “risk” (implementation). I believe the categories in your version is a better representation of how my company been prioritizing feaures, though based on gut. I will be tweaking our current score card for our next priority meeting. This was VERY helpful! And, to echo Joseph – “succinct”.

Well said, I love it! The scorecard approach is succinct, metric based, involves primary stake-holders, promotes cross-functional team cohesiveness and is definitive on feature inclusion/exclusion and why.