What Is a Buy-a-Feature Exercise? Definition
A buy-a-feature exercise is a prioritization game where participants receive a fixed budget of play money and a priced menu of features, then spend that budget to "buy" the features they value most. The forced trade-offs reveal genuine priorities rather than polite preferences.
Quick Answer: Buy-a-feature is a group prioritization technique from Luke Hohmann's Innovation Games. You give people limited fake currency and a list of features with prices, and they buy what matters. Because money is scarce, every purchase is a real trade-off — surfacing what customers actually prioritize under constraint.
How buy-a-feature works: spend a fixed budget
The mechanic is deliberate scarcity. Each participant gets a wallet that cannot cover everything on the menu. To buy one feature, they must give up another. That constraint is the whole point — it converts vague "I'd like all of these" answers into concrete choices.
A well-run session has four moving parts:
- A priced feature menu. List candidate features, each with a price. Prices should roughly reflect relative build cost or effort, so cheap wins and expensive bets feel different.
- A limited budget. Hand each participant play money that covers only a fraction of the total menu. A common ratio is enough to buy a third to half of the list.
- Strategic high-price items. Price a few high-value features so steeply that no single person can afford them. This forces participants to pool their money and negotiate — a signal of collective, not just individual, demand.
- A debrief. The purchase totals matter, but the conversation about why people bought or pooled is where the richest insight lives.
Run it with the right people. Buy-a-feature is a research method, so recruit actual or prospective customers, not just internal stakeholders. It fits naturally inside a broader customer research plan, where you triangulate what people say with what they choose.
A concrete buy-a-feature example
Imagine a team building a project-management tool. They have eight candidate features and cannot ship them all this quarter. Instead of debating internally, they invite eight target users to a workshop.
Each user receives a wallet of play money worth about a third of the menu's total price. The features are priced by rough effort:
- Recurring tasks — low price
- Time tracking — medium price
- Gantt-style timeline — high price
- Native mobile app — very high price (deliberately unaffordable alone)
What happens is revealing. Several users spend most of their budget on time tracking, a feature the team had ranked low. Three users combine their remaining money to jointly buy the mobile app, demonstrating a shared, urgent need. The Gantt timeline — an internal favorite — attracts almost no spend.
The team walks out with a ranked signal grounded in trade-offs. This is the kind of structured validation experiment that replaces opinion with observed behavior.
Buy-a-feature vs card sorting: a comparison
Both methods ask users to organize features, but they answer different questions. Buy-a-feature imposes an economic constraint; card sorting surfaces mental models and grouping logic. Choosing between them depends on whether you need a priority ranking or a structural map.
| Dimension | Buy-a-Feature | Card Sorting |
|---|---|---|
| Core question | Which features are worth trading off for? | How do users group and label features? |
| Constraint | Scarce budget forces choices | No budget; open or closed grouping |
| Best for | Prioritization and relative value | Information architecture and naming |
| Group dynamic | Negotiation and money-pooling | Individual or small-group sorting |
| Primary output | A ranked spend signal | Categories and grouping patterns |
Takeaway: Reach for buy-a-feature when you need to sequence a roadmap under real constraints, and card sorting when you need to understand how users mentally organize what you offer. They complement each other more than they compete.
What buy-a-feature reveals — and what it does not
It reveals relative preference under constraint. Because participants cannot buy everything, their purchases expose the features they will sacrifice others to obtain. That is a far stronger signal than a satisfaction survey, where nothing is given up.
It surfaces collaboration signals. When people pool money for an expensive feature, you learn that demand is shared and coordinated, not just one loud voice. Money-pooling is often the most memorable moment of a session.
But play money is not real money. This is the critical caveat. Spending fake currency demonstrates prioritization, not proven willingness to pay actual dollars. Someone can enthusiastically "buy" a feature in the room and still decline to pay for it in the market.
Testing Business Ideas by Bland and Osterwalder catalogs buy-a-feature as a preference and prioritization experiment for exactly this reason: it is strong evidence of relative interest and a useful early filter, but it sits earlier in the evidence hierarchy than experiments that capture real transactions. Treat its output as direction for what to test next — a pricing page, a pre-order, or a paid pilot — rather than a final verdict on revenue.
Design the debrief to protect against over-reading. Ask participants to explain each purchase. The stated reasoning often reveals that a "bought" feature was a proxy for an underlying job to be done, pointing you toward a better solution than the feature they literally picked.
Key Takeaways
- Buy-a-feature is a budget-constrained prioritization game in which participants spend limited play money on a priced menu of features.
- The technique comes from Luke Hohmann's Innovation Games and also appears in Testing Business Ideas as a preference and prioritization experiment.
- Scarcity is the mechanism — forcing trade-offs turns polite preferences into revealed priorities.
- Deliberately expensive features force money-pooling, which surfaces shared, collaborative demand worth noting.
- It measures relative preference, not guaranteed willingness to pay real money — treat results as direction, not proof of revenue.
- The debrief matters as much as the totals, because participants' reasoning reveals the jobs behind their purchases.
Frequently Asked Questions
Who invented the buy-a-feature exercise?
Buy-a-feature was popularized by Luke Hohmann in his book Innovation Games, which introduced a set of collaborative games for understanding customer needs. It has since been adopted widely in product and validation work and is catalogued in Testing Business Ideas as a preference and prioritization experiment.
How much play money should participants get?
Give each participant clearly less than the total menu price — commonly enough to afford roughly a third to a half of the listed features. The exact amount matters less than the ratio: the budget must be tight enough that buying one feature genuinely means giving up another.
Does buy-a-feature prove willingness to pay?
No. Participants spend play money, so the exercise demonstrates relative prioritization, not proven willingness to pay real dollars. Use it as an early filter to rank features, then validate the strongest signals with experiments that involve actual money, such as pre-orders or paid pilots.
How many features should be on the menu?
Keep the menu focused — enough options to force meaningful trade-offs but few enough to price and discuss in one session. Roughly six to twelve candidate features works well. Include a couple of deliberately expensive items to trigger money-pooling and reveal collaborative demand.