Dan Olsen Interview - Nir & Far

Hi, I'm Nir Eyal and this is the near and Far podcast. This podcast is about business behavior and the brain. On this show I do a few things. I read quick articles I've written about topics shaping your behavior. I interview authors of books I enjoy, and from time to time I devote episodes to answering your questions. If you want to ask me a question, visit the podcast page on itunes, go to Ratings and Reviews and ask me a question by leaving a review. I promise to read it and possibly include your question in a future episode. So please ask me anything now. Enjoy the episode and for more, you can always Visit me@nearandfar.com.

Hi, welcome to near and Far. I am Nir Eyal and today's guest says that you're probably doing innovation all wrong today. I've got with me my guest is Dan Olson. He is the author of this book, the Lean Product Playbook. Welcome Dan. Nice to have you on.

Great to be here.

So tell me, what are we doing wrong with innovation? How should we be doing innovation correctly?

Well, yeah, I don't know if people are doing it wrong per se, but what I found is a lot of people like Lean Startup has kind of taken the world by storm and been giving talks for a while. I used to say, who's heard of Lean Startup? When I would give a talk, a few hands would go up. Over time, more and more hands would go up. Now everyone pretty much knows about it. But what I find is that people have read the book, they're familiar with the high level concepts, they're really motivated, and then when they go back to their teams or back to their companies and actually try to do it in the trenches, they run into challenges or obstacles. The analogy I use is like when January 1st comes around and you decide I'm gonna get in shape and you're highly motivated and you join a gym and you buy some workout clothes and you show up at the gym, you have no idea what to do. It's not cause you're not motivated, it's not cause you don't understand the high level concepts. You just understand the details. So that's why I wrote a playbook that spends a lot of time focusing on making sure you're getting clear on problem space versus solution. Space is one of the key ideas and really understanding the customer needs that you're trying to address.

So back us up just for a second. So if you're not super familiar with Lean Startup methodologies, we what did Lean Startup change in people's mindset that got Us to this point.

Sure. Yeah. And I have a slide that basically summarizes in bullet points. Basically it's about getting explicit about your hypotheses instead of just having these assumptions in your head, talking about them, writing them down, and then figuring out what's the riskiest ones there. And how can we come up with cheap, inexpensive ways to test those and see if we're right or not? That's part of it. And getting out of the building, talking to customers and iterating rapidly. So those are some of the key concepts. And when I put that bullet point slide up, everyone in the audience kind of nods. And then when I say, well, yeah, you may have tried doing it and ran into challenges and everybody keeps nodding because it's hard to do.

So in theory, I mean, it sounds great. We've been talking about it for over 10 years now, about how this is a better way to make software. We should talk to our customers. I mean, not just software, all products, services. We should do rapid iteration, customer development. But what happens? Why doesn't the concept. I mean, I've seen it countless times where everybody believes we should be talking to our customers more. We should be doing more than just focus groups. We should actually be doing business. Build, measure, learn methodologies. But why does it fall flat? Why is it so hard to implement?

Yeah, I think. Well, a big part of it, I think is, which I write about in the introduction, is the whole problem space versus solution space. And it's human tendency. And it's so easy to just start saying, hey, let's build a product that's going to help people share photos, to just start coding it or to start designing it. I think it should look like this. Right?

Right.

And when you do that, you jump straight into solution space. And you haven't gotten clear on, well, who's this for? What are the real customer needs? What are the real pain points? And how is our product going to meet those needs in a way that's better or different? So that's what the problem space is all about. It happens all the time. You'll be in a feature team meeting and someone will say, we just need a wizard that does X. Or Maybe you're in B2B and some client says, we need you to build us this. And then you go off and build it, you launch it, and then it turns out they're not happy with it. It doesn't actually meet their needs because they just specified something in the problem space without getting rid of things. So a lot of it is it's Messy. The problem space is messy. If we talk to 20 users and said, hey, what's important to you? In sharing photos, they would each use different words. They wouldn't be computers spitting out the same string to us. You know what I mean? So it's kind of messy. They would be talking at different levels of specificity. And so several chapters in the book talk about how to, like, really get clear and define that problem space.

Are you saying we should always start in the problem space?

