Implementing wrong features not only keeps the business from growing but also wastes time and money. Unfortunately this cost of implementing wrong features does not show up immediately.
What is not built into the product is as important as what features are prioritized and built. Smartest product managers say No more often than you think. Given limited engineering cycles, they implement smaller number of core features really well compared to building a large number of good to have features.
Fallacy of a human mind
Prioritization is hard. There are several reasons to prioritize wrong things. Here are a few:
Your "own ideas" that you love and always wanted to implement.
Cool UI updates which will make you look good in the next demo but most customers may not care about it.
Feature that you are familiar and is in your comfort zone.
The next sexy thing that may not have much impact but which can create a lot of noise and give you recognition.
Features demanded by the loudest person in the room often gets more priority irrespective of the overall impact.
Why framework
There are several reasons why you should use a framework.
Dynamic nature of feature requirements
As a product manager you have to think about several feature/bug fix requirements. These requirements can arise out of:
Your own OKRs that you have to meet for the next quarter/year
Short-medium term business priorities (eg: reduce churn, reduce costs etc)
Requests from other departments to build internal tools or features that are connected to their own OKRs
Features added by competition
Features requested by your customers
Critical issues in production
As you can see, the requirements are dynamic in nature and unforeseen change requests come everyday. So, you need a way to objectively say yes/no/later to these requirements.
Keeps everyone on the same page
As a PM, you are expected to communicate your vision and priorities to senior leadership team, engineering team and most importantly to customers.
Without a well thought out framework it becomes very difficult to communicate why you have prioritized feature X over feature Y.
Frameworks provide a data driven way to objectively ranking features based on the business impact. With data, you can defend the priorities easily.
A tool such as prodroll will also clearly show that you are not just saying NO to one request, but to several requests. This makes the team understand the relative priority of the requests.
Stops you from becoming a feature factory.
When you rank the features on a relative scale with a framework that is most ideal for you, you can carefully take the product in a meaningful direction in the medium-long run. You will always have the context of what features were prioritized vs others.
This is a better outcome compared to reacting to things like new feature addition by competition, a vocal customer demanding a feature which will be useless to most others.
Forces to deeply understand the impact of features
Frameworks force you to understand the business and customers more deeply.
If you simply say "yes" to a request, you are more likely to get into "solution" mode ie, think about design and engineering instead of "why".
Since frameworks are data driven, you will be forced to think about impact on revenue, costs, NPS etc and also forces you to discuss with subject matter experts to make sure that your understanding of impact is correct.
This collaboration can also lead to you jointly discovering a better problem to solve or a better solution.
