How to Prioritize Features for Your Product Roadmap
Who makes the decision?
When prioritizing features for a roadmap, the process is often slowed down by lack of resolution - product managers arguing with marketers arguing with engineers and so on. Poor communication, misplaced passion and the need for 100% consensus often get in the way of quick resolution. So here are some steps to identifying roles and putting in place a decision process.
- Decide who owns, organizes and facilitates the decision process (driver) - often the product manager
- Decide who needs to be consulted before the discussion; get their feedback quickly (constituents)
- Decide who needs to discuss the decision real-time (committee)
- Set a regular meeting time for the committee
- Have clear criteria for how to prioritize and reach a decision
- Require a decision to be made by the end of any meeting
- Designate the one person that makes the decision if consensus cannot be reached (decision maker) - often the CEO/founder in start-up
The steps above put in place a rudimentary product steering committee.
How do you make the decision? By using a framework.
You may need a basic framework to help your group prioritize. The value of a framework is in providing a common set of criteria that can be used when discussing prioritization. I've seen two related but different approaches work here.
The first approach, a typical framework in product management circles, is what I call BUC. It involves assessing the following for each feature.
- Business benefits: What is benefit to your business, such as driving revenue, cutting costs?
- User benefits: What is the impact on user satisfaction or user experience?
- Costs: How much time and money will the feature cost?
There are many ways to create a weighted average "value" for each feature across these three categories. I'll leave that to a future brief. One challenge with this approach is that there are often limited resources in the organization to come up with accurate benefit and cost numbers. However, this process can still be good for validating "hunches" and looking for overlooked features. The framework is also a good approach for more complex business models serving multiple masters.
The second approach is what I call the "Three for One" approach. In this model you typically have a single goal in the roadmap that you're focusing on and everything else is secondary. For example, you might consider member conversion your most important goal ==> we receive many visitors to our service/site and want to better convert them into members, customers, etc. In this scenario it's best to cut straight to the chase and brainstorm what I call the top THREE. These are the three features that can have the biggest impact in the shortest amount of time on your ONE goal. There are many variations to this but you get the idea. This model works well in companies where there is already consensus on a singular goal or where the organization has strong product leadership from the top.
For the rest of this brief, I will primarily address first process - BUC. There are several specific issues to consider in using this process.
Defining your features
As simple as it sounds, all too often people do not have a common understanding of what features are being considered. Do not rely on a feature list where you assume everybody understands what the feature means. Take the time to provide a paragraph description of each feature including BUC elements specific to that feature. Typically, this will be the job of your product manager.
Granularity of assessment: Features vs. initiatives
It is impossible for a steering committee to discuss and make trade-offs on hundreds of features. Even though I've been using the term "feature" throughout this brief, the more accurate term might be "initiative." For example, if you want to better convert members initiatives could include: 1) improving your registration page itself, 2) new ways to present registration messages to visitors within a certain context, or 3) offer a new application to encourage registration. The trick is to not define your initiatives at too granular of a level of detail as this can lead a group into implementation discussion vs. prioritization. The specific implementation of a feature or initiative ideally should be left to your product team and, increasingly in today's world, to an agile process.
Business Benefits (the "B" in BUC) - What are your business goals?
Your group must agree on goals and objectives as it relates to business benefit. These goals vary from business to business. For example, most Internet services and SaaS application providers will have funnel metrics that drive their business. One example is visitors ==> members ==> initial monetization ==> retention/re-monetization. Enterprise software companies, however, have different approaches where they are trading off features that will help the sales team close deals vs. features that make current customers happier. Yet another business goal could be to reduce internal costs to maintain your product or service.
Whatever your business model and metrics, you will need to have a common understanding where your strengths and weakness lie, and what the business priorities are for this product roadmap cycle. Is it a single business goal? Is it two business goals equally weighted? Is it three goals but with varying degrees of priority?
User benefits (the "U" in BUC) - Too often under-emphasized?
While it's easy to sit around a table and talk knowledgeably about business benefits, it may be more of a challenge to discuss user benefits. Everybody talks a good game about the importance of the user, but many companies spend surprisingly little time digging deep here. A few reasons for this include.
- It is more difficult to get feedback from users
- Even if you do have feedback, it is difficult to quantify
- Users may not be your direct customer (think media sites)
The good news here is that the Internet is making it easier than ever to capture feedback from your users and incorporate that feedback into your prioritization process.
Costs (the "C" in BUC) - Hard to estimate
Costs also can be tricky. To get "accurate" costs (resources and time), one could spend weeks if not months examining the costs of a potential initiative that will never be implemented. Why? Ultimately the cost will be related to which specific features and how they're implemented. Do not fall into this waterfall trap unless you have extra product management and engineering management resources laying around. Get the right people in a room and assign a relative cost to all initiatives within a single day or less. Remember, you need estimates not exact costs for a prioritization exercise.
