Simplify: The Lean Startup — Eric Ries

Simplify: Books shortened.

I am late to the game on this one. Eric Ries published this in 2011. I joined the tech industry last year. His ideas have started to become mainstream for good reason and reading this book has really helped me look at technology-business development culture.

  • Focus on validating learning through proving hypotheses
  • Build-Measure-Learn as quickly as possible with MVPs
  • Go see the issues for yourself — see customers and use the product
  • MVPs are meant to be shit
  • Concierge MVPs seem bad but aren’t
  • Vanity metrics will kill you suddenly; establish and measure key metrics
  • Cohort analysis on key behaviours can save you
  • Pivots require courage and are tricky
  • Periodically have pivot or persevere meetings
  • There are loads of pivots
  • Small batches (of work) work best
  • Stop everything for errors — it can reduce errors
  • Engines (methods) of growth
  • Sticky growth — the minimum amount of growth
  • Viral growth — why 1 customer referring 1 friend isn’t good enough
  • The “5 whys” help you find issues that you can fix
  • Cross functional teams are the best
  • How to win with cross functional teams
  • Productivity can stop success
  • Vanity is lying to yourself

I will explain these further below.

Point 1: Validated Learning

Success is not delivering a feature; success is learning how to solve a customers problem

Validated learning is target all teams should have in developing products. Everything should revolve around an idea we have about the customer and and we should view progress as validating or throwing out that idea about the customer.

Kodak had two hypothesis about their customers when they first built online shared galleries for photos:

  • People want to create sharable galleries
  • People’s friends would want to interact with them and upload photos

With this information they went and tried to validate this. Customers gave their feedback on a simple “embarrassing” proof of concept (PoC) and customers responded with features they would like to see. Most of these were ideas the team had already had. Was this a waste of time? No. Now the team know what were the priorities to build, what could be removed or pushed back, what needed better design focus and they had verified customers would use and want the service. This was all done immediately, not after the development work had been poured over.

Validate the key business assumptions, validate growth and value hypothesis and validate smaller more tangible features.

Point 2: Minimise the loop

Success is in minimising the time in the loop. The more you learn about the customer’s wants the better. If you can only do some of the loop you need help.

Credit: Eric Ries — SlideShare

Point 3: Go see for yourself — Genchi Gembutsu

Yuji Yokoya became chief engineer of Toyota Sienna (popular Minivan in North America). He went to see how people use the cars by hiring many minivans and traveling around North America — 53,000 miles in total, meeting fellow minivan users along the way.

He came back with the insight that parents buy the car but the kids own it. He built that thinking into the design and grew the sales by 60%.

Point 4: MVPs should be shit

A Minimum Viable Product is just to demonstrate and test a hypothesis (validated learning). Dropbox was a video with little technology but just an idea. They grew their waiting list from a hacked video showing the idea 1500% in a night.

Point 5: Concierge can be king

By normal metrics a concierge MVP isn’t great — two highly skilled and salaried persons working on serving one customers every needs for a tiny return. By a validated learning perspective, every action they do is provided with immediate feedback to measure and learn from. With this knowledge the skilled people can slowly begin to automate the tasks they know the customer values.

Point 6: Vanity Metrics will kill you

Ideas and designs will always change behaviour. We can measure those changes in behaviour but make sure they measure what you think they do.

Take two start ups. One startup has a clear baseline, a hypothesis of how to improve it and experiments they want to test the hypothesis with. The second startup debates what is best, implements a few and celebrates the increase of any number which they assume there must be a link between. One will win.

Product progress must yield business results otherwise we need to pivot.

Don’t use volumes; use percentages. For example, want to know if your product is improving, do cohort analysis.

Point 7: Cohort Analysis

Analyse behaviour by comparing it to the previous cohort of users.

Split the monthly new users and track their behaviour (ie. visited site, clicked once, clicked 5 times, paid) as a percentage. It stops arguments like “we had more 1,000 X this month” without know what caused this and how that related to the quality of the product. Now you can say last month X% of new users paid now Y% do.

Point 8: To pivot is to have courage

Without a clear hypothesis on what you are doing you can’t fail and hence you can’t learn. Be scientific; else you will convince yourself you are right.

If an MVP doesn’t convey everything you want, only test what it does show. Small incremental learnings are better than one large MVP getting unclear feedback. Large MVPs are work done at risk.

Be willing to fail regularly — not once at large.

Note also some high profile entrepreneurs may suffer here through fear of damaging their profile.

Most people will say they wish they did it sooner.

Point 9: Pivot or Persevere

Eric Ries recommends regular “Pivot or Persevere” meetings with every team member and outside advisors.He suggests every month or two.

This could be applied to features, product, business model, the startup’s engine(s) of growth (explained later) or the initial idea itself. There is a catalogue of pivots.

