October 31, 2020
Product evolves over the years and one of the most important aspects of a product engineering is bringing right features to the market thus creating continuous value to the business.
It is easier said than done, especially when there are multiple stakeholders with conflicting interests. Collecting, disseminating and prioritizing items is key to product and business success. It is never easy. But, there are many formal and informal prioritization methods that you can use when conflict occurs. Some of them are as follows:
We often see founders and product owners excited about their new product coming up with a long list of features to do. It takes time, cost and effort to build features, and the main question is whether the customer needs all the features upfront?
According to Eric Ries, a Minimum Viable Product is a “version of a new product, which allows a team to collect the maximum amount of validated learning about customers with the least effort”. Hence, the prioritization of the features should focus on how fast you can release the initial product to market, validate the assumptions and collect feedback from customers.
One way to narrow down the features is selecting those that help users perform end-to-end business process. For example, in the online shopping scenario, the end-to-end business process should support a customer to find the suitable product, add the product to the shopping cart, order using one of the payment methods and have the product delivered. So, the initial feature list must contain at least one features that supports the business process. Even though there are many payment methods, you can go to market with one payment first, instead of providing multiple options.
An alternative approach is picking the features that solve key problems, first. For example, if customers key problem is product selection, you can either offer an online product selection or mail-in product catalog, and let the user pickup the product from the store. In this case, you solve the product catalog problem first, and then provide the delivery option next.
Either of this approach requires a good understanding of the customers, so you can pick and choose the features that are critical.
The general rule of thumb in software development is that 80% of users only use 20% of features. So, identify the 80% of the features that are frequently used and focus on those features development first.
A user journey map should provide the insights on what customers are using 80% of the time solving their problem or challenges. For example, your prospective customer may use credit card as a preferred method for online transaction compared to PayPal or Check. So, you can just introduce the credit card payment feature and solve 80% of customer needs.
Sometimes, the 80/20 rule may be too broad and you many way to further categorize the features into multiple groups. In this case, the MoSCoW method is better suited as it categories into four groups.
Must-Haves: these are key features that are critical to the product success or creates best value for the business. These features are non-negotiable, mandatory, and without these features the product will fall short. The Must-Haves are some of the features that should go into your MVP or initial release.
Should-Haves: these are features that are important, but not critical. Without these features, the product can still function and create value. Major bug fixes, enhancements or user experience improvements can be categorized into should-haves. These are features that you can implement them in subsequent releases.
Could-Haves: These are features that are “nice-to-haves”, but not considered important. This may include low priority bug fixes and enhancements with low impact. You can implement these features when the team had some bandwidth to work on.
Won’t-Haves: These are features that are either out of scope or will not implemented in the near future.
As the product evolves, the priorities might change. So, as part of your product catalog grooming, you should revisit the prioritizes and adjust accordingly. This ensures that you’re always working on critical items.
HiPPO stands for Highest Paid Person’s Opinion. This method focuses on delivering the feature requests from the highest paying customer or people with highest authority, first.
For example, in some cases, one of the major customer or client may fund the product development. In this case, satisfying their feature request becomes utmost importance.
In other cases, the founders or CXOs may directly involved in the product, and their requests will get pushed forward, first.
This prioritization method is less favorable as the team is not involved in the decision making process.
You may come across other quantitative and qualitative prioritization approaches such as cost-benefit analysis, weighted average, etc.
Some of the approaches require quality data or metrics to make appropriate priority decisions. As the product, you can continue to evolve the prioritization methods, over the period. To keep it simple, start with a simple approach that best work for you, and refine as you go.