Buy a Feature

1. What Is Buy a Feature?

Buy a Feature is a collaborative prioritization framework used in product management, innovation, and customer research. Participants are given a limited budget and asked to “buy” from a list of possible features or capabilities, each with an assigned price. Because they cannot afford everything, they are forced to make trade-offs.

The power of the method is that it turns vague preferences into observable choices. In a normal survey, customers and stakeholders often say that nearly every feature is important. In Buy a Feature, scarcity changes the conversation: people must decide what matters most, what can wait, and what is worth persuading others to support.

Consultants use Buy a Feature because it is simple to run, easy for executives to understand, and unusually effective at surfacing priorities, disagreements, and hidden value perceptions. Despite the name, the “features” can be software features, service enhancements, process improvements, policy changes, or investment options.

2. Origin and Background

Buy a Feature was created and popularized by Luke Hohmann as part of the Innovation Games approach. It is described in his 2006 book Innovation Games: Creating Breakthrough Products Through Collaborative Play, which introduced a set of structured games designed to help companies learn from customers and stakeholders more effectively.

The method was created to solve a familiar problem in product planning: when teams ask customers what they want, the answers are often broad, undifferentiated, and inflated. Buy a Feature introduces a constrained budget so participants must reveal relative priorities rather than offer wish lists. It became widely known through product management, agile, and user research communities, and it is still used today in both in-person and digital workshop formats.

3. How Buy a Feature Works

The logic of Buy a Feature is straightforward. First, the team creates a list of candidate features and assigns each one a price. The price usually reflects relative delivery effort, cost, complexity, or strategic scarcity. Participants then receive a budget that is intentionally too small to buy everything on the list.

Next, participants decide how to spend their budget. In many versions of the exercise, they are allowed to pool funds with others in order to buy more expensive items. That negotiation is not a side effect; it is one of the most valuable parts of the method. It shows which needs are shared, which features matter only to a niche group, and which options inspire enough support for people to collaborate.

The output is not just a list of what was purchased. Skilled facilitators also watch how decisions were made: which features triggered debate, which prices felt unfair, which items no one supported, and which combinations emerged naturally. Those observations often matter as much as the final “shopping cart.”

In practice, Buy a Feature is best thought of as a structured decision conversation, not a mechanical scoring model. It reveals preferences under constraint. That makes it especially useful when the team needs to see real trade-offs rather than collect another round of polite feedback.

4. When to Use Buy a Feature

Buy a Feature is most useful when a company has a defined set of options and needs help understanding which ones create the most perceived value. Common use cases include product roadmap prioritization, release planning, feature packaging, service design, internal investment choices, and portfolio simplification. It works in B2B and B2C settings, although it is often especially powerful in B2B environments where customers can explain the business rationale behind their choices.

The framework is particularly effective when ordinary surveys have failed to produce clear priorities. If every stakeholder claims every feature is critical, a constrained budget forces realism. It is also helpful when executives want to observe not just the result, but the reasoning, compromise, and coalition-building behind the result.

In practice, the method works best as part of broader customer insights work rather than as a standalone vote. The strongest applications combine the exercise with interviews, usage data, support-ticket patterns, commercial context, and technical feasibility.

It is most revealing when participants represent clear customer segments rather than an undifferentiated audience. A mixed room can still be useful, but the output becomes much stronger when the team can compare what enterprise buyers, frontline users, administrators, or channel partners value differently.

The method is not a good fit when the option set is still too vague, when participants lack enough context to judge trade-offs, or when major technical dependencies make features impossible to treat as discrete choices. It can also mislead if prices are poorly calibrated or if the participant sample is biased toward one vocal constituency. Modern practitioners therefore use Buy a Feature less as a standalone answer and more as one input into a disciplined prioritization process.

5. How to Apply Buy a Feature: Step-by-Step

1. Clarify the decision and scope. Define the specific question the exercise is meant to inform. Are you prioritizing the next release, a twelve-month roadmap, a bundle of service enhancements, or a capital allocation choice? Be explicit about which products, markets, customer groups, and time horizon are in scope.

