Buy a feature for product managers
Our reviewers evaluate writing services independently. Learn how we stay transparent, our methodology, and tell us about anything we missed.
Buy a Feature is a collaborative product-research exercise I use to explore what people value when they have to make tradeoffs. I give participants a set of possible features or improvements and a limited amount of fictional currency. They can buy items alone or pool money with others, then explain why they made those choices.
I treat the activity as a way to learn about priorities, language, and perceived value. It is not a pricing study, a binding vote, or proof that a feature will succeed. The value comes from the conversation around the purchase: what problem the person is trying to solve, what they are willing to give up, and what would make the option worth choosing.
Define the learning goal
I start with one or two questions the exercise can answer. I might want to understand which onboarding problems feel most important, how different roles trade speed against control, or which improvements participants connect with a desired outcome. I avoid asking the game to rank an entire roadmap and predict demand at the same time.
I define the audience and context. A current customer, a trial user, an internal operator, and a prospective buyer may value the same item for different reasons. I record who participated, what they knew, and which product situation they were imagining so I do not treat all purchases as interchangeable evidence.
I also decide what I will do with the learning. If the exercise changes the order of discovery questions, reveals a confusing concept, or suggests a follow-up interview, I can judge whether it was useful without claiming that the activity forecast adoption.
Choose items that represent real tradeoffs
I select a manageable set of items tied to the same product context. Each item should describe a customer-relevant improvement rather than an internal project label. “Faster bulk review for operations teams” is easier to discuss than a ticket number or a technical component.
I keep the items distinct enough to compare, but not so different that the exercise becomes a contest between unrelated products. I explain the problem, intended audience, and important boundaries in a short card or prompt. I avoid promising a specific implementation when I am still exploring solutions.
I set prices to create meaningful tradeoffs, not to smuggle in my preferred result. If every item is cheap, participants can buy everything and I learn little about priorities. If one item is priced far above the rest without a clear reason, the result mostly reflects my framing. I test the setup with a colleague and revise confusing prices or descriptions before using it with customers.
Make the currency and rules clear
I give each participant or group a limited, fictional budget. The amount is a design choice, not a representation of real money or willingness to pay. I explain what may be purchased, whether participants can pool funds, whether they can buy part of an item, and what happens if the budget is not spent.
I keep the rules simple enough that the conversation stays focused on value. I tell participants that there are no correct answers and that they should explain what they would gain, avoid, or make possible with a purchase. I do not reward them for choosing the items I expected.
I decide whether the exercise is individual, group-based, or a sequence of both. Individual choices can reveal personal priorities. A group version can surface negotiation, coalition building, and shared language. Those are different kinds of learning, so I label the format in my notes.
Facilitate the conversation, not the outcome
I introduce the context without pitching each feature. During the exercise, I ask neutral questions: What problem would this help with? What makes it worth the price? What did you choose not to buy? Who else would need to agree? What would you need to believe before using it?
I pay attention to hesitation and substitutions. A participant may buy an item because it stands for confidence, control, speed, or reduced coordination, even if the feature description is not the right solution. Another person may reject a valuable outcome because the prompt assumes a workflow they do not have.
I avoid correcting a participant’s interpretation in the moment unless the setup is factually misleading or unsafe. A misunderstanding can identify unclear product language or an assumption I need to test. I record the misunderstanding and distinguish it from a true preference.
Analyze purchases with explanations
I record the purchase, role, context, discussion, and notable non-purchases. Counts can show which items drew attention in this exercise, but they do not explain why. I use the reasons to identify desired outcomes, perceived barriers, and tradeoffs.
I look for segments and contrasts. An item may matter to administrators because it reduces coordination but matter less to daily users. Two participants may buy the same feature for opposite reasons. I do not collapse those explanations into one average if the distinction affects the product question.
I compare what participants bought with what they already do. A purchase can express a preference for an improvement while the current workaround shows what constraints matter in practice. I follow up when the gap between stated value and observed behavior is important.
Avoid common interpretation traps
I do not convert fictional currency into a willingness-to-pay number. The participant is making a forced choice inside an artificial scenario, not signing a commercial offer. I also do not read a purchase as a commitment to use the finished feature. Curiosity, social influence, and the appeal of a clear card can affect the result.
I avoid treating the most purchased feature as the automatic roadmap winner. The item may be broadly understandable, while a less popular item may address a severe problem for a strategically important audience. I combine the activity with interviews, product evidence, feasibility checks, and outcome measures.
I review the price and wording for bias. If people cannot compare items fairly, the result teaches me about the exercise design more than about their priorities. I note uncertainty rather than overclaiming.
Turn learning into decisions
After the exercise, I group insights into outcomes and assumptions. I might learn that participants want faster resolution, clearer ownership, or more confidence in data rather than the specific features I presented. I use that language to improve problem framing and design follow-up questions.
For each important insight, I record a next action: interview a different role, inspect workflow data, prototype a concept, test technical feasibility, or stop pursuing an assumption. I also record what the exercise cannot answer so it does not acquire authority it was never designed to have.
A practical Buy a Feature session
I choose one learning goal, prepare five to eight comparable feature cards, set a limited fictional budget, and invite participants from a defined context. I explain the rules, observe purchases and tradeoffs, ask neutral follow-ups, and capture non-purchases as carefully as purchases. I synthesize reasons by audience and outcome, then validate the strongest learning with another method.
Buy a Feature works for me when the tradeoff makes priorities discussable. The exercise is valuable because it reveals reasoning, not because a pile of fictional money can predict the roadmap.
Next step
Build stronger product strategy, discovery, and outcome-focused decision-making skills in the Product Manager Certification. Subscribe to the Product HQ newsletter for practical frameworks and career-ready product lessons.
