How to play the ‘Buy a feature’ design game
4 minutes read
‘Buy a feature’ is a simple and effective design game for getting people to choose the features that they would like to be available for a given product. It’s a great means of teasing out of people which features they would like and why. In this article I outline how to play the ‘Buy a feature’ design game and provide some useful templates for the game so that you can get started straight away.
What is the ‘Buy a feature’ design game?
As I’ve already mentioned the ‘Buy a feature’ design game is a great way of getting people to choose the features that they would like to be available for a given product. Like all the best design games it’s very simple to play, but provides incredibly useful feedback. Features are given a price depending on their complexity to implement, and players are given a stack of cash (not real obviously) with which to buy features with. By being mean and only providing enough cash to buy a limited set of features players are forced to choose those features they most want.
‘Buy a feature’ is a great means of exploring which features people are likely to find desirable in a product and why. Will someone blow their entire budget on a few monster features or instead buy lots of smaller ones? It can be useful for helping to determine which features to include for a product, for prioritising a product backlog (i.e. feature set) and for exploring the initial requirements for a product. After all, there’s no point in designing a fantastic new feature if it’s never going to be used by people in the first place. Sounds interesting? Here’s how ‘Buy a feature’ works.
Preparing your features
Before you can play ‘Buy a feature’ you of course need a list of product features. I won’t go into exactly how you build this list because every product will be different, but the list might include:
- Features that have been suggested by users
- Features that have been implemented by rival products
- Features that have come out of user research
- Features that have been identified as desirable during a phase of market research.
Features should be user focused, you wouldn’t for example want to include optimising SQL queries as a feature because the benefit might be unclear to someone (although you could rebadged this as a speed enhancement feature). Each feature should include a name and short description outlining what the feature is and what the benefits to the user are. You don’t want too many features for people to have to go through, about 30 is probably about the maximum you would want to present. If you find that you’ve got more than 30 features it probably means that you need to trim the feature list down before evaluating it with people, or that they are too fine grain and need to be a little bit more high level.
For each feature you will also need to assign a price related to the complexity to implement the feature. Prices should be relative, so for example a feature that is twice as complex (and hence costly) to implement as another should be twice as expensive. A good way to determine prices is to play something like Planning poker, although you don’t need to be too precise as really it’s just a ball park figure that you’re after. Having determined the price for each feature it’s a good idea to create feature cards. These are simple cards outlining the feature name, what it does and how much it costs. Players generally find it easier to go through a set of feature cards, rather than a long list of features as it allows them to create things like a ‘maybe’ pile and to discard features they don’t want. You can download a nifty template for creating feature cards below.
Show me the money
Once you’ve priced features and possibly created feature cards you’ll need to determine how much money you will provide. Too much and people won’t have to think too hard about the features they buy; too little and they won’t be able to buy the features they need. I’ve generally found that providing enough money to buy between a half and a third of the features works well because it really forces people to consider which features they most want.
Having determined the amount of money you will provide you need to create your notes. I’d recommend not using a denomination, such as pounds or dollars because you don’t want people equating the cost of implementing a feature with the cost (or impact to the cost) of the product. Using something like Monopoly money works well, alternatively you can print out a stack of 1, 5, 10, 20, 50, 100 and 500 notes using the template below.
Playing ‘Buy a feature’
‘Buy a feature’ can be played as a group (e.g. 2, 3 or 4 people), or one-to-one. I wouldn’t recommend playing the game with a very large group because things can become unwieldy and you will be forcing a lot of consensus when it comes to buying features. A good size group can however make for some interesting discussions. The time it takes to play the game generally depends on how many features there are. Generally the exercise shouldn’t take more than about 30 minutes, but expect things to take a little longer with bigger groups.
Having outlined how the game works and dished out the money you can then either present the features in price order (low to high, or high to low) or in a random order. If there is quite a price difference between features then you might want to think about ordering by price (to make it easier for people to determine how much can be purchased), although of course this might slightly bias the results. With the money dished out and features presented players can then start buying features. Because features often require a bit more explanation, and of course because you want to find out why something has been bought, it can be a good idea for you to play the role of shop keeper during the game. The shop keeper sells the features, answering any questions and taking payment when a feature is purchased. In order to buy a feature players should give the shop keeper the money required and outline exactly why they want that feature. The game continues until all the money has been spent, or all the features wanted by players have been purchased. Make it clear to players that it’s OK for money to be left over at the end because you don’t want people buying features just to get rid of their unspent cash.
If getting time with people is very difficult then you could also set-up a features spreadsheet to send out. This isn’t as useful as playing the game face-to-face because you’re not able to fully explore why a feature has been purchased. It can however be a useful alternative. You can download a nice little template for a ‘Buy a feature’ spreadsheet below. Enjoy.
18th January 2011 @ 7:12 pm
Great post. I love how it forces people to see the (real) cost of features. It’s way to easy for people to add feature after feature without consequence. This inevitably leads to a feature-rich product that never launches. Or that’s out-of-date by the time it does.
15th March 2011 @ 8:56 pm
Love the resource kit. Has anyone explored an on-line version of the game? That would be useful for remote users.
15th March 2011 @ 9:30 pm
Innovation games have an online version of buy a feature. I’ve not tried it out but it looks interesting and would certainly be useful when meeting users face to face is difficult.
28th March 2011 @ 9:53 am
What a great idea. This concept sound like it would fit any scenario whereby you’re trying to determine what ‘upgrades’ to your service your customers would value highest.
Are there any examples of a service online utilizing this example?
22nd April 2011 @ 4:12 pm
Thanks so much for spreading the word about Buy a Feature (http://innovationgames.com/buy-a-feature/). Luke Hohmann, our CEO and Founder, is the inventor of the now 14 Innovation Games of which Buy a Feature is one. You can find more about the game (both it’s use in-person and online) on our website (http://innovationgames.com).
6th August 2011 @ 5:40 pm
That’s such a great idea to show a CONCRETE example of opportunity cost. I’m gonna adapt the same idea, but use it with my wife! Maybe she’ll understand how buying “stuff” hurts you! Or how “but it’s only $100” is a flawed argument!
21st September 2011 @ 11:57 pm
If you want to really know whether or not a feature is of value, give out real money with the option of them keeping whatever they don’t use in the game.
If they are willing to spend the $1 or whatever on the feature over keeping it, you know that feature really has value.
This can be done quite simply using bitcoin.
Create bitcoin addresses for each of the different options.
An exchange site, such as TradeHill ( http://www.tradehill.com ) can be used to generate each of the addresses. (or an eWallet service like http://WalletBit.com )
Then generate addresses, fund those addresses and give each participant a note containing their Instawallet with the funds they can use to vote with
It is then trivial to add up the totals received for each option.
7th December 2011 @ 10:42 pm
If you use targetgroups or persona you can decide to prioritize these groups.
So if Targetgroup A has more influence on the success of your product/website you can
give the player in the game that represents that targetgroup more money to buy features.
10th February 2012 @ 4:13 pm
Nice overview of the game.
I’m intrigued by “Anony Mouse”‘s suggestion to provide *real* money that people can keep. I’m going to try and find a client to try it :-).
Patrick, a brief word on group size. “Buy a Feature” scales to an arbitrarily large number of people – in groups of 5..8. If want 80 customers to play, then you’d play 10 games. We’ve done this, for example, in our work with City of San Jose, CA, where we’ve gathered large numbers of community leaders to prioritize budget priorities. As you can guess, it is a bit easier to scale to large numbers of players using our online system, but both work well.
Have fun, and keep playing!
17th March 2012 @ 9:32 am
Thanks for this. I’ll be running this exercise with one of my corporate clients to give them experiential learning of the importance of prioritising features and I would greatly appreciate it if anyone could advise where I might be able to get a ‘dummy’ set of features from?
Thanks in advance
17th March 2012 @ 10:05 am
Thanks for this.
I’ll be running a session that will involve the team looking at additional features required to enhance the functionality of an existing out of the box software solution we are currently using.
And because there is no development work involved to assess complexity against, I was wondering how to price each additional feature? Any suggestions would be much appreciated.
29th October 2012 @ 4:09 pm
I would avoid any online version of this game. The true beauty of this exercise is the collaboration, when used in groups. Use it as an ice breaker (with a back burner or stalled projects) for groups working on concept and experience mappings, affinity diagrams and rapid prototyping.
The group interaction, conversation and questions can never be captured from an online program at half duplex. And this data when captured is priceless.