Digesting Feedback for Startups: "Agile Playing Card" Method
Its always a good idea to get some feedback on your project. Too much thinking on your own or what a former mentor of mine called, "Analysis paralysis" can really be an obstacle. I guess that's why there's a whole "get out of the building" movement. Try to show something, anything to your audience. (For more on my opinion on whether getting out of the building is a good idea please see my blogs on this topic).
For startups, its all about getting feedback and shifting through the suggestions and determining which ones are critical and which ones are nice to haves. Below is a suggested way to break the typical analysis paralysis when it comes to what features/functions to implement, and also a way not to throw the "kitchen sink" at the product in the hope that your target audience will adopt your product.
PLAYING CARDS METHOD
.JPG)
One of the methods we've adopted which (I believe) is an agile method and taught to us first by David Kuo of The Zero Step, was to make decisions using decks of playing cards. Might sound a little crazy, but it's worth a try and certainly moves the discussion along. Here's what you'll need.
1. List of features and functions that you're interested in putting in/updating in your product.
2. As this is a democratic sort of tradition, you'll need all of your available team members.
3. Decks of playing cards equal to number of team members.
4. Helps to have a white board to write stuff down and keep the "scoring".
5. Handouts or projection of the list of items you intend to discuss.
6. Open mind and judicious temperament.
First, distribute to each team member a set of playing cards from A to 10. No need for face cards. Assume that A = 1. 10 = 10.
Second, designate that 1 is least important and 10 is most important.
Third, make sure that everyone is STANDING. This is in the stand up meeting tradition. Things tend to go quicker when you are all standing. If anyone gets tired and tries to sit, please ask them to stand. Keep the integrity of the process.
Forth, begin by having your designated product development person briefly describe the first function for discussion. At this point, do NOT discuss the feature. Just outline what it is.
Fifth, allow everyone a moment to choose the appropriate card from their deck to represent their belief of how important the feature is to the next build. Remember at this point there should have been no discussion.
Six, on the count of 3, each person turns over their cards and shows their card, which indicates their belief as to importance of the feature.
Here's how you determine what happens. There are two basic scenarios.
A. Everyone turned over a card within a close range of each other. For example, members selected 5-6-7 as their cards. This means that the importance of the item for the next build is 6.
B. Everyone turned over cards and the range was broader than 3 numbers, such as 4, 5, 8, 9, 10. If this is the case, then whoever turned over 4 and 10 are the ONLY two allowed to discuss and argue their point of view. NO one else is allowed to speak their mind. Quickly allow the two to make their case and then go through the process of "reselecting" and turning over the cards again as in steps 5, select card; step 6, turn over cards.
1. Sometimes, this can be resolved within one repeat.
2. Other times, this may take several attempts. Repeat this process until you get within a 3 number range. Keep everyone standing as this will keep the process moving.
Best practice 1, try to think of the feature and functionality as related to the build for the next quarter, next month, rather than for the lifetime of the project.
Best practice 2, try not to make it about how hard or easy it would be to implement the feature.
Best practice 3, if you are in an active sales process of the product try to determine if adding the feature would gain you any additional customers. In other words, will the cost of implementation bring more audience/revenue.
Repeat the process for all of the items to be discussed on that day. You'll find that you should end up with a good priority list of items to implement. Typically, we've found that with a list of 15 items for prioritization, that with a team of six people or so, we can get through the entire list within a 60 minute period. Often, in time for lunch. Nothing like lunch looming as a reward to ensure everyone stays on point and committed to the task at hand.
Once you have priorities set, you can go about your current implementation best practices. Good luck!
.JPG)
