Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options
 
PerlMonks  

Building the Right Thing (Part II): Lean Startup

by eyepopslikeamosquito (Chancellor)
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'.
Re: Building the Right Thing (Part II): Lean Startup
by sundialsvc4 (Abbot) on Oct 22, 2015 at 15:12 UTC

    Do I laugh, or cry?

    There is a h-u-g-e difference between “coping with committee analysis-paralysis in deciding whether to provide a comments feature on a web-site” and “starting up a new company.”   The fact that this was presented as an example tells me what Eric’s new business-plan really is:   to coin a new philosophy, brand it Lean Startup®, and promote the hell out of it, shamelessly leveraging a previous, and curiously successful (marketing-wise, if not software-wise) “Manifesto.®”   It just might work.   For Eric, that is.   Otherwise, it is damned-stupid advice (IMHO ... you may click “downvote” and stop reading now) on how to start a company.

    First of all, many companies just should not have been started in the first place.   Great-sounding ideas are a dime a dozen.   There are all kinds of un-met potential business needs out there, and if you haven’t put it through the wringer of a true business plan and sold it to someone who’s not simply looking for the Domestic Production Activities tax-deduction (IRS Form 8903), you might be convinced that you don’t need one.   You might believe that customers know what they want before they see it.   And, in a world where nearly every mobile app costs $1.00 or less and 60% of the apps on the App Store have never been downloaded and where 95% of all apps earn less than $1,000 a month for their backers (many less than $1,000 a year), you might think that you can “rinse and repeat” your way from one “minimally viable(?)” product to another, while your backers are content to roll their dice again and again and again.

    A pinball has a much better chance.

    “A business” is a self-sustaining enterprise that produces a steady profit for its owners, sufficient to support its size at maturity.   It is almost a certainty that this cannot be achieved by writing and selling any piece of software.   The software must be in support of some other, profit-making venture, to which the software is merely a cost of goods sold (COGS).   If the software costs nothing, then revenue must be coming from some other source, and said revenue must be a stream.

    In the case of IMVU, that model is “pay to play.”   The tangible product is gift-cards.   Within the company, now that it is running, the activities that Eric describes are basically market-research and product development, and the revenue is going to continue to come in regardless.   This is not how an enterprise starts from scratch.

    The first step in starting a business is the cold, hard, reckoning of whether this business should be started.   (Usually, the answer is, “no.”)   Then, blunt and conservative financial projections.   A pre-planned exit strategy.   This is taking a calculated risk but it is not gambling.   (The starry-eyed strategy Eric describes is, again IMHO, nothing but gambling.   He knows better.)

    “Software development cost” is one of the biggest wild-cards, and the very first piece of advice that I would give to any such startup is:   “Throw ‘Agile’ down the chute with the rest of the garbage.”   An Agile team will take your $250,000 budget-allocation for software, blow it out to $500,000 and still not give you a robust, bulletproof, product that works 100% of the time.   Which is what you needed for the $250,000 and nine months that you had allotted in your business plan, and should have had, but did not get.   You need to assemble a hot-shot team of professionals who will contract to get the job done, and who will hand you the product in eight months with $50,000 to spare, and challenge you to find a bug, knowing that you won’t.   It can be done.   (I do not intend for these dollar-amounts to be actual-size.)   And your entire start-up process should be like that:   rigorous, ruthless, conservative, planned.

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 all is quiet...

How do I use this? | Other CB clients
Other Users?
Others exploiting the Monastery: (4)
As of 2017-12-16 01:45 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    What programming language do you hate the most?




















    Results (447 votes). Check out past polls.

    Notices?