Stig Brodersen 13:06
Eric actually comes up with a really interesting way of approaching this by saying that, if something is working out, it’s typically the product development department that would say it’s because of cool features. Then the marketing department would say it’s probably because of the launch.

Whereas if things didn’t pan out, it is who’s to blame now, right? So the marketing department didn’t do as good a job communicating the product, or they will tell the engineers to have all the right features, instead of basically just starting and asking the customer at the very beginning what is it actually that you want.

It’s just really, really hard to do when the product is already developed and it’s actually quite simple, because you’re already anchoring people’s mind to what kind of product that they want when you have made a full product launch. I think it’s a really good point that you have there, James. I think everyone can probably testify that they have fallen into that trap,

James Meirowsky 14:04
It’s easier to sell somebody something that they want than it is to try to convince them that they want it. Unless you’re Steve Jobs, right?

Stig Brodersen 14:16
But a really great discussion, guys, and really takes us to the second part of the book: steer.

The intention of this part is to figure out what it is really that we should be focusing on? So the first part was more about the vision, in terms of laying the foundation.

Now that you have somewhat of an idea of what your customer wants, how do you steer your organization into the right direction? I I think the main concept really to understand from this segment is the “build, measure, learn, feedback” loop. Let’s just call it a feedback loop. So how can we learn the fastest way so we can improve our product?

James Meirowsky 15:01
Yeah, Stig, that was a great point. When we’re really talking about this “build, measure and learn feedback” cycle, it’s really important to get through that as quickly as possible. I think it’s also really important to highlight how you determine what these three pieces are? That’s definitely one of the things that they discussed in the book and you kind of have to tackle it backwards.

You start with a learning piece. You say, “Okay, well, what metrics can we add to our solution to be able to track and answer these questions that we have?” Then once you figure out what those metrics are, there are a couple different categories which they talk about.

They talk about actionable metrics vs vanity metrics. I think those are very important components, but once you define what those actionable metrics are, then you can understand what we need to build in order to be able to collect these metrics. What do we need in our solution that will enable us to measure the metrics, which then answer the questions that we were trying to answer in the first place.

Preston Pysh 16:02
The thing that I really took away from this section, and just from my background with doing this, in different projects, is part of the culture with this is that you should never, it’s not like you go through this cycle, and then you complete it and you’re kind of done with it. Again, the culture is that you continuously are constantly looking at new ways to improve the process: new ways to update it, new ways to measure it. It really is a cycle that should never end and it should be built into the mindset of everyone who’s working on your team, that just because you fix something and you feel like you have an optimal solution, that it doesn’t stop right there.

I’m going to go back to the paper house scenario. In that story, the first time that we built one of these little paper houses, it took 15 minutes or 20 minutes to go through the whole process. Then after the scenario was done, the instructor would say, “Okay, now let’s see how we could optimize this process. Where were your value-added steps? Where were your non value added steps? How can you cut these in? How can you add more things? How can you realign your workforce so that you can actually produce more at a faster pace, and you come up with what you think will be a better scenario, and then you run it, then you run it again?”

At the end of this, you take something that was literally taking you 15 minutes to do one paper house, and you’re able to turn that around into a 45 second task with zero defects because you went through this iterative process, and you came to the solution.

The one thing I really remember from my master black belt that taught me after we got this down, like 45 seconds, I went up to him and said, “That has to be the fastest you’ve ever seen anybody do it.” He said, “If I gave you guys another five tries, you could probably get it down to 15 seconds.”

In my mind, I’m thinking that’s impossible. That’s physically impossible, but he was dead serious. And so, that’s the culture and mindset. I think that that’s really important for people to understand that when you’re going through this, you’re optimizing a process around customer specifications, and you’re trying to optimize that, you should feel like the job is never done. I think that’s a really important takeaway.

Something else that I want to highlight is your idea on measuring a lot of people when they start going through this, especially when you get around qualitative type things. The initial inclination of a person is to say, “Oh, well, that’s impossible to measure. So let’s just go on to the next thing, what could we possibly measure, if it doesn’t have some output from the computer, then we obviously can’t measure anything.”

You have to get out of that mindset, you have to come to the idea that you can literally measure anything. That might mean you go to customers with surveys, that might mean you go to employees with surveys, I don’t know, but you have to figure out a way to somehow quantify things so that you can collect as much information as possible, because that’s going to give you the clues and the tools to go about fixing and optimizing it in the future.

Stig Brodersen 19:04
Yeah, and a different thing that the entire discussion about how to measure things and risk metrics to measure in the first place. That’s really interesting, because it introduces the concept of innovation accounting, which seems pretty much out there the first time you hear that, but basically, he has a great point.

