Quick prototyping

This past weekend, a friend of mine, Mudit, asked me what I thought about his newest startup idea. It was a good idea. However, I told him I was concerned about whether user behavior would support or challenge adoption etc.

That lead us down the path of how to quickly prototype. Jared, who leads product for us, often talks about paper prototypes : printouts that he takes to cafés where target customers can quickly react. I do a lot of woodwork, and prefer to do simple models before I build the entire project.

For earfl, we tested last summer the notion of recordings via phone by setting up an extra phone line with ATT CallVantage – our VOIP service. Before we had any business plan, we wanted to test.

We found out that one of my friends was attending a wedding, and he agreed to post the phone number on signs at a dinner party, encouraging guests to call in stories about the couple.

We did the same thing for a high school reunion.

This simple prototyping helped us understand lots of things, proving some assumptions (callers tell good stories about friends, that are valuable for later playback), and highlighting problems (allowing users to re-record can lead to over-rehearsed contributions).

The test cost us less than $20.

So my advice to my friend Mudit was to start testing at under $20, and then take those learnings and test the idea at $100, and so on.

The idea is to invest greater money only as necessary to test. Sometimes one can get caught up thinking about issues (eg., how to raise $$) at a time when more critical ones can easily be tested/discarded at very low cost. Testing these may help with larger future concerns.

We have tried to take that to heart -- we continue to test cheaply on the side, use agile methods for development and have short release cycles. We may have grander ideas and can get easily excited about lots of features/functionalities. We put those grand ideas aside --- our hope is that we build upwards, listening to our users, testing, and modifying.