ICE model and valuing a new feature

I’ve written about ICE model and feature development prioritisation before.

Perfection paralysis and the death of product

Striking a balance between sales feature demands and product development

It continues to be a key area of debate amongst the companies i work with. So i’m likely to continue to write about it.

This time however I’ll focus on a specific aspect of the ICE model

Here we see a screenshot of an example valuation model which would fall under the I(mpact) and E(ase) categories of the ICE model.

Impact is quantified here by the revenue potential, the number of new revenue (annual) the feature might generate, you’ll notice a few features defined as ‘plug hole’ in this example, these are features that are more ‘repairs’ or upgrades to the existing platform, so they don’t impact new business – in this situation Impact, quantified by revenue potential, is calculated base on revenue potential of renewal revenue, upsell revenue, the logic being, if the platform doesn’t make certain improvements, then certain clients (who are impacted by these feature upgrades) are liable to churn. – so in this way, we are able to put a monetary value to each feature.

On the E(ase) side of the evaluation, in the diagram above we see ‘Dev Time-cost’ – here we have a time-cost estimate of the commitment the dev team needs to commit to completing a particular feature. in this way, we can evaluate how much effort the development would cost the company, and further down the funnel, this allows development to get a better idea of how to coordinate resources, and without going into too much detail, go on to setup the scrum cycles.

You can see at the bottom, the comparison between two items, one a feature, the other a plug, and you can see that if we only considered Dev time-cost we would want to focus on the feature, on the other hand, the ‘plug hole’ shows us that up to 80K is at risk by not focusing on that item, so we can see how this tool can efficiently bring to surface additional considerations into our decision making. In this specific case, to make a better decision we would want to consider for the 80k at risk, how many are tied to contacts that would end soon enough to be an issue… in this way we can think about which of the two features should be prioritised not just on Impact and Ease, but also the related risk on losing the 80k… i.e. how confident are you that delaying the ‘plug hole’ feature will not result in the loss of 80k right now.

To conclude, this is simply an additional way to look at information to allow for more pragmatic, deliberate decision making.

Leave a Reply

Your email address will not be published. Required fields are marked *