Je’s saying that if you look at traditional financial statement metrics, you might be coming up short, and he came up with an example for a company here that was consulting. He said that the company simply couldn’t understand why their top line wouldn’t grow. This was a software company. And he said, so which metric am I looking at?

Well, they were looking at the total number of users and then they were talking about the price. They have the same amount of users and they have the same price. So therefore, they have the same top line.

Then Eric Ries was asking them, “Why don’t you measure how many new sign ups you get per month and how many people leave?” It actually turned out that 39% of the users were new users, but they were typically leaving in a month, even though they were paying customers.

So just by measuring that, two good questions came up: why is it that we get so many new signups? What is it that we’re doing right? How can we perhaps improve that even and why are we doing it right? Then the other was: Why are people leaving, again, are we not making our product sticky enough so that they will stay with us and we can actually grow?

That’s just an example of when you have the right data, you can make the right decisions. The feedback loop is about setting up the processes so you can have the right data to make the right decisions. That was really something that resonated with me.

James Meirowsky 21:02
Yeah, one of the concepts that they introduce is just a couple of things. One of them is the MVP, which is the minimum viable product. A lot of you probably definitely heard about it before.

As you’re developing your MVP, it’s really important to try to get feedback based on a truly minimum product. It may not even be developing something that users can interact with. Maybe just drawing something on a piece of paper and getting that feedback.

Ultimately, the reason that you’re doing all of those things, so that you can have a discussion at some point in the future about what they would call pivot or persevere.

Pivot is when you take the product that you’re working with, you’re analyzing the data that you’ve gathered, and you have to come to maybe some hard conclusions or things that are difficult to swallow. If you’ve gathered the data, and it’s just not working well for you, then you may have to take your application and maybe kind of pivot the application to a solution that consumers do want. So it may not be your initial vision or initial leap of faith that you’ve defined, but there may be another direction that you can kind of head. That’s what the whole pivot meeting and discussion is about.

Maybe the data that you’re gathering really provides you the insight that says you ae on the right track and you will keep going down this path. That’s where you kind of go down the perseverance path.

Stig Brodersen 22:18
The whole concept about pivot is really fundamental. I think it’s important to stress that because you’re really testing a fundamental hypothesis for the entire business. It’s really, really hard to do, because you already invested so much time and energy in doing what you’re doing.

One of the examples that was in this book was the company Wealthfront. I don’t know how many people know Wealthfront. They are in asset management, but that was not how they started out. They actually started out as a computer game.

I know this might sound weird, but they had this underlying thesis that they would attract a lot of different games to play this game. Then based on that, they will find the best asset allocators. Also, they had this idea that when people figured out that they probably didn’t make that much money in the financial markets, they would probably allow the better players in this game to allocate the capital. That was the fundamental hypothesis for this business.

To begin with, Wealthfront really got a head start. They had more than 400,000 players. It was all a free game, but they were thinking, “Yes, I really figured out how to break into this.”

Now, the problem was that they needed to turn into a paid model one way or the other. So they were asking, “Well, how many people would like the best players of the game to allocate their capital for them?”

It turned out that of the 400,000 players, only 14 of them were willing to be paid members, which clearly was way less than expected.

Another thing was that only seven people in this game out of 400,000 were actually skilled enough to actually handle the people’s money. They didn’t even know if they’re actually interested in doing that. So basically, they decided to pivot and they decided to start all over.

The thing they realized was that they had developed really great tools for identifying the best manager. So the best *inaudible* I mean, that was really silly, but they know what to do. But the entire setup in terms of how to attract customers, which has been extremely costly for them, they needed to scratch all that simply because they were testing the fundamental hypothesis.

Preston Pysh 24:27
Let’s go ahead and transition to the third part of the book, which was “accelerate.” In this section, one of the things that he talks about to really kind of allow your company to break through and start to accelerate is this idea of the five whys.

So the example that he gives in the book, he says let’s say that a company was receiving complaints about a new version of their product and a feature was missing. The first why you’d say is, well, why is the feature missing? The answer might be because the server had failed.

Then if you go to the second, why you might say well, why did the server fail? And then the person might say, because an obscure subsystem was used in the wrong way. So then you’d say, well, why was it used in the wrong way? Then that person might say, the engineer that used it didn’t know how to use it properly. Then you’d ask the fourth time, well, why didn’t they know how to use it properly? Then they’d say, well, because he was never trained. They’d say, well, why was he never trained