2. Gather the required inputs and data. Start with a concise list of candidate features, rough effort estimates, known dependencies, existing performance data, and any relevant interview findings. If the feature list is weak, the exercise will be weak; many teams prepare it using prior qualitative research, support data, and usage evidence rather than relying on brainstorming alone.

3. Define the units of analysis. Decide exactly what participants are “buying.” The units should be meaningful and comparable: not one item at the level of a full platform rewrite and another at the level of a button color. If needed, roll smaller ideas into themes or break oversized initiatives into coherent chunks.

4. Set prices and budgets. Assign prices based on relative cost, complexity, or capacity consumption. Then give participants a budget that is materially lower than the total price of all options. If everyone can afford everything, there are no trade-offs; if almost nothing is affordable, the exercise becomes artificial and frustrating.

5. Construct the buying board. Present the options in a simple format: cards on a wall, a spreadsheet, a virtual whiteboard, or a workshop template. Each feature should have a name, a short description, and a visible price. Keep the artifact clear enough that participants spend their energy on choices, not on decoding the setup.

6. Run the exercise and observe the negotiation. Ask participants to make purchases individually or in small groups, allowing them to pool money where appropriate. Pay close attention to what people debate, what they immediately support, what they reject, and which features attract coalition-building. The comments around the purchase often carry more insight than the purchase itself.

7. Analyze the results and translate them into actions. Review what was purchased, what was underfunded, and what combinations repeatedly appeared. Separate must-have needs from interesting but weakly supported ideas. Where customers consistently fund bundles, the output can inform pricing strategy and packaging decisions, although it should not be mistaken for formal willingness-to-pay analysis.

8. Test sensitivities and alternative assumptions. Revisit the result by adjusting prices, regrouping features, or splitting the analysis by segment. If one feature moved from “winner” to “loser” because of a small change in price or scope, that tells you the initial conclusion was fragile.

9. Align stakeholders and iterate. Socialize the findings with product, engineering, sales, customer success, and leadership. Resolve disagreements about what the results mean, refine the roadmap, and decide what additional evidence is needed. Buy a Feature should end with a clearer decision process, not just an interesting workshop.

6. Example: Buy a Feature in Action

The situation

A $500 million B2B workflow software company was preparing its next annual roadmap. Its enterprise customers were asking for everything at once: audit trails, mobile approvals, AI-generated recommendations, expanded APIs, workflow templates, and sandbox environments. Previous surveys had been nearly useless because almost every request scored as “very important.”

Why the company chose Buy a Feature

The product leadership team needed sharper trade-offs, not more preference data. They selected Buy a Feature because it would force customers to choose under constraint and would let the team hear the business logic behind those choices.

How the exercise was run

The team built a catalog of eight roadmap candidates and priced them using relative development effort. Customers from twelve accounts were invited, with representation from administrators, operations leaders, and business users. Each participant received a budget that covered only a portion of the full catalog, and they were allowed to pool funds to buy expensive items.

What the company learned

Administrators and compliance-heavy accounts consistently pooled money around audit trails and sandbox capabilities. Operational users favored mobile approvals and approval analytics. AI recommendations attracted curiosity, but not enough coordinated funding at its current price. Several teams also combined purchases in ways that suggested a natural packaging logic rather than a simple ranked list of features.

What happened next

Management did not treat the result as a literal vote. Instead, it used the exercise to sharpen broader marketing priorities, refine the roadmap by persona, and redesign feature bundles for enterprise accounts. The final plan moved audit and analytics capabilities forward, repositioned AI as a later bet, and gave sales a clearer story about which benefits mattered to which buyers.

7. Strengths and Limitations

Strengths

• Forces real trade-offs. Scarcity reveals priorities more clearly than simple rating scales.
• Surfaces reasoning. The discussion explains why participants value certain features, not just which features they picked.
• Creates alignment. Product, commercial, and executive stakeholders can react to the same evidence in a shared format.
• Works quickly. A well-designed workshop can produce useful insight in days rather than months.
• Handles bundles well. Coalition purchases often reveal natural feature groupings and packaging logic.

Limitations

