Why You Need a Feature Prioritization Framework – Part 3

In the previous two installments of this series (see Part 1 and Part 2) we covered 6 feature prioritization frameworks, including the RICE method and the KANO model. In this post, we’ll consider the pros and cons of three more digital product development prioritization methods. The examples shown below are courtesy of Roadmunk. 

7. Product Tree

Also known as pruning the product tree, this collaborative innovation game was developed by Bruce Hollman. The focus of this activity is to shape the product so it matches the customer outcomes that bring the highest value to the company.

The game aims to prune product backlog items to ensure innovative ideas aren’t left behind. Here’s how it goes:

1. First, draw a large tree with a few big branches on a whiteboard or a piece of paper.
   • The trunk represents your product’s current features.
   • Outermost branches represent features available in the next release.
   • Other branches represent the features that aren’t available yet.
2. Ask participants (customers) to write potential features on sticky notes. These are the leaves of your tree.
3. Then, ask your customers to place their feature leaves on a branch.

By asking customers to place their desired features on the tree, you can identify the biggest clusters or branches. This allows you to determine which areas of your product need more work, which features need to be changed, and which product feature areas can be deprioritized from all immediate future releases.

Pros of the Product Tree

• Gives you a visual sense of how well-balanced your product features are.
• Allows you to tap directly into the insight of your customers without relying on a rigid survey.

Cons of the Product Tree

• Doesn’t give product managers quantitative values for how to rank each feature, only a general visual guide.
• Doesn’t separate features into any sort of grouping bucket, making the exercise time-consuming.

8. Cost of Delay

Joshua Arnold defined Cost of Delay as “a way to communicate the impact of time on the outcomes the company wishes to achieve.”

Specifically, the Cost of Delay framework prompts you to ask these questions:

• What would this feature be worth if the product had it right now?
• How much would it be worth it if this feature gets made earlier?
• How much would it cost if it was made later than planned?

The way you assign a monetary value to each feature is by calculating how much time and team effort it takes to build. You and the team can also assign value to the features in terms of how much they will be worth after they’re built.

Let’s say you have one feature that costs you $30,000 for each week it’s delayed, and it takes three months to build. On the other hand, you have a feature that costs $10,000 for each week it’s delayed, and it takes you the same amount of time to build. Within this prioritization framework, the first feature would be the one your team focuses on first.

In the graphic shown below, Apple Pay Integration would be the clear top priority, followed by Guest Checkout Improvement, Two Factor Authentication, and Reskin Shopping Cart.

Pros of Cost of Delay

• Allows you to quantify your product backlog in terms of money.
• Helps product managers make better decisions based on the value that matters the most to the company.
• Changes the team mindset around features from cost and efficiency metrics to speed and value.

Cons of Cost of Delay

• Provides parameters for determining feature monetary value based on gut-feel and intuition.
• Can lead to internal disagreements regarding the arbitrary value of any given feature.

9. Buy a Feature

Buy a Feature is an innovation game that can involve customers and stakeholders. It’s up to you and the needs of your product. When you use it as an exercise with your customers, this method can quantifiably tell you how much a feature or an idea is worth to the people who’ll end up using it.

The game goes like this:

1. Choose a list of features, ideas or updates, and then assign a monetary value to each one. This value isn’t arbitrary—it should be based on how much time, money and effort each feature costs you and the team.
2. Put together a group of people of up to eight customers or your internal team. Give them a set amount of money to “spend” on these features.
3. Ask your participants to buy the features they like. Some customers put all of their money only on the one feature they’re passionate about; others spread their cash around multiple different features. Ask the participants to explain why they spent money on the feature they picked.
4. Reorganize that list of features in order of how much money your customers spent on them.

Innovation games like this suggest that you price some of the features high enough that no one can buy them. This forces your customers to team up and negotiate which feature they’re willing to pool their money on.

Pros of Buy a Feature

• Provides the perfect method for those who believe in the Steve Jobs quote (“People don’t know what they want until you show it to them”) but also want to tap into the wisdom of customers.
• Replaces the stuffy, old-schooled customer questionnaire with a collaborative, fun exercise that forces your customers to rationalize why they think they need a feature.

Cons of Buy a Feature

• Can only include features in the product development roadmap—the results just tell you what features customers value the most.
• Requires you to get a group of customers in one place at the same time, which can be difficult to coordinate.

Which Model Should You Use?

So…you just choose one of these models, and you should be fine, right?

The answer is not so simple. In reality and in practice, it depends on many factors. For example, what is the industry of the product that you want to fit into a specific market? Is this a B2B or B2C product? Is this a service-oriented product?

Knowing which prioritization framework to use is not easy!

The Kano Model is useful for making customer-centric decisions, but it can take time to gather all the information needed for your insights to be accurate. Many people like the RICE scoring system as it takes confidence into account in a qualitative way, but there are still a lot of unknowns.

On the other hand, MoSCoW focuses on what matters to both customers and stakeholders, which is particularly useful for product managers who struggle with managing stakeholder expectations. It’s also the simplest to understand for non-technical stakeholders. However, there’s nothing stopping you from putting too many things into the <Must Have> category and overextending your resources.

Of course, these aren’t the only methods out there, and many talented project managers have their own ways of doing things. As with many things in product development, the best approach is usually to test, learn, and test again!

Link Features to Business Objectives

Product managers drive the <Why> behind a product strategy. Having a standardized prioritization process is only one piece of the strategic puzzle. There are many other moving pieces involved in making sure your strategy is driven by solving the most impactful customer problems.

However, the most important aspect of prioritization is that no matter what framework you choose, you must always make sure that each feature follows the business objective of your company.

The objective is not always linked to revenue growth. For example, an objective for a Google product would probably be more linked to market share. Google is swimming in money and may care more about taking a bite out of Apple’s market share with a product or feature than driving revenue.

The business objective can be a range of topics like revenue growth, cost savings, customer retention, market share, international market penetration, or vertical or horizontal market expansion among others.

Every single prioritized feature must be linked to a business objective. If not, it doesn’t matter how well-calibrated your feature prioritization list is—eventually the road map will become a roadmap to nowhere and your team can easily lose focus, which defeats the purpose of this entire exercise.

In the previous two installments of this series (see Part 1 and Part 2), we covered 6 additional feature prioritization frameworks. If you need help prioritizing features on your next software development project, we would be glad to help. Contact 3Pillar today to learn more.