Dispelling lean startup myths

Dispelling Lean Startup Myths- what you truly need to know to practice Lean right!

Sanchan Sahai Saxena

Go get it!

https://twitter.com/sanchansaxena

http://www.quora.com/Sanchan-Saxena

http://www.linkedin.com/in/sanchans

Myth #1

Myth #1Lean Startup calls for building an MVP that appeals to all potential customers

What I typically hear…

Myth #1


Myth #1“This is just not ready yet. We need to continue polishing the UX for our MVP

so it appeals to regular folks too – the Monicas from Montana. Otherwise,

they will never like the product and will never come back again.”


Myth #1“This is just not ready yet. We need to continue polishing the UX for our MVP

so it appeals to regular folks too – the Monicas from Montana. Otherwise,

they will never like the product and will never come back again.”

“We need to release our MVP in the wild and get it in front of as many users as possible. But before we can do that, we need to add more features and

options to appeal to a broader range of customers.”

What I tell them instead…


Designing for everybody is like designing for nobody.



Startups need to focus – and focus on the early adopters first.




Early adopters are a special breed.

Image from Paulo Ordoveza on Flickr

http://www.flickr.com/photos/44124483743@N01/3432723410/






They have the problem that you are trying to

solve and are willing to invest time and energy

in using a less than ideal solution.








You goal is to find the early adopters for your product and make your MVP viable for them – not everyone.

They have the problem that you are trying to

solve and are willing to invest time and energy

in using a less than ideal solution.




Where are your users?

* Image from Wikipedia article

http://en.wikipedia.org/wiki/File:Technology-Adoption-Lifecycle.png






All potential customers of your technology/product





Over time, your goal is to convert all potential customers to adopt your technology/product.





Over time, your goal is to convert all potential customers to adopt your technology/product.

But you have to start by converting your early

adopters first!


Target your MVP to the right users








Your MVPn

MVP, by definition, should not be designed to appeal equally well to all your potential customers.




Instead, you must focus on making yourMVP viable and appealing to your earlyadopters first.

Your MVPn


What others are saying…


Steve Blank (article)

In the real world not every customer is going to get overly excited about your minimum feature set. Only a special subset of customers will and what gets them breathing heavy is the long-term vision for your product.

Most customers will not want a product with a minimal feature set. In fact, the majority of customers will hate it. So why do it? Because you are selling the first version of your product to early evangelists.

You’re selling the vision and delivering the minimum feature set to visionaries not everyone.

http://steveblank.com/2010/03/04/perfection-by-subtraction-the-minimum-feature-set/



In the real world not every customer is going to get overly excited about your minimum feature set. Only a special subset of customers will and what gets them breathing heavy is the long-term vision for your product.

Most customers will not want a product with a minimal feature set. In fact, the majority of customers will hate it. So why do it? Because you are selling the first version of your product to early evangelists.

You’re selling the vision and delivering the minimum feature set to visionaries not everyone.

Eric Ries (article)

The minimum viable product is that product which has just those features and no more that allows you to ship a product that early adopters see and, at least some of whom resonate with, pay you money for, and start to give you feedback on.

And sometimes it’s useful to them because early adopters have the same kind of visioning power that entrepreneurs do, but because they can see what the end product is going to be.


http://venturehacks.com/articles/minimum-viable-product

Lesson #1

Lesson #1Make your MVP viable for the early adopters first

Myth #2

Myth #2Lean Startup calls for testing everything by practicing release early, releasing often methodology



Myth #1“We ship code twice a week because we want to release often and learn

quickly from our customers about things that we should be building for them next.”


Myth #1“We ship code twice a week because we want to release often and learn

quickly from our customers about things that we should be building for them next.”

“We release twice daily as it is consistent with the lean startup’s release early, release often approach. We just do it because we can and our

deployment systems are pretty awesome.”



Don’t delegate your vision to your customers!



I have a vision!

You must start

with your own Vision

– an idea of where you want to go.



I have a vision!

User Testing helps you find the best strategy (a path forward) to get to your Vision.

You must start

with your own Vision

– an idea of where you want to go.

As Eric said…

As Eric said…

Not having a vision is like

getting into your car and

asking your GPS where to go.

As Eric said…




Oh mighty GPS – tell me where should I go today?

As Eric said…




Oh mighty GPS – tell me where should I go today?

If you don’t have a destination in mind, no number of GPSs will help you - no amount of testing can tell you where you want to go.

Start with your vision…


…and articulate it as a collection of hypotheses!


Your Vision



Your Vision


Hypo- thesis1

Hypo- thesis2

Hypo- thesis3

