Why You Need a Feature Prioritization Framework – Part 2

In the previous installment in this series we covered three feature prioritization frameworks, including the RICE method, Value vs. Effort, and the KANO model. In this post, we’ll consider the pros and cons of three more digital product development prioritization methods. Examples shown below are courtesy of Roadmunk. 

The beauty of this product prioritization framework is its simplicity. It also puts the focus on the user experience rather than the internal opinions of your team and stakeholders. Along a horizontal line, you create a series of sequential buckets or categories that represent each stage of the user journey through your product. This allows you to think about the way your customers navigate your product from signing up, to setting up their profile, to using specific features. Along a vertical line, you then place these tasks in order of importance, from top to bottom. This allows you to prioritize the order of the features you will work on. In some cases, the bottom part of the axis is labeled “Backlog Items” for the tasks that you decide to put on hold. Finally, you draw a line across all these stories to divide them into releases and sprints.

• Helps quickly and efficiently identify your MVP.
• Centers around user experiences. You get to write the user stories.
• Facilitates collaboration—story mapping is a group activity that involves the whole team.

• Doesn’t take into account external product prioritization factors like business value and complexity.

The MoSCoW Method allows you to figure out what matters the most to your stakeholders and customers by classifying features into four priority buckets. MoSCoW (no relation to the city—the Os make the acronym more memorable) stands for Must-Have, Should-Have, Could-Have, and Won’t-Have features:

• Must-Have features have to be present for the product to be functional. They’re non-negotiable and essential. If one of these requirements or features isn’t present, the product cannot be launched, thus making it the most time-sensitive of all the buckets. Example: Users MUST log in to access their accounts.
• Should-Have requirements are important to deliver, but they’re not time-sensitive. Example: Users SHOULD have an option to reset their password.
• Could-Have are features that are neither essential nor important to deliver within a timeframe. They’re bonuses that would greatly improve customer satisfaction but don’t have a great impact if they’re left out. Example: Users COULD save their work directly to the cloud from our app.
• Won’t-Have denotes the least critical features, tasks or requirements and the first to go when there are resource constraints. These are features that will be considered for future releases.

The MoSCoW model is dynamic and allows room for evolving priorities. So a feature considered as a <Won’t-Have> can one day become a must-have depending on the type of product.

• Involves stakeholders without a technical background in the product prioritization process.
• Provides quick, easy and intuitive way of communicating priorities to the team and the customers.
• Allows you to think about resource allocation when classifying features and requirements into each bucket.

• Creates temptations for teams and stakeholders to overestimate the number of <Must-Have> features.
• Offers an exercise in formulating release criteria more so than a prioritization method.

Also known as opportunity analysis, this prioritization method comes from Anthony Ulwick’s Outcome-Driven Innovation concept. His theory states that customers buy products and services to get certain jobs done. This approach surmises that customers aren’t very good at coming up with solutions to their problems. But…their feedback is still important. It’s what the product team uses to come up with the desired outcomes for a product or feature. Opportunity Scoring uses a Satisfaction and Importance graph to measure and rank opportunities. After you come up with a list of ideal outcomes, you then survey your customers to ask them the following questions:

• How important is each outcome or feature?
• How do you rank the importance of each outcome or feature?
• How satisfied are you with the existing solutions?

After you plot these answers along the chart, you should see the features that matter the most to customers (the outcomes) yet currently have low satisfaction scores within your product. These are the features to prioritize for your next sprint.

• Provides simple framework for quickly identifying the most innovative solutions to common problems.
• Makes it easy to visualize and categorize priorities on a graph.

• Can cause customers to overestimate or underestimate the importance of a feature in the survey or questionnaire.

Does your product development team spend hours debating features? If so, how do you finally decide which features to build? Prioritization can be challenging, especially when you’re developing a complex product. As you can see, there are a variety of prioritization frameworks you could use, with some more elaborate than others. In the next post in this series, we’ll cover 3 more prioritization frameworks: Product Tree, Cost of Delay, and Buy a Feature. You can read part 1 of the series here. If you need help prioritizing features on your next product development project, we would be glad to help. Contact 3Pillar today to learn more.

Special thanks to these members of FORCE, 3Pillar’s expert network, for their contributions to this article.Daniel Lunski

FORCE is 3Pillar Global’s Thought Leadership Team comprised of technologists and industry experts offering their knowledge on important trends and topics in digital product development.