Conquering the Chaos: Feature Prioritization

In the fast-paced world of product development, and with limited resources and time, prioritizing what your development teams should be working on is one of the most demanding challenges Product Managers face.

As product leaders, it’s essential to understand the Pareto Principle to separate and prioritize the “Vital Few” features or RFEs from the “Trivial Many.” Every product leader likes to think they have good instincts regarding which feature to build next, yet most products ship features that are rarely used or never used. As a practical aside – there’s only one thing worse than a product or feature with no users, and that’s a product or feature with a single user or small number of users. You still have to carry the cost of the feature for the long term but get little value out of it.

Deciding which features to prioritize requires a framework to remove some subjectivity and stress from the decision-making, allowing you to move swiftly and confidently.

This blog post equips you with the knowledge and tools to navigate the prioritization process effectively.

Why Prioritize?


“Good fortune is what happens when opportunity meets with planning.”

– Thomas Edison.

You can’t plan without prioritization, and without a plan, your product is much more likely to fail. Good prioritization allows you to:

  • Focus on what matters most: Align features with your product vision and business goals. By identifying the “vital few” features, you can prioritize development efforts on what truly matters, leading to a more valuable and impactful product.
  • Deliver value faster: Get the most impactful features to users quickly. Identifying and focusing on the core features allows you to launch your product quicker, capturing market share and user feedback earlier.
  • Optimize resource allocation: Ensure your teams work on the right things at the right time. Limited resources can be directed towards developing the most impactful features, maximizing the return on investment.
  • Simplify the User Experience: A product with fewer, well-designed features is easier to learn and use, leading to higher user satisfaction.
  • Simplify the GTM. A product, even an MVP, with a clear purpose, value proposition, and a focus around a distinct set of use cases is much easier to position and sell.

Alignment

Ultimately, we all want to deliver the highest value features to the end user as quickly as possible. Unfortunately, while the goal sounds simple – the reality is quite a bit more complex.

For starters, what does “highest value” mean – most used? Higher willingness to pay? Most likely to deliver better productivity or enhance quality? Better stickiness? You can only answer these questions if you have a well-articulated strategy and set goals or objectives for the offering. Alignment to objectives is part of the prioritization process.

Who are your users? Are they all treated equally? Do you need to segment by free or paid or by customer/account size?

Are there dependencies between features? Do you need to deliver feature X before feature Y has real value?

Frameworks for the Win

Several frameworks can guide your prioritization journey. I split them into two broad categories depending on where you are in your product journey.

The first are lightweight frameworks that don’t require a lot of customer/prospect data and can be used to prioritize pretty much anything. Use these frameworks for early MVPs where your market sense is still the most significant determining factor.

  • Value vs. Effort: Plot features on a matrix based on their perceived value and development effort. These charts are nothing more than a simple way to visualize the choices.
  • MoSCoW Method: Categorize features as MUST-have, SHOULD-have, COULD-have, and WON’T-have based on their importance and feasibility. MosCoW is the simplest model and doesn’t require a lot of data to drive – it’s nothing more than a way to capture your market sense/instinct.

The second category assumes you have more data to drive your decisions and are more appropriate to a more mature offering in a more mature organization. The quantitative approach vs. the objective approach will allow you to scale, take toil, and stress out of the process and also let you tune your prioritization based on other factors such as market segment, customer size, or other objective categorizations (UX, security, retention).

  • R(ICE): Score features based on Reach (Impact, Confidence, and Effort) to compare features or enhancements quantitatively. (more info)
  • Kano Model: Categorize features as Basic, Performance, and Excitement to understand user expectations and satisfaction levels. (more detail)

Beyond the Framework

  • Choosing the most appropriate framework is just the beginning. Remember these additional points:
  • Gather data: Conduct user research, analyze user feedback, and leverage analytics to understand user needs and pain points.
  • Align with stakeholders: Get buy-in from key stakeholders by involving them in the prioritization process.
  • Be flexible: Market dynamics and user needs can evolve, so be prepared to adapt your priorities.
  • Communicate effectively: Clearly explain your decisions to stakeholders and users to avoid confusion and manage expectations.
  • Document Assumptions: as you learn more or situations change, you can change assumptions and reprioritize.

Whichever method you choose to prioritize feature development – effort, feasibility, or some other proxy for cost must be part of the algorithm. Creating an unachievable roadmap will guarantee some adverse outcomes:

  • Missed deadlines, overruns, and slips which will erode trust with your stakeholders (sales, execs., investors, customers)
  • Burnout amongst your team- leading to lower efficiency, leading to more overruns, and lower quality
  • Poor quality – lots of shortcuts leading to rework, half-baked, half-assed features

You likely need more information to make accurate estimates at the planning stage. Still, some cost estimates are better than nothing, and estimation is a skill that only improves with practice. Use what tools and expertise you have – expert consensus, t-shirt sizing, bottom-up, analogous estimation.

Remember, prioritization is an ongoing process, not a one-time event. Regularly revisit your priorities, gather new information, and adjust as needed. By embracing a data-driven and collaborative approach, you can conquer the feature prioritization challenge and build products that truly resonate with your users.

My recommendation is that once you have decent data flowing regarding use cases and features, then it’s worth investing in PM-specific tooling (ProductBoard, Jira Align), which will give you a choice of prioritization, tunable weighting, and integration with data sources such as support systems, win-loss analysis, survey data, and user research.

It is essential to be transparent in all things related to planning and prioritization – you should be able to justify why feature X is a higher priority than feature Y. Your stakeholders and partners in engineering and marketing need to believe your roadmap is focused on the right things at the right time. Be honest about how decisions were made – ie. When you have solid data or when you are using intuition. Be honest and transparent about your confidence level – this is especially important for early-stage products or companies where intuition plays a more critical role than rigorous customer/usage data.

Curve Balls

Finally, expect an executive override, customer escalation, or some other high-priority request to land at your feet, requiring you to re-plan and reprioritize. Demanding strategic customers who need feature X before signing a renewal, your CxO prioritizes a feature due to a high-integrity customer commitment.

The reality is that you have to be able to deal with these requests – as a PM – you have to be able to quickly assess the cost, strategic alignment, feasibility, vs. the opportunity cost (what roadmap items you will need to sacrifice) – you can only do that if you have a robust framework for prioritization.

Leave a comment