I mean, I think it's helpful to be clear what benefits there are. Now, the reality is, if someone's using an existing solution, you can go and talk to them and see what they like about it, what they don't like about it. So watching people interact with existing solutions can give you ideas about opportunities that you might address. Right. And it's not about being in the ivory tower and thinking about these things, but coming up with hypotheses. Again, least our approach. But hey, I think that these are pain points that people have, and then going out and talking to people to validate if that's the case or not. And eventually you will need a solution space artifact to show them so that you can get proper feedback, because you can't have these esoteric discussions with people. It sounds great if I go, hey, wouldn't you like an app that makes it easy to share photos? Sure. You say, sure. And the funny thing is, in your head, you may be envisioning a certain ui, and in my head, I'm envisioning. I guarantee they're not the same until we actually get it down to a mockup.

Because I feel like the way these things tend to happen is that a great idea pops into somebody's mind. So they start in solution land already. And I don't know if you can change that. Right. Like, inspiration comes from a vision. But then I think what you're saying is, as soon as you have that vision, we want to back up and get back into the problem space as opposed to just diving into the fun part of the solution space. But when should we pull back? When should we say, actually, wait a minute before we dive too far along into the solution.

So, I mean, the general lean approach would say, before you invest too many resources, the whole point is to not be wasteful. You know, Lean comes from lean manufacturing, back from the quality movement a while ago, which I studied before I moved out to Silicon Valley. It's all about eliminating waste. So the idea is, you don't want to say, hey, I have this idea. Have a team of 10 developers, go out for six months, code at, launch it, and then realize, oh, nobody else thinks that. And it happens all the time. All the time before you commit a launch. Yeah. So I think I like your ideas.

Yeah.

Have the whatever kind of breakthrough innovation idea, if it's in the solution space, great. But then kind of use, use kind of five whys techniques to be like, okay, why would someone care about this? What's it gonna do for them? And most importantly, what's your value prop? Like, why is this gonna be a better photo sharing app than the other ones that are out there? It's not enough to say, hey, I got clear on the customer benefit. You also need to get clear on why is it gonna be better than what's out there today.

Right. And have you seen that happen with like one big reason or have you seen that happen where there's lots of little reasons?

That's the thing. And I use the analogy of peeling the onion. I was talking to a startup the other day and I was going through my I have a product market fit pyramid to explain product market fit. Basically this book is on how to achieve product market fit. Which is interesting because if you Google it, people just talk about it matter of factly, like, oh, box succeeded because they had product market fit. So and so started fail because they didn't. It's not super helpful. Right?

Yeah.

But I asked them, I was like, the bottom part of the pyramid, it all starts with the target customer whose life you're trying to make easier and create value. Who's your target customer? And they're like millennials. And offhand that sounds like a good answer. But then you scratch how you think about it. It's like, well, there's actually a lot of millennials. They're not homogenous.

A lot of different problems.

Right. And so that's the thing and that's the challenge. You have to kind of iterate and kind of scaffold your way. And so you start thing and some high level benefit statement. Right. Of okay, we're going to make making people's taxes easier, but my advice is to peel the onion as you learn and talk to people and form more detailed diagnostics. Peel the onion and get down to the thing. It's like, okay, well not just we're going to help them do a better job on their taxes. We're going to like help them maximize their deductions. That's a very specific benefit related to that. Right. We're going to analyze their audit risk. There's ways to get really granular. Then what you do is make sure it's funny. I just did a workshop and it's funny because you can get situations where the team's building a feature and you try to map it back to one and you can't map, it's an orphan, it doesn't map to any of the problems. You're like, why are we building this thing again? You know, it's kind of funny. It's like, wait a minute.

So it's like the connect the dots.

Supposed to map them. Right. Okay. We're going to, if we're going to help them, you know, analyze their tax audit risk and we're going to help them maximize reductions, then that means this. Right?

Right. So let me ask you, so why are big companies so bad at this? I mean big companies try Skunk works, they try and invest in startups, they try and have incubators and by and large it doesn't work. Why is that?

