Framework to Prioritize Product Features and Development
Learn how you can categorize feature ideas, bugs, and take decisions with clarity
One of the hardest tasks when building a product is to achieve the product goals and user goals with the given resources you have in a limited time frame. Though, most teams never achieve the desired agility and balance among product requirements, resources, and time. But it still remains the top thing to chase as a product person in teams of all sizes. This blog is mostly for people who are building a product or running product development in early-stage with limited resources and time.
After setting the true north star for your product, zeroing down on the features that need to be built first while achieving the maximum product goals is a little tricky. There are always product needs, user requests, and insights from the market research that pull your product in various directions. But let’s assume for now that your north star is set. And you need to now continuously build, ship and iterate. Use the framework presented here for deciding the feature priorities and make your product roadmap.
Classify your feature ideas:
Here are three labels (Essential, Enabler, and Good-To-Have) that you can put on your feature ideas to bring up the most important on top.
Essential:
Features and functionalities that form the core utility for which the product exists. The product isn’t usable for the end-users without the essentials. And without the essentials, there's always something missing in the user journey that users will immediately notice. For example, for an E-commerce website, the essential functions are product listing, buying, making payment, and tracking the shipment. These are essentials for E-commerce. Similarly, you can list down the essentials for your own product.
Enabler:
In the same E-commerce example, things like searching the catalog, product categorization, reviews, ratings, FAQs, and wishlists are all enablers that make the user journey easier.
E-commerce can certainly work without all these, only a single product listing page, order placement, and tracking consist bare minimum that end-users need. The feature ideas mentioned in the Enabler category helps the user make a decision, browse product with ease, and understand the product completely before they make the purchase.
The functionality that assists a user to easily get the essential work done is “Enablers”. These features and functionalities come second on your priority list. And gets pushed up in the priority based on the requests from the users and the availability of team resources.
Good-to-have:
The last things on your priority list are features that are good-to-have but the product can do okay without them. Things that make the user experience pleasing beyond their expectations are good-to-haves on your product.
Continuing with the E-commerce example, a video of the product, recommendations/personalized curation, UI animations, etc. are good-to-haves.
Action and feedback:
Building essentials is important and identifying essentials is easy. But it’s the “Enablers” where most people confuse. Don’t confuse “Good to have” with “Enablers”. To drive the desired user behavior, we need to create enablers. When people take a certain action on the app/website, feedback is sometimes enough to guide them through the process. Spoon feeding the users is not fun for them. They like to discover some stuff on their own.
You need to work with precision on the essentials and enablers. 80/20 Rule applies here as well. 20% of features are used by 80% of the users. “Good to have” features/functions delight only a fraction of the users, but the essentials and enablers delight all of them.
Classify Bugs and User Requests
Once the 1st build is ready for your focus group, beta testers, or first few users, you’ll get a lot of bug reports, requests, and suggestions. Here are a few labels that I mentioned in the Product Lifecycle Management Framework to categorize and prioritize them.
- P0-Urgent: Show stopper, affecting the entire userbase, blocking a key activity on the app/product, affecting the ratings/reviews, hampering the key objectives of the app.
- P1-Serious: Things that you need to do damage control but are not part of the key functionality.
- P2-Fixes: Fixes in the currently implemented features, minor improvements, and UI changes.
- P3-Cosmetic: Good to have updates or features to be picked when the resources are available. Won’t have an impact on the major userbase.
Fixing the problems in your product — Bandages vs. Treatment:
This is the final part of the prioritization framework. It will often occur that different people who are working on the product will come up with problems that they notice in the product. They could be from business development, design, marketing, or development. And when building unique or one of its kind of product, in cases when you can’t say “let’s see how our competitors do it”. You’ll need to solve it with the help of team members. And you can categorize the solutions into two buckets: Bandage or Treatment.
*Imagine* You put a bandage on every wound you get. The bandages heal some wounds but some wounds become worse over time. And then you feel tempted to put another bandage on it or even worse, more than one bandage on it to cover it. Eventually, the body weakens and it cannot take the bandage solutions anymore. You might end up getting hurt physically and financially. And in the end, spend way more on a treatment that’ll not even guarantee your survival.
This can also apply to tech products. There are two types of solutions that we can offer for any problem: Bandage solution or Treatment solution. Some problems can be entirely taken care of by Bandage solution (cheap, quick, ends after a certain time). But if you overuse the bandage solution on the problems that require Treatment solution, you are in-turn hurting the product.
So it is very important to categorize all the issues you/users/teams face in the product. And always think from a point of view that what solution will make this issue go away permanently:
Can another human resource solve it? Can a feature solve it? Can I solve it with design? Can I solve with copywriting? Can I solve it by reducing a feature? Can I solve it by changing the narrative? Can I solve it by eliminating a category of users? And several other ways that are possible.
For bigger problems, you should always write down a Treatment Solution that’ll solve it in an extended duration by taking a set of actions and by building a set of functionalities/features/designs/tools.
That’s all on the framework to set prioritise while building a product.
