20、 Obama
上級 米 245 タグ追加 保存
このエントリーをはてなブックマークに追加
動画の字幕をクリックしてすぐ単語の意味を調べられます！
単語帳読み込み中…
字幕の修正報告
>>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