2/21/2013 - 10:04 PM

The Lean Startup - Notes, Quotes, and Choice Snippets

The Lean Startup

Characteristics of a lean startup:

  1. Uses "platforms enabled by open source and free software."

  2. Agile development

  3. "Ferocious customer-centric rapid iteration, as exemplified by the Customer Development process."

My belief is that these lean startups will achieve dramatically lower development costs, faster time to market, and higher quality products in the years to come.

Validated Learning About Customers

I don’t think revenue is in and of itself a goal for startups, and neither is profit. What matters is proving the viability of the company’s business model, what investors call "traction." Demonstrating traction is the true purpose of revenue in an early growth company. ... Traction is not just important for investors. It should be even more important to the founders themselves, because it demonstrates that their business hypothesis is grounded in reality.


Most importantly, they have lots of data about the unit economics of their business. They know how much it costs to bring in a customer and they know how much money they can expect to make on each one.


None of dollars, milestones, products or code can count as progress. Given a choice between what a successful team has learned and the source code they have produced, I would take the learning every time.

What Is Customer Development?

There’s so much crammed into The Four Steps to the Epiphany that I want to distill out what I see as the key points:

  1. Get out of the building. ... “In a startup no facts exist inside the building, only opinions.” ... Customer development is emphatically not an excuse to slow down or change the plan every day. It’s an attempt to minimize the risk of total failure by checking your theories against reality.

  2. Theory of market types. ... There are three fundamental situations that change what your company needs to do: creating a new market (the original Palm), bringing a new product to an existing market (Handspring), and resegmenting an existing market (niche, like In-n-Out Burger; or low-cost, like Southwest Airlines).

  3. Finding a market for the product as specified. ... We have our customer development team work hard to find a market, any market, for the product as currently specified. We don’t just abandon the vision of the company at every turn. Instead, we do everything possible to validate the founders’ belief. The nice thing about this paradigm is it sets the company up for a rational discussion when the task of finding customers fails. You can start to think through the consequences of this information before it’s too late. You might still decide to press ahead building the original product, but you can do so with eyes open, knowing that it’s going to be a tough, uphill battle. Or, you might start to iterate the concept, each time testing it against the set of facts that you’ve been collecting about potential customers.

  4. Phases of product & company growth. The book takes its name from Steve’s theory of the four stages of growth any startup goes through. He calls these steps Customer Discovery (when you’re just trying to figure out if there are any customers who might want your product), Customer Validation (when you make your first revenue by selling your early product), Customer Creation (akin to a traditional startup launch, only with strategy involved), and Company Building (where you gear up to Cross the Chasm).

  5. Learning and iterating vs. linear execution. ... Startups need time spent in a mindset of learning and iterating, before they try to launch. During that time, they can collect facts and change direction in private, without dramatic and public embarrassment for their founders and investors. The book lays out a disciplined approach to make sure this period doesn’t last forever, and clear criteria for when you know it’s time to move to an execution footing: when you have a repeatable and scalable sales process, as evidenced by early customers paying you money for your early product.

Myths about the Lean Startup

Myth: Lean Startups replace vision with data or customer feedback.

Truth: Lean Startups are driven by a compelling vision, and they are rigorous about testing each element of this vision against reality. They use customer development, split-testing, and actionable analytics as vehicles for learning about how to make their vision successful. But they do not blindly do what customers tell them, nor do they mechanically attempt to optimize numbers. Along the way, they pivot away from the elements of the vision that are delusional and double-down on the elements that show promise.

Getting started with split-testing

Three guidelines:

  • Start simple. "Tackling something too complex is more likely to lead to a lot of wasted time arguing about the validity of the test. A good place to start is to try moving UI elements around."

  • Make a firm prediction. "Split-testing is most powerful when it causes you to make your assumptions explicit, and then challenge them."

  • Don't give up. "If the first test shows that your feature has no effect, avoid these two common extreme reactions: abandoning the feature altogether, or abandoning split-testing forever. Set the expectation ahead of time that you will probably have to iterate the feature a few times before you know if it's any good. Use the data you collect from each test to affect the next iteration. If you don't get any effect after a few tries, then you can safely conclude that you're on the right track."

