Objective Prioritisation: Buy a Feature

This is one of RoadmapOne’s articles on Objective Prioritisation frameworks .

Most prioritisation frameworks are top-down: product teams score features using RICE or NPV, finance approves budgets, and stakeholders learn what got funded after the fact. Buy a Feature flips that script. It’s Luke Hohmann’s Innovation Game—a collaborative workshop where stakeholders get fake money, features get priced by development cost, and participants “buy” what they want. The features that generate the most spending get prioritised. It’s Shark Tank meets product roadmapping: stakeholders vote with their wallets, and the wallet votes reveal priorities.

Buy a Feature is spectacularly transparent: everyone sees what everyone else values. It forces trade-offs: you can’t buy everything, so what do you sacrifice? It creates stakeholder buy-in because they participated in the decision. But Buy a Feature is also spectacularly gameable. The executive with the loudest voice dominates the table. Sales reps form cartels to pool budgets on deal-closing features. Customer success teams bid up pet features until they’re overpriced. And introverted stakeholders—often your most thoughtful product people—get drowned out by extroverts with monopoly money.

Sign up now to run stakeholder workshops

How Buy a Feature Actually Works

Buy a Feature was created by Luke Hohmann as part of his Innovation Games suite—12 collaborative games designed to surface customer needs and align stakeholders. It’s been used by companies like Ticketmaster, VeriSign, and dozens of SaaS businesses to prioritise quarterly roadmaps and strategic initiatives.

The Basic Mechanics

1. Select Features for the Game Choose 12-20 features for participants to evaluate. Fewer than 12 and the game is trivial; more than 20 and it’s overwhelming. Features should be at comparable scopes (all epics or all major initiatives, not mixing £10k features with £500k platforms).

2. Price Features by Development Cost Assign prices based on estimated development cost. If Feature A costs £60k to build and Feature B costs £120k, price B at 2× the cost of A. Use round numbers (£50k, £100k, £200k) or points (5, 10, 20) to keep math simple.

3. Give Participants Fixed Budgets Each participant gets the same amount of play money—poker chips, Monopoly cash, or paper currency. A common setup: £300k per person, features priced £20k-£200k. The budget should allow buying 2-3 mid-priced features or 1-2 expensive ones, but not everything.

4. Price at Least One Feature Above Individual Budgets This is Hohmann’s key insight: price one highly desirable feature higher than anyone’s individual budget (e.g., £400k when each person has £300k). If stakeholders want it badly enough, they’ll pool money and negotiate. This reveals whether the feature is genuinely high-priority or just individually desirable.

5. Run the Buying Phase Give stakeholders 15-30 minutes to “shop.” They walk around a table where features are laid out (index cards, posters, or digital boards), debate with each other, pool budgets, and place their money on features they want. Facilitators observe but don’t intervene—the negotiation is the data.

6. Tally Spending and Rank Features Count total spending per feature. The features with the highest accumulated budgets represent stakeholder priorities. These form the ranked backlog.

The Workshop Variations

Customer Advisory Board Version: Run with 8-12 customers. Give them budgets representing their ARR (a £500k customer gets more money than a £50k customer). This weights priorities by revenue impact.

Internal Stakeholder Version: Run with sales, customer success, engineering, and product leads. Equal budgets create democratic prioritisation. Weighted budgets (by department size or strategic importance) create hierarchy.

Hybrid Version: Combine customers and internal teams in one workshop. Price features identically for both groups, then compare where their priorities align or diverge.

Buy a Feature in Action: Three Scenarios

Scenario A: SaaS Product—Customer Advisory Board

You’re a B2B SaaS product. You run Buy a Feature with 10 enterprise customers at your annual advisory board meeting.

Setup:

• 15 features priced £50k-£250k
• Each customer gets £400k budget
• One feature (Enterprise SSO) priced at £500k (above individual budgets)

Buying Phase Observations:

