Every product development team (and product company, in fact) spends considerable amount of time and energy on prioritization of its work. The obvious time goes into meetings, data gathering, discussions, brainstorming and so on and so forth, but the more hidden energy goes into second guessing the prioritization, getting buy-in, politics and other counter productive activities.

Getting this right is extremely hard, and there is no tool or set of tools that will make this easy and straight forward. Here are some suggestions that can hopefully help though.

• Forget about the medium term. In my experience, the most successful (and efficient) teams are the ones that have a simple, clear long term vision, and then a specific short term tactical plan. Don’t waste time planning what to do 6 months (your horizon might be shorter or longer, depends on the industry you’re in) from now, since things will have changed so much at that point that it won’t matter. This alone cuts your planning time by half.
• Make teams responsible for their own planning. The team building a product knows it the best, has the best insights into the users, the technology, and the market being addressed, and has the best incentive to create a plan that they can stick to. This does not mean that teams need to be fully autonomous and independent, but rather that external parties (other teams, executives, etc) should provide feedback and guidance, not hand down fully baked plans. This reduces that chances of second guessing sabotaging your plans.
• Get data, but use it fwiw. Data is always good to inform prioritization, especially if its data from your own product (usage, bugs, performance stats, etc). Make sure everyone involved in the planning process has access to, and looks at the data. However, don’t let data dictate your prioritization, and be especially wary of inaccurate (e.g. from a shady third party analyst) or mis-interpreted data (e.g. a very vocal user on your user groups over-represents certain issues).
• Let the team do the prioritization. Once you have this structure set up, and everyone has access to all the data, it’s time to prioritize. I like quarterly planning meetings, and I’ve used a range of methods for getting the releases scoped and lined up. One that I particularly like is to spend half the meeting (usually 30-45 minutes) getting everyone’s ideas on the table, and then the second half (another 30-45 minutes) voting (each team member gets 3-4 votes) which gives you a pretty rough but good idea of the order of how things and then you use that to scope releases of your product. This gets buy-in from the people who will be doing all the work, which is crucial.
• Communicate the plan widely. Let others know what the team has come up with, and ask for feedback, but don’t let randomization happen. This step might require you to take some thoughts back to the team to align better with other teams or just to share some excellent insight that someone outside the team might have had, but it should hopefully not force you to do the whole process again (if that’s the case, perhaps the team is not that competent?) This should defuse most of the politics (although that’s always hard).

Is this scientifically accurate? No. Does it account for all user feedback, and ensure that the most requested features get built first? Not really, but sort of. The problem with strictly analytical approaches to prioritization is that you end up with faster horses, when you really want to build cars (building on Henry Ford’s famous quote), so be careful. This is such a fuzzy process anyway, that often just getting a rough order in plan is crucial, and allows the team to focus on execution and building the product.

Remember, a body in motion tends to stay in motion, so don’t get paralyzed by planning and prioritization.

Do you have any other insights into prioritization? Share your thoughts in the comments.

- Gummi