I think there's a few reasons. I think one is a lot of times you still end up with a lot of stakeholders that have opinions about things and they can either shape the kind of context and requirements coming in or when somebody, if a team has air cover to kind of get going, then there's some milestone gate review and that's when kind of things can get bogged down. I think that sometimes there can be a lot of time and energy spent on stakeholder management which doesn't directly translate to innovation or customer value. Those are some things. I think the other thing too is just some companies, they forget what it was like to be a startup. Every company was a startup and so now they've got these big business units with big P&LS like hey, every product we make is 100 million or more in annual revenue. And they forget what it's like to like, it's like kind of analogy somebody uses like burning fires. You get these big burning fires, like burning 100 million, generating 100 million in heat or revenue. We forgot how to just get a little fire going and tend it and kindle it. And so what happens is they're like, oh my gosh, you've been at it for 9 months and you're only making 200k a year. So it's like there's no patience for the ramp up curve and iterating and seeing what the future potential could be.

Is it an oxymoron? Is corporate innovation just impossible?

I don't think so. No, I don't think so. I think that sometimes those Gunk work groups can do it. I think the interesting thing is what motivates a company, a corporation, to start going down this path. And I think sometimes it's usually fear, it's usually like, hey, we're gonna get disrupted. I see this coming.

So they see it.

That's a good motivator. Or they're worried about it, right? That's the best, frankly the best motivator. The other way is you have some leadership team or CEO goes, hey, you know what? I just feel like we're not innovating as much as you. We're not moving as fast. The products we're launching aren't getting the kind of receptiveness that we thought we were gonna get. So it can be either one of those that motivates someone to do it, but they're definitely your companies. There are people that make it work out, but it's usually like that motivation and usually the kind of leadership buy in and true leadership buy in.

Are there any big companies that are doing disruptive corporate innovation really well? Is there anybody you can point to?

That's I'd rather not say because I'd probably leave someone off the list and they'd be offended, but there definitely are examples of it. I think the other thing is what you see increasingly. I was just talking to someone in the ag tech space. The ag tech big companies have created these kind of incubators for startups and it's kind of like a seeding ground for them, you know what I mean? So that's like another way companies can kind of stay in touch with the latest innovation is by keeping kind of promoting and fostering these kind of ecosystems and staying close to those people. So that's interesting.

And you find that it's working. Have you seen that?

I've seen some of that work. I mean the general idea of companies acquiring other companies to continue to innovate, you see that all the time here in the Valley, right? Buying innovative products. So it's like build versus buy versus build decisions that you see happen all the time.

Give us some, some frameworks, some ways of thinking about product design that maybe we can carry forward that we could get from the book. Just give us a little taste of your favorite way of thinking.

So building on the problem space, solution space. The next thing is if say you do create a detailed definition in the problem space of all these benefits, then you're going to have to prioritize which ones you should go after, which ones are going to create the most customer value. Earlier in my Career. I created a framework called importance versus satisfaction. The idea is, okay, for each of these needs, we can ask people, how important is this to you? And different people have different levels of importance for different needs. That's the importance. And the satisfaction is, well, how satisfied are you with how you're getting that need met today? And basically it ends up being a two by two. And the low importance stuff doesn't really matter. And nobody does that on purpose. Nobody goes after low importance needs on purpose. They think it's high importance, but because they don't validate their hypotheses, they work on it, they launch it and they realize, oh, we thought this was important, but the customers don't.

And how would you ascertain that?

How do you can ask people? You kind of ask them like a survey. There's two ways to use the tool. One is kind of like a formal survey, which I've done, and I have examples in the book, where if you happen to have lots of customers and you can ask them quantitatively, hey, please rate the importance. Like in the book I share an example where this product had like 13 key features. And so then we kind of ask people to rate it so you can kind of see the relative performance of the different features.

Okay.

And the other way to use it just as a thinking tool, as you're forming your hypotheses, let's just divide this into low, medium, high. And this is what I do in my workshops. I often use Airbnb as an example and we talk about all the benef, but how are they going to be better than hotels? And then we have people rate, how important do you think that is for the customers? And they fall out differently.

And do you generally tend to see one overwhelmingly important feature that then you try and focus the product around that feature, or do they kind of tend to clump together? Is it different?

Some clump together. But what's interesting is it gets kind of multi dimensional, complex sometimes where it's like, oh, for this target segment, it all starts with the target customer, right? And what happens in Airbnb? One of the trick questions that I do is I just jump into customer needs. And the reality is people start listing them and some teams realize that there's a renter and a landlord and some teams don't. And so it's like there's two different users and a lot of times there's a buyer versus a user or a two sided market. You know what I mean? You need to kind of think through the benefits for both of those People.

Yeah.

And then when you get into it, then it's like, okay, well.

