Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?
 
PerlMonks  

Building the Right Thing (Part II): Lean Startup

by eyepopslikeamosquito (Bishop)
on Oct 21, 2015 at 21:11 UTC ( #1145592=perlmeditation: print w/replies, xml ) Need Help??

Just like pretotyping, discussed last time, Lean startup was a love-child born from the ashes of entrepreneurial catastrophe.

Having experienced devastating failure in his first two Startup adventures (Catalyst Recruiting and There.com), Eric Ries understandably became highly motivated to make sure that never happened to him again ... finally achieving startup glory at his third attempt, at IMVU in 2004.

Having experienced both heady success and catastrophic failure at startups, Ries was well qualified to develop a methodology to help startups succeed: Lean startup.

Ries was fortunate to have Steve Blank, a formidable methodologist, as his mentor at IMVU and he became Blank's star pupil. Indeed, Blank's "Customer Development" became a cornerstone of Ries' subsequent Lean Startup movement. Nowadays, Ries spends most of his time advising companies and teaching entrepreneurship.

Ries' experiences are not atypical: most startups fail. Indeed, the world is crying out for a way to reduce the waste and misery associated with failed startups.

Not only that, but with disruptive technologies on the rise, it's becoming more crucial than ever for established companies to innovate to survive.

Lean Startup vs Pretotyping

Lean Startup is an approach that is, to some extent, broader than the one put forward by "pretotyping". It's applicable before you get to the stage of having a "pretotype" (e.g. interviewing customers) and afterwards (when you're actually building and delivering live features.)

-- Adrian Howard aka adrianh

As usual adrianh is right on the money: Lean Startup is more ambitious than pretotyping, in that it covers all aspects of running a successful business, while pretotyping just focuses on identifying the right "it" to build. Put another way, pretotyping is a subset of Lean Startup.

What is Lean Startup?

After defining a Startup as:

A human institution designed to create a new product or service under conditions of extreme uncertainty
Ries defines Lean Startup as:
A set of practices for helping entrepreneurs increase their odds of building a successful startup
I think the key point here is "extreme uncertainty". Ries experienced first hand that traditional business practices, such as creating a detailed business plan, simply do not work in conditions of extreme uncertainty.

Steve Blank gives his take on Lean Startup as based on three principles:

  1. Business model canvas. Instead of writing a detailed business plan, entrepreneurs list a series of untested hypotheses in a "business model canvas", a diagram of how a company creates value for itself and its customers.
  2. Get out of the building aka "Customer Development". Go out and ask potential users and partners for feedback on all elements of your business model. Rapidly assemble minimum viable products (MVPs) to aid in eliciting customer feedback. Based on this feedback, make further small adjustments (iterations) or big ones (pivots) to ideas that aren't working. Rinse and repeat.
  3. Use Agile software development to develop the MVPs.

In the foreword to the Lean UX book, Ries further comments:

Lean Startup is a big tent. It builds on established ideas from many disciplines, from lean manufacturing to design thinking.
Clearly, there are many ideas and influences behind the Lean Startup movement, and it is constantly evolving.

Product Features vs Business Outcomes

Laura Klein gives a practical example that further clarifies what Lean Startup is about:

Before Lean UX, Company X might have said, "We need to record user comments for each product and display them on the product page". The product manager would have spent time writing a spec for comments on product pages. A designer might have come in and designed a great comment experience. Engineers would then have written code that matched the spec and the design. The whole process might have taken two or three months. At the end of the process, the product pages would allow users to leave comments. But so what? Would this make users spend more money on products? Would they stick around for longer? Would users even bother to leave comments? What is the actual benefit to the company for spending those three months?

The problem with this approach is that it starts with a feature rather than a hypothesis. It assumes that comments on product pages are necessary rather than identifying a user problem, coming up with an idea that might solve that user problem, and designing a test to see if the idea is true. A more Lean approach is:

Based on our preliminary research, we believe that allowing users to leave comments on product pages will cause customers to become more engaged and buy more items. How can we figure out if thatís true?

Now this has been stated in a way that allows the company to validate the hypothesis and easily change the feature if it turns out to be the wrong way to improve the metric.

That is, we focus on Business Outcomes, not Product Features.

Lean Startup vs Agile

Mary Poppendieck provides an interesting comparison between Agile and Lean Startup:

AgileLean Startup
Product RoadmapBusiness Model Canvas
Product VisionProduct Market Fit
Release PlanMinimum Viable Product
On-Site Customer"Get out of the Building"
IterationBuild-Measure-Learn Loop
Iteration ReviewPersevere or Pivot
Backlog"To Learn" List
User StoryHypothesis
Acceptance TestSplit Test
Definition of DoneValidated Learning
Continuous IntegrationContinuous Deployment
Customer FeedbackCohort-based Metrics
Product OwnerEntrepreneur
Certified Scrum MasterCustomer Success Manager

The February Revolution

In an attempt to cut through the considerable jargon and dogma from many competing methodologies, such as impact mapping, feature injection, real options, hothousing, user story mapping and similar, Gojko Adzic and others got together to try to distill the essence of these techniques into a simple set of principles. They came up with the following "february revolution".

Great results happen when:

  • People know why they are doing their work.
  • Organizations focus on delivering outcomes and impacts rather than features.
  • Teams decide what to do next based on immediate and direct feedback from the use of their work.
  • Everyone cares.

Departmental Silos

How is it possible that our departmental silos are operating with agility, but our companies are hopelessly rigid and slow? From our far-off vantage point, we have missed something essential. Although our departments may value agility, the interconnections between them are still mired in an antiquated industrial past.

-- Eric Ries (in the Foreword)

I'm interested to learn how your company is run. What works, and what doesn't, for you?

Perl Monks References

External References

  • Comment on Building the Right Thing (Part II): Lean Startup

Replies are listed 'Best First'.
A reply falls below the community's threshold of quality. You may see it by logging in.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://1145592]
Approved by hippo
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (7)
As of 2020-09-30 09:23 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    If at first I donít succeed, I Ö










    Results (160 votes). Check out past polls.

    Notices?