• Three customers immediately buy SSO by pooling £166k each—revealing it’s a genuine Must-Have for enterprise
• Mobile app redesign (£100k) gets £600k total spending—6 customers bought it
• Advanced analytics dashboard (£150k) gets £300k—2 customers bought it
• Zapier integration (£75k) gets £450k—6 customers bought it, highest buy rate

Prioritised Ranking:

1. Mobile redesign (£600k spending, 6 buyers)
2. SSO (£500k, 3 buyers pooling budgets = high intensity)
3. Zapier (£450k, 6 buyers)
4. Analytics (£300k, 2 buyers)

Insights: Mobile and Zapier have broad demand (6/10 customers). SSO has narrow but intense demand (3 customers willing to pool budgets). Analytics has weak demand despite being “strategic.” Buy a Feature surfaced that analytics is a product team pet project, not a customer priority.

Scenario B: Internal Stakeholder Workshop—Sales vs Product Tension

You’re aligning internal stakeholders before quarterly planning. 12 participants: 4 sales, 3 customer success, 3 product, 2 engineering.

Setup:

• 18 features priced £25k-£300k
• Equal budgets (£350k each)
• One feature (API platform) priced at £450k

Buying Phase Observations:

• Sales team pools budgets to buy three deal-closing features (£200k, £150k, £100k)
• Customer success splits budgets across four churn-prevention features
• Product and engineering buy API platform by pooling all their money (£700k combined)
• Result: Sales features get £450k, CS features get £420k, API platform gets £700k

Conflict: Sales and CS teams complain API platform “cheated” by pooling budgets from fewer people. Product argues API unlocks future partnerships worth £500k ARR.

Facilitation Fix: Re-run with rule: maximum 3 people can pool on any one feature. Second round produces more balanced results.

Insight: Buy a Feature exposes coalitions and power dynamics. Sales coordinated; CS fragmented; Product/Eng formed strategic alliance. These dynamics mirror real organisational politics—the game surfaced them explicitly.

Scenario C: Pricing Trap—When Budgets Don’t Reflect Costs

You run Buy a Feature with equal budgets (£300k each). Features priced proportionally:

• Quick win feature: £30k (priced honestly)
• Complex platform: £300k (priced honestly)
• Mid-tier integration: £90k (priced honestly)

Problem: Everyone spends their £300k on 3-4 cheap features (£30k-£90k). The platform gets zero buyers—not because it’s low-priority, but because it costs everyone’s entire budget.

Outcome: Roadmap fills with quick wins. Platform gets deferred. Long-term strategic value starved.

Facilitation Fix: Adjust pricing to reflect value, not just cost. Price platform at £200k (reflecting 2/3 of its cost) to make it affordable. Alternatively, give participants £500k budgets so they can afford one big bet plus a few quick wins.

Insight: Buy a Feature requires calibrating budgets and prices to avoid systematically deprioritising expensive-but-strategic work. Pure cost-based pricing creates feature-factory bias.

When Buy a Feature Is Your Best Weapon

Buy a Feature excels in four contexts.

First: Stakeholder alignment workshops. When sales, customer success, product, and engineering can’t agree on priorities, Buy a Feature forces transparent trade-offs. Everyone sees everyone else’s choices. Debates shift from “my features matter more” to “why did you spend £200k on that instead of this?” The game creates shared understanding, even when disagreement remains.

Second: Customer advisory boards and user conferences. Inviting customers to “buy” features makes them feel heard. They participate in shaping the roadmap, not just commenting on it. And you gain qualitative data: which customers pool budgets (indicating partnership-strength relationships), which features attract broad vs narrow demand, and where customer priorities diverge from internal assumptions.

Third: Surfacing hidden priorities. Sometimes stakeholders say “everything is high priority” to avoid hard choices. Buy a Feature forces choice: you can’t buy everything with finite budgets. The game reveals actual priorities through budget allocation—talk is cheap, spending isn’t.