The one line split-test, or how to A/B all the time

Sometimes customers actually prefer an uglier design to a pretty one. Without split-testing, your product tends to get prettier over time. With split-testing, it tends to get more effective.


Try measuring [your product] only at the level that you care about. Focus on the output metrics of that part of the product, and you make the problem a lot more clear.


Any product change that doesn’t change metrics in a positive direction should be reverted. Even if the change is "only neutral" and you really, really, really like it better, force yourself (and your team) to go back to the drawing board and try again. When you started working on that change, surely you had some idea in mind of what it would accomplish for your business. Check your assumptions, what went wrong? Why did customers like your change so much that they didn’t change their behavior one iota?

When NOT to listen to your users; when NOT to rely on split-tests

Maintain perspective. Listening is a means to an end, not an end unto itself.:

I remember having this problem when I first got the "listening to customers" religion. I felt we should just talk to as many customers as possible, and do whatever they say. But that is a bad idea. It confuses the tactic, which is listening, with the strategy, which is learning.

On the need for vision:

Seek out a synthesis that incorporates both the feedback you are hearing plus your own vision. Any path that leaves out one aspect or the other is probably wrong. Have faith that this synthesis is greater than the sum of its parts. If you can’t find a synthesis position that works for your customers and for your business, it either means you’re not trying hard enough or your business is in trouble.


The thing to remember about split-testing is that it is always retrospective - it can only give you facts about the past. Split-testing is completely useless in telling you what to do next.

Ideas. Code. Data. Implement. Measure. Learn.

To turn data into learning, you have to focus on the few key pieces of data the everyone agrees are important. And you have to get the decision makers and implementers to look at (and believe!) the data on a regular basis.

Pivot, don't jump to a new vision

We collect feedback for one reason only: to find out whether our vision is compatible with reality or is a delusion. ... We always seek to find a market for the product as currently specified, not conduct a focus group to tell us what the spec should be. If and only if we can’t find any market for our current vision is it appropriate to change it.

Business ecology and the four customer currencies

  • Four customer currencies: time, money, skill, and passion.

Different types of startups will be seeking to learn different things. Minimum viable product is a tactic for mitigating risk. It doesn’t say anything about which risks it should be used to mitigate. Startup founders need to use their own judgment to ask: which is the riskiest assumption underlying my business plan? In each of the ecosystem examples I gave above, the tactics of the minimum viable product are quite different. In some cases, Tim Ferriss-style landing page tests will suffice. Others require Steve Blank-style problem/solution presentations. And others require an early product prototype. The level of design required will vary. The level of engineering quality will vary. The amount of traditional business modeling will vary.


How do we know when it’s time to move from Customer Validation to Customer Creation? ... when we have enough data that shows our business ecology is value-creating and also ready to grow via a specific driver of growth.

Throwing away working code

For startups, [the] goal must be to create a rapid-iteration feedback loop that enables you to learn what customers want and will eventually pay for. Everything else, including anything that optimizes any other goal, is waste.

Cash is not king

You cannot become a lean startup by willpower alone. ... You need a process for systematically reviewing your costs and eliminating those that slow you down. ... This is why I constantly stress the need to set specific, actionable targets for new product initiatives or new feature split-tests. You cannot learn if you cannot be wrong, and vague goals are exceptionally easy to rationalize as success.

Work in small batches

  • "Software should be designed, written, and deployed in small batches."
    • "Small batches mean faster feedback."
    • "Small batches mean problems are instantly localized."
    • "Small batches reduce risk."
    • "Small batches reduce overhead."
  • "A few hours of coding is enough to produce a viable batch and is worth checking in and deploying."

Combining agile development with customer development

