Buy a Feature
Give users a limited amount of mock-currency to spend on a handful of features, to discover preference and priorities.
What is Buy a Feature?
Buy a Feature is a prioritization experiment that simulates real-world budget constraints by giving users a limited amount of mock currency to spend on potential product features. This technique forces participants to make trade-offs and reveals their true preferences by requiring them to prioritize features based on perceived value rather than simply rating everything as 'important.' The method provides quantitative data on feature demand while mimicking actual purchasing decisions.
This validation technique is particularly valuable because it eliminates the common problem of users wanting 'everything' when asked about features. By introducing scarcity through limited budget allocation, you gain insights into what users actually value most when forced to choose. The results help product teams make data-driven decisions about feature development priorities, resource allocation, and roadmap planning while reducing the risk of building features nobody truly needs.
When to Use This Experiment
• Feature prioritization phase - When you have multiple feature ideas but limited development resources • MVP definition - Determining which core features to include in your minimum viable product • Product roadmap planning - Deciding the order of feature development for future releases • Market research stage - Understanding customer preferences before significant development investment • Pivot considerations - When evaluating which features to keep, modify, or eliminate • Competitive analysis - Testing whether users prefer your proposed features over competitor offerings • Budget allocation decisions - When development resources are constrained and you need clear priority rankings
How to Run This Experiment
-
Define feature set - Create a list of 5-10 potential features with clear, concise descriptions. Include rough development cost estimates to set realistic 'prices' for each feature in mock currency.
-
Set mock budget and pricing - Give each participant the same limited budget (e.g., 100 coins). Price features based on development complexity - simple features cost 10-20 coins, complex ones 30-50 coins.
-
Create the experiment interface - Build a simple webpage, use tools like Typeform, or create a physical card-sorting exercise. Display features with descriptions, prices, and a running budget counter.
-
Recruit target participants - Gather 30-100 participants from your target market. Use existing customer lists, social media, or user research platforms to find qualified participants.
-
Run the experiment - Have participants 'shop' for features within their budget constraints. Allow them to see their remaining budget and change selections before final submission.
-
Collect additional data - Include follow-up questions about their decision-making process, feature importance reasoning, and demographic information for segmentation analysis.
-
Analyze results - Calculate purchase frequency, revenue per feature, and participant segments. Look for patterns in spending behavior and feature combinations.
-
Validate findings - Cross-reference results with other validation methods like user interviews or A/B tests to confirm feature priorities before development.
Pros and Cons
Pros
• Forces real trade-offs - Eliminates the problem of users rating everything as high priority • Quantitative insights - Provides measurable data on feature demand and relative value • Budget-friendly - Can be executed with minimal resources using simple tools • Quick to implement - Results available within days rather than weeks • Mimics real decisions - Simulates actual purchasing behavior better than surveys
Cons
• Artificial constraints - Mock currency doesn't perfectly replicate real buying decisions • Limited context - Participants may not fully understand technical complexity or implementation challenges • Sample bias - Results depend heavily on participant selection and may not represent entire market • Feature interdependence - Doesn't account for features that work better together or have dependencies
Real-World Examples
Microsoft used a Buy a Feature approach when developing Office 365, giving enterprise customers mock budgets to allocate across potential collaboration features. The exercise revealed that advanced sharing capabilities and real-time co-editing were valued much higher than initially expected, leading to prioritized development of these features over others that seemed important in traditional surveys.
A fintech startup used this method to prioritize mobile banking features, giving users 100 virtual coins to spend on features like bill pay (30 coins), budgeting tools (20 coins), investment tracking (40 coins), and expense categorization (25 coins). The results showed 78% of users prioritized bill pay and budgeting tools over investment features, despite initial assumptions that investment tools were the key differentiator.
Airbnb reportedly used similar prioritization techniques during their early days to determine which host and guest features to build first. By having users allocate limited resources across features like instant booking, professional photography, and enhanced messaging, they discovered that trust and safety features were valued much higher than convenience features, influencing their product roadmap significantly.