24 4 / 2010

Startup Lessons Learned Recap

As I’ve alluded to in my other posts, I’m a big fan of the Minimum Viable Product model developed by Eric Ries, Steve Blank, and many others.  This idea that you should basically do as little as you can to figure out if it’s worth pursuing something further really resonates with me.  Since I was 16 I’ve built other startups that tried to do too much that no one wanted and failed.  

So, I was excited to watch the Startup Lessons Learned conference broadcasted live on Justin.tv.  Some cool things I learned about how to cheaply test a theory before building it: 

1) Wizard of Oz testing

Max and Damon from Aardvark, a social search service, talked about how they used Wizard of Oz ops for much of their startup’s duration before being bought by Google.  The idea behind Aardvark is that you can send Aardvark a question (either by IM or now Twitter), any question, and Aardvark will fwd your question to someone knowledgeable about that topic.  The person responds to Aardvark, and the answer is fwded back to you.  I guess I’d always thought there was massive technology behind the system — lots of AI to determine who to send to and just general technology to send responses through IM protocols.  What I did not know was that for several months, before building out the technology, the founders would manually either type answers or fwd questions and answers to people on IM.  Before building *anything* they wanted to know if this was a model that people would use/like and find useful.  Turns out with their manual ops, people loved the service, so they gradually started building out pieces of the technology to automatize various pieces.  The total system took 9 months to build, but they validated the system way before they started building and iterated while they were building. 

2) Simple form submission

Flowtown previously had a service that took them 3 months to build and by the end of it, they only had one customer.  They realized they needed to speed up the time to figure out what people wanted.  So they built a landing page describing a service around contact information and told people to fill out a form if they wanted to buy it.  Upon filling out this form, users would get a message saying that the service hadn’t been built yet, but it certainly let Flowtown know who was interested in the service and how many people.  After realizing their new product garnered a lot of interest, they decided to build this new product.

3) Display what the product might do with a video

Drew from Dropbox, an online backup, storage, and sync service talked about how the MVP model is tricky for a service like Dropbox.  He said that incompleteness of a service like Dropbox wouldn’t be acceptable to his users.  Yet, building out a technically robust system like Dropbox *before knowing if people wanted it* was also unwise.  So he created a video showing how the product worked (video showed Wizard of Oz-Ops) and collected email addresses of people who wanted it.  The demand was astounding, and he launched his product to thousands of people on his email list.  

There are more things I’d love to share from the conference, but since this post is already long, I’ll save those topics for another day.