ICE Framework — “Brahmastra” for a PM’s roadmap (4 of n — Product management from ground up)
Some clarifications before I begin
PM here refers to a product manager, in case someone was wondering while reading the title (most likely a rare scenario).
For those who may be wondering what Brahmastra is — you can read more about it on wikipedia. Contextually, Brahmastra refers to an ultimate weapon that its user can use to solve all the problems.
Some background on evolution of our roadmap
Townscript’s journey in setting up its product team for the future has been full of several ups and downs. It has been full of trials and errors. Naturally, Townscript’s product roadmap has been a ubiquitous part of the whole journey. It has evolved from a memorized or user determined list of items to an even still user determined document but with sophistications of quick extraction of top priority items and their clear classification.
- Phase 1: In the beginning, it was an “old is gold” excel sheet with items listed in colorful sections
- Phase 2: Division of product roadmap into list of items for different themes signifying focus area of Townscript — “enabling organizers”, “marketplace”, “enabling internal teams”, “technical superiority” and “user experience improvement” — and for different platforms on which they would be built. The biggest challenge faced with this approach was that there was no quick and visually good way of filtering top priority items and even assigning priority to a new or old item.
- Phase 3: As one would, we also looked out for a product roadmap tool and came across Yodiz that provided us with cost effective usage and a lot of functionalities such as tagging, priorities, details of each user story, status for each user story, beautiful graphs to know about the status of whole roadmap and drag drop functionality to quickly move user stories across the roadmap. During this phase, we used to follow two week sprints and thus the sprint board of Yodiz was also helpful.
- Phase 4 (ICE framework driven roadmap): It took us a good 1.5 years to reach this phase. As our product(s) started increasing the inputs on what should be built, when should be built started pouring at light speed from all sources such as customer success team, business development team, operations team. To effectively manage these, our co-founder Sachin Sharma stepped in by seeking help from his network and two of the veterans provided crucial inputs. This was also the time, when we decided to break all our products into 14 functional modules, each representing a critical functionality or product that defines a user’s journey on Townscript and having its own roadmap.
As mentioned in one of my previous stories on a design project, Swaminathan Jayaraman was one of those veterans who first introduced us to an idea similar to ICE framework. As a part of the exercise mentioned in the aforementioned story, Swami shared with us a sheet in which we could list down all the product items that come as output of user studies or from internal teams and give a score of impact (scale of 1 to 5 with 5 being most and 1 being least impactful) and of effort (scale of 1 to 5 with 5 involving least and 1 involving highest effort to build). These scores would then get multiplied to give a priority score.
Additionally, we reached out to Anuj Rathi (Vice President of Product Management at Swiggy) to understand from his experience the ways in which we could effectively manage the 14 functional modules. He formally introduced us to the ICE framework (explained later).
We went ahead and implemented ICE score for each item in our Airtable based roadmap based on our qualitative (ideally should be a mix of quantitative and qualitative as explained later) understanding of impact, confidence and effort.
Somethings about ICE framework
There are a lot of other examples and definitions about ICE framework that you can probably read on the internet. To explain it in short, there are 3 elements (or scores) of the framework that are used to come up with a final score helpful in quickly ranking any set of items.
- Impact score: In product terms, this score is given on a scale of 1 to 5 to gauge by how much would a product feature or item move a product metric. If the movement is very significant, then a score of 5 would be given and if not a big movement then a score of 1. With the refinement of our product metrics in progress, we have determined impact scores based on interactions with users and internal teams
- Confidence score: This score is a measure of the confidence on the impact of the feature or item. A 100% confidence would normally signify that the impact is certain
- Effort score: This score signifies the time that would go in building the feature. Measure on a scale of 1 to 5, a score of 1 means that it will take a huge amount of time to build the feature while a score of 5 means that the feature can be built in as small a time as spent when Thanos snapped his fingers to wipe out 50% living beings on Earth in the movie “Avengers, Infinity Wars”
These three scores are then multiplied to give the ICE score. Example: impact score of 4, confidence of 80% and effort score of 5 would give an ICE score of 16.
How does ICE framework help us in prioritizing our roadmap
One way is pretty evident — simply sort by the ICE score to get the top priority items in our roadmap for each functional module.
However, just like all frameworks, there are pitfalls with sorting simply by ICE score. Say you have a lot of features to be built and each feature has the three elementary scores and the final score. If you sorted only with ICE score then you may end up ignoring those features that have a high impact, moderate confidence but lowest effort score. To avoid this pitfall, we employ a simple trick that in our quarter plan for product execution, we also pick couple of these high impact items so that we are able to move the needle by a significant amount when it comes to user experience, business growth, etc.
