My Lean Startup Experience (Manila)

I attended the first LSM in Manila (earlier this month). Here's my experience.

Long Hours...

It was a long two and a half days (July 4 to 6), getting out of the building, talking to strangers, thinking about ideas, listening, and trying to stay awake with lots of caffeine.

At the start of the event, attendees were asked to log their ideas if they had any. When the event started, the ones with ideas were given 50 seconds to pitch. It was hilarious!

After 20 or so ideas were pitched, we voted for the ones we wanted to support. The top 15 ideas were left. And we were asked to choose which ideas we'd like to go with, and that became our groupings.

I was hoping to have a live Skype session with Trevor Owens, Founder & CEO of Lean Startup Machine. I guess the internet connection wasn't good enough.

Validation Board

Although I've first learned about the validation board (via leanstartupmachine.com) a few years back, I wasn't clear with how it would be used to identify customers, their problems, and their solutions. Dr. Bernard Wong was able to walk us through how it is used. I find the latest version (called the Experiment Board) to be easier than the previous one.

Of course, listening to the speaker wasn't enough. I needed to get down and dirty, and do it! Boy, I was glad I was part of a team that felt comfy going out of the building and asking strangers.

Experiments

One of the more difficult parts of the experiment was to decide the success factor. I couldn't figure out if 5 out of 10, or 2 out of 3, would be a good success criteria. One of the coaches clarified that this is really a "gut feel". I like how he puts it. Imagine if it were your own money being invested in the idea. If the team came up with an experiment that resulted in only 5 out of 10, would you put your money into it? Or would you put your money into something that had 8 out of 10? Simple.

Lessons Learned

Here are some lessons I've learned. Some of them can be just my opinions. So, don't believe everything.

Customer and Problem First, Solutions Last

I've committed this mistake again and again. I would assume that a particular segment of the population had a certain problem that would need a solution. And before I even think about running experiments, I was already busy with the solution.

Start with the customer first. Run some experiments to see if a particular segment of the population (customers) do indeed have that problem and are in need of (i.e. already hacked, or willing to pay/buy) a solution. You don't even have to have a solution just yet. Focus on validating if the customer segment does indeed have that problem. Who knows? You might end up with a different customer segment, or a totally different problem.

In my experience, we were able to refine our customer segment. At first, we thought a bigger segment of the population had that problem. We learned that it wasn't true! In fact, a smaller, more specific, segment had that problem (for example, at first, you'd think that college students have this problem, but it turns out that people who have extra income have this problem).

Customer's don't care about your solution, they care about their problems.

Dave McClure, 500 Startup's founder

Note also that you can be in a two-sided (or n-sided) market. In which case, you'll need to run more experiments to further understand the customer-problem on each side.

Pivot After the Experiment is Invalidated

When experimenting your riskiest assumption, it is possible to get failures (i.e. not meeting the success criteria). When you do, don't worry, pivot. Again, don't assume that it will fail or succeed!

When pivoting, you'll need some more insights (validated learning) from your experiments to help you pivot to your next experiment, like why some people said yes to the problem, and some said no.

Don't Get Hung Up with Your MVP

Focus on your experiments first. MVPs will only be useful after you've validated your hypothesis through experiments. So, don't get hung up with your MVP.

When Eric Ries used the term for the first time he described it as:

A Minimum Viable Product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.

(emphasis added)

Now, MVP may mean different things to different people. I just want to add that an MVP is not the only way to learn about customers.

Some people make the mistake of prematurely jumping into their MVPs and incorrectly assume that a minimum set of features will deliver value to the customer and start generating revenue (or getting paid). While I do agree, and I'm a strong advocate of the saying, charge from day one and get paid, but… make sure you've validated something first. By the time you get to your MVP (e.g. concierge, wizard of oz), you ought to have proven some of your hypothesis through experiments (e.g. customer interviews, teaser pages, etc).

Happy Validating!

Happy validating! More power to your lean startup machines! Congratulations to our team (Carlo, Mannix, Tieza, Mar Kevin)! We got first runner up! Yeah baby, yeah!