Then because managers don’t believe in training new employees, because his team is too busy. So when you start digging down the path, and you start digging down this hole, you can see that maybe the issue is a training issue.

That may be because the company doesn’t have a policy or a training program, part of the company that might be the root cause of why it failed. And so, the person who doesn’t go this deep, they might just go and replace the server, or upgrade something that isn’t necessarily the root cause of what’s going on.

However, when you go five whys deep, what you’re actually getting at is the root cause, and you’re able to stop the issues that are causing those failures of whatever it might be. I think that this is something that is really important for people to apply in anything that they’re doing, what their business is, they’re trying to hit that accelerator in the direction that’s trying to go.

Stig Brodersen 26:19
One of the key things here is that it’s actually very difficult to implement. I mean, this probably all made a lot of sense, when we were just talking about you should just ask why. But if you think about it, asking the question can almost feel like you are provoking that person.

It’s about having a culture where it’s okay to say why. The way that this is explained in the book is that you should have what he calls a five why master. So basically, you should have a person on the team that has the authority to ask why. It should always be taken in the best possible way. I think from this, like an *inaudible*, it seems really interesting, but I think I would challenge everyone to sit at the meeting and keep asking why. I think you will probably experience a lot of friction.

James Meirowsky 27:24
Especially coming from a corporate culture, right? It has to be acceptable and it has to be okay to challenge problems and address issues, not just from one person, but from everybody that’s in the room.

However, you really have to have that one leader, that’s driving that conversation, make sure that everybody doesn’t get sidetracked and start going down these tangents about this problem or that problem. You have to stay focused and really say, okay, so why did this happen? Why did that happen?

Preston Pysh 27:50
One of the stories in the book that I really liked was about batching. So he provides this example where two people were licking envelopes and putting stamps on them, and basically like assembling a letter to mail. He said, you have a dad, and maybe a son, we’ll call it. The dad is going to raise his son by basically putting these envelopes together and then mailing them. The dad was going to take 50, and then the son was going to take 50.

In the story, the son says, I’m going to fold all the envelopes, first all 50, then I’m going to stuff them all in all 50 of them, then I’m going to lick the envelope. Then I’m going to put 50 stamps on. The dad said, well, I’m going to just you know assemble one at a time where I’m going to fold the letter, *inaudible* then put the stamp on. A

The question is: Who’s going to finish faster? Is it going to be the dad who’s doing them one by one? Or is it going to be the son who does the batch where he’s doing one task, but he’s doing it 50 times and then doing the next task 50 times? I’m really curious. When you guys were listening to this, did you guys already know the answer?

James Meirowsky 28:58
I kind of had an assumption just because the story was being told. I kind of thought where it was kind of headed.

Stig Brodersen 29:04
Yeah, well, I definitely fell into the trap. I was like, “Of course, you should just do a small task. Everyone knows that a lot faster.”

James is probably right. I should probably have thought about why you would bring up this example when it’s so obvious that the kid was so much faster when he wasn’t by the way.

Preston Pysh 29:21
For anyone who’s listening to this, the kid who’s doing it by batch is going much slower than the father. Whenever you think about it, the argument that I like the most, and I find myself in this situation a lot, especially whenever I was young and building cheap furniture is I always would batch things and then I would mess up on one of the mistakes where I’d put the screw in wrong, only to find out that I’ve put the screw in wrong on three chairs or four chairs or whatever before I realized that that was a mistake.

That’s one of the main things with batching is if you do let’s say you folded 50 envelopes and you folded them all wrong. You’re going to find out and it’s going to be a painful lesson to be learned as opposed to the person who does one unit completely from head to toe from start to finish. They may learn the mistake right then and there. So that’s one thing.

Stig, what was the other reasoning of why the single flow is faster?

Stig Brodersen 30:18
Well, I think that you might already have touched upon it, but it’s simply easier to pivot. That was the main thesis, because as you said, if your fold is wrong, you only need to reform one envelope, not 100 or 50. This is time, but your time is money so it’s really about mitigating costs. That’s basically the point of this.

Preston Pysh 30:41
Alright, guys. This was a fantastic book, I think it’s really important for anybody that’s in operations. If you’re an operational kind of person, or you’re getting ready to have a job in operations, this book is an absolute must read, just a great book to read, easy to read, well written.

Before we conclude this, we want to go around the horn real fast and capture everyone’s number one takeaway. I’m going to throw it over to Stig first, and then we’ll go to James.

