I recently started a new project at work of leading a team to build a design system for all of our products. In addition to wearing the front-end designer and developer hats, I’m also tasked as the defacto Product Owner whose responsibilities include building out the roadmap among other things.
As I was looking for help on prioritizing features I stumbled across this 14-year-old wisdom from Joel Spolsky on a prioritization.
I took a stack of 5×8 cards, and wrote a feature on each one. Then I called the team together.
At this stage, the idea was not to debate any feature on its merits, or to design the feature, or even to discuss the feature: just to have a vague, rough idea of what it was.
In part two, we went through all of the features and everybody voted on each feature: just a quick “thumbs up” or “thumbs down.” No discussion, no nothing: just a real quick thumbs up or thumbs down on each feature.
Next we assigned costs for each of these features, on a scale of 1 to 10, where 1 was a quickly feature and 10 was a big monster feature.
Based on the consensus estimate of costs and my own judgment, we put down prices on all the features.
The next step was making a menu of all thirty proposed features and their “costs”. Everybody on the team got a copy of the menu and was given $50 to play with. They could allocate their money any way they wanted, but they only had $50 to spend. They could buy half-features, if they wanted, or buy double features. Someone who really liked that Track Billable Time feature could spend $10 or $15 on it; someone who liked it a little might only spend $1 and hope that enough other people funded it.
Ta da! A list of all the features you might want to do, in rough order of everyone’s best idea of which features are the most important.
And now you can start to refine. For example, you can clump together features that naturally belong together, for example, doing software schedules makes billable time easier, so maybe we should either do both or neither. And sometimes looking down the prioritized list it’s just real obvious that something is messed up. So, you change it! Nothing is carved in stone. You can even change the prioritization as you go through development.
His approach to prioritizing features with the entire team is fun and refreshing.