Fourth: Building roadmap buy-in. When stakeholders participate in Buy a Feature and see their peers’ choices, they accept the outcome as legitimate. Even if their top features didn’t win, they witnessed the democratic process. This reduces post-prioritisation lobbying (“Why didn’t we fund my feature?!")—the answer is: “We ran Buy a Feature, here’s what everyone bought.”

When Buy a Feature Betrays You

Buy a Feature collapses in three scenarios.

First: When dominant personalities monopolise the game. The loud exec drowns out quiet participants. The charismatic sales VP forms a coalition to buy only deal-closing features. Introverted engineers sit silently while extroverts pool budgets. Buy a Feature reveals group dynamics—but if those dynamics are toxic, the game amplifies toxicity. The cure is strong facilitation: enforce turn-taking, require written votes before verbal negotiation, or run silent budgeting phases.

Second: When gaming overtakes authenticity. Teams form cartels (“Product and Eng will pool budgets on platform; Sales and CS pool on customer features”). Participants bid up features strategically, not authentically. Political coalitions override actual priorities. The game becomes negotiation theatre, not priority revelation. The fix is limiting pooling (max 3 people per feature), requiring anonymous initial votes, or running multiple rounds to surface stable patterns.

Third: When workshop dynamics don’t reflect business reality. Buy a Feature treats all participants equally unless you weight budgets. But a £1M enterprise customer’s opinion should matter more than a £10k SMB customer’s. A sales team managing £5M pipeline should have more weight than a 3-person CS team. Unweighted Buy a Feature creates democratic outcomes that ignore strategic reality. The fix is weighting budgets by ARR, pipeline value, or strategic importance—but transparency about weighting is essential.

Practical Implementation: From Workshop to Roadmap

Step 1: Define Participants and Scope

Who’s playing? Internal stakeholders? Customers? Mix? Choose 6-15 participants—fewer and dynamics are thin, more and coordination is chaos.

Define scope: Are features quarterly initiatives, annual epics, or multi-year platforms? Keep scope consistent.

Step 2: Price Features Honestly

Estimate development cost for each feature (person-months × loaded cost). Price proportionally: if Feature A costs £60k and Feature B costs £180k, price B at 3× A’s cost.

Use round numbers (£25k, £50k, £100k, £200k) or points (5, 10, 20, 40) for simplicity.

Step 3: Set Budgets to Force Trade-offs

Give each participant a budget that allows buying 2-4 mid-priced features or 1-2 expensive ones. If average feature costs £100k, give £300k-£400k budgets.

Price at least one highly desirable feature above individual budgets (e.g., £500k when budgets are £350k). This tests whether pooling happens organically.

Step 4: Facilitate the Buying Phase

Lay out features on a table (or digital board). Give participants 20-30 minutes to shop, negotiate, pool budgets, and place money on features.

Observe: Who pools budgets? Who negotiates vs decides silently? Which features attract broad vs narrow interest?

Step 5: Tally and Rank

Count total spending per feature. Rank by cumulative budget. The top-funded features represent stakeholder priorities.

Note qualitative patterns: Were there coalitions? Did specific stakeholders dominate? Did one feature attract many small buyers vs one large buyer?

Step 6: Validate Against Strategic Priorities

Buy a Feature surfaces stakeholder preferences, not necessarily strategic priorities. Compare workshop results to strategic goals. If customers bought only incremental features and ignored strategic bets, use Buy a Feature as input but overlay strategic judgment.

Step 7: Communicate Results Transparently

Show participants the ranked results. Explain which features will be funded and why. If you override Buy a Feature results (e.g., funding a low-ranked strategic platform), explain the override explicitly.

Buy a Feature and Other Frameworks: When to Combine

Buy a Feature is qualitative and collaborative. Pair it with quantitative frameworks for rigor:

• Buy a Feature + RICE: Run Buy a Feature to surface stakeholder priorities. Score top-ranked features with RICE (Reach, Impact, Confidence, Effort) to validate with data.
• Buy a Feature + Cost of Delay: Use Buy a Feature to identify which features stakeholders want. Calculate Cost of Delay to determine urgency.
• Buy a Feature + Kano: Run Buy a Feature, then tag winning features as Must-Have, Performance, or Delighter to ensure balanced portfolio.

Buy a Feature gathers input; quantitative frameworks validate and sequence. Together they create stakeholder-informed, data-driven roadmaps.

The Facilitation Challenge: Running a Good Workshop

Buy a Feature lives or dies by facilitation quality. Poor facilitation creates chaotic free-for-alls where loudest voices win. Strong facilitation creates structured debates that reveal authentic priorities.

Key facilitation techniques:

• Silent initial voting: Require participants to allocate budgets privately before group negotiation. This prevents groupthink and anchoring.
• Pooling limits: Cap pooling at 3-4 people per feature. This prevents coalitions from monopolising outcomes.
• Time-boxing: Limit buying phase to 20-30 minutes. Artificial scarcity forces decisiveness.
• Equal airtime: If verbal negotiation dominates, enforce turn-taking: each participant gets 2 minutes to advocate for their priorities before group negotiation starts.
• Transparent pricing logic: Explain why features are priced the way they are (development cost estimates). This prevents “why is X so expensive?” derailing the game.

Strong facilitators observe group dynamics, intervene when power imbalances skew outcomes, and surface patterns participants might miss.

The Uncomfortable Truth About Democratic Prioritisation

Buy a Feature creates the illusion of democracy: everyone gets a budget, everyone’s vote counts. But democracy doesn’t optimise for business outcomes. The feature that gets the most votes might not be the most valuable. The feature that attracts coalition-building might just have politically savvy advocates.

This is why Buy a Feature is an input, not a decision. Use it to understand stakeholder preferences and surface hidden priorities. Then layer business judgment: Does the winning feature align with strategy? Does it balance quick wins vs long-term bets? Does it optimise for loud voices or actual value?

Buy a Feature reveals what stakeholders want. You still need to decide whether what they want is what the business needs.

If you take only three ideas from this essay, let them be:

1. Buy a Feature Surfaces Priorities Through Constrained Budgets. Giving stakeholders unlimited say leads to “everything is high priority.” Buy a Feature forces trade-offs: you can’t buy everything, so what do you sacrifice? The budget constraint reveals actual priorities through observable choices, not stated preferences.

2. Workshop Dynamics Mirror Organisational Politics—for Better or Worse. Buy a Feature exposes coalitions, power dynamics, and influence patterns. Loud execs dominate quiet engineers. Sales forms cartels. CS fragments across pet features. These dynamics exist whether you run the game or not—Buy a Feature makes them visible. Strong facilitation is essential to prevent toxic dynamics from distorting outcomes.

3. Buy a Feature Is Input, Not Gospel—Layer Business Judgment. The features that win Buy a Feature represent stakeholder preferences. They don’t necessarily represent strategic priorities, customer value, or business outcomes. Use Buy a Feature to gather input and build buy-in, then validate winners with RICE, Kano, or Cost of Delay. Democratic prioritisation isn’t always optimal prioritisation.

RoadmapOne doesn’t directly simulate Buy a Feature workshops (it’s a physical/facilitated game), but you can import workshop results as stakeholder feedback and combine them with quantitative scoring. The game surfaces qualitative priorities; RoadmapOne’s frameworks (RICE, Kano, Cost of Delay) validate them with data.

Buy a Feature won’t replace rigorous prioritisation. But it’ll give you something equally valuable: stakeholder buy-in, visible trade-offs, and a shared understanding of why the roadmap looks the way it does. And in organisations where politics kills products, that might be the most valuable outcome of all.

For more on Objective Prioritisation frameworks, see our comprehensive guide .