Radically Honest Blog

Buy-a-feature Prioritization for Product Managers

Ever wondered how to make your product features not just good but stellar? Well, it’s not just about what you think is going to work. In the real world, it’s about what sells. 

This is where the buy-a-feature prioritization can really inject some perspective and help organizations get an idea about what features customers and stakeholders find valuable. 

If you’re a product manager keen to try a more unorthodox approach to prioritization, then the buy-a-feature model could be your ticket to making features that deliver real business. So, let’s dive in.

What is the Buy-a-Feature Model? 

So, what exactly is this Buy-a-Feature thing? In simple terms, it’s a prioritization technique that’s essentially a controlled emulation of the market you’re trying to capture. 

Think back to a Monopoly game or a time in school when you were allocated some play money to purchase or invest in a controlled environment. 

It’s quite similar to this, and while it sounds like it could potentially be fun, it’s a productive way to engage stakeholders and ascertain what features participants believe are crucial for your product.

Product managers use this approach to prioritize features based on real user feedback and perceived value. 

Here’s how it works: You present a list of potential features, each with a cost assigned. Team members, or sometimes even actual users, use a limited budget to ‘buy’ what they think should be developed. 

Participants are given a fixed amount of the play money. It could be monopoly money, chocolates, jelly beans, or anything that’s fungible and represents currency. Then, allow them to spend their play money on the potential features of the product. 

It’s like fantasy football for product development – strategic, slightly competitive, and surprisingly effective.

Buy-a-Feature Prioritization in Action

If you’re a product manager, then you know how valuable the opportunity is to view your product and its features through the eyes who matter most – your team and your customers. 

The Buy-a-Feature model is precisely crafted for this purpose. Let’s dive into this process, step-by-step, ensuring that you not only utilize this tool effectively but also master its nuances with finesse.

1. Curating the Feature List

The first step is crafting your feature backlog. Think of it as your product roadmap’s ‘menu’. Here, you’re the chef, and you need to decide what dishes (features) to offer. 

This isn’t just a random assortment; it involves strategic thinking about what features could enhance your product, taking into account user stories, market research, and business objectives. 

For our example, let’s consider a project management tool. Our feature list might include:

  • Advanced Reporting Capabilities
  • Enhanced Security Features
  • User Interface Redesign
  • Real-time Collaboration Tools
  • Mobile App Version

2. Assigning Cost to Features

Next, attach a cost to each feature. This isn’t about real dollars but a representation of the effort, complexity, and resource allocation required. For simplicity, let’s use ‘feature points.’ 

A complex feature like ‘Real-time Collaboration Tools’ might be 50 points, while a simpler one like ‘Enhanced Security Features’ could be 30 points. The trick is to balance your points system with the actual effort and value these features represent.

3. Distributing the Budget

Now, distribute the ‘play money’ among your stakeholders – these could be team members, select users, or even other department representatives. The total budget should reflect your actual development constraints. 

Say, if your team can realistically handle 100 points worth of features in a quarter, that’s your budget. Distribute it evenly or based on roles and influence – a product manager might get more points than a marketing rep, for instance.

4. The Shopping Spree

Participants now ‘shop’ for features. It’s not just about picking favorites; they need to consider the product’s overall strategy and user needs. 

They might have to make tough decisions, like choosing between ‘User Interface Redesign’ and ‘Mobile App Version’ due to budget constraints.

5. Analyzing Decisions

This is where the magic happens. Each stakeholder presents their choices and justifies them. This discussion is invaluable as it reveals what each person values and why. 

It’s a goldmine of insights, aligning personal perspectives with broader business goals.

6. Finalizing Priorities

The end result is a prioritized list of features that reflect a collective decision, balancing various viewpoints and strategic objectives. 

It’s a practical, democratic approach to feature prioritization that goes beyond gut feelings to data-driven decisions.

Example Buy-a-Feature Table/Template in Fibery