• It is sensitive to setup. Poor feature definitions or unrealistic prices can distort the outcome.
• It is not statistically robust on its own. Small workshops provide directional insight, not market-level precision.
• It can oversimplify dependencies. Some features cannot be meaningfully evaluated as standalone choices.
• It reflects perceived value, not full business value. Customers may underweight technical debt, regulatory needs, or strategic platform investments.
• It is not a pricing study. Despite the use of budgets and prices, it does not replace formal willingness-to-pay or elasticity research.

8. Common Pitfalls and How to Avoid Them

• Using vague features. If the options are too broad or poorly described, participants buy labels rather than real ideas. Use concise, concrete feature descriptions with enough context to be understood quickly.
• Miscalibrating prices. Arbitrary pricing can make one option look artificially attractive or impossible to buy. Base prices on relative effort or scarcity, and review them with product and engineering before the session.
• Mixing incomparable items. A strategic platform investment should not compete directly with a minor usability tweak unless both are normalized appropriately. Define units of analysis at a comparable level.
• Ignoring participant mix. A room dominated by one customer type can skew the result. Recruit deliberately and analyze outcomes by segment, role, or use case.
• Treating the output as a vote count. The exercise is a thinking aid, not a referendum. Interpret the purchases alongside strategy, economics, feasibility, and dependencies.
• Stopping at the workshop. Many teams run an engaging session and then fail to translate it into decisions. End with explicit implications for the roadmap, packaging, messaging, or follow-up research.

9. How Buy a Feature Relates to Other Frameworks

Buy a Feature vs. Kano Model

Kano helps teams understand the nature of customer needs: basic expectations, performance attributes, and delight factors. Buy a Feature does something different. It forces choices among options under constraint. Kano is stronger for understanding the type of need; Buy a Feature is stronger for exposing relative priority among specific options.

Buy a Feature vs. RICE, MoSCoW, or value-effort scoring

Internal prioritization frameworks such as RICE, MoSCoW, and value-versus-effort matrices are typically management tools. They structure the company’s view of impact, confidence, effort, and urgency. Buy a Feature adds the outside-in perspective by showing what customers or stakeholders choose when trade-offs are real. In practice, teams often use Buy a Feature to generate evidence, then feed that evidence into a broader internal scoring model.

Buy a Feature alongside Jobs to Be Done and conjoint analysis

Jobs to Be Done is often useful before Buy a Feature because it clarifies the underlying customer problem and helps define better options. Conjoint analysis is often useful after Buy a Feature when the team needs more rigorous quantitative evidence on trade-offs, packaging, or willingness to pay. Buy a Feature is faster and more conversational; conjoint is more analytical and statistically demanding.

10. Key Takeaways

• Buy a Feature is a prioritization exercise that reveals what people value when they cannot have everything.
• Its core strength is forcing visible trade-offs through constrained budgets and priced options.
• It works best when the option set is clear, the participant mix is deliberate, and the prices are directionally credible.
• It is especially useful for roadmap, packaging, and portfolio decisions where discussion quality matters as much as ranking.
• It should be used as one input into decision-making, not as a standalone answer or a substitute for market sizing, feasibility review, or pricing research.

11. FAQs About Buy a Feature

Is Buy a Feature still relevant today?

Yes. It remains relevant because it solves a problem that has not gone away: people still overstate priorities when there is no constraint. Today, teams often run it digitally and combine it with product analytics, interviews, and roadmap economics rather than using it in isolation.

What is the difference between Buy a Feature and the Kano Model?

Kano classifies needs by the kind of satisfaction they create, while Buy a Feature forces choices among specific options. Kano helps you understand what type of feature you are dealing with; Buy a Feature helps you see what customers would actually prioritize under constraint.

Can small or early-stage companies use Buy a Feature?

Absolutely. A startup can run a lightweight version with a handful of customers, prospects, or internal stakeholders. The key is to keep the option list short, the prices simple, and the decision question tightly scoped.

How long does it typically take to apply Buy a Feature in a real project?

A simple version can be designed and run in a few days, with a single workshop lasting 60 to 90 minutes. A more rigorous effort with participant recruitment, segmentation, multiple sessions, and synthesis often takes two to four weeks.

What data is needed to use Buy a Feature?

At minimum, you need a clear list of options, rough relative cost or effort estimates, and the right participants. The analysis improves materially when you also have customer interviews, usage data, support patterns, commercial context, and a clear view of feature dependencies.