Minimum Desirable Product and Lean Startups (slides included!) | Andrew Chen (@andrew_chen)

Minimum Desirable Product and Lean Startups (slides included!)

Comments

(if you don’t see the slides, go here to Slideshare)


Recent slides for a talk in Steve Blank / Eric Ries’s class on High-Tech Entrepreneurship

Yesterday I had the pleasure of giving a talk at Steve and Eric’s class at Haas on the topic of Minimum Desirable Product – if you haven’t read the original article, it provides some useful context. I included an set of slides above on the topic, updated from my talk yesterday, which you can peruse at your convenience.

After you’re done, you can read my extended remarks below on some stuff I learned along the way. Frankly, any of these could probably be its own blog post but I’ve been feeling lazy lately so you get a couple sentences apiece instead :-)

This is a good read, based on a presentation given to Steve Blank’s class at Stanford. Check out the slide deck and see the additional comments as well.

Lessons Learned: Learning is better than optimization (the local maximum problem)

Learning is better than optimization (the local maximum problem)

Lean startups don’t optimize. At least, not in the traditional sense of trying to squeeze every tenth of a point out of a conversion metric or landing page. Instead, we try to accelerate with respect to validated learning about customers.

For example, I’m a big believer in split-testing. Many optimizers are in favor of split-testing, too: direct marketers, landing page and SEO experts — heck even the Google Website Optimizer team. But our interest in the tactic of split-testing is only superficially similar.

Take the infamous “41 shades of blue” split-test. I understand and respect why optimizers want to do tests like that. There are often counter-intuitive changes in customer behavior that depend on little details. In fact, the curse of product development is that sometimes small things make a huge difference and sometimes huge things make no difference. Split-testing is great for figuring out which is which.

Another excellent post by Eric Ries about how there is a need to balance metric testing with reasonable design sense to overcome getting stuck in a particular direction.

Users Know: Pain Driven Design

What Is Pain Driven Design (PDD)?

The PDD methodology requires that, before you start design for a product or feature, you need to figure out what is causing pain for your users and potential users. The desired outcome of PDD is to make that pain go away by some brilliant method of your devising. You then check to make sure you made their pain go away without causing them any more pain.

This is a good post to read for anyone doing development. Sometimes we all get stuck in the ruts of normal design approaches, so thinking about it from a different perspective can make the difference of good and great.