The Lean Startup Methodology


Authors Note: All frameworks have moved to a new home at Strategy Umwelt. Please join me at this new platform for a revised list of mental models, strategy frameworks and principles


The Lean Startup is a business approach coined by Eric Ries that fundamentally aims to change the way that new companies are built and new products are shipped.

(Check out the book here).

At its core it is built upon three key areas:

  1. Iterative product releases with extremely fast cycle times
  2. Validated learning to focus on what customers want
  3. A scientific approach to decision making

This allows the output of shortened product development cycles, measured progress, and input of valuable customer feedback (observing behavior, not directly asking).

Organizations can design their products and services to directly meet the demands of their customer base without requiring large amounts of initial funding or expensive product launches that may fail. Waste spending and risk are massively reduced.

Originally designed for high-tech companies, the philosophy has now expanded out to include any individual, team, agency or company looking to introduce new products or services into the market.

Background

Ries developed the Lean Startup methodology through his direct experiences as a startup employee, founder and advisor. Through success and failure (and especially failure), he began to highlight the biggest mistakes made by these emerging organizations.

In the twentieth century, a good plan, a solid strategy and thorough market research were often indicators of likely success. The problem with a startup (and indeed a lot of businesses right now) is that they do not yet know who their customers are or what their products should be - as startups are essentially a search for a viable business model, there is too much uncertainty for accurate forecasting.  

Failure was the result of having too concrete a vision. It did not accurately represent consumer demand, and assumptions were not validated. When a product finally launched after a huge amount of investment, it ended up being something customers either didn’t want or wouldn’t pay for.

Ries calls this “achieving failure” - successfully, faithfully, and rigorously executing a plan that turned out to be utterly flawed.

A new methodology was required to address this.

Origins

The Lean Startup takes its name from the highly successful lean manufacturing philosophy developed in the 1980’s at Toyota by Taiichi Ohno and Shigeo Shingo. This thinking radically altered supply chain and production management, leveraging the knowledge and creativity of individual workers, shrinking batch sizes, just-in-time production and inventory control, and acceleration of cycle times.

In this system, any expenditure of resources for any goal other than the creation of value for the end customer was considered wasteful, and therefore needed to be eliminated.

In particular, it utilized kanban, a process of strategically placing small stockpiles of inventory throughout the assembly line as opposed to storing full stock in a centralized warehouse. Kanban provided the production workers with the necessary inputs to production as they needed them, in doing so reducing waste while increasing productivity.

They also famously employed a rip-cord system throughout the factory. This allowed any employee throughout the process to pull the cord and halt production if they identified a mistake, ensuring the least amount of time was expended in preventing a faulty product.

It also included a focus on maintaining close connections with suppliers in order to understand their consumers desires, keeping their ear to the group so they could satisfy customer wants and needs as opposed to largely gut decision making.

Validated Learning

The Lean Startup seeks similar goals - eliminate wasteful practices during the product development phase so that startups can have better chances of success without requiring large amounts of outside funding, elaborate business plans, or a perfect product.

All businesses have a vision. To achieve that vision, they employ a strategy (a business model, product road map, point of view on competition, ideas about customers etc). The product is the end result of this strategy.

While vision doesn’t change, the strategy must be flexible. This is achieved by employing Validated Learning - conducting frequent scientific experiments to test each element of the vision, and employing continuous deployment strategies.

The Lean Startup is primarily about assessing the specific demands of consumers and how to meet that demand using the least amount of resources possible. Ask yourself which efforts are value-creating, and which are wasteful?

Lean Startup Strategies

Every product, feature or marketing campaign within the Lean Startup model should follow the scientific method. This is achieved through what is called the Build-Measure-Learn feedback loop.

Build-Measure-Learn

This involves turning ideas into products, measuring how customers respond to those products, and then learning from the results (pivot or persevere). Success is derived from focusing on accelerating this feedback loop as much as possible.   

A true experiment begins with a hypothesis with predictions about what is supposed to happen. This is then tested empirically to determine if the hypothesis was in fact correct.

The Build-Measure-Learn loop therefore requires an acceptance of failure. Failure should only be viewed as a negative if it did not result in learning something fundamental to the business.

Build: The Minimum Viable Product