Hypo- thesisN


Your Vision


Hypo- thesis1

Hypo- thesis2

Hypo- thesis3

Hypo- thesisN

Create a plan that allows you to validate and learn about these hypotheses early and often!


Your Vision


Hypo- thesis1

Hypo- thesis2

Hypo- thesis3

Hypo- thesisN


2 weeks 1 week


Your Vision


Hypo- thesis1

Hypo- thesis2

Hypo- thesis3

Hypo- thesisN


Your Learning Schedule

2 weeks 1 week

Creating a schedule for learning…


Don’t release for the sake of releasing – release for the sake of learning.


Identify early on what you want to learn from your early adopters





Strategize how you want to learn (concierge MVP etc.)





Create a schedule that facilitates the learning using the right MVP with your users





Create a schedule that facilitates the learning using the right MVP with your users

Don’t follow a release schedule – follow a Learning Schedule ©



Eric Ries (article)

The issue there is, if you just follow the release early, release often mantra, you find yourself running around in circles.

Pretty soon you’re chasing your own tail a little bit because you’re not operating against a clear, long-term vision of what you’re trying to accomplish.

http://www.startuplessonslearned.com/2009/03/minimum-viable-product.html



Earlyvangelists, particularly in corporations, will be buying into your entire vision, not just your first product release.

They will need to hear what your company plans to deliver over the next 18 to 36 months.

These Earlyvangelists are first buying the vision and then the product. They need to fall in love with the idea of your product. It’s the vision that will keep them committed the many times you screw up. You’ll have bugs, your product will eat their data, you’ll get the features wrong, performance will be bad, you’ll argue about pricing, etc.

Eric Ries (article)

The issue there is, if you just follow the release early, release often mantra, you find yourself running around in circles.

Pretty soon you’re chasing your own tail a little bit because you’re not operating against a clear, long-term vision of what you’re trying to accomplish.


http://www.startuplessonslearned.com/2009/03/minimum-viable-product.html

Lesson #2

Lesson #2Learn early, Learn Often about your vision’s hypotheses

Myth #3

Myth #3MVP is the minimum product that you can ship quickly


Myth #1


Myth #1“We just need to build something minimum - get it out in front of real users

and get user data to iterate.”


Myth #1“We just need to build something minimum - get it out in front of real users

and get user data to iterate.”

“I don’t think we should build FeatureX. None of our competitors offer it either. Plus, it will take a long time to build. We must build something quickly

and something minimum.”



Sometimes I wish that Eric Ries coined

the term VMP (Viable Minimum Product)

instead of an MVP (Minimum Viable Product)

to reduce the confusion.


Sometimes I wish that Eric Ries coined

the term VMP (Viable Minimum Product)

instead of an MVP (Minimum Viable Product)

to reduce the confusion.

But oh well!

Thinking Minimum before Viable?


“Minimum” in MVP doesn’t mean cheap or minimal.



It simply means that you build what you need.



It simply means that you build what you need.

But first, you have to focus on defining

what you need to learn from your early adopters.

Find the Viable that is also the Minimum


All stuff that is minimum.

Minimum



Minimum

All stuff that is viable for all

your users.

Viable



Minimum


your users.

Viable



Minimum


your users.

Viable

Your MVP that is viable for your early adopters and

helps validate your hypotheses.



Eric Ries

Some entrepreneurs hear "minimum viable" product as "smallest imaginable" product. MVP, despite the name, is not about creating minimal products.


Eric Ries


David Aycan (article)

Sometimes, entrepreneurs miss a key opportunity to establish market differentiation by interpreting the "minimum" component of an MVP to mean "nothing challenging." Worse, they sometimes create a product that's not competitive by rationalizing that they can get 'something like' the core idea by replacing a feature with something easier to implement.

http://blogs.hbr.org/cs/2012/05/dont_let_the_minimum_win_over.html


Eric Ries


David Aycan (article)

Sometimes, entrepreneurs miss a key opportunity to establish market differentiation by interpreting the "minimum" component of an MVP to mean "nothing challenging." Worse, they sometimes create a product that's not competitive by rationalizing that they can get 'something like' the core idea by replacing a feature with something easier to implement.Steve Blank (article)

This minimum feature set (sometimes called the “minimum viable product”) causes lots of confusion. Founders act like the “minimum” part is the goal.

http://blogs.hbr.org/cs/2012/05/dont_let_the_minimum_win_over.html


Lesson #3

Lesson #3Aim for the Viable before you aim for the Minimum.

Thank you!This is my MVP presentation.

More iterations to come soon based on your feedback!

So don’t be shy and let me know what you think!