In a startup, rather than think of ourselves as having a marketing department and an engineering department, I now believe it's better to think of ourselves as focusing our energies on unknown problems and unknown solutions. Approaching each of them iteratively is the right thing to do. But the biggest payoff of all can be found when we combine them into one large company-wide feedback loop.

Achieving a failure

Great startups require humility, not in the personal sense, but in the organizational capacity to emphasize learning.

For Startups, How Much Process Is Too Much?

(from The Conversation - Harvard Business Review)

They just need to balance process with innovation. Companies that insist on building a world-class infrastructure before shipping a product are doomed to “achieve failure,” because they’re starved of feedback for too long. I learned this lesson first hand in a previous company. On the other hand, companies that take a “just do it” attitude without any process at all are also taking a major gamble.


Always choose the option that minimizes the total time through the feedback loop.

In other words, any change that accelerates learning is a win, and everything else is waste. This is very different from the trade-offs that need to be made in situations where the goal is to optimize for profit, margin, or growth.


You can build much faster if you don’t “waste time” measuring. That’s like suggesting you can drive faster if you close your eyes and hit the accelerator. It’s true, but dangerous

Two Ways to Hold Entrepreneurs Accountable

(from The Conversation - Harvard Business Review)

1. Establish the baseline

Start-ups should move as quickly as possible to build and deploy a minimum viable product (MVP). This is the smallest amount of work required to start learning from early adopters about whether a new product has any value whatsoever. This product will likely be buggy, have missing features, or have poor usability. In fact, in some cases the right MVP is just a landing page that describes the product combined with an offer to pre-order.


In this stage, instead of holding teams accountable to product milestones, hold them accountable to “filling in the blanks” for each input in the original model.

2. Demonstrate learning

The focus of the team should shift to improving the inputs to the model. Each iteration requires some combination of new ideas, new tests, new customer interviews, and new experiments. As the team learns, it should be able to make product changes that increase the metrics from the initial baseline.


In this stage, hold teams accountable for changes to input metrics — but only when they can conclusively show that they were responsible for those changes, and that they didn’t change just by chance (or some other external factor).

Is Entrepreneurship a Management Science?

(from The Conversation - Harvard Business Review)

Usually, new projects are measured and held accountable to milestones and deadlines. When a project is on track, on time, and on budget, our intuition is that it is being well managed. This intuition is dead wrong.

Most startups fail because they are building something that nobody wants. Enamored with a new technology or a radical new product, many entrepreneurs never find a set of customers who will buy it. Each new feature added to such a product is actually wasted effort, even if it’s done on-time and on-budget.

The Startup's Rules of Speed

(from The Conversation - Harvard Business Review)

Core Message:

As you speed up and begin to observe more chaos than you faced in the earlier days of your startup, don't slow down; instead "get more disciplined about the way [you] work, so that [your] mistakes are caused by genuine new situations and not sloppy execution."

Success leads to growth which leads to increased entropy. How will you respond?:

Every startup that achieves success eventually faces a critical moment — whether to speed up or slow down.

The startup begins to scale, and chaos increases.

The slow-down approach is characterized by the old engineering mantra: time, quality, money — pick two. ... The lean manufacturing revolution helped factories break out of the time-quality-money paradox through the recognition that trading quality for time is an illusion. Lower quality over time leads to slower production, because defects require constant rework and patching. The same thinking is allowing startups to break out of this trap, too and, in the process, actually accelerate as they scale."

Instead of responding to the chaos by adding old-school bureaucracy to slow down things down, Ries recommends speeding up:

  • Let’s get to the root cause of the specific problems we’re having, and see if we can change the way we work so that we can prevent those problems from happening in the first place.
  • Let’s be willing to have every problem under the sun exactly once, in exchange for never having the same problem twice.
  • And, above all, let’s get more disciplined about the way we work, so that our mistakes are caused by genuine new situations and not sloppy execution.

The Five Whys for Start-Ups

(from The Conversation - Harvard Business Review)