The two primary assumptions in startups are a value hypothesis or a growth hypothesis.

A value hypothesis asks whether a product or service really delivers value to customers once they are using it. A growth hypothesis asks how customers will discover the product or service - generally our early adopters.

In both of these cases, success is not derived from delivering a feature - it is derived from learning how to solve a customer problem.

So how can we test these assumptions? Ries offers up a solution in a Minimum Viable Product (MVP).

An MVP is a version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort. The goal of the MVP is to test the stated fundamental business hypothesis and to help entrepreneurs begin the process of learning as quickly as possible.

It is important to highlight that this isn’t just to answer product design or technical questions. It should be testing a fundamental question that the entire business hinges on.

MVP’s can range from extremely simple smoke tests (such as an advertisement or a fake door) through to complex early prototypes with missing features. The rule of thumb here is when in doubt, simplify - remove any feature, process or effort that does not contribute directly to what you are trying to learn.

Don’t be too concerned about a lack of polish. Early adopters are often suspicious of something that is overly shiny and worked on - if it’s ready for everyone, what’s the advantage of being early?

Worried about branding risk if you're in an established organization? Take a learning from the Innovators Dilemma and launch the MVP under a different spin off brand name or stealth company.

Measure: Innovative Accounting

As we build new organizational methodologies, we require new accounting methods. This involves moving away from traditional and outdated metrics in favor of new milestone measurements and prioritizations - and then confronting the hard truths these assessments reveal.

After creating an MVP and measuring results we achieve a baseline.  From there, experimentation switches to “tuning the engine” - targeted hypothesis in product, marketing or other initiatives to determine incremental growth improvements to this baseline. If it improves, keep it, if it doesn’t, throw it away.

Cohort Analysis

Traditional measurement analysis in established businesses often falls back on looking at cumulative totals - gross numbers such as total revenue or total number of customers. However this often fails to deliver actionable insight or can disguise real problems.

A cohort analysis is our solution. This is a subset of behavioral analytics that breaks users down into cohorts, or groups with common characteristics or experiences that can be tracked over a defined time span.

Vanity Metrics

We also need to ensure we are measuring data that is actionable, accessible and auditable.

One of the biggest dangers is an unhealthy focus on vanity metrics - a measurement that may look good on paper, but hides the truth.

Here is a marketing example. Say the business has demanded that you get more customers through your e-commerce site, so you introduced a campaign with a heavily discounted offer.

Suddenly you get a huge spike in traffic, and everyone pats themselves on the back. But a proper cohort analysis may show a different story - more customers came through but due to the discount they ordered much less than normal, so revenue actually dropped. Worse, these value seeking customers never revisited. The vanity metric of increased traffic was hiding much deeper problems.

Check out the paired metrics model for some further insights.

Split Tests

Split tests or A/B tests are experiments where different versions of a product are offered to customers at the same time, and then measured.

The goal of the split test is to observe changes in behavior between the two groups and to record the impact of each version to an actionable metric.

For split tests to work they need to be performed at the same time in order to remove the influence of external events - for example if they are shown on concurrent weeks there may be outside factors affecting the results which will skew the data. Think scientific method and use proper control mechanisms.

Split tests really are one of the best methods to experiment with “tuning the engine” and measure from the baseline. From this analysis we can decide to pivot or persevere.

Learn: Pivot or Persevere

As we measure and get feedback, we should be driving incremental growth and applying learnings to restart the loop. If growth is stalling or fails to materialize, it may be time to Pivot.

Pivots are a structured course correction designed to test a new fundamental hypothesis about the product, strategy, and engines of growth in a business - all the while keeping a foot rooted in the learnings that have been gathered so far.

So don’t throw the baby out with the bath water.

Businesses that cannot bring themselves to pivot or change their ways based on feedback from the market could find themselves in the land of the living dead - neither growing enough or dying, consuming time and resources but not moving ahead. It takes courage to make one, but without it your days are numbered until money dries up or a new player disrupts what you are doing.

Continuous Deployment

The last part of the Lean Startup is the idea of batch or continuous deployment. This refers to a process where any code that is written for a website or application is immediately deployed into production. This greatly reduces cycle times, and allows immediate feedback from real customers on code changes and features.

