by How to design a Product Scoring Mechanism?
- Features
For this example, I chose to prioritize product features, but entrepreneurs, product leaders, and almost anyone can prioritize with the PSM method anything that he or she would like: tasks, potential hires and more. Let’s assume that I’m building Airbnb in their early stages. Choosing your features could come from a team discussion, work with your stakeholders, customer feedback, etc.
- Setting parameters
These are the parameters that you and your team think will affect your product prioritization. For example, if you are planning to build 3 product features with your team, each will have a score for the 3 different parameters that you defined. Examples of those parameters could be time to build, complexity, cost, etc.
- Setting weights
Because not all apples are red, each parameter could have a different weight and impact on your total decision. Maybe you are short in funding and cost would have the larger focus, or you are in fierce competition with 2 other startups and then Time to Build would be the most important parameter. There are many ways you can define PSM weights. The most common way to define weights is to choose a number that could be from 1–10 or 0–1 and then multiply each score with the weights that you define.
- Setting a scale
Setting a scale for your parameters could be done globally for all parameters or individually for each. Setting a scale is a tool to help you align everyone on how they should score the different parameters. What is the minimum score value, maximum score value and what each one mean.
- Scoring (input)
After you clearly defined the PSM scales and aligned the team, scoring is the actual work for you and your team to think objectively on each parameter and evaluate it for each feature. It is important that each team member will do this on his own to prevent influence from other team members. However, if you feel that a collaborative work would be better you could try it you know your team best.
- Normalization (optional)
Normalizing your scores is optional. If you keep your scales uninformed, there is no need to normalize them. However, if you do not keep them uninformed or use weights in your PSM, you would want to normalize your scores.
- Output (Total Score)
Remember our mechanism and that it compute the numbers that we put inside? It’s time to compute the output. Like every part of our Product Scoring Mechanism it depends on how we build it, but for simplicity, we will compute a total score for each feature. I will use a simple summation of the different parameters to get one score for each feature.
- Prioritization
Now it’s time for prioritization. This is the answer to the question that you asked. The question is: are you looking for a minimization problem or maximization problem? In our case, a good solution would be something which is quick to build, simple and doesn’t cost a lot. Parameters that could create conflict are importance or value to customer, but then you would have to adapt your scale for minimizing or maximizing.
- Benchmark
In some cases, you would like to set a benchmark or a default score in your company or team. This benchmark could be set after trial and error to validate in the same scale what would be a score that beyond that score you would decide to launch for example and below to archive a feature. A benchmark could also be a score that you would retrieve from market research or data analytics. The most important thing to remember is to keep the benchmark and your PSM in the same scale, or else it means absolutely nothing.
- Recommendations
Now your product recommendation can have an objective an unbiased back. You will be able to confront your intuition, emotions, and ego with numbers and not only your numbers but with your team’s PSMs. However, making product decision will be much easier when you have a mechanism that helps you make your decisions slightly better and clear.
What is the problem with the Product Scoring Mechanism?
We’re back again with bias. Critics would say that the way you build your Product Scoring Mechanism is biased, and therefore the scoring and output are still biased. I agree we can manipulate any mechanism to give the results we wished for. However, when dividing larger problems to smaller ones as we do in this method we minimize our bias into problems that we can quantify more clearly, and sometimes really measure a number like cost or time to develop. Building your Product Scoring Mechanism with a diverse team will also minimize the bias of this mechanism.
