Why you shouldn’t dot voting to decide what to work on

While reading Empowered, I started to reflect on the different kind of prioritization models that product managers use and are taught to use. There are more prioritization models than you can count, and many of them have one fundamental problem: they are built to please, not to choose the right opportunity.

Just to name two of them: dot voting and buy a feature. Both are extremely popular, I was myself that PM that used dot voting to create a common buy-in in the team around the next best feature to build. But if I could go back and talk to that girl now I would tell her: what are you doing?

Image courtesy of Jo Szczepanska via Unsplash

Buy a feature

Let’s start considering the popular framework of ”buy a feature”, that Marty Cagan talks about in his latest book and ignited my reflections. The concept is really simple: stakeholders spend some fictional money to ”buy a feature” from the product team and make sure that a certain problem gets prioritized. You can use this method as a scoping technique in a bigger project (which features shall be part of the MVP) or as a way to prioritize standalone requests from stakeholders.

As much as this is a great way to force a stakeholder to compare and contrast all the different things they want to do and make their wishlist shorter, it is a horrible way of prioritizing.

Why? Because not all stakeholders should have the right to buy a feature. Not all problems are worth solving nor are aligned with the current product strategy. Therefore your job as a CPO or PM is not to create a sense of fictive fairness where everyone gets time, but to take the tough conversation and say no. If it is not a good strategic fit, no matter how much money you have, you shouldn’t be able to buy the feature.

Dot voting

The same goes for another extremely popular framework: dot voting. It is unlikely that, if you work with product development, you never used it. I believe this is the first thing they teach you as a PM in a workshop: lineup the ideas and then let the team vote. The post-it with the most dots is the one going forward in the process. Everyone has a saying, all opinions are heard, everyone is happy. Right? No, of course not. The unhappy part here is the outcome we want to reach as part of the product strategy. As we are never gonna get there by choosing the most popular post-it, I learned this on my own skin.

The reason why I stopped using dot voting to pursue an opportunity is that, and I know this might be unpopular, I truly believe that not all the dots are worth the same.

If we are debating what is the best technical solution, then the voice of the most senior engineers or of the technical director is the one that counts the most, they should decide on the solution to pursue. If the decision is about usability, UX and user researcher has a veto in my eyes, and if it is a question about a strategic product direction, then it is the CPO or the PM. As Orwell would say ”all dots are equal, but some are more equal than others”.

Dot voting is still great for some purposes, but not for prioritizing. I use it, for example, to let the team voice their preferences about a topic in a workshop, or as a means to quickly select some ideas that then would need to be validated further but it shouldn’t be the way you decide to pursue a solution.

Prioritizing shouldn’t be about pleasing someone, about creating a false impression that everyone has the same understanding of the problem and how to best solve it, or about letting stakeholders believe that all of their problems matter in the same way.

Prioritization is not supposed to be fair, it should be an exercise of ruthless focus, where product should keep its eyes on what matters the most: the outcomes.

It took me some years to learn it, but if I had to give some advice to someone just starting their PM career, this is what I would say: do not seek consent when choosing a solution, make the expert opinion count, and be firm on the strategy.