Stig Brodersen 31:06
My number one takeaway was that you need to ask the customers, but it’s not enough to just ask them. They really need to put the money where their mouth is. I think that was probably something that I haven’t thought too much about. I heard all this about surveys, asking customers, but really requiring people to pay for what it was… First, how do they really act? Not only how would they say they would react, but if they really need to purchase this product? How are they going to react?

I think that was probably my number one takeaway, getting back to that loop again, and again and again, and then finding the best product for the customer.

James Meirowsky 31:48
Maybe one of the biggest lessons I learned from the book, or the basic ways, was about accountability and blame. It’s easy to develop a product and deliver that to a consumer. You spent all this time in engineering, and then it’s not successful. It’s easy to blame the consumers, right? It’s like saying that just wasn’t the right product for them. They just didn’t want this. We went to the wrong demographic. It’s hard to accept that accountability.

What this framework does is kind of shifts that accountability backward. Another great takeaway revolves around this concept of redefining what productivity is, the Lean Startup challenges the reader to feel accomplished at the end of day, based on value that they’ve given to the people using a product as opposed to maybe the more traditional feeling of accomplishment around how many boxes did you check off it on your task list at the end of the day.

Preston Pysh 32:36
Yeah, so mine would be, well, Stig stole mine. So I can’t do that one. That was about the customer, but I’d say my second one would be the lean mindset at the start of the company. If you’re starting a new company and you really kind of take these ideals, and you breed them into your culture, I think that that has the ability to really have a huge impact in the long run. It can be really beneficial for a company.

Amazon comes to mind. For me, this is a company that is all about lean manufacturing. I would like to believe that that started on day one with the way Jeff Bezos founded the company. It was really indoctrinated into the culture there that you run around with this lean mindset and this improvement process that is constantly taking place. How can we optimize? How can we focus on the customer giving them exactly what they want?

I think because they started out thinking that way, when they became a multi billion dollar company it was that much easier to keep those values in place as they move forward. So if you’re getting ready to start a company, or you’re wanting to grow it, even if you want to keep it small, maybe reading a book like this, and really thinking about it from that context would be really beneficial for you in the long run.

James Meirowsky 33:57
I have a quick question for you guys. Did you get the feeling after reading the book that you can almost create any product based on any idea and at the end, it would be successful? That’s really how I felt after reading the book. I was like this is a really good framework. It’s maybe not 100% of a blueprint, but it really does give you that feeling.

Preston Pysh 34:17
I think if you’re talking about an online business, yes, I felt like you could bring me an idea. I really felt like I would have some of the tools or at least the incentive to be able to start something that was an online business.

But if it was a brick and mortar, I think that you’d have a much harder time kind of taking the framework that he’s talking about, because a lot of the book is about online business.

James Meirowsky 34:40
Yeah, I agree with that.

Stig Brodersen 34:42
I think you’ve said it right, James. It’s really a framework that we’re talking about. It’s not a blueprint at all. It’s really like how to look at cutting costs, how to look at collecting information from the customers, and I think that they’re really just timeless principles.

I don’t think I was as optimistic as you probably because I’m not as good with computers as you are, but I was really positive about starting new projects, because I got this feeling that I could scrap it without putting too much time and money into it. I guess that was really a huge takeaway for me.

James Meirowsky 35:15
Preston, you get a background around handling some projects, right? What were your thoughts around the whole? It’s called an agile framework,? But from a more of a less traditional waterfall project management type perspective, do you have any thoughts around that?

Preston Pysh 35:27
From my experience in the project management realm, it’s all about the critical path. It’s all about knowing what that critical path is and what it is not. Knowing what’s in parallel, what’s in series when you’re trying to develop something that has a lot of things going on all at the same time.

So if you’re a project manager, and you have events and milestones that are tied from one to the next, and you can’t figure out which one has to proceed the other, that’s where you get yourself in a lot of trouble. Your assumptions are so important when you’re dealing with a really large project because sometimes you’ll make assumptions and you don’t think that something’s on your critical path.

It just added a month to maybe your burn rate per day is like $300,000, it might be a really high number. If you add 30 days is something that you weren’t prepared for, I mean, you just got throttled. So I think it’s really important for somebody who’s handling a large project and knows what those milestones are to really understand what is a serial or parallel task, and then knowing what your critical path is, and then making really good estimates on what those cost implications might be.

Outro 38:40
Thank you for listening to TIP. To access our show notes, courses, or forums, go to theinvestorspodcast.com. This show is for entertainment purposes only. Before making any decisions, consult a professional. This show is copyrighted by The Investor’s Podcast Network. Written permissions must be granted before syndication or rebroadcasting.