Buy a Feature: Prioritize With Real Customer Trade-Offs

Buy a Feature is a collaborative prioritization game, created by Luke Hohmann, in which customers spend a limited budget of play money to buy features from a priced menu. Because the budget is scarce and the best features are priced high, spending forces real trade-offs and reveals genuine priorities and willingness to pay.

Quick Answer: Give customers a fixed pot of play money and a menu of priced features. Price the best features so no one can afford them alone, then watch what they buy — and what they pool money for. Spending behavior, not opinion, ranks your roadmap.

What is the Buy a Feature game?

Buy a Feature is a prioritization exercise in which customers or stakeholders receive a fixed budget of play money and use it to "buy" the features they want most from a menu where every item carries a price. It swaps what people say they want for what they are willing to spend to get.

The game comes from Luke Hohmann, who introduced it in his book Innovation Games as one of a set of structured, playful exercises for learning what customers actually value. It is among the most direct techniques in that collection because it attaches an explicit cost to every choice, and it pairs naturally with the other Innovation Games for prioritization that Hohmann documents.

The engine of the game is scarcity. In an ordinary conversation, every feature is free to ask for, so people quite reasonably want all of them. A ranked survey has the same flaw dressed up as data: rating ten features "very important" costs nothing, so most come back "very important." A fixed budget removes that free lunch.

Once money is finite, priorities stop being abstract. A customer who swore five features were essential now has to fund maybe two of them — and the ones they reach for first, with their own limited pot, are the ones that actually matter. The gap between the survey answer and the spending decision is exactly the signal you were missing.

Reach for it when you have more good ideas than budget. Buy a Feature earns its keep whenever several strong options compete for the same scarce resource and you need customers, not the loudest voice in the room, to break the tie. It fits a product roadmap, a service package, a pricing tier, or any decision where you can only fund a few of many candidates.

The Buy a Feature setup: features, prices, and budgets

A Buy a Feature session has five moving parts: a menu of features, a price on each one, a budget for each participant, the participants themselves, and a facilitator who runs the room. Get these five right and the game largely runs itself; get them wrong and you collect noise.

The menu is the heart of it. List real, comparable options — features, improvements, or service add-ons — written in the customer's language rather than internal jargon. Keep the items roughly the same "size" so a single purchase means something consistent, and offer enough options that people have to choose without drowning them in a catalog nobody can hold in their head.

Before you price anything, it helps to see how the pieces fit together. The table below breaks down each element of the setup and how to design it.

The through-line across all five rows is deliberate scarcity: the budget must be smaller than the menu, and the best features must cost more than any one wallet holds. Everything interesting about Buy a Feature — the trade-offs, the negotiations, the pooling — flows from those two constraints. Miss them and you have a shopping trip, not a prioritization.

Choosing participants deserves as much care as choosing features. A table full of colleagues will buy what the company already wants to build; a table of real customers from one segment will buy what the market values. When those two lists disagree, the disagreement is the most valuable thing you learn all day.

How to price features and set each player's budget

Price features by their rough relative cost or value, then set each budget below the menu's total so no one can buy everything — and price your headline features so high that no single player can afford them alone. That last rule is what turns a solo shopping trip into a revealing negotiation.

There are two defensible ways to set prices, and you can blend them:

• Price by build cost — expensive-to-build features cost more play money. This keeps the exercise honest about engineering reality and teaches customers that everything has a trade-off.
• Price by value — set prices to reflect rough market or perceived value. This surfaces willingness to pay more directly, since customers weigh price against the benefit they expect.

Whichever you choose, the budget is what creates the tension. If every participant can comfortably afford their favorite item, they buy it and stop, and you learn almost nothing. Set the total budget across the group so that, together, they can fund only a fraction of the menu — enough for a few real choices, never enough for a spree.

Price your best features to require collaboration. Say you are validating a note-taking app with five options on the menu: faster sync, offline mode, shared workspaces, an AI summary, and a calendar integration. If any one person can afford offline mode outright, you never learn who else values it. Price it above a single budget, and the interesting moment appears — a buyer who wants it has to talk others into chipping in.

That pooling is not a side effect; it is the richest data the game produces. When three people combine their money to fund one feature, they are telling you it matters more than everything they gave up to make it happen. A feature that only ever gets funded through pooling is one your segment cares about intensely — even if no individual would spend their whole budget on it alone.

Getting the denominations and totals right takes a little calibration, and it is worth doing on paper before the session. For a deeper treatment of the numbers, our guide to setting Buy a Feature prices and budgets walks through how to size the pot and space the prices so the trade-offs land where you want them.

How to run a Buy a Feature session, solo or in a group

Run a Buy a Feature session by presenting the priced menu, handing out budgets, and letting participants spend — individually first if you want clean per-person data, then together so the negotiations surface. The facilitator's only job is to keep the buying moving and to ask "why" every time money changes hands.

In a group, seat a small table of customers who share a segment, give each person their play money, and open the floor. People start by buying obvious favorites, then slow down as the budget tightens and the expensive items force conversation. This is where you stop talking and start listening: the debate over which feature deserves the pooled money is the whole point of gathering people in one room.

Solo or one-on-one, the game still works and is often more practical for a founder running customer interviews. Walk a single customer through the menu, hand them their budget, and have them spend it while thinking aloud. You lose the group negotiation but gain a clean, uninterrupted view of one person's trade-offs — and you can repeat the exact same exercise across many interviews to see where the pattern holds.

A few facilitation habits separate a useful session from a fun-but-empty one:

• Stay neutral. Never defend a feature or nudge a purchase; the moment you sell, the data is contaminated.
• Ask why, not whether. "Why did you fund that one first?" beats "Do you like this feature?" every time.
• Capture the order. What people buy first, under a full budget, ranks higher than what they buy last with leftover change.
• Record the arguments. The reasons behind a pooled purchase are worth more than the tally, and they vanish if you do not write them down.
• Let silence work. The pause before an expensive purchase is where the real deliberation happens — don't fill it.

For the full step-by-step, including timing, materials, and how to close the session, see our walkthrough of how to run a Buy a Feature session. The mechanics are simple enough to learn in one sitting and sharpen with every round you facilitate.

How to read the results and the negotiations that matter

Read the results by ranking features on what customers actually funded — especially what they bought first and what they pooled money to afford — not on the raw count of buyers. The spending pattern is the ranking; the conversation around it tells you why.

Start with the obvious tally: which features got funded, and by how much. But the order and the effort matter more than the totals. A feature one person bought instantly at full price carries different weight than one three people scraped together for after a long debate — and a feature nobody touched, however loved it looked on your roadmap, just failed a real test in front of you.

The table below maps common spending behaviors to what they signal and what to do next.

The pattern to internalize is that the negotiations carry as much signal as the purchases. When customers argue about whether to pool for a feature, you are watching them price it in real time. Because participants sacrifice a scarce resource to get what they want, Buy a Feature produces a form of revealed preference that a questionnaire cannot — which is why it belongs in the same toolkit as structured willingness-to-pay research.

Treat one session as a strong signal, not a verdict. Run the game across several groups or many interviews and look for the features that keep getting funded first; those are the ones with durable demand rather than a single enthusiastic table. If you would rather keep the evidence — who bought what, and why — alongside your other validation signals instead of on scattered sticky notes, a platform like Edmired can hold it in one place. And for how the method stacks up against a simpler instrument, see our Buy a Feature vs. survey comparison.

Common Buy a Feature mistakes to avoid

The most common Buy a Feature mistakes all defeat the game's one job — forcing trade-offs — usually by quietly removing the scarcity that makes spending meaningful. Each is easy to avoid once you know to watch for it.

• Budgets that are too generous. If people can afford most of the menu, nothing is traded off and everything looks important. Keep the total well below the menu's price.
• Pricing everything the same. Uniform prices turn the game into a vote and erase the collaboration that expensive features create. Vary prices, and set your best features high.
• A menu of look-alike items. Ten variations on one feature give you noise. Offer genuinely distinct options that compete for the same money.
• Inviting the wrong people. Stakeholders and internal teams buy what they want to build; only real customers in your segment reveal market priorities.
• Selling during the session. A facilitator who defends or nudges a feature contaminates the result. Stay neutral and let the money talk.
• Treating one session as proof. A single table is a signal, not a mandate. Repeat across groups before you rewrite the roadmap.

The subtlest mistake is reading only the totals. Two features can attract the same amount of money for completely different reasons — one bought instantly by a few devoted users, the other funded reluctantly by a crowd unloading spare change. Watch the order, the pooling, and the arguments, or you will mistake mild consensus for genuine conviction and fund the wrong thing with confidence.

Key Takeaways

• Buy a Feature turns opinions into spending decisions — customers buy from a priced menu with a fixed budget, so what they fund, not what they claim, sets the priority.
• Scarcity is the entire mechanism — the budget must be smaller than the menu, or nothing is traded off and every feature looks essential.
• Price your best features beyond one wallet — when the most-wanted items cost more than a single budget, customers must pool money, and that collaboration is the richest signal in the game.
• Order and pooling beat raw totals — a feature bought first at full price, or funded by a group scraping money together, outranks one that merely collected spare change.
• The negotiations are the data — the argument over whether to pool for a feature is customers pricing it in real time, so capture the reasons, not just the purchases.
• It works solo or in a group — run it in customer interviews for clean individual trade-offs, or at a table for the revealing group debate.
• One session is a signal, not a verdict — repeat across groups and interviews, and trust the features that keep getting funded first.

Frequently Asked Questions

Who created the Buy a Feature game?

Buy a Feature was created by Luke Hohmann, who introduced it in his book Innovation Games. It is one of a set of collaborative exercises he designed to help teams understand what customers value. The scarce-budget mechanic that forces real trade-offs is what made it widely adopted for product and roadmap prioritization.

How many people do you need to run Buy a Feature?

You can run Buy a Feature with a single customer in an interview or with a small group at a table. Groups add the negotiation and pooling that make the game revealing, so a handful of participants who share a segment works well. For clean per-person data, run it one-on-one across several interviews instead.

Can you run Buy a Feature remotely or online?

Yes. Buy a Feature works remotely using a shared whiteboard or spreadsheet for the priced menu and a simple tally for each participant's budget. The mechanics — priced features, a scarce budget, spending out loud — translate directly to a video call. You lose some of the in-room energy but keep the trade-offs and the willingness-to-pay signal.

What is the difference between Buy a Feature and dot voting?

Dot voting gives everyone equal dots to place on their favorites, which measures popularity but not intensity or trade-off. Buy a Feature attaches prices and a scarce budget, so customers must weigh cost against value and sometimes pool money. That added friction reveals conviction and willingness to pay that simple dot voting cannot capture.

Does Buy a Feature measure real willingness to pay?

Buy a Feature measures willingness to pay with play money, so it reveals relative priorities and trade-offs rather than exact prices. Because participants sacrifice a scarce budget, the signal is far stronger than a survey's. Still, confirm the top features with real commitment tests — pre-orders or paid pilots — before you commit to building them.