John Doerr, the man behind much of the modern product culture as we know it, once said:
“Ideas are easy, execution is everything. It takes a team to win”
Ideas are not an exclusive tool of the product manager. On the contrary, PMs often have close to no creative control over the product. The product manager’s responsibility is not to execute anything, either. Engineering does all the heavy lifting while, at most, we test things before going live.
Product managers are, among many other things, the ones responsible for bridging the gap between ideas and their execution. Prioritization is the name of our game and taking risks is what makes our hard-earned cash worth it for our contractors.
Being so vital, it’s not surprising that there are so many different ways you can make your prioritization. The lean industry LOVES a good framework: the opportunity tree, CSD matrix, RICE score, Kano model, and more…
I could write a book if I were to cover them all (not a bad idea). Instead, let’s talk about one of the simpler, most flexible frameworks out there — my favorite, the ICE score.
Initials and acronyms make everything better, but not necessarily easier to understand. Breaking down what ICE stands for, we have the following values:
The theory is that you score each initiative on your board according to these criteria and, after some calculation, you have the most impactful and easiest to deliver opportunities ordered from top to bottom on your behalf.
The calculation is not rocket science, either. You score each item from 0–10, then multiply everything to get the score:
It seems all too easy, but some questions immediately come to mind after introductions: how do I know what would cause more impact beforehand? How much confidence is confidence enough? I haven’t had the time to talk about this with engineering, how do I predict effort? Should I do those things alone, or should somebody else participate?
As it is with many things in product management, there is no straight answer and each case is different from one another.
Let’s go deeper into each criterion of the ICE score in the hopes of making things clearer.
Impact is where it all begins. No one would argue that doing something with no value is worth it, it doesn’t matter how little effort it takes.
Value here is evaluating how intimate the relationship between effort and result is. If you have an objective in mind or a particular KR you want to influence, you can think of several ways of delivering that. Naturally, you would prioritize the ones that seem to deliver more at once.
Imagine you want to increase conversion. You can either streamline your current sales form or you can add a new service to your portfolio. Any one of them can deliver the result you want, but improving the form is clearly the best option… right?
How would you know that the form upgrade from the example above is indeed the most impactful option? Product management deals with large amounts of uncertainty regularly, and discovery is our main navigation tool.
Uncertainty here means risk, specifically in the sense that you’re not in control of the outcome given the effort you exercise. How much you study about a given topic, how often you talk to your customers, how close you are to the engineers — all of these things, bundled under the “discovery” topic, are the only way you can increase confidence and therefore mitigate risk.
So, back to the example. Between the form update and the portfolio increase, let’s say you did more discovery on the portfolio. You are confident that this is the lowest risk impact to be taken (be it big or small), so that means we should go for it first… or should we?
People often overlap the concept of effort with the amount of engineering work for a given task. This is not entirely true, and the same stands for its opposite: ease. The amount of work involved in delivery should also take into consideration both its past and post efforts.
Designers must design, PMs must discover, sales teams must be trained, other teams might have to adapt to the novelty, documentation must be updated, and so forth and so forth.
Calculating ease is equivalent to identifying how much it will cost to ship, and how much time (which translates into money) it will take for something to flow from ideation to delivery.
In the example we are working with, changing the form is way easier to push across the chain of products compared to adding a new service. Not to say that one is more important than the other, but one of them is definitely cheaper.
If you want to have a better statistical approach to it, share this exercise with your team or with stakeholders. Take everyone’s average score for each criterion and then calculate the final results. This is optional and by no means necessary. You can do it alone as a way to justify your prioritization and collect feedback after the fact.
Closing the proposed example we started with, should we improve the form or increase the portfolio? Let’s recap:
There it is! We should prioritize the form then! Easy…
…it’s not that easy, isn’t it?
As it is with all frameworks, the ICE score is a tool to better manipulate very complex decision components. No framework is capable of composing all variables into a single abstraction, which means that no prioritization is perfect right out of the bat.
Some other intangible factors must be taken into consideration before committing to a backlog: what does management understand as priorities? If you are dependent on other teams, do they share your commitment to timing? Is a lower-scored initiative a blocker for a higher-scored one?
Those are just some of the variables that might force you to make a change or two in positions after you have the score in place. Besides that, there are complete dimensions of decision-making that are left out of the ICE score.
The top-of-mind example is the first letter of its cousin framework, RICE. The R stands for reach. This variable is important when assessing options that deal with vast amounts of users.
Imagine that a social network such as Facebook is trying to crack down on fake accounts. Doing something that addresses more accounts instead of a few is a further guarantee that the results will come as intended.
ICE is a fast, effective prioritization tool to get you out of the dark. When you have just a bunch of initiatives loosely related and, for all intents and purposes, you think that starting with A or B is all and the same, ICE has a quick answer to deliver.
As obvious as it sounds, you need a priority list before being able to change such priorities. Whenever we enter quarter planning, I throw everything we brought up in the past months inside ICE to get the first glimpse of a plan.
Frameworks in general are great starters, but they cannot and never will replace product manager experience. There is a reason why you are being paid (instead of the designer or tech lead) just to plot ideas into a framework.
Remember, you are the bridge between idea and delivery. It’s your responsibility to deliver an effective, trustworthy direction for the team to follow. The ICE score (like any other framework) it’s just a tool.
A good ironsmith needs a good anvil, but a good anvil can’t make up for a bad ironsmith.
Presuming you understand how and what you should use the ICE framework, let me share some quality-of-life tips to step up your prioritization game.
First, don’t always use the 1–10 ruler. The standard ICE score asks you to score things between 1 and 10. I think this leaves way too much space for questioning if you have few initiatives. What is the difference between scoring something as a 3 or a 5 if there are no 4s?
Instead, try and standardize each value with smaller ranges:
Next, manipulate the scores instead of the positions. You must remember that I said you’ll need to change in which order each initiative is after the fact, right? Often, you’ll use your score to base your decision-making. If you show up with scrambled numbers, people won’t take you seriously.
Instead, transform 6s into 8s or 10s into 7s to naturally settle initiatives on the positions you need them to be. Be sure you can explain why something is over or underrated, though.
Use ICE as a tool for discovery. ICE is normally used after discovery is somewhat done, but I like to use it also to prioritize what to discover first. Thinking about the dual-track scrum, it’s a healthy habit to have a roadmap of deliveries and discoveries as well.
The lower the confidence but higher the impact — this is what you should prioritize discovery with. You mustn’t think with the numbers as I’ve just recommended above, though.
Finally, nobody needs to know. Perhaps you’re working for a company with a very early product maturity. No problem. You can use ICE (or any other framework) to build your personal prioritization and disclose only the results to your peers. When people naturally come and ask you how you got that done so quickly, smile and present them with the product management blog from LogRocket!!!
If the right people read it, product transformation will happen in no time, I’m sure.
In this article, we covered the ICE score and how to use it in modern product management. We covered the various components of the ICE score, how and what to combine it with, and gave some additional insights. I hope this was informative, thank you for reading!
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Aliza Carpio, Sr. Director of Technical Product Management at JLL, talks about the importance of “finding your believers.”
This article covers insights for overcoming common challenges, as well as ways to embrace innovative ecommerce strategies.
Dipto Chakravarty, Chief Product Officer at Cloudera, talks about how it takes rigor to design complex technology and user experiences.
As an alternative, this article outlines a case against MVPs, drawing on my own personal experience in the realm of product management.
Learn more →
