Product Prioritization: Applying the Three Feature Bucket Framework
“Adapt what is useful, reject what is useless, and add what is specifically your own.” -Bruce Lee
As product managers we must master the ability to say “no” to the myriad features we could be building in order to say “yes” to the few we should be building. Triaging is critically important to tackle the sheer quantity of project or feature ideas that get thrown our way daily from various stakeholders. Not understanding how to efficiently prioritize can push even the most organized PMs to the brink.
Roadmapping is a tough exercise, but can help us master decision making. As product managers, our goals include creating focus, consistency, and transparency across all the teams we work with. Accordingly, we need to ensure that our prioritization processes (a key component of our roadmapping techniques) also achieves a strong level of clarity and consistency.
There are so many prioritization frameworks and methodologies that I’ve honestly lost count. There’s RICE, MoSCoW, Opportunity Scoring, Impact/Value vs Effort, Kano, and the NPV-based financial analysis, to name a few. There’s no wrong answer when it comes to choosing the process that works best for you. As Bruce Lee alluded to, take what you like from this smorgasbord, adapt it to you and your team, and discard the rest.
I’ll give you an example. Several years ago, I read Adam Nash’s blog post about Three Feature Buckets. His post stuck with me because he succinctly captured the qualitative and quantitative inputs that create a balanced portfolio of features to satisfy both business requirements and customer needs. Over the years, I’ve riffed on Nash’s framework across products to create my own custom-weighted scoring model. The screenshot below shows this model in action. At the top of the backlog spreadsheet are my version of the three buckets: Customer Feedback, Metrics Movers, and Strategic.
- Customer Feedback. This bucket takes customer input from a variety of sources into account, including: customer interview responses, support requests, community forum threads, voice of the customer feedback from the sales team, etc.
- Metrics Mover. Every quarter or year, you as the PM know what metrics are most critical for your business or product. Align your work with those metrics and score your backlog on how confident you are that the feature in question will correlate to a movement in that particular KPI.
- Strategic. This last bucket is a bit of a catch-all. It allows for a third category of work that may not move a metric immediately, or that customers may not yet be asking for, but fulfills our long-term vision to get your product where it needs to be in 3–5 years.
More recently, our team experimented with this model by using t-shirt sizing to represent the potential impact across these three buckets. Thus, a score of ‘1’ meant extra-small impact and a score of ‘5' meant extra-large impact. We also weighted the three buckets in terms of overall importance, and further broke the top three buckets into specific sub-buckets which were also weighted. (If you do something similar, try not to create more than 2 or 3 sub-buckets or it gets too complicated.)
Obviously, this is just one way to prioritize. And while the specific frameworks or tools you use with your teams will vary, I do have a few highly recommended suggestions to include as part of your prioritization processes:
1/ Create a habit of reviewing the backlog, prioritization framework, and scores with your team of Engineering, Design, and Product leads. This means a regular meeting (3 to 4 times a quarter) to go through each line item since your last review. This repetition will help remind everyone on the team of the goals you set for yourselves. If something is not scoring high on the priority list that you all agree needs to get done, it indicates incorrect inputs or incorrect scores. In either scenario, the ensuing discussion among the Engineering Leads, Product Managers, and Design Leads is a successful outcome of these backlog review meetings.
2/ Share your prioritization framework and process with the rest of your team, your cross-functional stakeholders, and management. Use whatever tool you prefer here — JIRA, a spreadsheet, a Word doc, or a hand-written scroll. All that matters is that your framework and the relative priorities based on that framework are transparent, easily accessible, and understood by folks outside your core team. A good rule of thumb to measure success here is whether a cross-functional audience member can access your priority list without attending any of the aforementioned meetings and still understand why their pet project isn’t being prioritized (e.g., “it has no way of affecting the net new acquisition we are pushing for this quarter”).
Prioritization is never easy, but this structure will help get your teams aligned and speaking the same language. Pick your favorite methodology, iterate on it with your team, continue building valuable products, and have fun!
