The Science of Ranking Features 

Homemade formula to build features that work for your audience.


When it comes to building a website, an app, or any product for that matter, it could be a real hassle to define the features you want to build first and establish a reasonable roadmap.

Indeed, most of the time we urge to build some killer-feature without actually knowing if this feature will satisfy our final users.

This is why I came up with a little formula I use in my own projects to attribute scores on defined features in order to rank them and maximise your productivity.


Considering user needs and time-to-build

Recently, on a presentation called “How to be a lean product ninja” by Dan Olsen from the Google Ventures Team, I discovered the Kano Model.

The Kano Model (Wikipédia)

The Kano Model is an amazing tool that I like to refer in order to define products attributes or features. According to the Kano Model there is three kind of features:

  • “Must be”: The essential feature, if this does not appear then our user will be deeply frustrated and unsatisfied. On the other hand, its existence is just considered as “normal”.
  • “Delighter”: A feature that can cause a great satisfaction if it exists and if if it is functional (e.g Amazon’s one-click buying for instance).
  • “Perfomance”: A feature that gives a lot of satisfaction or dissatisfaction proportionally to its promises.

Besides, the Kano Model offers something really important when you think a product: it must be built around the user needs. User needs are the most important factors when you define the key features.

The second most important important factor is time. Time to build. The more it takes time the more you lose money, opportunities, and time to market.

Defining the ranking process

First, we can set a user satisfaction scale from 0 to 10. We will discuss later how to define this user needs.

Then, we have the time factor. It is defined in hours: 1 for a hour, 2 for two hours and so. It is important to note that we cannot set a time factor for only 30 minutes (0.5). And honestly, if you can build a feature is less than a hour maybe this is not really a feature.

The final score will be defined by the ratio between the user need and the time to build, as Un/t.

The farther you get to 0 you get the more important is your feature.

Now let’s say we want to implement a Facebook Login. The user need score is 3.75/10 and it takes 2 hours to build it properly.

The final score would be : 3.75/2=1.875.

Defining the User Needs

“Un” is an important component of the formula but it is also the most difficult to define.

First, I believe that at some point you will have to test with a panel and interview people. This is why, I use user feedback as half of the score. The satisfaction score from 0 to 5 is defined by user feedback.

Then, if we take the Kano Model as a reference, we have our three main attributes : must be, delighter and perfomance. Now, let’s apply a combo coefficient to each:

  • “Must Be” = 2 because it is by definition “essential”.
  • “Delighter” = 1 because this is our best chance to please our users without any risk of dissatisfaction.
  • “Perfomance” = 1.5 because its efficiency is proportional to its promises.

The combo coefficient combined with user feedbacks we have a score from 0 to 10.

Let’s take our Facebook Login example :

  • Our users rated it 2.5/5
  • And we estimated that it was a “performance” attribute, so we give it a combo of 1.5.
  • The result is Un = 2.5*1.5 = 3.75.
This is what your features backlog could look like. Then just sort the scores.

So, in the end, I believe this little “process” might help you to rank your main features but I think this is more appropriate for little to medium size projects.

For the bigger ones I am sure there is more appropriates methods. Actually, I would be happy to discuss those methods and maybe improve this one.

Email me when Gilles Bertaux publishes or recommends stories