To bring this to life, here’s a simple template you can create in Fibery and use during your Buy-a-Feature sessions. This example is based on our hypothetical product.

Budget Allocation:

  • Total Feature Points Available: 100
  • Distribution: Depending on the role and influence, allocate points to each stakeholder.
A quick and dirty list of features in Fibery
A quick and dirty list of features in Fibery

Create a table representing the features, allocated points, and the amount of times purchased by the participants.

A quick formula in Fibery makes the world go around
A quick formula in Fibery makes the world go around

Create a formula to represent the value of each feature after the exercise is completed.

Voilá! The formula spits out the score to our right, giving you a quick priority order.
Voilá! The formula spits out the score to our right, giving you a quick priority order.

View the updated scores in the table.

A quick graph View done in Fibery helps you visualize the results
A quick graph View done in Fibery helps you visualize the results

Generate a graph that visually displays the results of the exercise.

This table and report help in visualizing the features along with their ‘costs’. Product managers can use this to understand which features need prioritization within their allocated budget, ensuring a strategic approach.

When to Use (or Avoid) Buy-a-Feature

In the world of product management, knowing when to deploy the Buy-a-Feature model is as crucial as the model itself. Let’s dissect its applicability with some common use cases.

Ideal Use Cases for Buy-a-Feature:

  1. User-Centric Products: For products where user experience and satisfaction are paramount, Buy-a-Feature is invaluable. It aligns development with user preferences, ensuring that the features most likely to enhance user engagement and satisfaction are prioritized.
  2. Resource Allocation Decisions: In scenarios where resources are limited (and when are they not?), this model helps to distribute efforts wisely. It’s especially effective in small to medium-sized enterprises (SMEs) or startups, where every development hour counts.
  3. Feature Overload Situations: When your backlog is brimming with ideas and potential features, Buy-a-Feature can cut through the noise. It aids in distilling a vast array of possibilities into a focused, manageable roadmap.
  4. Stakeholder Alignment: In environments where multiple stakeholders have a say, this model democratically harmonizes divergent opinions, ensuring that the final product reflects a consensus rather than a single viewpoint.

Scenarios Where Buy-a-Feature May Not Be Ideal:

  1. Fast-Paced Markets: In industries where trends and customer preferences shift rapidly (think tech or fashion), the model may lag behind the market’s pace. Here, agility and quick adaptation are key, and the deliberative nature of Buy-a-Feature might hinder rather than help.
  2. Highly Technical or Niche Products: For products deeply rooted in technical expertise or specialized knowledge, the collective ‘buying’ decisions might not accurately reflect the technical feasibility or necessity of certain features.
  3. Early-Stage Concept Validation: When you’re still in the conceptual phase, trying to validate the core idea of your product, Buy-a-Feature might be premature. At this stage, lean methodologies and rapid prototyping might serve you better.
  4. Low Stakeholder Engagement: If stakeholders or team members are disengaged or lack sufficient insight into user needs and business objectives, their choices in the Buy-a-Feature exercise may lead to misguided priorities.

Buy-a-Feature is a powerful tool in a product manager’s arsenal, but it’s not a one-size-fits-all solution. It shines in user-focused, resource-sensitive environments but may falter in rapidly changing markets or highly technical domains. 

Like any strategic tool, its effectiveness hinges on the context and the skill with which it’s wielded.

The PM’s Hot Take

Buy-a-Feature is both prioritization and a reality check. It forces you to look at your product through the lens of practicality and not just passion.


Wrapping it up, the Buy-a-Feature model isn’t just another arrow in your quiver. It’s a mirror reflecting the true value of your product features. 

It’s about getting real with what matters most to your users and your business. 

Ready to shed new light on those feature lists? Embrace the buy-a-feature model. 

And for those hungry for more nuggets of product management wisdom, why not explore our really honest blog posts on Ruthless Prioritization and ABCDE prioritization? Keep the learning alive and the insights coming!

Psst... Wanna try Fibery? 👀

Infinitely flexible product discovery & development platform.