Okay, let’s say you already have a clear strategy that users have validated. 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, you’ve put all that work into learning about your customers, so we know what’s right for them, right? Not so fast. You still need to get buy-in from your Executive team.
It is true that as a Product Manager, you get to propose the contents of the release. But your decision is not final. It’s just a recommendation. You still need to get buy-in from others. After all, you are not the CEO of the product,
You may be concerned that your initial prioritization will go out the window as soon as you start collecting buy-in from others. 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 robust voice-of-customer data 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 the scorecard criteria for that release before 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, the process will take much longer. At that point, you are asking them to drive, as opposed to you leading your process.
For example, here’s a scorecard with some possible categories and weights.
In the example above, I’m giving features that impact Operational Efficiency 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 category 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 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, this category subtracts from the total when you calculate the score. The result is a prioritized list where riskier features are lower in priority.
Now, keep in mind that the scorecard can often change, 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 critical 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 in usability, performance, or stability. Those are “hidden” areas of a product, but they affect the customer as well.
At other times, your product lacks internal operational efficiency, meaning that your internal team lacks the tools to manage and support your infrastructure. All those internal tools are needed, but since the customer does not see them (and the Sales team can’t monetize them), it is sometimes difficult to convince executives and peers to invest in that functionality.
Our job as Product Managers is to surface those needs and prioritize them accordingly. A scorecard with the correct categories and weights can be a great tool to support a release’s short-term direction without losing focus on the long-term strategy.
For example, let’s assume that you are really lacking in 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 a scorecard, you can show you are genuinely considering their needs and bringing them to the prioritization table. But there are currently competing priorities that better support the strategy.
The Bottom Line
It’s up to you, the Product Manager, to lead feature prioritization for each release, make sure you are using your development resources in the best way possible, and keep both your customers and Executives happy.
Scorecards are just one of the frameworks you can use for prioritization. For additional prioritization frameworks, here’s a great article by Jim Semick, and here’s an in-depth look at the Kano Model by Jan Moorman. Regardless of which one you pick, make sure you have a method for aligning features with the overall strategy and more immediate internal and external needs.
17 Comments
Daniel,
I ready this article a while back and coming back now it is still relevant and should be used daily by product managers.
Thank you! I’m glad you found it useful.
-Daniel
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 =)
Thanks for you comment as usual!
DanielDaniel, you wrote:
“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.
A few tweaks I discuss in my slideshare on prioritization (http://www.slideshare.net/bmmccarthy/prioritization-301):
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.
I have a couple of downloadable Excel templates for this kind of scorecard (yes, one of them has weights) on my blog here, if anyone is interested: http://www.productpowers.com/utility_belt/
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?
-Daniel
It is great to see PM conversations that include “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.”
I’ve been advocating cross-functional approaches to delivering customer value for, literally, decades. Customers need, want, and will pay for value beyond feature/functions. Sometimes technology companies invest in feature/function to the detriment of other areas of value. Bain & Co did some great work on value for both the B2C and B2B markets. https://www.bain.com/insights/topics/elements-of-value
I recommend that every product manager and every company executive familiarize themselves with this work. I further recommend that every product organization endeavor to document, share, internalize a comprehensive model of the customer as well as an understanding of how different functional groups contribute to delivering value to the customer.
I’m glad you liked the article Ellen. Thanks for your comment and for sharing the link from Bain. I’ll definitely check it out.
-Daniel
Love this concept, it’s methodical, practical, makes sense and solves a challenge I’ve been grappling with so ticks all my boxes!
Thank you Nathanael, I’m really glad you enjoyed it!
-Daniel
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”.
Thank you Monique! I’m really glad you enjoyed the article. I’m curious to see how your new categories are received within your team. Good luck!
-Daniel
Daniel,
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.
Thank you Joseph, I’m glad you liked the article!
