Notes to the Product Managers: Prioritize the Backlog!
In this dynamic and rapidly changing world where needs are unlimited, resources are limited, stakeholders are tough and deadlines are almost tomorrow, starting work without prioritising will cause crushing under heavy workload.
However, one of the most important goals of the product manager is to design / develop the most meaningful and valuable lean product (minimum viable product) for the end user. While developing the MVP, company and product strategy should be followed, end user needs should be considered, competitor and market analysis should be done. It is critical to know how to prioritize the the requirements gathered from different stakeholders in order to be able to do all of these at the same time.
To be honest, prioritization is perhaps one of the most difficult issues in product management. The reason why it is difficult is that it does not depend on a clear equation and is closer to subjectivity. Although there are actually dozens of methodologies for prioritization, the product and company strategy must be clear before all these models. The clarity of the strategy determines which areas are prioritized, as well as determining which areas the product manager and team will not go into. After these definitions are understood by the team, prioritization methodologies can be used to determine the order in which the features should be made.
METHODOLOGIES
Many models such as waterfall, spiral, incremental, agile, lean and many systems such as scrum and kanban are the subjects of which books are written on product and software development issues. I will not go into the details of these in this article.
Although the models are very different from each other, the purpose of all models is to save time, money and effort to produce a better product. You should not evaluate these models alone, but bring a total perspective by considering the prioritization methodology, the extent of uncertainties in the product and the market, and how clear your customer base is about the product.
There is a frequently used and recommended method in product management processes: the MoSCoW model. After stating that the MoSCoW technique has nothing to do with Moscow, the capital of Russia, except the word similarity, and it is an acrostic, we can open the word as follows:
Must Have: Items in which it is not possible to complete the project if it is not completed. It will not make sense to deliver a Must Have item that cannot be delivered on the targeted date at a later time.
Should Have: We can classify tasks that are very important for the project but not vital to the completion of the project in this category. The project can be completed even if a Should Have task is left unfinished; however, this can cause problems that will give you a headache and annoy you.
Could Have: We can classify items that can also be called Nice-to-Have features, which increase customer satisfaction and contribute positively to the user experience, in this category. It is recommended to evaluate these items only if we have the time and resources.
Won’t Have: Requirements agreed upon by stakeholders that they are not critical and have the least benefit. It would not be wrong to say that it is controversial whether they will provide a direct benefit for the product even in the next development periods. In fact, the presentation of these items by the stakeholders will be important in terms of clarifying the scope of the project.
As a second model, we can talk about KANO. The KANO is a technique used in the Customer Satisfaction and Product Development process, defined by the Japanese Professor Noriaki Kano in the 1980s.
Kano model technique is also used in Business Analysis processes to define the product called delightful, where the customer will experience a high level of satisfaction while defining the features that the product should have.
According to the KANO model, a product or service should have requirements in 3 different categories;
Threshold Attributes: The minimum level of features that the product must have in order for the customer to use the product. The absence of these features leads to high levels of dissatisfaction, while their presence affects customer satisfaction to a degree that is negligible. These are the requirements that your customers do not even need to specify, and that they think will already be within the scope of the product or service they will receive.
Performance Attributes: They are requirements that customers directly demand and that increase their satisfaction level as they are met.
Excitement Attributes: These are the requirements that customers do not directly express or even realize, but for which the satisfaction of them is an element of great excitement and commitment. Failure to meet these requirements does not trigger any dissatisfaction.
RICE Scoring Model: RICE is an acronym that stands for Reach, Impact, Confidence, and Effort. By evaluating and scoring each of your competing ideas, you can come up with a concrete number to determine which initiatives should be prioritized and in which order.
Conclusion
Let’s say you prioritized the backlog according to many methods above and implemented them according to product development techniques. What about after? Are all the features of the product used? Or does one stand out too much? It will be beneficial for the product to monitor whether the features you have launched as a product manager are used, to learn the reasons if they are not used, to take actions accordingly, and to remove them from your product if there is no hope.
