Products, the ticking force behind consumerism.
Is building them as easy as having an idea and assembling a team that can program the product into existence?
In an ideal world, maybe.
The real world is made up of many volatile forces—the market, the fleeting desires of users, and the notions of team members and stakeholders.
To bring everyone to agree with each other and to build something that can have a chance at a market is an enormous undertaking.
How can product managers and product owners make sure that what they are building is worthwhile?
Or rather, how do you choose the right features to work on?
In this blog, we are going to list 9 methods that will allow you to prioritize the right features for your product so that you do not waste your time or resources.
Principles behind feature prioritization for effective product development
Effective product strategy
Before the product roadmap, comes the strategy. Led by the value proposition or the USP of your product, your product strategy is made out of insights that tell you what you need to do in order to win at the market.
Every other technique, feature prioritization method, and tool come only after you have a firm product strategy in place.
Trying to build without a product strategy is like playing chess blindfolded. The moves do not matter because you have not planned where to go next.
So, before jumping into development, take some time with your team. Encourage everyone to think, brainstorm, and research and put together a strategy.
Everything else falls into place once you have a product strategy. Still, you will need some deliberate nudges to ensure that everyone is on the same page.
An aligned team is more than an efficient assembly-line—it is an opportunity to do something beyond building a run-of-the-mill product.
Any team with a product requirements document and a product roadmap can build something for a presupposed market.
But an aligned team has a shared heart that beats for a common purpose, which is, putting something of value out in the market.
Alignment, then, is about the emotional rapport of the team members as well.
Without an aligned team, it is hard to get out and make a dent in the market.
No amount of technical ability is going to save you at the market if your customers are not impressed with what you offer.
Don’t be disheartened. Instead, understand that even though you build the product, it will be your customer who would use it the most.
Ultimately, the product is ‘owned’ by the customer.
You’d need to build something that caters to their needs but is also intuitive and does not require a lot of head-scratching to work.
Simple, yet powerful—and users would surely cling to the product.
The features that you end up prioritizing depend a lot on your understanding of customer satisfaction.
9 methods to prioritize features
Value versus Complexity quadrant
A simple yet effective method to separate tasks to prioritize them, the value versus complexity quadrant is utilized in different forms by experienced product managers.
In this method, a graph is drawn with the x-axis as the degree of complexity and the y-axis as the amount of business value. Business value can be anything: profits, brand perception, customer satisfaction, and so on.
Then, this graph is divided into four squares, or quadrants. Each quadrant represents a level of prioritization.
Quadrant 1 (Q1) contains tasks that yield high business value and are less complex to execute — the sweet spot. Q2 has high business value and high complexity; Q3 is the inverse of Q2.
Q4 are tasks that are highly complex and have no significant business value, meaning that they can be effectively ignored.
Productivity enthusiasts might have seen this method in a different iteration and name — the Eisenhower Matrix. In any case, the effect is the same: tasks that are important and easy to execute come to view, and can be immediately delegated.
An extension of the value versus complexity quadrant, weighted scoring allows you to have granular prioritization levels. This can be really helpful when there are a ton of initiatives and features that need to be built, and stakeholders want to make sure that they are not missing out on something important.
To use this, draw a bigger VVC quadrant on a proper graph (this can be done on any word processor) and fill out all the tasks. On a different window, open a spreadsheet. Identify the reasons for every increase in business value/complexity, and use them as fields.
The scores convince stakeholders why an initiative is given more importance while the chart shows the overall impact of a feature on a product.
This method focuses on the intersection between product development goals and user satisfaction. This means that beyond mere features, the emotions of the end-user is also taken into account. It has three attributes, threshold, performance, and excitement.
Assigning tasks to these attributes has the obvious effect: you get to skim out the non-essential initiatives. But also, you get to see the features that act as hooks for your user, something that can give your product a competitive advantage.
This model can be represented in any manner, and even the VCC quadrant can be extended to do so. The key, however, is user delight, i.e., it acts as a reminder for the fact that good products can be built by anyone, but true innovation is a different game altogether.
Sometimes, you need a little bit of a reality check so that you do not drift away from the product’s vision. But, what if you could continuously stay tethered to the expectations?
Customer buy-in is an external method and can also help you figure the excitement attribute for your Kano analysis.
You open up the development window to a select few, and show them all the features that have been identified. Next, you get them to bid a price for each feature. The highest of the average scores gets the most priority.
This can be effective for products that are still trying to zero in on their niche or for teams that feel capable to build anything but require a direction.
This is one of the commonest methods out there for prioritizing features. Data from either of the above methods can be used to optimize this. Essentially, the entire flow of the product is laid down — the user journey of a product. Then, for every part of the journey, features are assigned.
So far, straightforward. But mapping is more than just assigning; you’d also need to write down goals (a purchase, subscription, or some action that drives your revenue) and analyze the string of features and clicks that lead toward that.
Once you figure that out, you prioritize them.
In this method, every feature is built over a sprint, and are tracked by user stories.
People view products as more than mere tools; they see it as the experience/task itself. For example, Google is not a tool that lets you search for something. You ‘google’ to find something.
Using a grand example such as that one can seem unfair, but the reality is that every feature and offering is an opportunity to enmesh yourself with the user’s life.
And, the more connected you/your brand are with them, the more profitable you become.
To use this method, you can take the weighted score and run them through an innovation parameter. Defining the parameter is not easy, but questions like “Is this feature unheard of?” and “Can this feature change how people use this type of tool?” can help you out.
The obvious takeaway is that any innovative idea that is not important is not an opportunity, so you needn’t build them.
This method is classic and easy enough that once you read about it here, you’d not need to refer to this again. MoSCoW is a mnemonic that stands for:
- Must have
- Should have
- Could have
- Would have
Not much explanation is needed. But just for clarity, here is how you would separate your initiatives:
- The must-haves are the ones crucial for the functionality of your product. You cannot not build ‘em.
- Should-haves are features that users have come to expect from a product from a genre. You cannot have a music player that cannot make a playlist.
- Could-haves are features that can be built for accessory or for delighting the consumer.
- Would-haves are anything that you plan to build in the future and can avoid adding to the current version’s burden for now.
One obvious drawback is that you don’t get the immediate separation of non-essential tasks that happens in a value versus complexity quadrant.
Prune The Product Tree
This method tries to help you deliberately move toward product-market fit. The product is considered to be a tree, with its branches as features. Anything that is deemed non-essential by market research or the VVC quadrant is immediately cut, or pruned.
It is more of a visual exercise than an actual method to figure out what should be prioritized. But, visual cues are very important. While pruning your product, you can visibly see if one side is uneven, or if the branches are too short.
Balancing core functionality while innovating is key to product-market fit.
Short for Reach, Impact, Confidence, and Effort, this is another straightforward method that can be used to prioritize features.
Categorizing tasks under each is pretty easy. First, a little bit of defining the parameters:
- Reach can be thought of as a relatability score, in the sense that you’d consider features that users would ‘relate with’ on a surface level.
- Impact is a deeper score as it considers features that impact the workflow, productivity, satisfaction, and experience of the user.
- Confidence is the score that ties all the other scores together, especially the above ones. Here, you’d score your confidence over a feature’s ability to scale up to a certain reach and impact.
- Effort is the score that considers the complexity and workload for developing a feature.
Other methods to prioritize features
- Internal Rate of Return (IRR): A metric that lets you assign a development cost to every feature, which can be then compared with projections of how much each feature would earn.
- Value versus Risk: A variation of the Value versus Complexity, and can compare and contrast features and the market risk associated. Useful when highly disruptive or innovative features are being built.
Things you should avoid while prioritizing features
Allowing personal biases
Every product owner or product manager is prone to this, one way or the other. Giving importance to favorite features or listening more to a particular stakeholder, biases lead to an uptick in the wrong kind of features.
Sometimes, the biases aren’t personal but rather department-specific. A stakeholder from sales would highlight features that sound good or are easily sellable, while a dev would emphasize on the latest technical trend.
Understanding these preferences and building mechanisms to avoid them, be it internal or interpersonal is a much-needed soft skill for product owners/managers.
Straying from objectives
This can happen on a personal as well as on a group level. Building products is always exciting and people get carried away in the process.
Several reasons why these happen: maybe a brainstorming session led to some new ideas or someone independently decided to implement something.
Whatever that might be, being in touch with the core objectives, either through regular meetings or a detailed roadmap would be helpful.
Not knowing when to say ‘no’
A good product idea can be inspiring. So much so that while basking in the opportunities, you might say yes to too many features and initiatives.
Key to management is limiting. There would not be much to plan, arrange, or prioritize if the roadmap has only the very essential features.
Sometimes, product owners might add features out of obligation for superiors. Know that you were hired for the sole reason of acting as a regulator, so you’d need to take risks and make the right decisions for the betterment of the product.
Deciding too quickly
Another thing that inspiring ideas can trigger is detailing plans before researching the whole scope of the product.
The excitement needs to be contained and channeled into other outlets, because planning before knowing whether a feature is necessary, feasible, or a user-need would be a waste of time.
This can also happen with organizations that spend less time on market research. In their case, it is not the matter of ‘quickly’ but deciding without the necessary insights. In any case, it sets you for failure, or at best, slows the development pace.
Product development is not a walk in the park.
There are a lot of things to consider—customer satisfaction, functionality, market risk, ROI, and so on.
For the first-ever version of your product, you’d need a clear vision for what you build.
You cannot build everything since any predicted success of the product is still untested.
And during prioritization, you cannot risk choosing the wrong features as this is the first impression you are making over your audience.
A lot of delicate steps to be considered.
With these feature prioritization techniques, you are most definitely going to tread with the necessary caution.
All the best of luck (and efforts!) and for more on development, check out our other blogs.