How to Prioritize Features for Your Product Roadmap

Updated: September 16, 2010

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.

  1. Decide who owns, organizes and facilitates the decision process (driver) - often the product manager
  2. Decide who needs to be consulted before the discussion; get their feedback quickly (constituents)
  3. Decide who needs to discuss the decision real-time (committee)
  4. Set a regular meeting time for the committee
  5. Have clear criteria for how to prioritize and reach a decision
  6. Require a decision to be made by the end of any meeting
  7. 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.

  1. Business benefits: What is benefit to your business, such as driving revenue, cutting costs?
  2. User benefits: What is the impact on user satisfaction or user experience?
  3. 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.

  1. It is more difficult to get feedback from users
  2. Even if you do have feedback, it is difficult to quantify
  3. 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.

Featured Research
  • Best ERP Features and Benefits for Your Business

    Are you considering investing in ERP software for the first time? Or maybe you already have an ERP solution but you’re worried it’s becoming dated. If either of the above apply to you, read our latest guide on the top ERP features and benefits based on the size of your business. You may be surprised at how versatile and cost-effective it is becoming - regardless of if you own a small business or run a large enterprise. more

  • 9 Spooky Signs You Need a Contact Center Upgrade

    When was the last time you evaluated the performance of your current contact center and the software you are using? The results may be frightening! If it’s been awhile since you invested in contact center software, there is a good chance that your needs have changed or that there are better options available now. Fortunately, it’s relatively easy to determine if you need an upgrade or not. more

  • 7 Ways the Wrong Phone System Can Haunt Your Business

    The wrong phone system could be haunting your business - and we’re talking about problems more serious than ghosts and ghouls. From increased costs to issues with scaling, we’ve identified seven important ways that a less than ideal phone system could be holding you back. You’ll be surprised at how much of a difference this can make to your bottom line too. more

  • Ditch Your Fax Servers

    An in-house fax server gives an IT department centralized management and monitoring over the entire enterprise's faxing. This can help your company track usage and better maintain records for auditing and record keeping. However, there are serious drawbacks that come with utilizing an in-house fax server solution and these range from security to cost-prohibitive pricing. more

  • The IT Manager's Survival Guide

    As an IT manager, maintaining physical fax servers and infrastructure is not a high priority. However, fax capability remains a business need simply because chances are your industry is dependent on its security. What if there was a way to reduce the amount of time spent handling fax complaints and maintaining physical servers? And this way took into account security, cost savings, and freed up your IT resources. Would you be interested? more