Much like Agile Development, this has courted some controversy, mainly due to the introduction of risk. For example customers may be exposed to all manner of bugs in the system. Ries argues that the positives far outweigh the potential problems with this approach.

A large number of recent startups have undertaken continuous deployment with huge success - see some of the case studies below.

Detractors

Zero to One

Peter Thiel makes a point of calling out the Lean Startup methodology in his book Zero to One. This is less a direct criticism and more trying to frame the Lean Startup as what it is - a methodology, not a goal.

His main problem is that would-be entrepreneurs are told that nothing can be known in advance - you need to listen to what customers say they want, make nothing more than an MVP, and iterate to success. While this has resulted in some interesting mobile apps that do small tasks (a local maximum), it has less power in developing big 0 to 1 game changing idea or large scale business (a global maximum).

Thiel uses Apple as an example. Unlike what most people think, the Jobs legacy has nothing to do with product aesthetics. The greatest thing Job’s designed was his business.

Apple imagined and executed definite multi-year plans to create new products and distribute them effectively. Forget MVP’s - Apple’s success was derived from careful long-term planning, not by listening to focus group feedback, launching many experiments or copying other people’s success.

Keep this in mind if you approach the Lean Startup methodology - it may be wise to balance short term goals with long term planning to achieve optimal success for your venture.    

Google Ventures

Braden Kowitz at Google Ventures echoes a similar sentiment in an article about what fuels great design. Organizations can often get stuck in the excitement of making new things that they fail to take a breath and stop and listen to customers which can actually slow things down.

Being focused on getting an MVP or product out as fast as possible will show you how many customers are using this specific product, but what it won’t show you are the deeper reasons behind why they are using it. It may be necessary to validate this through other methodologies.

Their solution is to undertake User Research up front, and at key times during the validation process. They echo the sentiment of not asking customers what they want (as they likely don’t know what they want) but rather to try and determine what they like or dislike about other products, and observe when they get stuck or confused of using them.

By understanding a customer problem, the initial product may be much better validated before it materializes as an MVP, meaning that things may move faster as there will be less fundamental pivots from an inferior base.

Remember, “learn early and often” is much better than “launch early and often”.

Quick Case Studies

MVPs

Zappos

Zappos wanted to test the theory that people wanted and would buy shoes online. But their biggest concern was that building a massive e-commerce website with a huge database of inventory could destroy the business if their hypothesis wasn’t validated.

The solution was to create a much simpler MVP website to test their theory. They approached local shoe stores, and took pictures of their inventory, and posted them online. If a customer bought the shoe, they would buy it full price from the store and send it to the customer.

Through this process, the hypothesis was validated and the full site was built - which then sold to Amazon for a billion dollar purchase.

Dropbox

The Dropbox team had a big ambition - they wanted to revolutionize online file sharing. This posed serious technical hurdles and complexity, with the primary problem being seamless synchronization across the full gamut of computer platforms and operating systems.

File synchronization posed a thorny issue. What they found was that it was a problem that most people didn’t realize they had, so they didn’t realize they needed a solution. A classic example of why asking customers what they want won’t tell you what to build.

The solution was to create a simple MVP video that explained the problem and solution and allowed users to sign up for the beta. Seeded across the web, it drove 70,000 signups overnight after launch, and paved the way for it to be the powerhouse it is today.

The original demo video.

Split Tests

AirBnb

AirBnb built its own A/B testing platform, which has been integral in maximizing their bookings. They write a great post with details on their process.

A/B Test Platforms

Facebook, Etsy and Cloudera have all open sourced their A/B test platforms, which have been integral to their growth and success.

Experimentation

OK Cupid

The dating site constantly experiments on its users, and keeps a blog dedicated to explaining the tests and results.

Continuous Deployment

Google & Hubspot

Google and Hubspot have managed to speed up their product development without losing control. The secret - a lot of automated testing, elimination of middle management, and small specialized cross functional teams.

Amazon

The average time between code changes at Amazon is a whopping 11.6 seconds, with 1,079 max deployments in a single hour.

Non-Startup Examples

Capital One

Capital One managed to climb to the top of the banking world by their focus on constant test, learn and innovation strategies.

Procter & Gamble

P&G have focused on training their staff in design thinking to operate more scientific and lean. The result was more profits.


This post continues my series on mental models.