Twice in the past seven days—in the same coffee shop—I have seen two different road warriors plugging away at their notebooks.
With their RSA security tokens blatantly taped to their laptop lids.
The first time I figured it was a fluke. The second time I wondered why I hadn’t seen this before (I probably had, but just didn’t register the significance). These two examples are a great way of highlighting the need to rise above the technical details and see the forest for the trees.
The engineers who originally created the concept of the token solved a very real problem—the need to create a more secure password. The technical solution is brilliant, but being engineers, they didn’t empathize with users who would react based on the inconvenience their little hack caused. Putting it in the form of anything that can be taped to a laptop is probably bad (however rare this is). Putting it in the form of something they wouldn’t dare (a cell phone) is a much smarter idea, for instance.
So when you, as a geek, create something that appears radically different from the previous solution let me offer this advice (once you’ve filed at least a patent disclosure, if you think it might be worthy):
To to a bar with a decent variety of women (by their nature, they think differently from you). Order (and finish) one stiff drink before continuing. Order only weak drinks thereafter.
Offer to buy at least three different women top-shelf drinks (read: anything the bar can make) in exchange for as much time as it takes them to finish (make it 15 minutes if they order a shot). Save the receipt, as this is a proper business expense.
Give them the elevator pitch for your thing–20 seconds max. Then ask them these questions:
- Does this invention solve a problem you have?
- Does this invention annoy you?
- What would you pay for this?
- Where would you keep it?
Write down all their answers after each interview. A bar napkin will suffice, and make you seem like less of a geek. Do not take notes on any sort of computing device, though if you must use something more formal, use a Moleskine.
Question 1 answered with a no might be a show-stopper. Either what you created has no value, your elevator pitch sucks (you are an geek, after-all), or your subject is the wrong target audience. Figure out which of the three this is after a handful of interviews.
Question 2 is critical because nobody else asks this. If they answer anything similar to yes, then you haven’t solved their problem (or you have, but have also created a new one). In either case, you’re not done designing. This will take a few more sprint cycles to figure out.
Question 3 directly gets to the value proposition. Don’t give them a multiple choice list unless they draw a blank. Left to their own devices, they might come up with a figur larger than you think you could get. The more this answer surprises you in that direction, the more you should focus on this project and ignore other projects.
Question 4 is designed to be a bit of a double entendre on purpose. Because you’re a geek, and you need practice flirting. But mostly because it’s both a proxy for value (verifying their answer for #3), and designed to illicit actual usage models. If it’s software, and they say “on my desktop”, this probably equates to high usage and value. If it’s a widget, and they say “in my purse”, that probably equates to low value. But if it’s a widget and they say “on my keychain” or “clipped to my purse” then you have a winner. These are highly specific examples, but you get the point—if they would keep it somewhere accessible, then it’s more important than something that would go in their purse, gym bag, car trunk, Start Menu, bottom-left desk drawer, etc.
The exercise I describe may sound silly, but it is designed to be a framework for doing something difficult—to think outside of the box and understand someone else’s perspective.