5.10.1 Prioritization - Buy a Feature
At a Glance
Other names Buy a Feature
In Brief
In Buy a Feature, participants receive a limited budget of play money and decide which features to purchase from a priced list. Each participant gets only enough money to buy roughly one-third to two-thirds of the available features, so the budget forces trade-offs. Pricing one or two features beyond what any single participant can afford pushes them to pool money, and the negotiation that follows surfaces their priorities and the reasoning behind them. The output is a feature list ranked by spend, plus the negotiation notes.
Common Use Case
You have a backlog of fourteen to thirty candidate features and a small group of target participants you can convene for sixty to ninety minutes. You need to know which features they would actually pay for, not just rate as “important” on a survey. The output is a ranked-by-budget feature list plus the negotiation reasoning participants used to get there.
Helps Answer
- Which features would customers actually pay for?
- How do participants make trade-offs between features?
- What is the perceived relative value of different features?
- Are there features that only specific segments care about?
- What coalitions form around which features?
Description
Buy a Feature is the Prioritization variant that uses a fixed play-money budget to rank features by what participants will spend on them. A fixed budget forces participants to trade off features against one another, the way they trade off real money against real purchases. That produces sharper signal than a 1-to-5 rating scale, where most features cluster near the top because nothing is at stake. The conversations during the game — the debates, the compromises, the lobbying — are as informative as the final purchases: they show not just what participants buy, but why they buy it and what they give up to do so.
The game produces three layers of insight:
- Individual priorities. What each participant buys with their own money reveals their personal must-haves.
- Negotiation behavior. When expensive features require pooling money, participants persuade others to join them. The arguments they make and the compromises they accept reveal how strongly they want a feature.
- Feature abandonment. What participants choose not to buy — even when they can afford it — flags features that sound appealing but are not worth the trade-off.
Buy a Feature is stated-preference data from a small group, not a representative measure of willingness to pay. Use it to compare features against each other and to hear the reasoning, not to forecast revenue. When the question is which problems matter rather than which features to fund, prioritize pains first with Pain Point Sorting.
How to
Prep
1. Build the feature list.
Write fourteen to thirty candidate features on cards, a poster, or a handout. Each feature gets a clear name, a one-sentence description, and a price. Keep the list in this range: long enough to force trade-offs, short enough that participants can hold the whole set in their head. Use participant-facing language, not internal codenames.
2. Set prices to provoke trade-offs, not to model engineering cost.
Pricing is the most important design choice. Price at least one or two features high enough that no single participant can buy them alone, so the group has to pool money to fund them — the negotiation that follows is where most of the insight comes from. Price to push participants into trade-offs, not to signal how much each feature costs you to build.
A workable distribution for a fourteen-to-thirty feature list:
- Five to ten low-priced features that any participant can afford.
- Five to twelve medium-priced features that require trading off other purchases.
- Four to eight high-priced features that require two to four participants to pool money.
Use round numbers so participants can do the math in their heads.
3. Distribute play money.
Each participant receives the same budget — enough to buy roughly one-third to two-thirds of the total feature value if they spent only on cheap features. Keep the budget tight enough that participants cannot have everything; the constraint is what makes their choices meaningful. Print bills, use poker chips, or hand out paper certificates — whatever holds up to being passed back and forth on a table.
4. Recruit four to seven participants per group.
Aim for four to seven participants per group: small enough that everyone has to talk, large enough that coalitions can form. Run multiple groups if you can recruit more than seven — features that win across several groups carry far more weight than a single session’s result.
5. Draft the rules sheet.
Write the rules out so the facilitator can read them verbatim. The core rules:
- “You have $X to spend on the features in front of you.”
- “You can buy any feature you can afford on your own.”
- “You can pool money with other participants to buy a feature together.”
- “You do not get change. Leftover money has no value.”
- “You have forty-five minutes to make your purchases.”
Execution
1. Open with the rules and the budget reveal.
Read the rules verbatim from the sheet you drafted in Prep. Hand out the play money in front of the group so the budget feels tangible. Take ten minutes for introductions and rules so participants understand the mechanic before any money moves.
2. Step back and let them play.
Once the rules are clear, the facilitator’s job is to observe, not to guide. Participants only negotiate honestly if they believe they have to convince each other, so stay out of it. Do not validate choices. Do not explain features beyond the printed description. If a participant asks what something means, note the confusion as a finding and redirect them to the description on the card.
Forty to sixty minutes is the right window for purchasing and negotiation. Take notes on who approaches whom, what arguments get made, what deals get struck, and what features get abandoned without discussion.
3. Track purchases as they happen.
As participants finalize purchases, record:
- Which features were bought.
- Who paid for each feature, and how much each contributor put in.
- Which features were purchased through pooled money, and which participants formed the coalition.
A simple spreadsheet column for each feature works fine. If you are running the session remotely, a shared online whiteboard lets participants drag chips onto features while you log the same data.
4. Debrief for fifteen to twenty minutes.
After time is up, walk the group through the results. The high-leverage questions:
- “What was the hardest trade-off you made?”
- “What feature did you want but decided not to buy? Why?”
- “What surprised you about other people’s choices?”
The reasoning that comes out of the debrief is often more useful than the purchase data itself.
Analysis
Analyze results across several dimensions:
- Most-purchased features are clear priorities. If a feature was bought across multiple groups, it is a strong roadmap candidate.
- Features that inspired pooling are aspirational and high-value. These often represent capabilities that could become key differentiators — and the negotiation around them tells you which segments will fund them.
- Features no one bought are candidates for cutting from the roadmap, regardless of how much engineering effort has already been invested.
- Negotiation patterns reveal segment dynamics. If certain participants consistently lobbied for the same features, they may represent a distinct customer segment with shared priorities.
- Leftover money tells you about satisfaction with the available options. If participants consistently had unspent money at the end, they may prefer a simpler product or the feature list may be missing something important — go back to generative interviews or Pain Point Sorting to find it.
- Dominant negotiators Assertive participants may drive group purchasing decisions. Observe whether quieter participants were genuinely persuaded or merely yielding. Ask each participant to privately write down their top three before the game begins so you can compare individual intent against group outcome.
- Price anchoring Participants may equate higher price with higher value, rather than making independent judgments. Remind the group at the start that prices are for gameplay only, not signals of importance or quality.
- Coalition pressure Once a coalition forms around an expensive feature, participants may feel social pressure to contribute even if it is not their top priority. Watch for reluctant contributions and probe them in the debrief.
- Framing bias Feature names that read as marketing copy or internal codenames prime participants to buy based on the label, not the underlying capability. If purchasing patterns look suspiciously unanimous, check whether the winning features had more vivid or aspirational names than the rest of the list.
- Unequal information Some participants may understand certain features better than others, giving them outsized influence. Make sure each description is clear enough that the least-informed participant can evaluate it.
Learn more
Case Studies
Capital One: $100 Buy-a-Feature across two audiences
Capital One ran Buy a Feature with both front-line retail bankers and executive management on a $100 virtual budget; the two groups split predictably (bankers wanted customer-serving features, management wanted process-efficiency features), and the high-value/low-effort intersection became the MVP scope.
City of San José: Buy-a-Feature as participatory budgeting
San José’s 2016 participatory-budget event used Luke Hohmann’s Budget Games adaptation to let roughly 300 residents allocate a ~$64M maintenance-and-beautification budget across 30 projects in small facilitated groups, with senior city officials present to answer questions.
Further reading
- Hohmann, Luke. Innovation Games: Creating Breakthrough Products Through Collaborative Play. Addison-Wesley, 2006. The primary source for the Buy a Feature mechanic, including the pricing rule, group-size guidance, and budget design.
- Buy a Feature — Luke Hohmann
- Buy-a-Feature — ProductPlan
- How to play the “Buy a Feature” design game — UX for the Masses
- Innovation game — Wikipedia
Got something to add? Share with the community.
