While I found the book very motivating, I wasn’t in a place where I could act on the advice Steve offered.  Well to be honest, I could have, but I found the prospect of interacting with customers very early in product development a bit scary.  How would I find prospective users that would be willing to talk with me before I had something really useful to demonstrate?  In my mind I had defined “really useful” as being nearly perfect. 

With the founding of Firestarter Labs, I want things to be different.  I have lived through several less than satisfying product development efforts, and I’ve vowed to learn from my mistakes.  Taking the lessons of Steve Blank and Eric Ries to heart we are developing a series of hypotheses and  seeking to test them with the least amount of effort.  To date we’ve used the concept of the Minimum Viable Product (MVP) to:

1. Test a set of domain names and marketing messages.  We first wanted to determine if it would be feasible to reach prospective customers through search engine ads.  We had only a simple landing page which described our basic offering and allowed people to sign up for an upcoming Beta test.  We tested a few different domain names and ad copy to get a feel for what worked, and tracked our conversion rate (how many people registered for the Beta).  For $50 we learned a lot.  Did we identify the optimal domain name and marketing copy?  Of course not, but it was good enough for us to move on with a little more confidence.
2. Test the intuitiveness of the solution.  Using the Balsamiq paper prototype software we mocked up some variations of the user interface.  Working with just a handful of outsiders (not carefully chosen early adopters) we were able to determine that people got the idea and that the most basic of our designs might give an acceptable user experience.  From here we began our Web-based implementation – working in no longer than three week iterations.  We define the functionality required to test our next hypothesis and estimate how long it will take to implement.  We then work to that deadline – compromising functionality if necessary. 

The tests so far have been useful, but not yet surprising.  We’ve found that our user interfaces are intelligible and we’ve been able to simplify, however we have not yet verified exactly which features will generate the real value to our users.  In a month or so we will begin testing for utility.  That is to say, determining whether users obtain meaningful benefits from our software as they go about creating their own presentations. 

Now if I could only get over my fear that with every new test we’ll discover something awful.

If you want more on the Lean Startup methodology check out Eric Ries’ presentations