More on this book
Community
Kindle Notes & Highlights
by
Eric Ries
Read between
December 14, 2020 - March 11, 2021
We gave ourselves a hard deadline of six months—180 days—to launch the product and attract our first paying customers. It was a grueling schedule, but we were determined to launch on time.
As launch day approached, our fears escalated. In our situation, many entrepreneurial teams give in to fear and postpone the launch date. Although I understand this impulse, I am glad we persevered, since delay prevents many startups from getting the feedback they need.
In retrospect, one good decision we made was to set clear revenue targets for those early days. In the first month we intended to make $300 in total revenue, and we did—barely.
The quantitative targets created the motivation to engage in qualitative inquiry and guided us in the questions we asked; this is a pattern we’ll see throughout this book.
I wish I could say that I was the one to realize our mistake and suggest the solution, but in truth, I was the last to admit the problem. In short, our entire strategic analysis of the market was utterly wrong.
We figured this out empirically, through experimentation, rather than through focus groups or market research. Customers could not tell us what they wanted; mos...
This highlight has been truncated due to consecutive passage length restrictions.
Then the second customer comes in and says the same thing. Then the third customer comes in, and it’s the same thing. You start to see patterns, and no matter how stubborn you are, there’s obviously something wrong.
We had the incorrect preconception that it’s a challenge to learn new software and it’s tricky to move your friends over to a new buddy list. Our customers revealed that this was nonsense.
We wanted to draw diagrams on the whiteboard that showed why our strategy was brilliant, but our customers didn’t understand concepts like network effects and switching costs.
We had a mental model for how people used software that was years out of date, and so eventually, painfully, after dozens of meetings like that, it started to dawn on us that the IM add-on concept was fundamentally flawed.
Our customers did not want an IM add-on; they wanted a stand-alone IM network. They did not consider having to learn how to use a new IM program a barrier; on the contrary, our early adopters used many different IM programs simultaneously.
I had committed the biggest waste of all: building a product that our customers refused to use. That was really depressing.
In other words, which of our efforts are value-creating and which are wasteful? This question is at the heart of the lean manufacturing revolution; it is the first question any lean manufacturing adherent is trained to ask.
Learning to see waste and then systematically eliminate it has allowed lean companies such as Toyota to dominate entire industries.
Lean thinking defines value as providing benefit to the customer; anything else is waste.
I realized that as a startup, we needed a new definition of value. The real progress we had made at IMVU was what we had learned over those first months about what creates value for customers.
Would it have been possible to learn the same things with less effort? Clearly, the answer is yes.
For one thing, think of all the debate and prioritization of effort that went into features that customers would never discover. If we had shipped sooner, we could have avoided that waste.
I thought my job was to ensure the timely delivery of high-quality products and features. But if many of those features were a waste of time, what should I be doing instead? How could we avoid this waste?
I’ve come to believe that learning is the essential unit of progress for startups.
The effort that is not absolutely necessary for learning what customers w...
This highlight has been truncated due to consecutive passage length restrictions.
I call this validated learning because it is always demonstrated by positive improvements in ...
This highlight has been truncated due to consecutive passage length restrictions.
Despite my claims that we learned a lot in those early months, lessons that led to our eventual success, I haven’t offered any evidence to back that up. In hindsight, it’s easy to make such claims and sound credible
We adopted the view that our job was to find a synthesis between our vision and what customers would accept;
As we came to understand our customers better, we were able to improve our products. As we did that, the fundamental metrics of our business changed.
Aligned with a superior strategy, our product development efforts became magically more productive—not because we were working harder but because we were working smarter, aligned with our customers’ real needs.
It is also the right way to think about productivity in a startup: not in terms of how much stuff we are building but in terms of how much validated learning we’re getting for our efforts.4
After our pivot and many failed experiments, we finally figured out this insight: customers wanted to use IMVU to make new friends online.
All the existing social products online were centered on customers’ real-life identity. IMVU’s avatar technology, however, was uniquely well suited to help people get to know each other online without compromising safety or opening themselves up to identity theft.
This is true startup productivity: systematically figuring out the right things to build.
The irony is that it is often easier to raise money or acquire other resources when you have zero revenue, zero customers, and zero traction than when you have a small amount.
Every time I teach the IMVU story, students have an overwhelming temptation to focus on the tactics it illustrates: launching a low-quality early prototype, charging customers from day one, and using low-volume revenue targets as a way to drive accountability.
These are useful techniques, but they are not the moral of the story.
The Lean Startup is not a collection of individual tactics. It is a principled approach to new product development.
The question is not “Can this product be built?”
The more pertinent questions are “Should this product be built?” and “Can we build a sustainable business around this set of products and services?”
In the Lean Startup model, every product, every feature, every marketing campaign—everything a startup does—is understood to be an experiment designed to achieve validated learning. This
This is one of the most important lessons of the scientific method: if you cannot fail, you cannot learn.
The Lean Startup methodology reconceives a startup’s efforts as experiments that test its strategy to see which parts are brilliant and which are crazy.
A true experiment follows the scientific method. It begins with a clear hypothesis that makes predictions about what is supposed to happen. It then tests those predictions empirically.
Just as scientific experimentation is informed by theory, startup experimentation is guid...
This highlight has been truncated due to consecutive passage length restrictions.
The goal of every startup experiment is to discover how to build a sustainable bus...
This highlight has been truncated due to consecutive passage length restrictions.
Zappos is the world’s largest online shoe store, with annual gross sales in excess of $1 billion. It is known as one of the most successful, customer-friendly e-commerce businesses in the world, but it did not start that way.
Founder Nick Swinmurn was frustrated because there was no central online site with a great selection of shoes.
He envisioned a new and superior reta...
This highlight has been truncated due to consecutive passage length restrictions.
he started by running an experiment. His hypothesis was that customers were ready and willing to buy shoes online.
Zappos began with a tiny, simple product. It was designed to answer one question above all: is there already sufficient demand for a superior online shopping experience for shoes?
However, a well-designed startup experiment like the one Zappos began with does more than test a single aspect of a business plan. In the course of testing this first assumption, many other assumptions were tested as well.
By building a product instead, albeit a simple one, the company learned much more:
It had more accurate data about customer demand because it was observing real customer behavior, not asking hypothetical questions.