Staying in hotels, there's like the 18 year old backpacker who's very different than the business traveler as far as what's important and how satisfied they are with what's out there.

This brings up a really interesting point and something that, that I've really struggled with as I figure out what businesses I think could get big versus maybe what business I want to invest in or start. Market sizing has always come down to me. That's the one thing I think we've made product development more of a science through customer development. Lean startup, that's become more of a science. I've been working on customer engagement and habit formation, that's becoming more of a science. I'm having the toughest time figuring out how big something like this could be. If you had come to me with Airbnb or Facebook when it first started, or Pinterest when it first started figuring out that market size question for which market we should go after, have you come across any tools to help with that?

Gosh, it's funny because I agree with you. And the ultimate example of that is agile development. You see more and more adoption of that. And so when I speak to agile teams, my talk is called how to make sure what you put in your backlog makes sense. Because you may have this Ferrari just crunching out features every two weeks that are high quality, but if you, if what you're putting in doesn't make sense, it doesn't. You know, the other example, like you're saying is you may really address a need, but there's three people in the world that have it and you may nail it. Right.

And you just happen to talk to those three people.

Right. Well, there's availability bias. Yeah. So, but then it's funny because it's like, you know, there's like bottoms up estimates and there's bottoms up approach of talking to people and validating things. And then there's the old, you know, like the business plan, tops down, total addressable market kind of thing.

Right? Yeah.

I think of the examples you listed, Airbnb might be the one to be easier to see because you're like, well, how much are people spending on hotels today? We can disrupt that.

That's true.

Facebook and P, those are user pay models. Right. So, yeah, Right.

But every one of these companies, they take an existing market. And even if Airbnb would have sat down and said, okay, let's say we replace all the hotel rooms in the world, what would that look like? That's actually not their cardinal achievement. It's that they unlocked.

I know, they created. Right, they created bigger. Exactly.

So hard to estimate. But back to what you said earlier about the backlog, that's a constant problem of, you know, we've got 1600 things we could build. What do we build? So any tools for thinking through.

That's basically why I developed that Importance versus satisfaction was like, okay, we've got all these feature ideas for this new product. Which ones are we going to use? And we found out, okay, this product, for example, this feature, it's really important, but it's also people are super happy with how we did it. So I was psyched. My second thought was, let's not spend any debt resources.

How do you ascertain the satisfaction? The importance I got. You're asking them what about satisfaction survey as well.

It's the same where you just ask them to rate satisfaction. And that's actually in some sense that one's probably easier for a customer to answer because they know like I use this thing, how happy am I with it or not?

And what about for new features that you can't just ask them because it doesn't exist?

That's a tough one. Yeah, so that's a tough there. The satisfaction is basically like, you know, however you're getting it done today.

I see.

So like the counterexample I use there is like in the upper left quadrant. High importance of satisfaction is Uber. Uber's done a lot of things right to be so successful, right. As far as product work, you know, great rollout plans of different cities, logistics, operations, marketing. But I think a fundamental reason why is they addressed a high importance need. If I asked a bunch of people, hey, how important is it to get to your flight on time? How important is it to get your meeting on time or wherever you're going? It'd be pretty high.

Super important.

And then you know how the cab situation is in San Francisco, right? It's like you used to have to call a cab. They may or may not show up. If they showed up, it might be late, right? And so you can imagine asking an array of questions to people and saying, hey, think about the last 10 cab rides you did. How satisfied were you with how punctual the driver was, how comfortable, how clean was the car, how comfortable was the ride, how safe did you feel on the ride, how polite was the driver? How easy was it to pay? And there'll be low, right? It's really about. That's the problem space. That's how you probe the problem space is by getting in and creating those facets and not just saying, how was your ride? Not staying at the superficial layer of the onion, but getting into what those attributes are.

I love it.

And you don't have to already know them. You know, you gotta do some qualitative to figure that out.

Yeah. Awesome. Awesome. Really great. Well, thank you so much for coming on the show. We really appreciate it. Here's the book again, the Lean Product Playbook by Dan Olson. Great book, highly recommended. And thank you again for watching near and Far. Thanks for listening to this episode of the near and Far podcast. You can always find more at my blog, nearandfar. Com. And don't forget, if you have a question you'd like me to explore in a future episode, leave me your question. The former review for the podcast on itunes.