>>Thomas Sharon: Hi everyone. Thanks for coming.
My name is Thomas Sharon. I'm a UX Researcher here. And without further ado, I would like to introduce
you to Eric Ries, the founder of the Lean Startup movement. And thank you for coming. [applause] >>Eric Ries: See, I don't know. It's hard
to know when you have an audience you don't know. It's hard to know what to say. So, some of you maybe know the blog, Startup
Lessons Learned. Anybody? Quick show of hands. OK, good. We have true new people. So, thank
you. Thank you for coming to check it out. So my name is Eric Ries. I don't really want
your undivided attention. So keep your laptops on. That's fine. And in fact, if everyone
do me a favor and take your phones out of your pockets. I mean, I'm sorry. I know I'm not supposed
to have this one, but if can turn them on. No, I'm not joking around. Out of the pockets,
please. 'Cause this is gonna be a talk. You might get bored and you might wanna tweet
amongst yourselves. Or I don't know, whatever special internal
tools you guys use. Whatever it is, please feel free. All I ask is that you use the Lean
Startup hash tag, at least if you're on Twitter. Okay. Is that fair? I won't tell anybody.
Don't worry. I'm in New York because I'm writing a book.
So one of things you do when you're writing a book is you have to go to tell as many people
as possible that this book is coming out. It'll come out in the fall. I thank you in
advance for preordering it. You can do so at lean.st. That's my life now is as a professional expert
selling books, which is a far cry from how I started, which is as a programmer writing
code. So I'm one of those people that grew up writing
code. I used to write code for a living, which is a job I knew really well and understood.
I was pretty good at it. And then, I started doing startups and I started
to have to manage people who wrote code for a living. I knew that slightly less well. And then I was managing people who managed
people who write code for a living. And now, I am this professional expert. And
so I advise people who manage people who manage people who write code. So I've become very
far removed from the actual work of product development. But that journey has taken me from just writing
code to doing this because I actually think the way that we organize new product development
is basically wrong. And that most of the energy that we are investing into what is called
'entrepreneurship', when it's two guys in a garage, or 'disruptive innovation' or something
else buzzwordy when it's done inside a big company, is wasting a lot of people's time.
And I think we can do something about it. So that's what I wanted to talk to you guys
about. Thanks for coming. So anyway, and this book, of course, will
be available in stores everywhere in the fall. So, if you read the book, you will learn five
principles of the Lean Startup. And we'll go through them today. And I wanna invite you to ask questions either
on Twitter, if you're not feeling that courageous, or interrupt me at any time or we'll have
time at the end. All right? So, entrepreneurs are everywhere. The first
thing is, especially in an audience like this, I wanna be clear, that entrepreneurship is
not just about two guys in a garage eating Ramen noodles. In fact, what makes you an
entrepreneur is not what kind of noodles you eat, but the context in which you operate. And as I've been travelling around talking
about Lean Startup, what I have learned is that there are entrepreneurs in all kinds
of places you wouldn't necessarily expect. And we have a lot more in common than people
realize, because entrepreneurship is management. But not the kind of general management we're
teaching MBAs and that we have studied for the last hundred years, something fundamentally
different. It is management of a kind of work that is measured by validated learning, rather
than just making stuff. We accelerate that learning through something
called the 'build-measure-learn feedback loop'. And then we measure and hold entrepreneurs
accountable using a new accounting system called 'innovation accounting'. Now, I apologize. You came to a very, I'm
sure, you saw the signs up here like, "Ooh, an exciting talk about entrepreneurship and
startups and that's gonna be cool." And what did you get? You got management and accounting, which are
perhaps the two most boring topics on Earth. So if anybody wants to leave now, I won't
be offended. It's OK. Because the truth is, what do people know
about entrepreneurship? I feel like -- who saw 'The Social Network'? OK. Right. I feel
like that's probably the best modern example of the entrepreneurship story we're all used
to. And you see this in magazines and you see
it in 'The Social Network'. I noticed last night that the story, 'Ghostbusters' -- remember
'Ghostbusters', the movie? It's an entrepreneurship story. They start a business. They, Dave,
everything’s the same. It's like the same plot structure as 'The Social Network', believe
it or not, except it has a Stay Puft Marshmallow Man, which is awesome. In these entrepreneurship stories, what happens?
It's a story in three parts. Act One: The plucky protagonist, his character,
his character flaws and how he came up with his amazing idea. Act Two: What I call the photo montage. It's
usually about two minutes long. It goes from "they finally get the thing to work". Then
they're writing on whiteboards and drinking some beer, pounding on some keyboards. And
then they get their first customer. And then that's pretty much it. No dialogue or anything
in the photo montage. And then Act Three: Now that we're on the
cover of magazines, how do we divide up the spoils? And who's in charge? And who's in
Who's Who? And how do we deal with the EPA and all that stuff? For fans of 'Ghostbusters'. What I think is really interesting about these
stories about entrepreneurship is that 95 percent of the time of the movie is spent
in Acts One and Act Three, even though in real life, all of the important work of entrepreneurship
happens during the photo montage. But the problem is, for a story-telling point of view,
the photo montage, even though it has no dialogue and only lasts two minutes, is it's unspeakably
boring. What do we do as entrepreneurs that actually
makes a difference? We spend our time trying to figure out which customers to listen to
and who to ignore, how to product-prioritize product features. I mean you guys, how many product prioritization
meetings do you go to? It's not exactly the stuff of movies. It's unbelievably boring. And how do we hold people accountable? How
do we measure to figure out if we're actually making progress or building something that
nobody wants? See, watching somebody pretend like they don't have anxiety that their vision
is wrong, is not very good for movies. But that's what most entrepreneurs do. And so, we're gonna have to talk about stuff
like management and accounting, 'cause it's time to go inside the photo montage and try
to figure out what can we do to make the actual work of entrepreneurship more effective. So,
entrepreneurs are everywhere. My goal, my mission in doing this whole Lean
Startup thing has been to try to put the practice of entrepreneurship on a more rigorous footing.
And so, I started out with a definition. Here's mine: What is a startup? "A human institution
designed to create something new under conditions of extreme uncertainty." So I think the most important part of this
definition, and for our purposes today, a very important part of our discussion is what
it excludes. It doesn't say anything about what the size of your company is. It could
be five people, 5,000, or 50,000. It really doesn't matter. It doesn't matter what sector of the economy
you work in. It really doesn't even matter what industry you're in. If you fundamentally are operating with extreme
uncertainty about who is your customer, what product do they actually want, and how do
we build a sustainable business, then you are an entrepreneur. And when I work with
large companies, one of the things I have been trying to do, is to get them to adopt
entrepreneurship as a job title. Entrepreneurship is a career. When you become
an entrepreneur, you are no longer an engineer. You are no longer a marketer. You are no longer
a UX designer. Whatever it is you used to do, all of a sudden now, you have a different
job title and you've entered a new career path. But unfortunately, we don't get the memo that
tells you that. So, it can be a little bit confusing. That's all a fancy way of saying a startup
is an experiment. What I mean by "experiment" is not just like let's ship it and see what
happens, OK? That's not science. If you just put some compounds in a beaker and heat it
up, you might look like you're doing science. But unless you have a hypothesis that you're
trying to test, you have theory, it suggests which experiments are gonna help you and then
you make specific predictions, then, fundamentally, you're not conducting an experiment. And we mean, in a Lean Startup model, "experiment"
in the scientific sense. We're trying to create a science of entrepreneurship that will help
us to stop waste people's time, because that's what we're doing on an industrial scale. And you guys know. Anyone's who's worked on
new products knows that most of them are doomed to failure. And when you get at the end of
that product -- I mean as an engineer, I kept having over and over again the experience
of working on amazing technology that is today sitting on a shelf or worse, that fundamentally
nobody is using. And I kept looking for more and more technical solutions to that problem.
I thought, "If we could just get the right development methodology, if we just had the
right amount of unit tests or the right this or the right that, then we could stop that
happening." But the biggest waste that product development
faces today is not building things inefficiently, but building things very efficiently that
nobody wants. And I brought a demonstration. We all know that most startups fail. Who remembers
Web 2.0? Remember Web 2.0 when that was really cool? At the height of Web 2.0, 2006, a graphic
designer put together this graphic. Have you seen this before? This was the like the logos
of all the incredible Web 2.0 companies that were gonna change the world. And in just three years, in 2009, a different
graphic designer was feeling a slightly different set of emotions when they put together this
graphic. Our three year report card in Web 2.0. I mean, the blood red Xs, these are all
companies that are just dead. I think for our purposes today though, a much more important
part of that chart to look at are the green circles. I won't point at any of them in particular,
but some of those green circles are supposed to be the success stories of Web 2.0. But
for this chart, what that means is there are companies that were acquired by a larger company,
including this one. And listen, I'm all for people making money. So when a company gets acquired by another
company, usually investors and the founders make some money and that's all good. But my
question is which of these companies are actually success stories? Success stories by the higher
definition, not of "did anybody make money?" But rather, which of these companies succeeded
in living up to the aspirations, dreams, time, talent, and energy of the founders and their
investors? And more importantly, their employees. See, look, we all know that when big companies
buy startups, at least half the time, they die afterwards. So we buy something for hundreds
of millions of dollars. And then we wind up selling it three years later for tens of millions
of dollars. That's not supposed to happen. In general
management, that doesn't happen. When you buy an asset, it depreciates in a predictable
way. But when big companies buy startups, it doesn't happen exactly like it’s supposed
to. And I think the problems that corp-dev departments
have when deciding how to buy startups and which startups to buy and then how to integrate
them into the parent company, are the exact same problems that internal innovators who
are trying to create brand new startups inside big companies have. And they're the exact
same problems that venture-backed entrepreneurs have with their investors. All of us lack a theory of entrepreneurship
to guide our behavior and so we're falling back on tools and methods that are not appropriate
to entrepreneurship. That's my belief. So, I don't think it has to be this way. See, it's one thing if startups were failing
because they were taking too much risk. If one of these companies was working on teleportation
and then it turned out to be too hard -- we couldn't quite get the technology for quantum
entanglement like we thought -- I accept that kind of failure; that happens. But I chose Web 2.0 for my demonstration,
especially for you guys. You know. There's not a single company on this chart where you
would say, "Boy, I wonder if that can be built." Right? "Geez, I wonder if that new social
network -- is it possible to build it?" We all know. Software companies, we can build
anything we can imagine. Think about that for a second. The dominant question of our time is not can
it be built, but should it be built. And the issue is can we build a sustainable business
around a particular product? So, the future of our society, our economic growth in the
future, the GDP growth of industrialized countries in the future is going to be dependent on
the quality and character of our collective imaginations, which I think is a very strange
place to be. That is really different than the kinds of
economic problems that general management was designed to solve in the 20th Century.
Now, most of my startups have failed. So I know that's not how you're supposed start
one of these talks, like, "Hi. I'm a professional expert and I have had more failures than successes.
So you can be just like me if you'll follow my advice." So, I'm sorry about that. But those of you
who spend any time around entrepreneurship know the truth that where there's startups,
there's a lot of failure. And it has to be somebody's fault in a talk like this and obviously
it shouldn't be my fault 'cause I'm the expert. And preferably, it should be the fault of
someone who's dead so that they can't argue. So I chose this guy. [laughter] This is Frederick Winslow Taylor. He died
in 1915, which is very handy for the purpose of this talk because it means he can't talk
back. So, sorry, Fred. Fred Taylor invented something called "scientific
management" in the early 20th Century, which today, we call "management". See, people don't
really remember Fred Taylor. And those who've studied scientific management
in school probably remember him for some of his outdated and really ridiculous ideas,
like time and motion studies or the idea that a worker is basically just an automaton and
should be told what to do. The reason we don't give Fred Taylor the credit he deserves is
because he invented things that to us are so obvious, we can't imagine them ever having
been invented. It doesn't make sense. Like, everybody knows that work should be
done as efficiently as possible, right? And that we should treat work like a system and
that we should have managers organize that system. That's just plain common sense. And my favorite, Fred Taylor, invented something
called "The Task and Bonus System", which we just call "tasks". The idea was if you
want to do a large project, the best thing to do is decompose that project into a series
of individual tasks, assign those tasks to functional specialists. And everyone just
does their part knowing that if everybody does their part well and everybody else does
their part, the whole will actually work out like the manager said. And here's the best part. If you do your task
particularly well, better than expected, you should be paid a bonus rather than being penalized.
What could be more obvious? Except in the 19th Century, the way work was organized is
that if you did your task better than expected, you were penalized. [pause] Why? Because that showed a lack of integrity.
You obviously could have done it better before. But you didn't. So that proves that you're
a liar. It gets worse. Not only are you a liar, but
what about all your compatriots, your coworkers, who do the same task the old, slow way? They're
liars, too. All of you have been lying this whole time and you should all be penalized. Imagine working in a factory where if you
can come up with a better way to do your repetitive job, not only would you be penalized, so would
all your coworkers. Can you imagine the culture that would grow up around such a thing? That
everybody is working really hard to make sure that nobody ever does anything in any way
better because then we'll all be in trouble. That phenomenon was so widespread in the 19th
Century, they had a name for it. They called it "soldiering". That all the workers were
intentionally soldiering on, trying to do work as slow as possible so that nobody would
get in trouble. Now, we laugh when we think about that kind of thing happening in a factory.
Because to us, the way that we manage physical products, and just all regular general management,
is light years beyond what was possible in Fred Taylor's day. But they also believed something else that
I think maybe you'll find a little bit familiar. They had this idea that what basically was
the great man theory of work. That fundamentally, the job of managers was to select the best
possible person. Of course, this is the early 20th Century. So a great man of upstanding character with
good integrity, the right attributes, put them in the job and fundamentally leave them
alone. Because if you just trust a great man to figure out what needs to get done, they
would figure it out. Does that sound familiar? We still manage
knowledge work and innovation work that exact same way. We still believe in the great man
theory of entrepreneurship and we believe it especially about the great man software
developers. And yet, when we look back on this time, decades
from now, I think we're gonna laugh at the kinds of things that we do when we need to
develop new products. It will seem as antique to our future selves as Fred Taylor feels
to us. Because I think that entrepreneurship is management. It's just a different kind
of management than the general management that has been practiced since Fred Taylor's
day. So, we need to create a different paradigm
for management that's not better than general management. It's not worse than. It's simply
a parallel discipline specifically for entrepreneurship. And so, here's my attempt. The first concept in the entrepreneurial management
toolbox is this thing we call the "pivot". Who's tired of hearing about pivots already?
Anybody? OK, I apologize. In Silicon Valley, everybody's hand is up, by the way. This word
has become ridiculously overused. Believe it or not, I saw this just the other day in
the New Yorker magazine. Can you read this caption? "I'm not leaving you. I’m pivoting
to another man." [laughter] So this word started in Lean Startup and then
it became this monster of an overused, overhyped concept. Typical for Silicon Valley. We went
from not knowing what the concept was to being tired of hearing it and claiming that it's
overhyped, without having passed through the intervening stage of ever learning how to
use it correctly. That's just – that's how we operate with the hype-cycle in Silicon
Valley. So, I'm sorry about that. I really didn't intend. But you can't understand anything about entrepreneurship
unless you have a word for this concept, because it is the universal constant of all successful
startups. If you can get the real story of what actually happened in the early stages
of a company, you will find out that successful startup founders do not, do not, have better
ideas than the failed ones. Contrary to what you see in the movies, most startup founders
of successful companies had ludicrously bad ideas at the beginning. And what's amazing about the successful startup
founders is not that they just persevered indefinitely, but that they had this funny
combination that when they run into difficulty, it's not just that they gave up ship and went
home. Neither did they persevere the plane straight into the ground. They do this thing we call the "pivot". By
analogy to basketball, one foot firmly rooted in what we've learned, changing one other
thing about the business at a time. And the premise of the Lean Startup is as follows:
If we can reduce the time between pivots, we can increase our odds of success before
we run out of money. See, the way you think about startup runway,
is not how many months of burn do I have left? It's fundamentally how many opportunities
to pivot do I have left? And sure, we can extend the runway by raising more money. But we can also extend the runway by figuring
out how to pivot sooner. And every day we shave off that time is a magical extension
of our runway by a proportional amount. Does that make sense? OK, I'm getting at least
a few nods. That's good. So, to increase the odds of success, we need
to figure out how can we pivot sooner. We need to bring our focus to a validated learning.
Anyone know this? This is the waterfall methodology of software development. It's traditional
in one of these talks when you're gonna beat up on methodologies to call one the "waterfall
methodology". So this is mine. This is just Fred Taylor's idea as applied
to software development. When I was trained as an engineer in Silicon Valley, I was taught
this as the manufacturing metaphor of software development. You can imagine, incidentally,
how pissed off I was when I found out that they don't use this in manufacturing anymore.
This is way obsolete. So it's not clear to me what our excuse is
in software development for copying an obsolete model of manufacturing. But I understand why
it’s so appealing. The idea is that since software is so intangible,
we like to imagine our work travelling on an assembly line, a virtual assembly line,
from department to department. And if everybody does their part and trusts everybody else
to do their part, everything works out fine. It's entertaining to beat up on the waterfall
methodology because it has such a bad track record. But it’s important to understand
that waterfall works as long as the solution and the problem are both relatively well understood.
So if we were building something that is fundamentally similar as things we have built in the past,
this works great. If you're building a video game sequel, amen.
If you're building the next iteration of a product that zillions of people already use,
that's fine. But entrepreneurship doesn't deal with those circumstances. So it's basically
a waste of time. Now, when you do waterfall, you have this
problem I call "achieving failure" where you successfully build the wrong thing and you
boast about how good you are at doing it. My question is, if you go to a startup board
meeting, or a milestone review meeting for most new products, what do we talk about?
Milestones, right. We are on track. We're building features we said we were gonna build.
We talk about our gross numbers like – hey, we have this many customers just like we said. I remember being in a company once that was
looking, had a plan. They said we were gonna have this nice hockey stick-shaped growth.
And we're on the nice, long flat part, and everything's going according to plan. Sounds
a little familiar, maybe. And you're going to court like, the plan is
genius. Like, nobody is using our product as expected, as expected. But next week, it
should turn up. And how do you know if you were on the long,
flat part and you're gonna just, or you're on the hockey stick and you're gonna just
coast indefinitely? I believe we can actually answer those questions quantitatively. We'll
get to that. So, to me, we are bragging about how we're
building a product that nobody wants. But we're doing it on time and on budget. As if,
I have this image of a general manager driving a car off a cliff and while they're driving
their like, "But I'm getting great gas mileage," right off the cliff. That's what startup failures
mostly look like. And I think that's true in big companies,
too. Not that I would presume to talk about you. But in other companies I've seen, for
sure. So, in manufacturing, they abandoned that linear way of working. That's why we
call it Lean Startup by analogy to lean manufacturing. These are two other unfortunately deceased
men who made this possible. Deming is famous for having said, "The customer is the most
important part of the production line." By which he meant everything that we do should
be gauged to be decided by whether the customer cares that we do it. So if the thing is of high quality in the
customer's eyes, that matters. But if we're doing a lot of internal transport, with the
meetings that we have, the specifications, the customer doesn't care about any of that
internal stuff. So let's try to eliminate it. When these ideas were handed down to me as
a Silicon Valley engineer, they looked like this. There's our very own guru of extreme
programming, Kent Beck. You guys know Agile very well, so I won't bother getting into
it. Suffice to say that all Agile methodologies
have their origins inside the IT departments of big companies. Every single one. And there's
a reason for that. They are designed for situations where it is the problem that's known, but
the solution is unknown. And so, by building something that is well-understood iteratively,
we can increase the odds that the project will be successful. So, the classic -- Chrysler Corporation needs
a new payroll system. Agile to the rescue. But this isn't the world that we live in as
startups either. If the customer is the most important part of the assembly line, what
do we do if we don't know who the customer is? That in whose eyes should we judge our
work? In extreme programming, which customer should we sit down next to the engineers to
tell them what to do? The assumption of Agile and all previous management
approaches is that there is somebody who can give us an authoritative, definitive answer
to design questions. And in entrepreneurship, that assumption breaks down. We are working on products where nobody knows
what the customer wants. At best, we have a theory, a hypothesis, a plan, a hope. And
so, this is what Lean Startup looks like. Now, at Lean Startup we have our own guru,
Steve Blank. He's still alive, but I put him in sepia tones just to be consistent. [laughter] Steve invented something called "customer
development", which is an iterative process of trying to figure out who your customer
is, which we can merge in parallel with Agile development to this company-wide feedback
loop of learning and discovery. This changes the unit of progress from making stuff to
validated learning. Let me try to illustrate what I mean. I created
a company called IMVU in 2004. We make a 3-D avatar instant messaging technology. And at
that time, we wanted to be the next AOL back when that was still cool. And we wanted to
take over the hot, new social technology of IM. We really thought that was the wave of
the future. Whoops. And here was our plan. See, everybody
knows that instant messaging is a network effects business, right? So, therefore, if
you wanna get someone to switch from their IM network to yours, it's kind of a pain 'cause
they'd have to bring all their friends with them. So there's high switching costs. And therefore, IM isn't an industry characterized
by high barriers to entry. That's the MBA analysis of the instant messaging market.
And we spent a lot of time figuring that out at the whiteboard. And we said, "Ah, we need a strategy. A strategy
for avoiding that problem and here it is. We'll create an instant messaging add-on that
interoperates with all of the existing networks and can bring 3-D avatar technology to your
IM client. So we take your boring 2-D IM and make it 3-D. Wow." This is before 'Avatar' and the current 3-D
craze. So we thought we were on to a real trend. And so, here's the reason we got so
excited about that strategy. It would be inherently viral. Because when you would decide you wanna
go 3D, you would have to be IM’ing with somebody and they would automatically get
a text link inserted into the chat stream that they could just one-click, pick-up boom,
IMVU installs. Now you're both in 3D. Doesn't this seem like a good idea? Well,
we met with investors at that time. The strategy part of it, they're like, "That does sound
very promising." And when I tell the stories to MBAs now, I get a lot of nods, like "That
is good stuff. I don't know what the hell this guy's been talking about until now, but
this I understand. This is strategy." And the strategy actually is very good, except
for the tiniest, tiniest problem, which is that every single thing I just said is false.
Customers actually don't have high switching costs for IM. Their network effects are way
overblown and our customers refused to invite their friends. It was a total deal breaker. We'd have customers come in an in-person usability
test. We're paying them to be there. And we'd be like, "OK, download our instant messaging
add-on." The customer would be like, “What is that?" "An instant messaging add-on. It
interoperates with all your IM." And you gotta picture of a 16- year old like, "What? Is
it an IM client?" And we're like, "No, no. You won't have to run a whole other IM client."
They're like, "Why not?" Like, "Oh, it would be so complicated to download." They're like,
"Dude, I have like seven IM clients. What's the big deal?" And we're like, "There are
seven IM clients?" [laughter] So that was problem number one. We're like, "Listen, we are paying you to
be here. So how about you download this thing? OK?" "All right. Fine." "Download the thing."
OK. "Customize your avatar." They love this part. "Like, ooh, that's really cool, interactive
like that." Great. "OK, now you customize your avatar. Invite one of your friends."
"No way." "Why not?" "I don't know if this thing is cool, yet and I'm not gonna invite
my friends to something that turns out to be lame." See, I know people who are selling like business
software are used to the concept of "mission critical". We didn't understand that in our
business, mission critical, like the law of commandments of mission critical software,
one of them needs to be like, "Do not make teenager look lame in front of their friends."
Total deal breaker. They wouldn't do it. We were like, "We're
paying you to be in this usability test." And it's just like, "I'm not doing it. You
can keep your money. I will not. It's not worth it to me." And they kept saying things
like, "Let me use it with -- let me try it out first. And if it's cool, then I'll invite
one of my friends." And we were like, "Oh, OK." We're from the video game industry. So we knew what that meant. That meant single-player
mode. So we built another version of the product, single-player mode. Allowed you to -- we had
another teenager come in for a usability test. "Hey, download this instant messaging add-on."
"I don't know. What the hell is that?" "Just do it." "OK." "Customize your avatar." "Oh,
that's cool." "OK, try it by yourself." And they could check out the avatar, dress
it up, do the moves and the whole thing. Learn how to use the chat bubbles. And then we're
like, "OK, now invite one of your friends." Teenager, "No way." "Why not?" "This thing
is lame." And we're like, "But we told you it was gonna be so lame." I mean, we're supposed to be listening to
customers, but they don't know what the hell they want. And they told us to build this
thing and we're like, "It'll be so cool once you invite some of your friends." And they're
like, "Listen, old man. I'm not doing it." [laughter] And we were really devastated. Okay. So anyway, long story short, this was a total
deal breaker. This strategy is completely flawed in every respect because it’s based
on empirically incorrect facts. Now, we wound up having to pivot the company
and we created our own instant messaging network and it all turned out fine. But I'd like you,
if you would, just for a minute to sympathize with me personally. OK? Because I was the
engineer. I was the CTO of this company. It was my job to write the software to do
instant messaging interoperability. So I wrote, I don't know, 25 thousand lines of code or
something. I did it all Agile, refactored, really elegantly structured if I do say so
myself. Good unit test coverage, the whole shebang. And all of my code got thrown out. [pause] The good code got thrown out and the bad code
got thrown out. The well-factored code got thrown out. The stuff I was proud to show
my mom and the stuff that I wouldn't want anyone to see at all was equally thrown out. Because a [ ] of quality is if you don't know
who the customer is then you don't know what quality means. So failure is a great equalizer
of quality. It all had to be thrown out. And I was really depressed. Because you gotta
understand, we had spent six months killing ourselves to build this product. And we had
spent I don't know how many hours of my life that I can never get back arguing with each
other about the following. Which bugs did we absolutely, positively have to fix. And
which ones could we live without? Sound familiar? Which features just had to be in version one
or which ones could we just maybe could maybe postpone to a different release? That's what
we spent all of our time doing. And yet, we had this problem, which was that
customers would not download our product. Like, this product sucked. It was really buggy.
It would crash your computer. I was really embarrassed to have shipped it. And we almost
didn't ship it, I was so embarrassed. But then, I was actually relieved cause nobody
found out how bad it was because nobody would use it. And I was like, "Wait, something is
not right here. Why am I relieved that nobody's using the product? That doesn't seem right." And long story short, my cofounders dragged
me, kicking and screaming, to the realization it was time to pivot. We had to throw that
code away. And we created a standalone IM network and we were much more successful,
la di da. But here's the thing. I had to make myself
feel better somehow because I was like, "Gosh. Would the company have been just as well off
if I had spent the last six months on a beach somewhere, having nice drinks and doing nothing?" And I was, "Did I even need to be here given
that all the work that I did was thrown away?" Anyone feel like that's true? Anyone know
what the excuse I used was to make myself feel better? You can shout it out. It's OK. I guess, yeah. >>audience 1: You built a team. >>Eric Ries: What's that? >>audience 1: You built the team. >>Eric Ries: We had the team at the beginning.
What did they need me for? Why was it worth having done this exercise in the first place?
What's that? [audience 2]: You learned something. >>Eric Ries: Because I learned something.
Thank you. The last excuse in the book. If you've utterly failed to execute, you can
always claim to have had a good learning experience. At least you learned something. I mean, I
don't tell you guys. In general management, you claim to have learned
something, you're likely to be fired. A general manager who learned something -- one of two
things is true. Either they didn't make a very good plan, in which case, definitely
should be fired. Or even worse, they made a really good plan and failed to execute it.
I'd definitely fire that guy. So, I think it’s natural that we have a
little bit of an aversion to wanna just say that we learned anything because that is very
dangerous. But in entrepreneurship, failure is, not only is failure an option, it's practically
the only option. It's what happens when reality intervenes with our plans. >>audience 2: So, what did you learn? >>Eric Ries: So here's what we learned specifically.
We learned the hard way, that customers did not wanna use our product to connect with
their existing friends. They wanted to use it to make new friends. That doesn't seem like a very big deal. I
mean, it's all a very modest change in semantics. But from a code and product point of view,
that is a radically different product. It required a very different experience. And
we didn't throw out every line of code. But we had to throw out a lot. The pivot was quite dramatic. And I made myself
feel better with this whole learning story until I asked myself the following question.
I mean, literally, I was up nights once I had this question asked to me. Which was, "Wait a minute. If my goal of the
last six months was to learn this important thing about customers, why did it take six
months? How come the word 'learning' is only coming up now after we failed and we need
an excuse? We never used the word 'learning', not one time during those six months. All
we ever did was argue about features and bugs." And then I was like, "But would we have had
the same learning if we'd built a slightly different first product?" Like, for example,
did we have to support all seven IM networks? What if we'd supported only three? Would the
learning value have been the same? Sure. Customers won't download, so who cares? What if we'd
supported only one network? Learning values the same. Now, that's a lot of code between
seven networks and one, that's a lot less code that needed to be written. But this is the thought that literally made
me sick to my stomach. I'd say, "Wait a minute. What if we had just created a single web page
and in three hours created a photo mockup of what the product was going to look like
and said, 'Hey, download this amazing 3D avatar instant messaging add-on.' And had a big download
button. Would we even have had to create the second page where we admit that we didn't
build the product, or would a 404 have been adequate?" Come on, it's the 404, obviously.
Because nobody would download the product. It was a deal breaker. Nobody wanted it. That
meant that we didn't even need page two. And that was really upsetting to me, personally.
Why? Because I look at my business card and what did it say? It said a lot of things,
but all I saw was "guy who writes code." My job is to make features. So if I went home at the end of the day and
I write good code, I had a good day. And now, but if my goal is to learn this thing about
customers, and I can do it without code, is that my job? Is it possible that something I could do in
three hours is just as meritorious as something that requires 25,000 lines of code? It didn't
seem right. But I think that's actually true. Fundamentally,
startups exist to learn how to build a sustainable business. We call it "validated learning"
'cause we have to back up that learning quantitatively. Any old idiot can tell a good story. But we need a system for rigorously assessing,
"Are we actually learning how to build a sustainable business?" And everything else is a complete
and total waste of time, including our precious code. Now, in the lean manufacturing revolution,
the first question they had to teach people to ask was "what is the difference between
value and waste"? And in a factory, this is actually relatively
straightforward. Value is the stuff that we make. The customers want. And waste is everything
else. But if our unit of progress is gonna be learning, then our unit of value has become
intangible and now we have an issue. Which is -- OK, we can eliminate all the stuff that
we do that doesn't contribute to learning. So, we have this concept in Lean Startup called
"minimum viable product", which is, what really needs to be in that first version? And now
we have a good answer. Only what is necessary to learn whether our plan is correct or not.
Everything else is extraneous. But that's still a little bit vague. And so
the next step in lean manufacturing was to focus on cycle time. And so what that looks
like is this. Very simple heuristic. This is the flux capacitor of Lean Startup. All we are as a software startup is a catalyst
that turns ideas into code. When customers interact with that code, they create data
which we can choose to measure quantitatively and qualitatively. And then if we want, we
can learn impacting our next set of ideas. This, we can use to put the concept of the
pivot on a more rigorous foundation. A pivot is one major turn through this feedback
loop. And the heuristic for any kind of startup advice that anyone wants to give you is really
simple. Does it minimize total time through this loop? So I don't know about you, I go to a lot of
startup talks, I read a lot of startup blogs. All the advice is like this. "You know, it's
really important to have great design. Design always wins. Except craigslist didn't have
very good design and neither did EBay. So sometimes it's fine to have no design. But
make sure its very scalable, cause you don't want to be the next Friendster. Except that
Facebook wasn't very scalable and it was fine. So make sure you have good design and design
doesn't matter. It's scalable, but not too scalable." It's not very helpful advice and if you go
down the list, it's like make sure you raise plenty of money, but not too much money. Make
sure you have the right kind of people, but not those other kind of people, but actually,
sometimes those other kind of people are fine. And we focus on all this contradictory stuff
'cause for any particular piece of advice, I can find you somebody who followed that
advice and then made a lot of money. I can also find you somebody who didn't follow that
advice and made a lot of money. I can find you people who followed that advice and made
no money and people who didn't follow that advice. I can find you all four quadrants
of a logical possibilities chart. So, how do we know what advice to take and
what not? I think this is the heuristic you wanna use. If it gets us through this feedback
loop on a sustainable basis faster, it's a good idea. And if not, not. There's a lot more, of course, to Lean Startup.
There's a zillion things on this graph. You can read them all on my blog, Startup Lessons
Learned. Of course, you can buy a certain book. I've heard it's coming out in the fall.
It's really good. All of these techniques, like continuous deployment,
where we put software into production, like 50 times a day on average. So, 20 minutes
from the main trunk to production, no branches. Things like net promoter score where we can
evaluate in real time using a tracking survey, what customers really think about our product.
Everything you know about usability tests, five whys, which is drawn from the Toyota
production system. Each of these techniques has -- they operate
at one stage of the feedback loop, but they have the net effect of minimizing total time.
That's what the Lean Startup is about. But I wanna mention one more really boring
topic called "innovation accounting". See, we've forgotten what accounting was designed
for. I mean, we think of accounting as that thing that the really boring people do to
keep track of where the money goes, right? That's pretty much what it is. It's just a
ledger that says, "Where did all the money go?" But accounting was invented for a very different
reason. It was invented to drive accountability across departments. Because if you wanna have
a large company with many different divisions, you have to be able to hold the managers of
those divisions accountable to some things so that you know that they did a good job.
General Motors, which invented most of our modern management paraphernalia, had this
concept. When I first read this concept, I literally
laughed out loud; I couldn't believe it. It was called the Standard Volume. It was the
ideal number of cars that General Motors should sell, division by division, in an ideal year.
And they actually had the math, and staff, the macroeconomic staff to figure out, given
all the macroeconomic data available, how to translate the standard year into our coming
actual year. So they could go division by division and
tell each manager, "Given that we're in a recession, or the economy is booming, you
should sell this number of Oldsmobiles. And therefore, if you sell more than the standard
number, you get a bonus. And if not, you failed." And it's not fair if you didn't have that
concept, then if it's a good year, all the managers seem like they're doing well. And
in a recession, everyone seems like they're doing badly. You can't tell which manager
actually made a difference. Now when I read that concept, I laughed out
loud because I was like, "Wait a minute. Are you telling me there was a time when people
could make forecasts about what was going to happen in the future, and then it actually
happened?" I don't know about you. I have never in my
whole life seen a forecast of anything that turned out to be remotely accurate. No startup
I have ever worked for has had a roadmap that turned out to be remotely true. I have never
seen a company say how many customers they would have in the future and then deliver.
Never seen it. So to me, the idea of the standard volume
is ridiculous. But I understand when you have a sufficiently large company and you have
a sufficiently long operating history, you can do this. Maybe this sounds a little bit
familiar. So, if we're using accounting to drive accountability,
but all of our accounting depends on having a long operating history and a lot of customers,
how do we drive accountability if there's no customers yet? If the CFO of a company, hypothetically speaking,
gives a certain team a bunch of money and sends them off to some remote location to
do their work, like to Australia or something. And then they hang out in Australia or whatever.
And then a year later, they say, "What are your results?" And the team says, "They're
not very good, but we're on the brink of success." How is the manager who gave them all that
money supposed to know if A: They are in fact on the brink of a success or they're just
on the flat part of the hockey stick, or if they've just been goofing off for a year?
Or more likely, if they're just executing a bad plan. And at what kind of milestone should we hold
them accountable to if we can't hold them accountable to the gross numbers of customers?
'Cause that's fundamentally not fair. If we're focusing on the gross numbers, incidentally,
we might decide we're gonna do a lot of publicity and PR and be like, "This thing is gonna be
amazing," to drive customer awareness. But we all know if you happen to find yourself
on such a team, that that early awareness is fundamentally lethal. But it's not fair
to just say, "Well, just let them do whatever and hope for the best." You guys know exactly
how that turns out. So, what is the solution? I think we can answer that question now with
something I call "innovation accounting". Here it is. Instead of focusing on product milestones
and gross numbers, we have three learning milestones we can focus on. We have to take
our attention away from the vanity metrics. Vanity metrics are the numbers you put in
a press release to make your competitors feel bad. Like the total number of pages on the
internet that you've indexed. I happen to like that one a lot. There was a time when we had a big index,
number of in pages indexed battle. And it's like, "We have four billion and you only have
two billion." But like, what does that actually tell you about the quality of somebody's business?
Absolutely nothing. They could be four billion really dumb pages.
It could be one guy's website who's just really excited about the number four billion. Or,
it could be four billion people who each have one crappy website. If you read "TechCrunch", you're gonna see
a zillion stories about "This company has sent 400 messages through their platform."
But is that 400 million people who are all about to turn out, or one very excited customer?
We don't know. We used to have a competitor in IMVU that
would report on the gross GDP of the value of their whole user to user economy. And my
CEO would sometimes come to me and be like, "These guys have a four hundred million dollar
GDP. What's our GDP?" I was like, "What does that even mean in our context? If two users
exchange some virtual currency, is that part of the GDP? I don't know." It's a completely
meaningless number, but it sure made us feel bad. I'm all for vanity metrics and press releases.
Go to town. That's fine for making your competitors feel bad. But what happens when we use those numbers
to guide our own business? Is that "when the numbers go up, it's always because of what
I was working on"? Everyone thinks I made this feature last week and now the numbers
went up. So obviously it's due to me. Of course, the people in marketing feel like it's 'cause
their new marketing campaign, etc. What happens when the numbers go down? Anyone ever been in that meeting? Oh, it's
seasonal effects. Did anyone ever hear seasonal effects used to describe numbers going up?
Never in my career. It's always like, if it's going up, it's features. If it's down, it's
seasonal effects, or worse, those idiots in marketing. And over time, each us lives in our own private
reality where the stuff I do makes numbers go up and the stuff that those guys do make
numbers go down. So is it any wonder that we think each other are idiots? Now, expand that organization larger and larger
and larger as people are in ever more permanent silos, speaking their own language, living
in their own private reality. Is there any wonder that they have trouble working together? Maybe that sounds a little bit familiar. Okay.
Just checking. So instead of that, we're gonna use actionable metrics, which are about per
customer behaviors, things that can be measured at microscale. And the first thing we're gonna do is establish
the baseline. So now we can put the purpose of the minimum viable product on a much more
rigorous setting. Somewhere in our business plan, there is a model that says, "Hey, if
customers behave in this way, then we’ll have zillions of them over time." And we can't
get into all the details on how to build those models. Of course, there's a great book coming
out. You can learn all about it. In the meantime, what we wanna do is just
figure out what are the real numbers for each of those inputs at microscale? That's what
the minimum viable product is for. So, if there's some number, some spreadsheet somewhere,
that says, "Hey, ten percent of customers who come to our website should register for
our product." Then we should have a big banner in our office somewhere that's like, "We must
have ten percent conversion or we die." And then, we each have a minimum viable product
as soon as possible to find out what that number is today. And most likely, when you do that experiment,
the baseline will be horrible. Like, it'll only be one percent and it's supposed to be
ten percent. And like, oh my God. In general management, that provokes a crisis cause now
we failed and uh-oh. There's this thing called the "audacity of zero", which is how much
easier it is to raise money and get people excited when you have no results. Or having
zero dollars of revenue in a startup is a great time to raise money. Having one dollar
of revenue is a disaster. 'Cause with zero, it's like, "Well, why is it zero?" "'Cause
we haven't launched." So, obviously it should be zero. Everyone's like, "Oh, that makes
sense." God forbid you have one dollar of revenue,
'cause then they'd say, "Why is it only one dollar? I thought this thing was gonna be
an overnight success and now you're proving to me that it isn't." So with zero you can
always be an overnight success. With any other number you're screwed. But we need to change that. We need to say,
"Finding out the truth of where we are right now is progress. It's a milestone that we
should celebrate." And then we do step two, which is we tune the engine. We make product
development changes that are not designed to drive huge gross numbers, but to make those
conversion numbers go from the horrible baseline to the ideal in our business plan. And whenever I've done this with teams, I've
only ever seen two cases. Case one, it's supposed to be one percent. It's one percent but it's
gotta be ten percent. So, a few iterations in, it's one percent, three percent, six percent,
six and a half percent, seven and a half percent. Now, it's not ten percent yet. So the model
isn't exactly working, but you can say, "Are we gonna get there?" Yeah, probably. Each
thing that we do seems to drive the number up a little bit. We seem to be heading in
the right direction. We're split testing to make sure that the changes we're making are
in fact driving the change. It's all good. Here's situation number two. It's one percent,
three percent, three and a half percent, 3.75 percent, 3.8 percent, 3.81 percent. Now, the
numbers are going up every time. So it's not like the numbers are going down. It's not
like it's zero. But you might ask yourself a question four, five, six months into hitting
that asymptote. Are we ever gonna beat ten percent? I think it's safe to conclude the
answer is no. Of course, theoretically, it is possible.
The next iteration will be that magic one more feature that gets you to ten percent.
But in reality, that's not the case. When the team gets to the point where hitting
that diminishing returns, everybody knows you're not gonna make it and you enter the
land of death march. So instead, I recommend we do three. We schedule the meeting in advance.
That three months from now, six, whatever it is, we're gonna have a meeting to decide
whether to pivot or persevere. And by that meeting, we will have the data
about whether our efforts to tune the engine are working or hitting diminishing returns.
And so, we have all these concepts in entrepreneurship, like product market fit, that are very vague.
This system allows us to put those concepts on a much more quantitative basis. We can't
turn whether to pivot into a formula. I can't tell you what to do. I still rely
on human judgment, just like science does. But if we make specific predictions, if we
use innovation accounting as our accountability model, then we can be training our judgment
to get better over time, just like in science. So, don't do product development astrology.
Do product development science. I left a bunch of questions unanswered 'cause we only have
a short time together. Like, how do you know specifically when to pivot? What's the relationship between our vision,
our strategy and our product? What exactly should we measure in each of the engines of
growth? How is it that products grow? How do we know if we're on that hockey stick,
or on the long, flat part forever? How do we test if we're creating value? What specific features should be in the MVP?
Can we go faster? The answers to these questions and so many more are in the new book coming
out in the fall, called "The Lean Startup". You can, of course, preorder it at lean.st. Thank you very, very much for doing so. I'll
just give you my contact information. Please be in touch if I can be helpful in any way.
We have a brand new website, which is itself a minimum viable product about theleanstartup.com.
Please check it out. We would love your feedback. And you are all officially invited to the
Startup Lessons Learned conference, which is gonna be May 23rd in San Francisco, but
we also simulcast. Last year, we were in 50 cities. So presumably we'll be in New York, too. I
hope if you can make it, you will drop me a line. And if this proves in any way helpful,
I hope you'll email me and tell me about it. Thank you all very much. [applause] So we have time for a few questions? OK, let
her rip. If I stumped all of Google, I'm gonna be pretty proud of myself. That's going right
on Twitter. [pause] Sweet. [pause] >>Female Audience Member #1: So, I just wanted
to touch on something that you mentioned is reviewed too many times; the pivot. >>Eric Ries: Uh-huh. >>Female Audience Member #1: I have trouble
understanding exactly how much work to put in for the first pivot. I think the second
and the third might be a little bit more, OK, maybe not. [laughs] But just starting
off, like how much work should you really put in for that first pivot? >>Eric Ries: There's no way to answer that
question in general, honestly. You have to put yourself into a position where
the team will know if it's working or not working. And the problem is that most teams
have a plan, which is basically to ship it and see what happens. And the problem with ship it and see what
happens, you can feel like you're being very agile, but you're guaranteed to succeed at
seeing what happens. And so, you'll therefore always feel like it was worth doing and you'll
feel like you're on the right track no matter what. The only way to get yourself into a position
where you have to pivot is to make specific, concrete predictions ahead of time that if
they turn out to be wrong, will actually call your theory into doubt. And the issue is that we all know that most
projections for new products are complete BS. You have to tell the CFO, or whoever,
that you're gonna have a zillion trillion customers in year five. Otherwise you won't
get the money to do your project. But we know that we just made those projections
up. So when they don't prove to be correct, we're like, "Well, that doesn't prove that
our vision is wrong. It just proves that it took longer than we expected." So, yeah, the
hockey stick is still gonna happen, but it's taking longer. If we do innovation accounting and we make
very specific per customer behavior predictions -- like one thing we'll often have people
do is sell the magic version of their product on a landing page somewhere. And it's like, don't even say what the product,
like how it works. Just say the benefit that it gives you and see if you can get people
to sign up. If people won't sign up for the magic, they're certainly not going to sign
up for your product, 'cause magic is always better. And if magic isn't even good enough, if the
conversion rate on magic is too low, then you already know that you have a problem.
Not that that means that therefore give up, go home. It just means there isn't already
enough latent demand for what you're doing. And so you're gonna be in a different kind
of market then maybe you expected. Does that help? So the minimum viable product truly
is the minimum, the least amount required, to get that first information. It's not, "Oh,
if it doesn't turn out into an overnight success, we give up." And if you release that pressure to get it
right the first time, like, I feel like a lot of us feel like we have to do this circus
act to make it seem like we could predict the future. Like, one of those brilliant visionary,
the next Steve Jobs. Not even Steve Jobs is as good as Steve Jobs. That's a story that
we've all been told. And every company I've worked with internally,
there are these genius heroes who always seem to be able to get it right on the first try
and everyone else is trying to emulate. But when you meet the hero, you're like, "How
do you do it?" If they're being honest with you, they're like, "I actually don't know." Or, "Actually that's not how it happened and
it wasn't as easy as everybody thinks. Now I feel incredible pressure to replicate that
success again." And so, you can imagine the negotiation that happens with the superstar
over their next project. They don't ever want to be in a position where they do something
and it doesn't work, or they'll have to quit and go to convince some other company they're
a superstar. I hear that happened recently. Anyway. Is
that helpful? >>Female Audience Member #1: Yeah. >>Eric Ries: OK. Any other questions? [pause] >>Male Audience Member #4: So most of the
rapid feedback you're talking about seems to be very applicable to consumer applications
where the cost of trying something in the amount of time it takes to try something is
pretty low. I will or will not sign up for Twitter or Facebook or whatever the next thing
is. >>Eric Ries: Yeah. >>Male Audience Member #4: How does it apply
if it's a bigger thing? If it's an enterprise sale or if it's a bigger commitment, do you
just basically take the same process, but the time scale is longer because the commitment
process is longer for each step? >>Eric Ries: Yes. I mean, that's the short
answer. I mean, the long answer is my background's in consumer internet. So I talk that way just
naturally about large sample sizes and split tests. Just the way that I, I can't help it.
That's my whole career. What's funny is that Steve Blank, who I mentioned
earlier, has a great book called "The Four Steps to the Epiphany", that I hope you all
read. When he talks, his background is in enterprise software. He gets this question
too, all the time. Except when he gets the question, people say, "Well, of course, this
will work in enterprise software. But how will it work on consumer internet?" Because we just assume that the tactics that
have worked in one industry don't work in another. So the answer is truly, it's the
principles that matter, not the tactics. And so, the principle of the build-measure-learn
feedback loop is cross-industry. So for example, in consumer internet, because we're used to
having large numbers of customers, we do all this analytic stuff as a crutch. It's actually,
it's actually -- it's because we have it worse than the enterprise people. When you have a lot of customers, you can't
get to know any of them particularly well. In fact, you just have, you have to rely on
archetypes and summaries and assumptions. When you have a small number of customers,
it's a huge asset because you can know each of them extremely well and the experiments
that you do can have much higher fidelity. So like, physicists don't get to ask electrons
what they're thinking about doing. They're not available for comment. But when you're studying something that can
actually interact with you, it's a whole different, whole different ballgame. Question over here?
Yeah. >>Male Audience Member #5: What product should
Google be pivoting on right now? >>Eric Ries: What? What product should Google
be pivoting on right now? Listen, I would never presume to tell Google anything about
that. I mean, look. >>Male Audience Member #5: You were invited. >>Eric Ries: What's that? >>Male Audience Member #5: You were invited. >>Eric Ries: I was invited. But look, but
seriously. Like, the outside expert doesn't know anything. You guys know your business
way better than I do. And you know what products need to be pivoted. You know. You don't need
me to tell you. The better question is, how on Earth are we
gonna get to pivot them? Because we're stuck in a management and accountability framework
where pivoting is failure is a problem. So for example, a certain Google product that
I know especially well because it was competing with something that I was working on at the
time, I won't get into too much detail. One of our cofounders at IMVU went to work
on this product for Google. So, you're Google people. You can talk about this. So they had
a lot of inside information about what we were doing available to them. And at first,
we were really nervous because it meant that we were gonna face competition from Google. Here's what happened. Google spent two years
working on that product. Spent, I can't imagine how much money developing it. And when it
finally came out, they launched it with a big bang, put the Google brand right on it.
And then when some things didn't go as expected and it turned out to be an embarrassment,
like, it got pulled and killed. And the whole time, we were like, "What is
going on over there?" 'Cause we were iterating and changing constantly over that whole two
year period. By the time they launched the product, we felt like they'd launched a product
that did what our product did two years ago. And by giving it the big launch hype, putting
the Google stamp on it, the inevitable problems, the same problems we had had when we launched,
but we were able to pivot because we had a pathetically small number of customers and
no one had ever heard of us. That's a huge asset. It's actually a relief.
'Cause it means you can screw up. Nobody knows. Nobody cares. Obscurity is a benefit. By putting
the Google name on it, by claiming it was the next big thing, Google put that team,
I assume, in a position where there was no way for them to pivot. It became an embarrassment
to corporate, or somebody, and the thing got pulled. Now, [pause] that product could have pivoted.
It was a really good product. It had a lot of really good things about it. There was
no physical reason why it couldn't pivot. But two million dollars, two years and millions
of dollars in, with all these expectations and the Google name, I can't imagine the pressure
they were under. I felt bad. So, the right question is, what could Google
have done to build that same product and put it in a position where it could have pivoted?
I actually think that leadership in today's economy means creating platforms for experimentation
for your teams. I borrow that phrase from Scott Cooks, founder
of Intuit, who's been a big doctor of Lean Startup. So if you want to be a general manager in
a big company like Google and you want Google to be more entrepreneurial, my point of view
is it's on you, not on your team, on you to give them a safe sandbox for experimentation. So for a risky new product, do not, I would
never put the Google brand name on it. For shame. And I would never talk to the press about
it at all, if you can avoid it. And I would try to have it have as small a number of customers
as humanly possible while still doing that innovation accounting. Then, teams will pivot just fine. Nothing
wrong with Googlers. It's a management problem. In my humble opinion. Yes. >>Male Audience Member #6: So let me follow
up with that directly. >>Eric Ries: OK. >>Male Audience Member #6: Let's say you write
a new mobile application and you post it to the-- >>Eric Ries: Hypothetically speaking. >>Male Audience Member #6: Yeah, yeah. The
app store or the market. If you do that at Google, with the Google name in a blog post,
you'll get a hundred thousand downloads no matter what it is. >>Eric Ries: Yeah. >>Male Audience Member #6: It can be almost
anything. But it's true. And by virtue of that, you are now, when people browse to categories,
shopping, personal finance? >>Eric Ries: You'll be number one. >>Male Audience member #6: you will be up
there. You will have that visibility and those will lead to clicks and you will be featured. And you will jump start in a way that you
can't do if you're nobody and you put up an app out there. You may very well just be in
the noise and you'll never break out of that no matter how great the product is. >>Eric Ries: Right. >>Male Audience Member #6: So, I mean having
done this twice-- >>Eric Ries: Entrepreneurs never ask hypothetical
questions, by the way. So I understand. >>Male Audience Member #6: Yeah. Yeah. So
I can tell you there's real value. I mean, I know the successes that I've had are in
large part because of having that name attached to it. And that initial jumpfrog, the initial leapfrog
made up for, was market that I couldn't have bought. >>Eric Ries: Yeah, look, you get free marketing,
but so what? Free marketing is worth so much less than we think. Like, yes, that accelerated
your process of success, but only because you had the right product and it worked for
your customers. So putting rocket fuel into a rocket that
has problems with it is not a good idea, right? You accelerate too fast. The thing blows up.
Now, sometimes you achieve liftoff because you actually do have the right product. But marketing, marketing dollars are not as
hard to come by as they used to be. The really great products today have an engine of growth
that allows them to grow organically anyway. So, yes. Google has huge advantages of putting
their brand name on it. It can get you a lot of downloads. But also, there's a huge liability
about that because-- >>Male Audience Member #6: Well, that's a
good question then. So why is it not OK for Google to fail? Why not take risks and just
fall on your face? >>Eric Ries: Listen. >>Male Audience Member #6: and admit it quickly
and move on? >>Eric Ries: If it was me, I would be celebrating
failures and I would make those people heroes. If it was up to me, but that's the culture
that I live in now. But see, failure is not what we want to celebrate.
We wanna celebrate successful pivots away from failure. And that's challenging because
it's easy. If you're charismatic, you can get resources
for anything and you can ship stuff and get people to use it and then you can engage in
a ton of what I call "Success Theater", to try to make it seem like you're a big success.
And so, those people tend to get the celebrations, whether they actually add any value or not.
They're like a cancer on most organizations, in my opinion. But what do we do instead? We don't want to
celebrate those people. We don't wanna just celebrate people who fail because they accomplished
nothing. So we have to have a system for evaluating which failures were actually instructive and
then we have to celebrate the learning and what the learning turned into in the next
try. So yeah, if Google corporate was fine with
people failing and having the Google name be associated with nasty stuff, that'd be
fine. But I just think that's unrealistic. I mean, I wouldn't be that comfortable. If I was Google, I would be launching those
things under a different brand name altogether. I wouldn't tell anybody that they're made
by Google until they're actually proven to be viable. How do you think Apple does it. The stuff
that we all consume and wait in line for, we're the first people -- the first person
who buys an iPad at the Apple store is the first person to have used the iPad? Come on.
That's my humble opinion. Helpful? >>Male Audience Member #6: I didn't follow
the last line. >>Eric Ries: Then maybe I shouldn’t have
said it. [laughter] Cancel that. I do think giving teams a platform
for experimentation, having clear analytics for testing whether they're making progress
or not, and celebrating pivots is the answer. Whatever Apple does, who knows? >>Thomas Sharon: All right. Last question. >>Eric Ries: Make it count. >>Thomas Sharon: Or this was the last question. >>Eric Ries: Too much pressure? It's a Google-branded
official question. It's going on the internet. [pause] >>Thomas Sharon: All right then. >>Eric Ries: Ok, thank you all very much.
I appreciate it. [applause]