The key to startup speed is to maintain a disciplined approach to testing and evaluating new products, features, and ideas. As start-ups scale, this agility will be lost unless the founders maintain a consistent investment in that discipline. ... Being in motion is not intrinsically worthwhile. Start-ups need to maximize their speed measured in validated learning and not just tasks accomplished or energy expended.

Vanity Metrics vs. Actionable Metrics

Top Quotes:

  • "A/B experiments produce the most actionable of all metrics, because they explicitly refute or confirm a specific hypothesis."
  • "The key to actionable metrics is having as few as possible."

On designing good split tests:

A good rule of thumb is to ask yourself, "if this test turns out differently from how I expect, will that cast serious doubts on what I think I know about my customers?" If not, try something bigger.

Example Metrics:

Consider the most basic of all reports: the total number of "hits" to your website. Let’s say you have 10,000. Now what? Do you really know what actions you took in the past that drove those visitors to you, and do you really know which actions to take next? ... Now consider the case of an Actionable Metric. Imagine you add a new feature to your website, and you do it using an A/B split-test in which 50% of customers see the new feature and the other 50% don’t. A few days later, you take a look at the revenue you’ve earned from each set of customers, noticing that group B has 20% higher revenue per-customer. Think of all the decisions you can make: obviously, roll out the feature to 100% of your customers; continue to experiment with more features like this one; and realize that you’ve probably learned something that’s particular valuable to your customers.

The Promise of the 'Lean Startup'

(from BusinessWeek)

Top Quote:

The ultimate goal of a lean startup is to identify where its vision intersects with what reality can accommodate. It is neither a capitulation to "what customers think they want" nor a willful ignorance of conditions on the ground. It is a company built to learn.

Other Choice Snippets:

Parallel to this work by the “solution team” (engineering, ops and QA), there is a new kind of “problem team”—what we used to call business development, marketing, and sales—that is asking such bigger questions as: Who will our customers be? What problem does our product solve for them? How many of them are there? And how will we reach them?

The problem team is not merely engaged in a series of whiteboard exercises. They are working to validate or refute their hypotheses and then to share their findings with the rest of the company so they can be used to reduce uncertainty and further chart the enterprise’s future. Each iteration leads to a “pivot” in which the company systematically changes some part of its vision to adapt to reality.


Instead of seeing process as a synonym for bureaucracy, [the lean startup] sees it as a synonym for discipline.


The promise of the lean startup is that instead of building our companies according to myths, we can guide them with facts and the knowledge required to use those facts well. Put another way, we won’t waste our time building products or services that nobody wants.

Startup Lessons Learned 2010: Opening Keynote from Eric Ries

  • "The unit of progress for entrepreneurship is learning, not execution."
  • "In a lean transformation, question #1 is: which activities are value-creating and which are waste?"
  • "In a startup, product and customers are unknowns."
  • "Minimize total time though feedback loop"
    • Loop: ideas => BUILD => code => MEASURE => data => LEARN => ideas => ...
    • Slide w/ graphic

Customer Development Case Study: Dropbox

(from Startup Lessons Learned Conference - April 2010)

  • Reframed "launch early and often" as "learn early and often"
  • Dropbox's Minimum Viable Product: 3-minute screencast Hacker News => yielded immediate, high-quality feedback
  • Set up simple landing page to capture email addresses of interested users (i.e., potential customers)
  • Beta launch video, targeted at early adopters
  • Experimented with using paid search to attract customers
    • Result: Cost per acquisition was almost 3x the product cost
    • Theory: People were not searching for the solution that Dropbox provided; people were complacent and accepted the problem as a fact of life. "Search is a way to harvest demand, not create it."
  • Changed marketing strategy to encourage word-of-mouth
    • Referral program with 2-sided incentive permanently increased signups by 60%
    • Heavy investment in analytics, split-testing, etc. to maximize the effectiveness of the referral program
  • Recommended metrics to track: Startup Metrics for Pirates