Notes on Feature Prioritization (Part 1/3): Challenges in using frameworks

why are prioritization frameworks challenging to apply

Photo by Slidebean on Unsplash

If you read articles about product management, it seems such an elegant and structured field.

For everything you do — interviewing, hiring, customer interviewing, prioritising features, crafting the product strategy & roadmap etc, you will find dozens of methodologies and frameworks.

So, when you start out as PM, you are more than excited that you will get a chance to apply all these frameworks.

But reality is far removed from expectation. It is frustrating to see the ‘chasm’ between how you do things vs how your framework tells you to do things.

Especially in startups, you face so many challenges in applying prioritization frameworks that you often end up relying on ad-hoc prioritization based on:

• What your ‘gut feeling’ tells you [I think so, that’s why….]
• What the most vocal customer or sales executive is saying [loudest voice in the room…]
• What the CEO/VP thinks should be prioritized [highest paid person’s opinion…]

Obviously, this is neither a sustainable or scalable way of prioritizing features. It will often lead to prioritization of wrong features and eventually come to bite you back as a PM. (If things go south, its always the PM who has to bear the blame.)

In order to avoid such a situation, you should be armed with the knowledge to overcome the challenges faced while prioritizing. In the subsequent paragraphs, I will take you through the key challenges faced while prioritizing features and give a few guidelines on overcoming them.

Challenges faced while using prioritization frameworks

• Absence of a problem backlog — You have no clue around all problems the customers face, what is the frequency with which issues are reported etc. When you don’t have a well-maintained backlog, some crucial problems might not even make it your list.
• Time consuming — Applying an framework requires patience and rigor. It is not something you can do in a couple of hours. And as a product manager running from one meeting to another, time is a currency you are always short of.
• Complicated — Using a framework sounds straightforward when you are reading about it. But when you try using it for your use case, you often realize that it’s not easy as it sounds. As they say, “The devil is in the details.”
• Insufficient knowledge — Most frameworks require you to assign scores/weightages on criteria such as business value, customer value, complexity etc. Often, you don’t have comprehensive knowledge of the product, business or technology to accurately assign these weightages.
• Lack of buy-in: If no framework is currently being used, then good luck trying to get people to trust in a brand new prioritization framework.
• Ad-hoc requests — As mentioned above, there can often be multiple voices in the company that will force you to do ad-hoc prioritization. Where there is top-down prioritization happening, its hard to convince the senior leaders to listen to you.

Things to Keep in Mind while Prioritizing

• Make time — You won’t get time in your schedule unless you make time. (Check out these time saving techniques to become more efficient)
• Take your time — It will take multiple sittings over several weeks as you will have to put in a lot of thought into thinking about what to do.
• Your opinion doesn’t hold much value unless you back it up with quantitative data(eg. feature usage, support tickets) or a qualitative (eg. customer requests) analysis.
• Some features will be prioritized regardless of the weightages you assign — These could be features that are i)important from a ‘competitor parity’ perspective OR ii)requests from high revenue generating customers etc.
• Prioritization is a collaborative exercise that must take into consideration the opinion of other stakeholders — Building the product roadmap not something that can be done in silos. (To receive buy-in, your work-in-progress roadmap should have sufficient visibility among higher ups)
• You have limited technical expertise — Often, the ‘most desirable’ thing might not be the most feasible. (Get the views of your engineering counterparts to understand the technical complexity of any potential solution)
• Winning the trust of your senior leadership is a task that can take months. Only when people start trusting your judgement, will you get a chance to take independent decisions around the product roadmap.

Conclusion

Prioritization is hands down the most important exercise you undertake every quarter. Deciding which features to build over the course of a quarter (or even longer), will determine what design, engineering, marketing and QA will work on. Thus, its not a job that can be taken lightly by any product managers hungry for success.

So, the next time you sit down to identify the features for your roadmap, make sure you go all out to tackle the challenges that you face.

This is a 3 part series based on my learnings on prioritizing features and building a product roadmap. Part 2 of this series talks about how to classify the customer feedback properly and generate a solid evidence based product backlog [read here]. In the final article, I will discuss how to craft a solid product roadmap based on this carefully collated product backlog.