Point 10: Catalogue of Pivots

  • Zoom in — 1 feature becomes the product
  • Zoom out — product becomes a feature
  • Customer Segment — change who you serve
  • Customer Need — solve a different problem
  • Platform — allow 3rd parties to jump onboard you service
  • Business Architecture — switch between high margin/low volume or low margin/high volume
  • Value Capture — typically how do you get paid (subscription, one off, etc.)
  • Engine of Growth — explained later
  • Channel — how you deliver your product/service
  • Technology — would it be better with new technology?

Point 11: Small batches win

A.K.A single piece flows in lean manufacturing

Batches are the number of elements that go from one location to another. Eric Ries gives the example of a father racing his daughters to make Christmas Cards. Intuition says write all the cards, address all the envelopes etc, etc. Repetition is efficient. Lean says the opposite.

Intuition doesn’t account for sorting, checking (the right card to the right envelope), moving etc. Individually total time making the cards may be lower but the time to do it all may not — we want the whole process efficiency to be higher not individual elements.

Also small batches can be more flexible with failure. Say the envelopes don’t seal properly, this is noticed immediately and no extra work is required in pulling envelopes out of cards and rewriting them all. This is why Toyota strongly pushes small batches in its manufacturing.

Point 12: Andon cords

Toyota invented lean manufacturing basically and the lean startup borrows its ideas in places. That is why Toyota is mentioned a lot. Toyota also invented the Andon cord, which they have now retired to the dismay of some lean enthusiasts.

Andon cords can be pulled by anyone on the manufacturing line which will stop production to allow an investigation. This works because they work in small batches.

IMVU (Eric Ries co-founded startup) took this principle. It is an immune system for their product. If you fail any tests of the immune system it reverts your change, alerts people and blocks further changes until it is reviewed and root cause analysis is performed. This is called continuous deployment. It is essential for a digital product.

You may ask why Toyota has got rid of the cord. They have buttons now instead of an actual cord.

Point 13: Engines of Growth

These are methods of sustainable growth:

  • Word of mouth — Your customers are your advertisers
  • Side effect of product usage — Customers involve other future customers
  • Advertising (* so long as it is sustainable — ie. cost of acquisition doesn’t outweigh revenue)
  • Repeated purchase

Point 14: Is your growth sticky?

“If the rate of new customer acquisitions exceeds the churn [leaving] rate the product will grow”.

You want compounding growth. If it isn’t you may want to pivot.

Point 15: Is your growth Viral?

If 1 in 10 customers recruit another customer your growth rate is 0.1 or 10%.

If 10 in 10 recruit your rate is 1 or 100%.

It is only viral if growth rate is more than one.

Start with 10 people. If you had 9 in 10 people refer a friend you would end up with around 250 by the end of 6 weeks. If you had 11 referrals from 10 customers you would end with 408. If you had 12 referrals you would have 515.

By getting 3 (comparing 9 to 12 referrals) more referrals from your 10 customers you double your customer base growth. This is virality.

Point 16: Root cause analysis with 5 whys

When there is a problem ask why 5 times. “This broke.” “Why?” “This happened” “Why” “Well because of this” “Why is that happening” “Well that”.

You get the idea. Look at the underlying problem and then fix it.

Point 17: Cross Functional Team

Putting everyone in front of customers is not wasting time. It decreases build-measure-learn cycle times.

Don’t have some people seeing customers, creating ideas and coming back to tell the team. Everyone should be involved in everything.

This can be complex. Devs may want to just dev. PM’s (or others) may ask what they should do then, etc etc. That behaviour only sacrifices learning on account of individual efficiency.

Now that everyone is full involved, communication should be full open.

Point 18: Sandboxes

So you have the team but are there any rules in the fast moving, customer focused, startup environment? What about in a larger corporate environment?

  1. Allow any team to run an experiment but they must complete it
  2. No experiment can be longer than a few weeks
  3. You can only affect a small portion of customers
  4. 5–10 metrics must be defined and evaluated
  5. Any project within the experiment must be measure with the same metrics
  6. Monitor the metrics constantly. If something bad happens kill and undo the experiment.

Point 19: Productivity isn’t excellence

Most of us will feel best utilised when we are productive. We work best when we work. No surprises. “That meeting was a waste of time” is said daily.

Are meetings a waste of time? I don’t doubt some are but not all. Otherwise we wouldn’t do them.

Individual efficiency is what we are protesting typically. Individual efficiency isn’t what leads to profit, growth and success. It is needed at points but in a lean startup the goal is learning and individual productivity doesn’t address that.

Focusing on only one aspect of the build-measure-learn isn’t accelerating your time through it. Make sure you teams know this.

Point 20: Don’t lie to yourself

Projects are greenlighted on intuition, not facts.

That is fine, but teams should be building the vision to reality, not providing life support to the vision. Life support is playing “success theatre”.

Anytime failure is justified as learning it should be thoroughly tested not accepted. It is at risk of pseudoscience.

Be rigorous. Second guess success.

Founder of EveryHour.xyz and Product Owner @ dunnhumby; just genuinely interested in a lot of things. Built racecars, built electronics, now building software

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store