6 Ways Roadmaps Help You Be Better at Your Job (and Your Career)
As product managers, creating and maintaining product roadmaps are regular duties. Product roadmaps enable us to do our entire jobs easier. It only requires...
Prioritizing features is such a critical task for product managers and there’s no single “right” way to do it. Instead, product management teams must sort through potential features and find a realistic order based on the importance and demand of each item. Because of this, nearly 37 feature prioritization frameworks have popped up over the years.
So how do you know which one is the best fit for you and your organization? Here’s a crib sheet to help you narrow things down and pick a feature prioritization framework that will work for your team.
No gut instincts in this department. These prioritization frameworks use cold, hard arithmetic to divine which features should jump the front of the queue.
The RICE scoring model uses four elements for feature prioritization: Reach, Impact, Confidence, and Effort. This puts the emphasis on what the real effect on the business will be for each potential project, but with a little consideration regarding how much work it will be.
RICE works best in a group setting and forces stakeholders to publicly state what results they think each feature could have, instead of just saying it’s “important.” The downside is that you’ll have to do some homework to really quantify the market effect of each potential item.
Weighted scoring is another number-heavy prioritization technique where each feature receives a score for various attributes. Add them all up and the feature with the most points gets the top spot.
This is a great method when you’re looking for something truly objective and qualitative as there’s no editorial element—the numbers speak for themselves. The problem with this framework is that it doesn’t factor in any level of effort. Plus, you must do some upfront work to figure out how much weight to give each attribute.
There are several highly collaborative prioritization methods involving the evaluation of a giant pile of potential features and enhancements collected by the product team and organizing them.
Affinity Grouping is great for brainstorming collaboratively and getting lots of non-product folks involved in the activity. You’ll develop themes and associate specific items with them, making it easy to define the contents of a theme-based release. The downside is that this doesn’t help you prioritize those themes or evaluate their business impact.
Another sorting and classification exercise for prioritization is the MoSCoW method. MoSCoW is short for Must Have, Should Have, Could Have, Will Not Have Right Now, and categorizes features. With this framework, the team takes every possible feature and assigns them to one of these four categories based on their importance to the success of the product.
This approach is great for getting representatives from the whole company involved and building consensus about what’s truly important for the immediate future. It takes level of effort into account since too many Must and Should items will create a project way too big for prompt delivery. MoSCoW’s shortcoming is that it works best for a single, time-boxed release and doesn’t have a great way to scale across multiple releases for a full roadmapping exercise.
With a pile of fake cash you can give each feature a monetary value—the more you’d pay for it, the more important it is. Buy-a-Feature is an excellent way to see who values what more, as various stakeholders may value features quite differently. By putting their (fake) money where their mouth is, people are forced to make feature prioritization decisions. We don’t have unlimited time, so we don’t get unlimited budgets, either.
This approach is great when you can’t otherwise get a consensus on which initiatives are most important and your customers just say they want everything. It doesn’t take costs or level of effort into account. But it will help break some logjams while revealing what people truly care about.
Most product managers don’t have the luxury of an army of idle developers twiddling their thumbs and standing ready to build whatever we fancy. But some organizations are truly running lean and mean. When you throw in a short runway to make progress, product teams must make sure they’re making the most of their time.
Value vs. complexity is great for identifying the “low-hanging fruit”. It will have the most bang for the buck, forcing product teams to assess the business return against the level of effort. It may not be as valuable for more mature products (where most of those low-hanging items have already been picked off). But when you’re trying to decide what to move to the front of the line based on how quickly you can make a real impact, it can be a helpful method for any type of product.
While many feature prioritization methods key off group work and collaboration, the DACI decision-making framework is a great fit for a busy team that wants to delegate to subject matter experts. It helps organizations break projects down into smaller bites and assign various steps to different individuals. This way, organizations can reach decisions quickly without sacrificing input and approval from the folks that matter most.
The strict process will streamline product decisions and spread the burden out across the organization. But for it to work well the Driver must stay on top of things to ensure the process doesn’t stall out on anyone’s overburdened plate or overflowing inbox. It’s also not the most inclusive framework, which may not play well in organizations where everyone is used to offering their two cents on things.
While no prioritization method ignores customer needs, few put it front-and-center throughout the product development process quite like quality function deployment (QFD). QFD is customer-centricity on steroids as it ensures customers get a product they definitely want and will use, not just what the product team thinks will resonate with the market.
QFD is best suited for iterative innovation of existing products with well-understood customer bases since you need a really good sense of use cases and personas to shift the focus to quality in such a significant way. Because quality trumps everything, it can also slow down releases and increase costs since there’s no appetite for corner-cutting.
The Kano model is another customer-centric prioritization method. The emphasis is on customer satisfaction, although it does take implementation effort into account as well. Revenue, ROI and other business factors aren’t part of the conversation.
Kano is best used in early-stage products (even MVPs) when you’re trying to find what’s going to delight customers and increase their love for the product, while still being realistic about what product development can do before each release. While it can be used for more mature products, at a certain point you run out of “Wow” features and just need to do boring stuff like scalability and revenue optimization.
As you’ve seen, there are many frameworks available to product teams looking for a little structure around their prioritization efforts. As products mature and organizations grow, what once worked may no longer cut it.
Luckily none of these require irrevocable commitments and product teams can use trial and error to see what’s a great match for their company’s style and current state. Regardless of which one you choose, having some scaffolding around the prioritization process is sure to provide momentum and get to a decision point faster than an anything-goes brainstorming session.