When it comes to developing a new product, feature prioritization will always be a topic that’s at the front of mind for product teams. No matter how much experience you might have in your industry, even the most impeccable product managers can struggle with figuring out which features they need to include on the product prioritization roadmap, and which are simply not appropriate for their brand. Whether you’re looking for a way to enhance the value of your existing product, or you’re creating something new from scratch, the good news is that there are solutions available for almost every industry.
To help you get a better insight into your own product strategy, we’re going to use this article to introduce you to six different priority management frameworks. Once we’ve been through each one, we’ll give you some key takeaways that you can use regardless of your chosen solution.
One of the simplest ways to cut down on the complexity in your product prioritization strategy is to score each feature with a weighted system, to help you see your options in terms of a numerical hierarchy. For instance, imagine you talk to all your shareholders, and agree that the following three driving factors are most important to your new product:
You should be able to assign different features to these factors depending on the results you’ve seen in the past. Once you’ve done that, you can assign relative weight to each feature depending on what you consider to be the most important. For instance, you might think that your current focus is on growing your customer base. That would mean that 50% of your efforts go into attracting new customers, while 30% goes into maintaining your current user base, and 20% go into managing support costs.
Basically, this strategy is all about giving yourself an easier way to measure the value of each critical feature in your product strategy. Remember, you need to make sure that everyone involved in the decision-making process agrees on the weighted values you choose.
Another popular option for priority management is the Kano model, which allows product managers to consider the new potential features of any product with a focus on how much joy the feature will bring to the customer, compared to how much investment you’ll need to make as a company into that new feature.
The Kano model builds on the idea that, while there are some essential features you’ll need to have in your product if you want it to sell, continuing to invest in those “threshold” features might not do much for customer delight. On the other hand, features like performance can give a proportionate growth when it comes to customer satisfaction, as you continue to invest in them.
The Kano model simply asks you to split your feature selection down into the “basic expectations” that your customers have about your product, the satisfactory features that keep your customers happy and improve return on investment, and the “delight” features which deliver profits that significantly outweigh the investments made into your product.
The opportunity scoring framework for product prioritization is built around the “Outcome-driven innovation” concept. Created by Anthony Ulwick, the framework builds on the core idea that people buy certain services and products with the distinct aim of getting a job done. That means that the expected outcome matters more than anything else.
One of the many conclusions of the opportunity scoring framework is that customers might not be very good at finding the perfect source of solutions for their problems. However, they can be very valuable at providing insights into the kind of outcomes they want when trying to fix certain problems. Through user research, the opportunity scoring method allows you to build the desired list of outcomes for a product, and then attribute features to those outcomes to ensure that the needs of your customers are satisfied.
Generally, you should be able to plot feature prioritization on a graph, by looking at the way different features serve different customer problems.
The MoSCoW method is yet another solution for feature prioritization that’s often used in management fields, to help teams to come to a consensus on what they believe to be the most important aspects to customers and stakeholders. The term is simply an acronym that outlines each of the potential categories for prioritization, and the “o’s” are added just to make the system more memorable.
In the MoSCoW method, feature requirements are classified as follows:
Must haves: These are the critical features that must be included in the product. If just one of these features isn’t in the final product, then the release would be considered a failure. However, features can be downgraded out of the “must-have” category with agreement from the full team.
Should haves: These requirements are still very important, but they might not be critical to the product release. They’re generally quite nice to have, however, and can improve the profitability of the product.
Could haves: These features are also desirable, but they’re not particularly important in any way. Instead, they’re usually, the low-cost enhancements that can be delivered to the product but can also be removed without much impact.
Won’t haves: Finally, these are the least-critical features or the requirements that simply don’t align properly with the product strategy. They’re usually dropped from production entirely, or they can be reconsidered in future releases.
The MoSCoW method is a quick and simple method for product prioritization, but it’s sometimes difficult to determine the exact position of features in the product roadmap using this model, as it’s not very in-depth.
Finally, this product prioritization framework is more of a group game, than a serious approach to product strategy. However, that doesn’t mean that it can’t do incredible things for streamlining your plan. The “prune the product tree” solution is all about shaping the growth direction of the product to help ensure that it meets with market needs, while simultaneously, understanding that certain features will need to be left behind.
Here’s how the system works:
This game allows you to extract valuable data from your team about where you’re heading as a business. Additionally, it can help to bring people together on a shared view of the most important aspects of product development.
Last, but not least, the Systemico model focuses on giving businesses a framework to prioritize their product development based largely on the value that features can bring to the customer. The idea behind the Systemico model is that the concept of value is both holistic and systemic. That means that product requirements should be considered based on how they consider engagement levels and user goals.
The Systemico model is also closely linked to story mapping as a strategy, as it creates a two-dimensional grid which makes visualizing the scope of the product easier according to two separate priority levels. The first priority is “user goals”, where the product can be defined in terms of which functions are necessary, while the second priority is user engagement. The engagement aspect measures the level of interaction between the product and user. There are four degrees to think about here:
Core: Features that are essential to satisfying the basic needs of customers - these are the baseline requirements for users in any produce space.
Use: Features that are intended to improve the accessibility or usability of the product, and therefore enhance the appeal.
Engagement: Functionality that helps the user to have more interaction with the product, and encourages them to keep coming back in the future
Exploration: Features that might help to strengthen the bond between the product and the user.
There’s no one-size-fits-all solution when it comes to making things work with feature prioritization. Ultimately, you’ll find that while one framework is used for a particular set of circumstances, another strategy is more appealing in another situation. After you go through each of your options in depth, you’ll begin to recognize which solutions give you the best results, depending on the goal at hand.
Although all the choices outlined above use different strategies, it’s also worth noting that they each feature a few commonalities that you’ll need to keep in mind regardless of what you’re hoping to achieve with your product prioritization activities. Here are just some of the most important takeaways that you can keep in mind, whatever framework you use.
Typically, the best prioritization methods work when you’re considering high-level features and user goals. This is because the team can focus on providing value to the end-user, rather than getting bogged down in concerns about price points and budget.
No matter how you choose to define the perfect features for your product, it’s worth remembering that you should always put effectiveness first. The objective of product prioritization isn’t just to set your priorities and stick to them. Instead, you should make sure that you’re constantly aware of what is truly adding value to your company.
Sometimes, the people responsible for product strategy within a team can feel as though they have to do everything by themselves. However, most of the time, feature prioritization isn’t a solo effort. Most of the time, the best thing you can do is get other people involved in your product journey. To do that, you’re going to need to make sure that you have the right collaborative software in place to keep everyone on the same page.
The more you can bring people together to collaborate on different features and solutions, the more likely you are to get a comprehensive strategy that isn’t affected by bias or subjectivity. In the end, the technique you choose to make the most out of your product prioritization solution isn’t nearly as important as the conversation your team has about the priorities you need to think about.
Even if you don’t necessarily agree about the framework you choose to find the right features or solutions for your new product, if you can come together and agree on the criteria, then you should be ahead of the game.