Eric Ries
episode 42
Eric Ries is disrupting the world of entrepreneurship. His book 'Lean Startup' has become a movement and a community for big and small business people alike.
He's the father of the MVP idea and tools like the Lean Canvas. So embark on a journey to discover the essential ideas behind the worlds leading product development methodology.
Introduction
The Source Of Inspiration For Eric - The 40M worth Of Shadow Beliefs
A BLOCK
Start With Test And Learn
How To Know If People Want A Product
Chad Book Review
Lean Startup by Eric Ries
The Startup Way by Eric Ries
B BLOCK
Measuring Your way To Success Or Failure
Building the Minimum Viable Product
Lean Startup Lessons Test Before you Build
Lean Startups MVPs and the Importance of Learning
C BLOCK
Eric Ries explains The Pivot
Pivot or Persevere
Solving Problems With The 5 Whys
TRANSCRIPT
Hello and welcome to the moonshots podcast. It's a huge episode 42. And I'm your cohost Mike Parsons, and as always, I'm joined by the international jet-setting mr. Chad. Owen. Good afternoon. Good morning, Mike. How are things I hear you've settled into a new abode and they're in lovely Sydney. This fall.
Yes. Right. Should I say spring? Spring? You're the fall. I'm the spring. Yeah. I have to report to you Chad, into all our listeners. I have survived renovating my own house. I have to credit my lovely wife who did all the work. So I am talking to you from my new studio. I am very happy. I am, as they say, a pig in mud and very excited to get back.
We're recording the show with you because Chad usually I'm the one that's zipping all around the world, but you hands down have been traveling more than me the last year, four weeks. Where have you been and what have you been up to? Oh, yeah. I don't know that that's necessarily a good thing, Mike, but yeah, I've been really fortunate to have some fantastic clients in San Francisco, San Jose, Scottsdale, Arizona, London, England.
It's been a whirlwind six weeks, but I'm excited to kind of hunker down, settle in, maybe pick up some more books of people for us to potentially profile, take it easy and kind of coast into the new year. Oh, yeah, that sounds perfect. As the winter sets into Brooklyn, I can see you nestled in there reading up on some inspiration and new ideas and boy so far in this series.
I mean, we've had clay Christiansen. Peter Drucker. We've had Simon Sinek. I mean, we are really handpicking some of the best innovation writers in history, but we've got one more left as part of our writer series. Chad, who are we going to dive into today? We are going to end this series with kind of the person that kicked off this latest craze in the product world innovation world.
I'm sure all of you have heard of the lean startup while all of these ideas aren't necessarily his he's very much inspired by many of the people that we've profiled. Yeah. We're gonna, we're going to dive into the works of Eric Reese author of. The lean startup. Yes. And I cannot tell you personally, Chad, like the lean startup, the work of Eric has inspired my work greatly.
In fact, when I was living in San Francisco, I got to work with Eric when together, where at the start of the FastWorks program for general electric. And that really hooked me to this idea of focusing on just the essential part of a product and really testing whether it's certainly a good idea, but whether it's truly viable and it has radically changed the way I thought, what about product?
And I can't tell you how much this topic of. Getting just the minimum product and making sure it's viable is something that I am as of just today after the show, I'll be with a client and we're actually building a number of products together. And the essence of our conversation is these a brand new products.
Never been on the market before. It's not like version 2.0 or anything like that. And the whole discussion is about navigating between what is just enough of the first iteration of the product and what do we need to do to prove its viability. And yeah, all of this is an, a huge dialogue of what are we learning.
And I think that's what Eric Reese has given us. He has packaged build a product in the modern age, in such a powerful way. Chad, you must just run into this all the time. As you're talking with all these innovators, entrepreneurs, creating new things, whether they know it directly or indirectly, they're all kind of using versions of the lean startup.
Yeah. He distilled the things that were working in Silicon Valley and elsewhere. And. Created an understandable model and wrote a very good book with a great story, kind of based on his own experience and founding IMCU and his struggles, which we'll hear directly from him about that experience. But others like Steve blink go even further back into the history of Silicon Valley.
You know, they kind of begun this science of entrepreneurship and Eric really kind of brought it to the masses. And made it accessible to everyone, ways of thinking about entrepreneurship and different methodologies. And I remember picking up the book probably in 2011, not too long after it came out. And while I'm not a traditional techie entrepreneur.
Type person. I really latched onto it. And he's like, you know what? I think most anyone can kind of operate their businesses in this way. And so I'm really excited to dive into the different frameworks that Eric lays out in the lean startup. He just pulls from so many different, interesting perspectives, like.
The Japanese with the Toyota lean management system I've was don't get me started. I love the five why's come on and chat. That's true. Yeah. And this idea of Kaizen or continuous improvement, there's so much, I can't wait to get into it. Yeah. So for our listeners, we're about to embark on what we, Chad and I both thought was the essential author on how to build product in the modern age.
Meaning whether you have built a product. Or whether you're thinking about building a product, this show has a ton for you because for all the seasoned product guys that listened to our show, we know there's a lot of you, this might remind you of some principles or might just fill in one or two little blanks that you've been touring with, whether it's what you measure, the, how you, how you think about the rate of learning, pivoting, all of that kind of stuff.
However, if you're thinking about creating a product, perhaps you're even dreaming of having a successful app on the iTunes store. This is the show for you. And in fact, the reason why we picked Eric as well as Simon Sinek as the two most contemporary authors is you almost have this ultimate combination of Simon Sinek because all about leadership and how you behave.
And Eric is really about what you do. It's the art of building great product. So together got really the two essential books you need for entrepreneurship in the modern. Age and both of them, Chad, by gosh, Simon Sinek, Eric Reese. Can they tell a story or what? Yeah. I want to get to these clips just to be sure we can get through all of them.
Mike, I think there's so many fantastic ones. And I think it's probably best to just hear from Eric about his own struggles as an entrepreneur. And I think where many of his ideas were. We're tested in the real world. So that's actually his time as CTO at a company that he founded called IMV. So here's him really just talking about kind of the Genesis of much of what he learned while trying to build a fantastic product that would go on to become a unicorn company, but we'll find out that it didn't quite turn out that way.
I know none of you would do a plan like this. Maybe you have a friend who's attempted this, or may be thinking about attempting this in the future. So, uh, let this be a lesson because we did something, I call a cheat failure. Uh, w we burned through about $40 million building this company. And, and after the five years of stealth, R and D, uh, we failed, uh, pretty, pretty spectacularly, but you got to understand nothing.
I say the rest of this lecture is gonna make any sense since at all, if you don't grasp that, we didn't fail to execute the plan. That was not our issue. We had a flawless execution, so we built a really amazing product, really compelling technology. We did hire the best and the brightest, and we had a great launch.
I mean, we were in New York times wall street journal CNN. I had all the right bloggers saying, this is the future of the internet. And we just had one small problem, which is that, although we got all these mainstream customers to try our product, none of them liked it. And so we couldn't convert all that energy into a workable business.
And so you ask, well, how can all those smart people, well, having worked on it for such a long time have come up with such a bad, bad plan. It's because we were crippled by what I call shadow beliefs. These are beliefs that were universally shared within the company yet were never, ever spoken out loud or ever written down.
I'll share three of them with you right now. The first that we know what customers want, which you have to believe. If you're going to, you know, devote 120% of your time and energy into building a company. But the thing is entrepreneurs have this civility, we call it the reality distortion field. If the ability to get a people in their vicinity to believe things as if they were true, they're not strictly speaking, literally true.
And one of those things is that people right now desperately need this new technology that we're building inside the reality distortion field. And I don't want you to get the idea that there's something wrong with that. All entrepreneurs have it. Good entrepreneurs, bad entrepreneurs. The issue is that there's another category of people that can use the reality distortion field and we call them crazy people.
Right. So if you want to create a cult, it's extremely useful to have the reality distortion field. So the crux of the issue is how do you know if you're in a store and for those who are in a startup today? I, well, I know you're not in this situation, but maybe you have, think about whether the vision that you're calling is the vision of a brilliant startup founder or of a crazy person.
We'll get to how to tell the difference in a moment, uh, number two, that we can accurately predict the future, which it's something that crazy people sometimes do say also startup founders. Um, you know, you gotta have a business plan if you're a startup and the business plan has to have a spreadsheet in the back of what you explained to your investors, that in year five, you'll make a hundred million dollars.
Anybody willing to admit to having that spreadsheet in the back of their plan. Now I have nothing wrong with having a spreadsheet and your business plan. That's a good idea. The issue is what happens when we start to believe those projections are literally true, like we're Nostradamus, and we know what's going to happen in startup.
Number one, we had the spreadsheet that said in year one, we would have a million simultaneous users. So on the engineering team, we were really excited. Well, that means we need to build a serious heavyweight architecture to support those million users when they show up. And of course, when they didn't show up, not only have we wasted a lot of time on it, protect her that no one was going to use even yeah, worse, we'd lost the agility necessary to change that architecture.
Cause it was this big heavyweight monstrosity that was patent pending, but ultimately useless and shadow belief. Number three, that advancing the plan is progress. When we're in conditions of extreme uncertainty and we don't know what to do, it's natural to just kind of fall back on what we can see and measure.
And the easiest thing to see and measure in a startup is milestones. So in starting number one, we were very rigorous about making sure that we hit deadlines and we did what we said we were going to do, and we made the plan and there's a reason why we were able to execute that good plan. We held everybody accountable for really doing good work.
The only problem is we didn't have a mechanism for asking ourselves, is this plan any good? Like, is it worthwhile to advance it? Yeah, well, it's so nice to hear from Eric himself. And to hear here, the kind of candid admittance that made a $40 million mistake or from what he called these shadow beliefs.
And Chad, what for me, this is all about if I just decode this idea for our audience, he's like, it was. All guesses. Everyone was guessing it was going to be big. The numbers in the spreadsheet for the year five revenue was a guess. Everything was a guess. And to me, this is the greatest source of product failure, people guessing.
And, but yet the guesses somehow become these truths that nobody questions. And so in his story, Five years later, $40 million later, they realized they didn't have anything. And it was all because they were guessing. So to me, the biggest thing we can take from Eric is stop guessing about what customers want from your product and transition into knowing, learning, and validating.
I think it's such a powerful story. Don't you, Chad? Yeah. And it's funny cause it begs the question. Well, okay. So yeah, maybe I am guessing, but what do I do now? Eric, doesn't leave us hanging. He doesn't leave us hanging. So he created this framework of build, measure, learn, and this idea of testing. And so I'll just let him help answer his own question that he's asking.
And how do we move beyond trying to predict the future, like a crazy person. There are different ways to conduct experiments that can test the assumptions in a business plan. We can talk to customers in person or on the phone to really get a sense of how they react emotionally qualitatively to our ideas.
We can build a minimum viable product, some early prototype that is designed to test to see whether customers will engage or purchase, or we can do split test or a B experimentation where we create different variations on a theme and see how similar groups of customers react to each. Each of these kinds of experiments is appropriate in different situations, has merit in different industries at different stages.
And it's key to choose the right, right approach for the right situation. This methodology is in stark contrast to the traditional way of building product in particular technology products, where we use, we just go into the backroom and spend three or four years implementing the newest and greatest technologies and packing with all the features that we know our customers want.
Right. Mike. That is exactly what we shouldn't do, but what has been done for years, it's what we call the waterfall approach. And, and it all starts with these massive requirements, which are completely guesses and it differs all interaction with customers and users until actually the product is launched and what Eric is really promoting.
And I cannot recommend enough is actually start with testing and learning with your customers. Hack stuff together. Proto-type interview really get to know what the pains and gains that affect your customer are. And then you start to actually test whether you can relieve the pains and create the gains.
And this is a massive learning that we can all take, which is. Don't start with a long business plan. Start with what you think is a big problem. And how can you apply a radical solution to create enormous benefit for your customers? It is simple to say Chubb. It actually, it's a bit harder to do. Isn't it?
Yeah. So the idea is that Eric is really running with here, I think were pioneered by Steve blank. And so if any of you are really interested in kind of this very early stage entrepreneurship, I'd highly recommend you take a look at everything that Steve blank wrote, but he's kind of the father of what's known as customer development.
And these are the things like. How to ask potential customers the right questions, to know if there's a, there, there, if there's a big enough problem for you to try and solve at that point, you're really not even thinking of a solution that you may build. You're really just understanding truly what the pain point is.
Right. And only then, do you understand the pain point? Do you begin building something? So those of you that may be thinking, Oh, you know, I'm not a coder and I don't necessarily, I'm not an industrial designer to build something and launch it on Kickstarter. It's like, if you can actually get really good at the things that Eric is laying out, doing customer interviews, doing MVP prototyping, and doing AB testing, you'll be.
Is ahead of everyone else. And you and I have seen this, how many times have you and I worked on projects together where we've literally seen executives have that aha moment with testing and learning. I mean, at least two dozen times. I mean, even, probably more for you. Yeah. It's magical for them because it's like, innovation is really not that hard in the end and it's technical really?
It's not, it's, it's empathetic right in the end. It's just. Caring about the pains of your customer. And I think this really launched us into this next idea is some of the advice Eric has for us when we're thinking now about building this product, how do we actually know if people want it? How do we, how can we kind of move from the guests to the knowing?
So let's have a listen now to Eric Reese on how to know if people want a product. If we do innovation, accounting, and we make very specific per customer behavior predictions. Like, you know, one thing we 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 benefit. It gives you and see if people can get people to sign up and people won't sign up for the magic. They certainly are not gonna sign up for your product. Because magic is always better. And if magic isn't even good enough, if the conversion rate on magic is too low, then you know, 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 going to be in a different kind of market.
This was kind of revolutionary to me. When I first moved to New York city, I connected with some people that were doing just this. They were inventing product and service ideas. And just creating landing pages to sell those services that did not exist. So they had these sexy pictures of, you know, a new scooter rental service, which is funny because now it's kind of coming from security.
There's all this scooter rentals out there, the pricing and everything. And when you clicked buy, it actually took you to like a survey, um, where, you know you to answer some questions. It blew my mind because it's such a brilliant way to test if there's true demand for what you're offering. Yes, it would be better if you got them to actually like put in some credit card information, but then I think you're kind of walking in a shadowy line there.
Yeah. I was just so amazed that people were testing. Sometimes it doesn't ideas in a weekend until they found something that was working and only then did they get the band together to actually try and make it? And we can look at companies like Dropbox. Who are enormous now, but started with this very process.
And the crazy thing is this client that I'm actually going to see later today. Yeah. In the last month we actually had seven teams doing this demand testing. And I can't begin to tell you how much insight this gives you certainly into. Is there a market there, is there a need there? However, the one thing I would say is to compliment that you really need to do deep prototyping to know that there's a pain and again, and that you might be able to address those, but already what we're starting to see.
Is this culture of learning and testing and not holding on to your product, vision, like a stubborn, mad scientist type, but rather saying, look, I'm going to go out there and solve a big problem and I will test. Many times, and perhaps my idea is going to change it quite a lot based on what I'm getting back.
And it's that feedback that is where we de-risked our project. And traditionally, that's not what we've done so already, we've got this huge learning, this practical advice of test and learn continuously. Yeah. So you've got this great recent example, Mike, I'm curious how different was the concept of what you and the client wanted to build at first versus where you are now after having gone through these several teams, several weeks worth of testing?
I would say that what's interesting is sort of the general notion of. We saw a pain in the market and we wanted to address it. I remember 17 teams. There's probably 25 30 executives. This was a serious accelerate, a program full time, eight weeks. The mission, the general ideas have not changed too much.
The idea to help a particular segment in a market in a particular area that has not changed. But boy, Chad, how we will address the pains of the user and the gains they're looking for that already has changed dramatically with a combination of these two principles, right? Testing market demand and prototyping with real customers.
And we just have very, very, the basic prototypes and we're about to launch into some deep design and user insights. So we've got a long way to go and already it's the, how you deliver the product is what's changing dramatically to what was first imagined. Yeah. That's really interesting that the kind of mission and core purpose for what you're doing doesn't necessarily change, but.
How you get there can be kind of wildly different based on your first assumption. Okay. Because this is the way you're trying to fit into the life of the end user. And that's where you've obviously made lots of assumptions and quick, real testing, correct you on that. And, and you know, too often we pick up a product and go, Oh my gosh, this is like the worst.
Did anyone dish this? Um, so that's, that's sort of the first big thing that we've got from Simon. And I wanted to point out to our listeners. I think you and I are obviously big fans of lean startup. And the interesting thing is that, um, Eric also wrote another book. Um, so he's got a lean startup, which do you think there is a bigger Bible?
In Silicon Valley, Chad, that is used by more people than the lean startup. I cannot honestly think Eric recent Sinek would have to be the two biggest, most influential authors for sort of contemporary tech entrepreneurs. Can you think of any Eric Reese is practical on every startup founders, bookshelf.
Others may have some other books, but I think everyone has the lean startup on their bookshelf. Yeah. The other thing is he wrote more recently the startup way, which deals a lot more with if the internal machinations of startups and large companies, as they start to, to go into their growth and maturity phases.
So I want to highlight that the startup way is another book by Eric F our listeners are interested in, of course, as usual we'll have links to all of these. In our show notes, which you can get on moonshots.io. But before we go into MVP and measurement skills, tactics and ideas, I wanted to ask you Chad, in reflection since 2011, when you first read lean startup, what stands out to you as like one or two of the biggest things that you've taken away from that book and embodied.
If you look at how you've worked in the last seven years since reading the book. Where has Eric's book, the lean startup inspired you the most. For me, all of us, myself definitely included have so many hits in assumptions, subconscious assumptions that we're making when we're working with clients or building products.
I'm always amazed at kind of my own like ignorance in assumption making, it's just, there's kind of a limitless capability for us humans to think that we know and can predict the future and the way things will be. And I think kind of the flip side of that for me, or the way I hack that. Is to really just be in conversation and dialogue with as many people as I can.
And so, you know, the storyteller in me, like I love interviewing people. I love embedding myself with interesting teams that are building cool and innovative products. And I think as long as I continue to keep my finger on the pulse and really am just sure that. I'm engaging in talking with people and doing those kinds of interviews.
And that is how I can work through and past many of the assumptions that I make. Yeah. I'm very much the same. And my reflection on the lean startup is I wish I had read it approximately like 15 years before it had come out. I started an internet radio station in Australia in 1990. And if only, yeah, I'd had lean start up there and I would have learned so many crucial lessons and you're right.
I was just guessing so much of it. The product itself was pretty cool, but. It just wasn't viable working out how to make money on internet radio in 19. Yeah. But you tried it and now you have all those learnings. That's informing what you're doing now. Right. That's the message that I love from Eric is while he does kind of call spending $40 million in five years of failure, T talks about walking away with lots of insights.
And he actually, a little earlier, I can't remember which clip there was this idea of innovation, accounting. I think, you know, what that implies is that there is a way to some metrics and measurements on this kind of maybe vague idea of like, do I know so enough about my customer and do I know enough about the problem?
And there is a way to begin these things. So here's him actually talking about how we can measure our way to success or failure. We're going to use actionable metrics, which are about per customer behaviors, things that can be measured at micro scale. And the first thing we're going to 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, they will have zillions of them over time. And we can't get into all the details of how to build those models. Of course, is a great book coming out and you can learn all about it.
Um, in the meantime, what we want to do is just figure out what are the real numbers for each of those inputs at micro-scale that's what the minimum viable product is for. So if there's some numbers, some spreadsheet, somewhere that says, Hey, 10% of customers who come to our website should register for our product.
Then we should have like a big banner in our office somewhere. That's like, we must have 10% conversion or we die. And then we need to 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 1% and it's supposed to be 10% and like, Oh my God, 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 and 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 1%, you know, it's 1%, but it's gotta be 10%. So a few iterations in it's 1%, 3%, 6%, 6.5%, seven and a half percent. Now it's not 10% yet. So the model isn't exactly working, but you can kind of say. Are we going to get there?
Yeah, probably. You know, each thing that we do seems to drive the number up a little bit. We seem to be kind of 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 1%, 3%, three and a half percent, 3.7, 5%, 3.8%, 3.81%.
Now the numbers are going up every time. So it's not like the numbers are going to, it's not like at zero, but you might ask yourself a question four or five, six months into hitting that asymptote. Are we ever going to be 10%? 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 10%. 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 going to make it. And you entered the land of death March. Yeah, those key metrics, that story he tells is so bang on many new companies are managing the success of their product on very, what he called gross numbers, which is how much traffic are we getting in very top line numbers, but it's actually like the conversion rates, the retention rates, the repeat visit rights.
That all drive the success of a business. And it's really empowering what he's saying. Instead of focusing on a very broad number, get one key metric like conversion rate, like retention and, and really focused on shifting that to the point of viability. I think this is the source of success. When we talk about measuring your way to success, it also means that if you're just not going to get there, don't beat around the Bush.
Just kill it. And actually killing product sounds like traumatic. In many, many ways. It can be a relief because it ends up sort of subconsciously we all knew it. Wasn't going to get there, but we didn't have the heart to admit it. I mean, I just love this thought, Chad. Hmm. When I first heard about this idea of MVP, I was like, Oh, you know, this sounds great building the minimum viable product, but for me still, that was even kind of like too big of a concept.
And I didn't really understand it, but in this clip, I think he does a good job of tying it. So the minimum viable product is the smallest. Most concise simplest version of your product or service that you can use to measure that one single metric. So you kind of have to come up with the metric first, choose the target.
And then what you're building is like the least time consuming cobbled together, but it will still measure that. Accurately thing. Yes. So that's what it means by minimum viable. And it took me a long time to kind of understand that nuance because we're always tempted to keep adding things in there, but it's like, Nope.
If you can measure that one metric that you're trying to hit, then that's what you need to work on and to it. Yeah. And it's all about getting to building something that is sufficient. To delight early adopter customers just sufficient just enough, because what we want to avoid is five years, $40 million as Eric did.
And in he's very candid about what you want to do is you want to invert that you want to do as little as possible to create enough value for your core early adopter customer, in order to know if you're on the path to success. But Eric also has some thoughts for us on how you actually build. The minimum viable product.
Let me say a word about minimum viable product. I know, you know, people will have heard of this phrase at least a little bit. The idea here is we want to kind of, most startups are torn between these two different approaches to building product one, which I call maximizing chance of success. It says, look, we're only got one shot at this, so let's get it.
Right. Right. That's what I talked about. Startup. Number one, we're going to ship it when it's right. And that actually is perfectly rational. If you only have one shot and you want to take the best shot, you can build the most perfect product you can. The issue is of course, you know, you can spend, I don't know, say five years of stealth, R and D building a product you think customers want and then discover to your chagrin that they don't.
So the other possible extreme approach is to say, well, let's just do release early release. Often people have heard that phrase and this just said, look, we'll just throw whatever crap we have out there. And then we'll hear what customers say and we'll do whatever they say. But the issue there is, if you show a product to three customers, you get 30 opinions.
And now what do you do? So minimum viable product is kind of a synthesis of those two possible extremes. We want to figure out what's the minimum set of features necessary to engage with it early evangelists, to start the learning feedback loop going. Yeah, he said it way better than I did, but you shouldn't be too hard on yourself there because there's a really big nuance here is talking about these one, hit one shot projects versus shipping fail, fast approach.
What he's trying to do is to navigate through that, to learn enough from enough people without building too much. And it is. And not being beholden to the whims of the masses, you know, that could pull your product app is in a million different directions. Absolutely kill your company, you know, death by a thousand cuts.
That's right. So what's funny is that he's really almost encouraging you to limit the actual product building. Yeah. He's almost saying differ being into the product build until you know, enough. So he's now in his perfect followup to this idea is that before you get to that building, make sure you've got the lessons and you've tested before we build.
So let's have a listen to Eric Reese, giving us some wisdom of what to do before you build. Yeah. It, it is amazing when you really think about all right. I want to, what do I want to learn? Um, classic thing to learn is will customers sign up for my product at all? If it was already built, if I already had it perfect.
You know, would they want to buy it for me? Well, easiest way to do that test is to put up a single one page landing page where we describe what the product is. We pretend we're, we've already built it and simply say, would you like to preorder this product right now? In most cases, when I've done that test, I didn't even have to make page two where I apologize that the product doesn't exist because nobody even wants it also possible to build a much less functional prototype.
Then you would normally think about, you know, an engineer building, uh, the key is to and assimilate as much of the experience for customers as possible. So there's a very famous company called Dropbox that today's when I saw them. Valley's hottest companies. They had this very complicated technology for file sharing that they were trying to build.
And the whole idea was it would give you this magical experience that just worked across all your computers, magic synchronization, and the way they built their MVP was not with an ounce of technology. They just made a video, a video of it, of this kind of prototype that they had done built on their computer that made it look like it would work like magic.
But the video showed you what the experience would be. And then they use the video to get people again, to sign up to pre-order, to commit, to be part of their community. And that was enough without any technology to show them they were on the right track. Hmm, I'm curious my cause of the timing of the lean startup and things like Kickstarter.
Like it's not a coincidence. The brilliance of spending the time and effort to create a video instead of spending like four or five years in research and development, it didn't drew Houston, like put that video on like Reddit or something, and then they got. Millions of signups for the service. Yep. And all of this comes from different ways to explore market demand, to build a product like Dropbox is going to take you a team of a dozen, a good six months to do in a meaningful way to get to MVP.
So if I could some crafty storytelling guy called Chad in Brooklyn to make these beautiful film that inspires what a great signal of before I hire my desk. So team of developers, the beautiful little film that I've just made has had a huge viral success. This tells me one thing. There is a pain in the world that we might be able to solve.
Cause people are that suffering from this abuser problem. I've got files in the cloud on my desktop. I want to sync them all magically. I take that as great signal. It's positive signal. That is so important in those early days. If you could sit there and say, Hey, our video got a hundred thousand views and a thousand comments, I actually consider that to be a meaningful test that we can learn from, well, why don't we look and see what people said?
What did they mention as their biggest pain points? Oh, it tends to be larger files or it tends to be Photoshop files or documents from outlook. I mean, who knows the point being. You can learn. And that's why it's so interesting that a guy who is an engineer, Eric Reese is an engineer. He's like, you can do all these things before you do anything engineering.
It's really interesting to me too. Like there's this massively successful company Kickstarter that has this idea as their business model, you know, that they're, you know, replicating for everyone and kind of. Baking that philosophy of testing and learning from the market before you're even building anything.
Now I understand that Kickstarter's changed a little bit, and I think many of the ideas and products that are showing up there and projects are a little more fully baked. Yes. Then Eric would probably advise you of, but it's a small criticism for platform, you know, that it's enabled at least tens of thousands, if not hundreds of thousands of makers, you know, to get products and services and films and music out to the masses.
Yeah. And this, this idea that ties together, the testing before you build. There's an idea in this path of MVP and those many key metrics that we were talking about. And it's really this huge topic is critical shift towards what is the right thing, learning that a product creator, an entrepreneur. Founder is having, how much are they learning?
And this really is at the core of Eric's spoken. He gives us lots of different things to learn about. So let's hear from him and talking about how important learning really is to the success of building a great, the core problem of a startup is you don't know who your customer is. You don't know if you're on the path to a sustainable business Haley's problems.
So the unit of progress in a startup is learning what we call in the start on validated learning, scientific, proven learning that you actually are, know what you're talking about. And so if, and that sounds pretty good, most entrepreneurs at that point are like, yeah, who's not for learning. Everyone's for learning.
But if we say no, no, no, that is the unit of progress. Anything else you do that doesn't contribute to learning actually is a form of waste. Including building too robust of a product launching too big in the press. I mean, launching in the press classic sign of a startup, that's about to, um, I wish they'd get the press to write about that.
That'd be great. Anyway. Sorry. Uh, those things are waste. They don't actually help you learn because if a hundred customers don't like your product. Then what does it matter? What the hundred and first customer that doesn't like your product, what's the learning value of the thousand customer or the a hundred thousand.
And so a lot of the companies I've built failed. So spectacularly not because the technology wasn't good or didn't work because we literally couldn't get anybody even to try it, to tell us how bad it was. Okay. That that's the kind of failure. That's the gluten, when we talk about, well, oftentimes the minimum viable product is simply an experiment that allows customers to sign up, you know, would you even have to create page two where you apologize, the product's not available yet?
Not if nobody signs up and that's the most common case actually is that you can't even get anyone to find out that you haven't built the product yet. And I understand not your idea, right? The problem I understand when you are in it, it seems impossible, but that's what we're trying to do is not when people get really fixated on the parts of lean startup that fit on a bumper sticker and a bumper sticker, bits of them are people's favorite parts, pivot.
Sorry about that. MVP. I know it's very tight iteration. Uh, you go on YouTube is a very funny video where there's a lean start expert is trying to convince a drug dealer. They need to iterate more. Like it's gotten out of control. I understand though, the bumper sticker stuff, people love, but the heart of it is to apply the scientific method to the process of entrepreneurs strip itself so that whatever you have you do as an entrepreneur that will help you learn faster.
That's what you do. And sometimes that's as simple as a landing page experiment. Sometimes it's more complicated and you know, tactics are not what we're trying to teach. We're trying to teach this set of principles about learning and measuring the right things. For me, this new or new to me, mental model of viewing entrepreneurship through the lens of kind of the scientific process.
That to me is the magic of what Eric wrote in the lean startup. I'd totally agree to put this into context, entrepreneurship, innovation, whatever you call it. It is really hard and the odds are incredibly low of success. And so therefore having a method with checkpoints measures frameworks is essential because you're literally embarking on one of the hottest things ever.
I mean, one in 10 startups kind of make it. That's it and incorporate innovation like 5% of things make it. Yeah, if that, so he's giving us some sort of map with stops along the way and freeways and side roads and all sorts in order to get us there. And I totally agree. It is demystifying. What is one of the hottest, most complex things?
It's art, it's science, it's everything in between. It's really important. If any of our listeners are embarking on building a product, starting a company, just read lean startup, right? Yeah. I actually had kind of a small revelation, listen to that last clip with regards to a client of mine that I have now.
And mrs. So great that I'm revisiting this book. Let's see here seven, almost seven years later. That's one huge fun part about doing this podcast with you. Mike is like you and I have some of the trust, these people in our careers, but I think diving back into their insights, you know, their wisdom, it's like Kuda thought that I could have learned from Dita ROMs, you know?
This year, or, you know, mr. Eric Reese here, but to get back to the client story, they have a relatively big list that they send out their thought leadership and content marketing out too. And they've been trying to push a new service offering and it didn't take off. It didn't take off. And the light bulb just went off and I was like, Oh my gosh, they went behind the scenes and figured out what they thought that their customer wanted.
And then they put it in front of them already, fully baked, and then they were met with crickets. Oh, I get it now. Oh, there you go. But it really is so powerful. So what we're talking about is rate of learning. That's inspired by Eric Greece. Or just any learning at all that is better than what most people are doing nowadays.
I'm realizing, yeah. The are here is that most products out there don't last for very long and a full of assumptions. Like when segway launched its product and it couldn't go upstairs, they didn't have charging bays. And people felt really awkward when they got on them. The list is massive when we really truly get to it.
The opportunity here is to put learning at the center and that's. Oh, so what we're doing on the show, I think we're just learning out loud together. Aren't we? Chad? Yeah. And it's funny too, cause this next topic that Eric speaks to is something that you and I have discussed as we've created this new venture, this new podcast together, the stakes aren't quite as high, maybe it's 500 company trying to create the new product.
That's gonna help them crush the competition. But there's this idea of like, okay, so. I'm learning, I've built my MVP. I'm iterating it. I'm getting my learnings, but how do I know if I'm on the right track or if I should kill it, or if I should do something different and it's kind of like the entrepreneur or the innovator's dilemma of like, not knowing exactly how to proceed.
And so Eric has a really fantastic laying out of whether or when you should pivot and when you should persevere. Three months from now, six mil, whenever it is, we're going to have a meeting to decide there, to pivot or persevere. I, that meeting, we will have the data about whether our efforts to tune the engine or 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 on a much more quantitative basis. We can't turn whether to pivot into a formula. I can't tell you what to do is still relies on human judgment. Just like science does.
But if we make specific predictions, if we use innovation, accounting as our accountability model, and we can be training our judgment to get better over time to do increase the odds of success, we need to figure out how can we pivot sooner. We need to bring our focus to validated learning. 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 have 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. You 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.
This one is like serious fashionable level product insight. And I just want to dig into this a little bit. What he's talking about is not just the testing and learning, but actually if you want to survive, the key is to test and learn and each moment. That you're doing a test and learning from it. You want to try and make as close to the next moment that you can conduct your test.
It's not just that you're learning, but how quickly you're learning will help you succeed. And it does this for a couple of reasons. First of all, if at 10 o'clock I test and learn, and then I revise my prototype and at 10 Oh five, I test again. If I keep up this rate of learning in one hour, I could have between say 10 and 12 customer interactions where I've tested and learned.
I am miles ahead of where I was at 10 o'clock when I get to 11 o'clock and the whole nuance here is that traditional approaches to product design have very long gaps between these moments of learning. Weeks if not months between. Oh, absolutely. Absolutely. So what he's saying is guys lock yourselves in a room and test all day long, hundreds of times with hundreds of different customers.
This is the ultimate because not only. Do you actually make progress into solving the customer problem? You actually align the entire team of product creators around it. Um, and it becomes this huge momentum shift. If you have a test today for half an hour, every day, Monday to Friday. And you do this for two weeks, two months, or for our whole year.
If you are open to the learnings, I guarantee you success. Yes, we'll come because you'll have conducted enough tests that your odds of success are massively high. I also guarantee you that your product and service will be in a very different place than when you thought it would be. And that's a good thing, because if you stick to what you thought you should have built, then you know, you're going to end up like Eric spending $40 million over five years to build something that no one wanted to use.
No one could even get there to tell them how awful the product was. That was like how few people that's. Right. So I wanted to share a little story about this same client. I was doing a program with these 30 or so executive seven different startups. And what was really powerful is I would have made Eric Reese proud.
I was dropping all these test and learn on them and showing them how to part of it. And it was so infectious for them because the validation. Finally demystified so much of what they were dreaming about that literally after our session had finished. So we'd gone for like half a day. One of my clients is texting me and said like, all these execs are running around the building, testing their prototypes and they hooked that.
Like they're addicted. That's all they want to do because. And this is the real message here for everyone. The more you test, the more you look into the eyes of a customer, ask them to do something with your prototype, learn from it, revise it, make it better. And then you just iterate that process. And a number of times you just get to like, ah, I think I know what they want.
I think I know what's going to work versus, Hey, I've got a nice PowerPoint deck and I, and a shop story, but I'm guessing everything inside of these days. That's it? That's the idea. Yeah. And I think what Eric is asking all of us to do is choose the target metric that you can test with your MVP and make not tasks completed, or lines of code written B you know, the measurement of how successful you are in building the product.
It's actually your rate of learning. That is the most important metric for your entire organization to be operating under because he says, you know, All of that time in between tests, in some ways it's just waste because learnings is the goal to be mined inside of the startup. It's so true. That's so true.
And that yeah, between the moments of test and learn allows you the time to fill in your own bias and perception. So you sort of abstracted and get a bit off track, but if you're testing so much, It's very hard to get off track because the message from customers and their experiences, their interactions is so strong.
But I think we got one last I thought, uh, from Eric. Um, and it's really when you're in this testing and learning moment, either with customers or asking why your product hasn't worked, there's a very powerful. Idea about what you can do to get beyond surface level problems and get to the real crux of things.
So let's wrap up with our inquiries and hearing from him, talking about how to solve problems with the power of asking why we use a technique from the Toyota production system called five whys. The idea is when we run into a problem, we have a server crash or a product that doesn't work. We want to get to the root cause of what caused it to fail and then fix that root cause behind every seemingly technical problem is actually a human problem waiting to be found.
Let me give you an example at my last company, if a server crashed, we would ask a question like why then the server crash. It would be because a new API was pushed to that server. But why was that? It's because we just launched a new feature that used that API in the wrong way. Well, why is that? It's because we had an engineer who was new and didn't know how to use that API properly.
Well, why is that? It's because that engineer was never trained. Well, why is that? It's because their manager didn't believe in training. So what seemed like a technical problem of a server crashing is revealed to be a managerial problem with that engineer's manager, the technique of five whys is to make a proportional investment in each of the five levels of the hierarchy.
So fix the server and improve that API and teach that engineer the proper way to use it. And also have a conversation with the engineer's manager. Hmm, I don't do this nearly enough. I know I was listening to it again. Oh, I could probably as a couple of examples where I could probably use this right now.
Yeah. I think what I'm taking away from here is I'm getting more and more interested in uncovering my clients. Biggest challenges that I'm hoping to solve and, you know, the collaborations that we kick off in the engagements and might be asking why once, but yeah, I can definitely see myself really using this technique to yeah.
Just get closer to the heart of what's really going on. Yes. And I cannot tell you in a product lens or whether you're just running your business this year, this art, it's really critical thinking what he's proposing here. And it's really establishing facts, asking why and systematically going in a discipline way too.
Core of the problem and whether you're trying to do that on your business or whether you're trying to do it with customers and the service or the product that you're giving them, what's really powerful here is if you're testing a learning your way through the five whys, here's what starts to happen.
If you're building a product and you serve an immediate use case or a problem. What tends to happen. And this is another sort of dark art of product design is that once you address a more surface level problem for a customer, they will allow you that'll give you permission to understand the bigger problems, the higher order of things they're trying to achieve.
And so a great product often goes right from the bottom of Maslov's hierarchy of human needs, right up to the very top. So you, uh, then offering a product or service that does a thing, or two has some features, which has some benefits, which helps people serve their mission of having fulfillment, uh, having impact on the world.
It can get that high and that's what great companies. Do they build a suite of products that get right up there. So if you use them solving problems by asking the five why's, whether it's a, just a tactical business problem or solving the problems of viewing customers, it is a great mechanism to unlock it like a truckload of value.
I love how kind of tactical that last bit is. I can use that. Like tomorrow
you could go on and on with Eric race. The body of work is so good. I really feel like we got this great sort of rocket ship ride from like, just stop test and learn. Don't jump into building your product, ask the right questions before, make sure there's some sort of market latent demand for it and whatever you do.
From a to Zed learn all the way. I mean, measure, learn, build, measure, learn. Yeah. That's the mantra, isn't it? Yeah. I've been really excited packaging. These episodes in different series from Apple to designers to now authors. I'm also excited to turn to our next series here and go into the world of investing.
Oh my gosh. I am so excited for this one. Who might we, uh, who might we learn from there? Oh, Chad. Well, the two classics. We're going to follow a similar vein to that of which we did with the authors to classics into more contemporaries. So for the classics, we're going. Warren buffet and Charlie Munger who have so much wisdom, I am a part excited and pop overwhelmed all the research for that show because Warren buffet writes an annual shareholder letter that is gold every single year, at least has investment, always dim, dripping out of it.
So we've got those guys. And then for our more contemporary ones, Chad, who you liking. I just read an interesting book about Peter teal called conspiracy, which Oh, you read that. Yeah. It doesn't necessarily relate to his investments, but he is a very interesting person and, you know, has very interesting philosophy.
So while I understand the mental models of someone like Charlie Munger and Warren buffet, I don't as much about Peter teal. So yeah, I'm interested in turning and looking at what he's doing. He has a great book called zero to one, which is essentially his whole philosophy. It is an amazing book. It's up there with the hard thing about hard things.
It's up there with Simon Sinek categories. Grace is amazing. So that'll give you a little sense of that. And then what about someone from Y Combinator? Yeah. Well, I don't think we could skip over Paul Graham. I think his essays that he's been publishing have, he's probably got over a thousand now. Yeah. Far are fantastic and required reading for everyone.
So we've got all of that to come. And do you think we might slot in a little special edition? I know people loved hot or not. You reckon we might slip in something. What's the French word. When you have a little something in between two meals. There's a fancy word. I'll have to look that up for the next show.
Yeah. Do you want to do something special before we jump into the investor series? I think it probably depends on some scheduling, but we definitely want to bring back favorite. Well, okay. I don't want to pick favorites. Sorry. Yeah. And I didn't say that one of our fantastic guests here on the show and Gary Hoover.
To talk about the history of disruption, which I'm looking forward to. That would be awesome. And just as a teaser, after the investor series, we will dive in and do a four part series on the greatest architects. And there's a lot for us to get into this so much ahead, Chad. I just want to say thank you to you for being with me on this journey.
As we learn out loud together, and to all our listeners who have given us so much great feedback, and I want to thank them for coming along the ride for the last 40 plus shows and for them staying with us right until the very end of show 42 with Eric Greece, I've really enjoyed it. Chad. I hope you're ready to rest up a little bit now that it's the evening in New York.
Oh yeah. Well, unfortunately, I've got back to back calls after this. You can probably hear my phone blowing up in the background there. Alright. Chad's got a dash and take the cold. Thank you ever so much, Chad, and to our listeners, that's it for another show of the moonshots podcast. That's a wrap.