Dan Olsen

Product Management Consultant and Author

Tactics for B2B SaaS from The Lean Product Playbook

Dan Olsen: We can, uh, jazz it up here a little bit. I'm excited to talk to you guys today. I'm Dan Olson. I'm going to be sharing some advice on mastering the problem space and how to achieve product market fit today. I'm just a little bit about my background so you know where I'm coming from. I um, started out with an engineering background. Actually my first job was designing submarines and then I moved out here a while ago to go to business school at Stanford. And that's where I learned about product management, uh, this career called product management. And when I heard about it, I said, that's what I want to do. Sounds awesome. And I asked people, where's the best place to learn how to do it? Since I had never done it and they said into it. So I was fortunate to get a job at intuit.

Dan Olsen: I worked there for a while, then I was a product leader in some startups and then I got into being a product management consultant, which is what I do today. Um, I also have a big believer in sharing best practices. So for four and a half years now I have a meetup called lean product down in mountain view. Um, where I each month I host a top product speaker, uh, as well. So if you're interested, you should check it out down, like I said, down into its headquarters. My Twitter handles that Dan Olson and I put my slides and talks on my website, Dan Hyphen olsen.com. Um, who hears in product management. All right, we've got, sometimes I speak at different conferences, we have a lot of product managers. I just want to start out with like adding, you know, sharing some deep wisdom from product management, which is the product manager's motto. So it's a little bit like spider-man's bottom guessing. We have some in the bay area, the best be some marvel fans who know Spiderman, who goes spider-man's motto, yell it out if you know it

Dan Olsen: with great power comes great responsibility. Right? The PM motto is a little similar, but it's a little different, which is with great responsibility comes no power basically. And we're laughing on the outside, but we're crying a little bit on the inside too. It's a little sad that we don't, we have to influence without authority, right. And get people to do things. So anyway, um, we're responsible for a lot of things as product managers. I'm sure the speakers today are covering a lot of different things that you know, we should be doing as pms. Uh, one of the main things we're responsible for is product market fit and product market fit is kind of a buzzword. It was coined by Marc Andreessen back in 2007. Um, and then it got popular with the lean startup movement. So, uh, some of the terms like MDP can be hotly debated within your company.

Dan Olsen: I'm sure people disagree a lot on that. For market fit, people talk about more simplistically like, oh, Box. Yeah, they succeeded because they had product market fit startup X. Sadly they failed because they did not have product market fit. So people talk about it simplistically like this true or false kind of condition. Um, and uh, as an engineering background kind of person, I was like, I wanted to create a framework for how to achieve it. And after working on so many companies and products, I kind of came up with the framework. And so that's what I want to share with you today. That's also why I wrote my book, the lean product playbook. Uh, I like to give a copy away. The way you can win a copy is to tweet. So if you send a tweet with my, a handle @danolsen, if you want to throw in some hashtags or whatever, uh, happy to give a book out later on I'll announce a winner on Twitter.

Dan Olsen: Um, but the key framework for how to achieve product/market fit is the product market fit pyramid. I want to walk you through that. This is the, basically the key framework for the book and how does she park market fit? It's got five layers, it's a pyramid, and each layer builds on top of the other layers. So the first layer is your target customer. The bottom, it's the foundation of the pyramid. Whose life are we trying to make better? Who are we trying to create value for? Everything starts with that. And if we change who we're focused on, then everything above it could change as well. And the next layer up for them is for that customer, what are their underserved needs are we want to focus on customer needs and how we can create value for them by by delivering customer benefits. And the word underserved is important there.

Dan Olsen: We don't want to, if someone's perfectly happy with how something's getting met today, then that's probably not what we want to target. We want to target things that aren't being served so well but taken together, this is basically the market. These two layers formed the market. And if you look in an economics or marketing textbook, it'll say a market is you know, a group of people that share a set of common needs. So that's the market. You don't actually control the market. You can decide which one you want to try to go after. What you control are the three product layers of the pyramid. And the first one is your value proposition. This is which benefits are we actually going to say our product delivers on and how are we going to do so in a way that's better or different than the competition? And this basically in an ideal world we'll build on top of underserved needs.

Dan Olsen: Um, the next layer up is feature set. This is the functionality that actually conveys those benefits to the user. And then finally the user experience, which is what they actually interact with to use the features to get the benefits. Right. And so one way of looking at this as these are the five key hypotheses that you need to get right enough to achieve product market fit. So what I'm trying to say is you need to be, you know, have a good enough idea about your target customer, their underserved needs, value prop, feature set in UX. And if all five of those are good enough, then you'll achieve product market fit. And when you see this framework this way, basically probably market fit is just how well are all the assumptions and execution that we're doing in these layers. How well does it resonate with the market?

Dan Olsen: Basically, so that's the product market fit pyramid. The other thing is, since this is a B2B conference, a lot of times we have more than one customer. I'm using customer in the broadest sense. So if you have a buyer versus an end user versus an Admin, basically each of those needs its own has its own pyramid, right? Each of those is a distinct customer with potentially distinct customer lead needs. And you know, at some point they might merge up into the same feature set in the UX, but they might be distinct. Like you can think of admin use cases where their admin UI and features that no one else can use. But um, so it's meant in the broadest sense, if you have multiple people or you have a two sided market, you've got to think about the needs and the pyramid for both of them.

Dan Olsen: And once I had this peer mentor realizing to create a process to help people work through these key hypotheses, and I call it that, to lean product process. And all you do is you start at the bottom with step one and you articulate your iPod, sees about your target customer, you move up to step two there needs step three value prop four, five and then when you've got to use your experience, whether it's a live product or a prototype, I'm a big fan of using tappable or clickable prototypes to test your hypothesis. Then there's a six step where you take, you take that prototype where your live product and you close the loop with customers to test with them and get feedback to see where you're at in product market fit. And this obviously an iterative process, but that's the lean product process. And what I'm, my focus of my talk today is just going to be that many product teams focus here.

Dan Olsen: They spend a lot of time on what features should we build and what features do our competitors have and what should the UX be. Um, and I think it's to the detriment of, of their product strategy. So what I'm going to be focusing on today, I only have 30 minutes, is just these two steps. I want to go deep in those two steps. Obviously target customers important, I just don't have time to get into that today. But there's fundamentally a big difference between these top two layers and these bottom layers. And the top two layers are what I call solution space, right? This is basically the solutions that you're building, that customers are using. Um, but to really deliver product market fit in a lot of customer value, you need to be think product teams need to be thinking a lot more deeply about these problems, space layers. So that's what I'm going to be focusing on today. Who's heard of, yeah.

Speaker 1: Which way is it pointing? Go for it. Sorry.

Dan Olsen: The better. Right? Cool. So we iterated, we're good. Um, we, we improve Mike market fit. All right, so, uh, and who's, you're in a problem space before. Here are some more stuff few people have. So I'm excited to hear more and more people using that term. But let me define how I view what those two different things are. Problem space is basically a customer problem, a customer need or a benefit that the product should address. So if I said, you know, I want to create a way to make it easier to share photos with your friends, that statement, make it easy to share photos. Your friends would be in the problem space. If the next thing that I said was, oh yeah and last month I built an app that actually does that. That app would be in the solution space where if my friend Mike was a designer and he created an awesome set of mockups for that app that was set, a mock ups would be in the solution space.

Dan Olsen: So that's the difference basically. Um, problem space. Also, you know, if you, you may know the user story format, a well-written user story as a blank, I want a blank so I can blank write problems, please focus on that. So I can like what's that core reason that it's going to create value for the customer. And again, solution spaces, specific implementation are designed to address that need. So we're trying to decouple that. A lot of times, most teams just a lot of teams just start jumping right into designing or building things without getting really clear on what problem they're trying to solve. Um, and it's, and I understand why at the end of the day, developers have to code something and launch something. Designers have to design something and we basically, we live in solution space so it's natural to be like gravitating towards solution space. But I think good pms are able to decouple problems and solutions, um, and get really clear that to make sure that we're clear on the problem and that our solution that we're about to build is going to solve that problem.

Dan Olsen: The example I like to share to illustrate this is when NASA was sending astronauts into space, they knew that the ballpoint pens that we use here that rely on gravity wouldn't work because there's no gravity up there. And it wasn't NASA. Um, but one of their contractors and it didn't ask them to do it. One of the contractors said, you know what? I think we could have been a pen that can write in space without gravity. And he went off and spent $1 million of r and d and he invented this space pen. I'm gonna have one right here. So they're pretty cool. I haven't verified it myself, but they tell me this rights in space. If anyone works at NASA and wants to help me validate that, that'd be cool. But basically, you know, they did it. And uh, and if you read about this, you'll see there's an urban legend basically that NASA spent $1 million.

Dan Olsen: It wasn't all NASA, but they did spend $1 million faced with the same challenge the Russians gave their astronauts pencils and you can actually get a Russian spacemen. It's a red pencil and a box poking fun at the space pen, right? So why do I share this example? I show the example one. Obviously if these two solutions are equally good at solving the problem than the one that didn't take $1 million and all that time and effort is better solution to higher ROI, right? That's the obvious lesson here. But the more subtle lesson here is that it's really easy, even when you're trying to focus on problems based, it's really easy to let solution space be, uh, thinking creep in. And I call it solution pollution. So when the head of the Fisher pen company said, you know what, I think I can have been a pen that writes in space and that was his problem statement.

Dan Olsen: He had some solution pollution in his requirements. What was the, what would you have is what was the pollution that he had? Yeah, the word pen is like he baked the solution in the requirements, right? Not surprisingly cause they were a pen company. So they were focused on pens. Right. Um, and so we want to basically avoid solution pollution. And this happens in our future teams, and I'll talk about this in a second. We want to avoid this, right? It would have been better if you had just been vague and said, oh wait or write in space. That would have been a little more solution agnostic. Right. And the number one tactic to get people, if somebody proposes something in the solution space, is to just get at why. Cause what's going on is in their head they're proposing a solution and jumping into it, but subconsciously they're thinking there's a problem and they believe that that solution is going to solve that problem. That's basically what's going on, right? And we can ask why. Even with the astronauts, it's like, why do astronauts need to write in space? Like why do they need to do that?

Dan Olsen: Anybody take up, write things down and refer to it later, that's an even better problem space name. And maybe that opens up the solution space to crazy Siri like voice commands or something like that, right? Where you talk to it or something like that. And how does this play out on our feature teams? Right? This plays out in our Jira tickets and Trello tickets where it says like, add a drop down that does blah blah blah. Right? Adam. But build builder wizard at an API call are those problems or solutions, right? Those are all solutions, right? And so we're doing that shortcut. We're skipping the problem when we do that same thing in Trello, write out a menu, create a setting screen out of database table. And so when you see someone on your team doing that, maybe that's the best way. Maybe that's the best way to solve the customer problem, but maybe not.

Dan Olsen: And we're not sure you have people just building something without really clear on the problem. So asking why is a key technique to do that? Let's talk about more of a software example. I used to work at intuit. Um, one of our big products is TurboTax who use TurboTax here. Yeah, we've forgotten about it and I was like six months ago and we wanted to just forget about it. That's cool. Right? So it's a tax present application. So it's in the solution space. It competes with another application tax cut. Right. And what we want to do, what we can do is try to map between the two. What you want to do is start on problems. We use a map, but we can try to reverse engineer what value TurboTax rates. For those of you that use TurboTax, what value? Why did you use it? What value did it create for you?

Speaker 1: [inaudible]

Dan Olsen: You didn't know the tax code or the tax rules, right? It's convenient. Yeah. Cheaper. Yeah. Ease of use. Yeah. Automation. Yeah.

Speaker 1: Cool.

Dan Olsen: Anybody else?

Speaker 1: The only option that, [inaudible]

Dan Olsen: Yeah, the last minute. If you, if you procrastinated, it's your only option. Right? So that's the thing. See, this is beauty. That's the beauty of it is you can have these great, you can go talk to customers and customer discovery interviews and get these value statements. Now, did I get the same statement from any one of you guys? No. So that's the thing about the problems because it's very messy. How am I supposed to, I'm the PM for TurboTax. How do I make sense of the automation versus the convenience versus the rules? Right? How do I make sense of that? Right? So it's like I forget, let's just code something and ship it. Let's not worry about process. But our job is to figure out the policies. I, I'd argue, PM's main job is to bring that to the table. The designers are going to design, the developers are going to build, right?

Dan Olsen: Our job is to really understand the customer and their needs and so we want to do is start out with some high level context. So if I had to, you know, you guys were given some detailed answers, which is great. If we got to some general context it would be something about like help me do my taxes, helped me prepare my taxes. Right. And obviously that's, that's not detailed enough. We want to get more detailed to the kind of statements that you guys are making. But the other person that really helped me appreciate the difference being problem space and solution space was the founder of intuit Scott Cook. And when he would give a talk to a group of pms like this, he always used to love the asking the question, who's the biggest competitor to TurboTax? And we'd all be, you know, excited and hope you would pick us so we could get the answer right for the founder.

Dan Olsen: Right. And he'd pick you and you'd say it's tax code. He's like, no, you're wrong. It's pen and paper. Cause more Americans get their taxes done with pen and paper basically. Right? Uh, catch up with me here. There you go. Pen and paper. Right. And that's the other thing is that you, a lot of times we focus on the software competitors that we have, but there are other ways that people are getting things met, right? Excel hacks or work arounds or other things. And so what we want to do is focus on the problem cause the problems don't change anywhere near as much as the technology solutions, the waves of solutions that come and go. So what we want to do is start in the problem space instead of the solution space. Let's say we were working on a tax product like TurboTax. Well you want to do is, you know, once you're clear on the context is that is it as a team brainstorm what are all the different ways we could help people with their taxes cause do divergent thinking.

Dan Olsen: We're not saying we're going to do all these things, but it's fun to explore the problem space to think about all the ways you could create value. We might come up things with, well it can check my tax a computer or compared to pen and paper, you can, you can make sure I don't make any math mistakes, right? You can file my taxes instead of having to print them out and go to the post office. You can file at the last minute and just push a button, right? It can ask you questions and help you maximize your deductions, save you money on your texture. It can help you reduce your audit risk. These are just for examples basically, but you'll notice that they follow a certain pattern. They all start with a verb, like an action word because it's actually doing something to create value for the customer and their written not from the customer, the the technology's perspective or the company's perspective, but from the customer's perspective.

Dan Olsen: Right? And so what you want to do is basically peel the onion. I want to show an onion here because a lot of times on product teams, we stay at the outer layer of the onion and it sounds good, but like the real way to create value and achieve deep product market fit is to peel the, peel the onion and get very specific. Now if you do that and you brainstorm, say dozens of potential benefits that you could do, um, it can be kind of messy, right? Even this little acne exercise here with six or seven answers was a little messy, right? Answers all over the place. So it is a little messy, but you will find that there are clusters of related benefits. So let's say we take a, these three benefits, help me prepare my taxes, uh, reduce my audit risk and check my return.

Dan Olsen: And we asked people in customer discovery, why is that valuable? Why is that valuable? Right? What I'll be doing is I'll get, I'll get them to kind of do higher level answers, right? And by asking them why? Cause people can start out very specific. Um, and I might find that these are all ladder up. We call it benefit ladders to a common theme of say empowerment or confidence. And the way this might go is kind of like the story you were saying is like, Hey, you know, I don't know the tax code. Maybe I'm not good at computers, I'm not good at numbers or math, but every year I got a file, my return or else you going to come after me or find me or throw me in jail. So every year I've been like stressed out having to do this and figure this out.

Dan Olsen: And then, you know, a friend told me about TurboTax, I used it, it just asked me questions and held my hand. And next thing you know, step-by-step, I'm done with my taxes. That might be the story about empowerment or confidence, right? And I call it again, a benefit ladder where even though there are different detailed benefits, they all ladder up to that same kind of benefit. There can be a completely separate ladder that has nothing to do with that. It has more to do with just saving you time. It's kind of an orthogonal benefit. Right. Some people mentioned that when we were just talking here and we can talk about will saving time, preparing, you know, if you took a stopwatch compared to the old way, it took me five days and now it takes me one day or filing right, mailing it versus finally doing it online.

Dan Olsen: And that could be a whole separate ladder about uh, saving money, saving money by maximizing your tax deductions or saving money compared to a CPA, right? So these are three distinct benefit ladders for turbo tax. And this is what I call a problem space definition. Basically you don't have to go like three or four levels deep, two levels deep is adequate. You know, you've got your detailed benefits and then your overall ladders here, right? But I think this is frankly like one of the main value adds that product managers can bring to the team is exploring this and defining this so that as ideas come up, we're clear on what problems are going to solve for people. We want to start here and then map in a solution space. Um, so I've spent a little time talking about the needs. Now I want to move on to talking about the value proposition and again, your value proposition.

Dan Olsen: Once we've explored the problem space, we've kinda suspended judgment. We're just exploring all the possibilities. Now it's time to figure out what, which ones are we actually gonna focus on? What are we going to actually tell customers that our product does for them and how are we going to be better than the other competitors that are out there, right? That's what your value prop is. And the tool that I like to use for this is the Keto model, um, which has to do basically on the horizontal axis with for each need that we're talking about, how fully does the product meet it from, not at all to the product fully meets the need and then on the y axis as a result of how much the product meets that particular need, how much user satisfaction or dissatisfaction results. And if it seems a little complicated.

Dan Olsen: The cool thing about the Keto model is it breaks all the benefits and features down into one of three categories. The first and clearest is a performance benefit or feature. The more the product meets this need, the more customer value or satisfaction is created. The lesson meets the need, the less, right? If we were in the microprocessor business and our chip was 15% faster than everybody else's, we'd be like 15% higher performance. If I was shopping for a car, say, and I saw two cars and they were pretty similar, but then all of a sudden I realized one car has twice the miles per gallon of the other car, all other things being equal, I'd pick that car because for most people, miles per gallon is a performance benefit, right? So, so that's performance. The second category is must haves. Now having a Mustang, it doesn't actually make anybody happy, right?

Dan Olsen: But not having the must haves makes people unhappy. That's the definition of a must have. Right? Um, and sticking with cars, say I was shopping for a new car and I went into the showroom and I saw a car that looked great and I read the Spec sheet on the window and I really liked the specs and I was thinking, Hey, this is the car for me. But then I looked inside and I realized, wow, there's no seatbelts in this car. Right? I wouldn't buy it because I'd be afraid of getting hurt or dying. Right? So seatbelts are a must have for a car. But if car a has five seatbelts and carby as a a hundred seatbelts, I don't say car B's is 20 times better than Cartier. Once you have one seatbelt per person, you basically flattened off and you've checked things off, right?

Dan Olsen: The final category is delighters. So are wow features basically. So I'm having, having not having a delighter doesn't cause any problem cause people aren't expecting them to be there. But having a delighter can create a lot of positive customer value. Not Today, but when the first car sticking with cars came out with GPS navigation, it was a delighter right before that people were putting out Google maps, you're getting lost. And then the first couple people that had GPS navigation just put in your address and it fundamentally changes how you got from point a to point B. But as we know over time, more and more cars got gps navigation and Garmin and Tom Tom came out with their their devices and now we all just use our phones. So that just shows that this is not a static picture. It's dynamic basically that these needs and features migrate over time.

Dan Olsen: So the yesterday's delighters become today's performance features and become tomorrow's mustache. And the pace with which that happens just depends on the level of competition and innovation in your space. But what we want to do is use these three categories, take our benefits, and use these three categories to categorize them to get clear on how we're going to be better than the competition. And we're going to put these into what I call the value proposition grid basically. And what you want to do to create this grid, I've kept this generic, is for your product category one per row, list out what are the must have benefits, a one per row, what are the performance benefits? One per would the delighter benefits. So that's step. Step two is create a column for each of your key competitors and then a column for your product. Step three is rate or score your competitors, right?

Dan Olsen: And so if you have numbers, you can use numbers or you can just use high, medium, low, it's fine. As long as the ratings make sense. As you look across a row on a relative basis, that's fine. But say you weren't in the microprocessor business, you could put numbers in, but you know, low, medium, high is fine. So in this case, both of our competitors have the must have benefit. Um, competitor a is the best performance benefit one. Competitor B is the best performance benefit too. They're both so. So performance benefit three and these guys a have a delighter here, right? So this is the backdrop upon which we want to figure out how we are going to be better and create more value for our customers, right? This is the essence of competitive analysis. And you know, I may be tempting to try to be high, high, high, you know, I run these workshops all the time and the other time I ran it and there were six benefits and one team put five of the six high.

Dan Olsen: So Steve Jobs has a good quote about, you know, a lot innovation is about saying no. So if there's ever a team that only picks one high, I award them the Steve Jobs Award. But, um, so we want to pick our battles, right? We don't have the resources to beat everybody on every dimension and it's not really strategic and it doesn't provide a clear value positioning in the marketplace. So given this backdrop, like we might go with a value proposition like this, of course we're going to have the must have, uh, we're going to do a little bit on performance benefit one. We're not going to try to be be better than competitor a, uh, we're going to say no and not worry about performance benefit too. And we're going to focus on being the best at performance benefits three, right? Maybe we've identified some market segment that really values that benefit or maybe we have some technology solution ideas as to how we can deliver better value than these other people there.

Dan Olsen: And then we have our own idea for a delighter as well. What matters the most from this exercise is what's called your unique differentiators. And that is what's the performance benefit where you're going to be the best and what are the unique delighters that you have basically, right? That's what, that's what we did that point in this exercise and in the process with lean product costs, we don't have time to cover the rest of it today. This would inform our MVP and our feature set and our UX design so that we go and test and validate this, but we want to get clear on what this is and a couple of points on how to create a winning value proposition. You know, you don't compete on my stabs, you just, you just don't compete. You have to have them, but you're not gonna win in the marketplace.

Dan Olsen: Right. And sometimes I see people launch MVPs that just have the must haves. And then they don't do well. You need to be the best on at least one performance benefit, right? If you can also have a digital edge delighter in addition, that's a very powerful combination and you and when you start to look at products through this lens and you see products that suddenly launch and like quickly become number one in that category, it's often because they've got this one two punch of a clear outperforming benefit and a clear delighter. And so I just actually want to close with an example of that. Now I've mentioned TurboTax and now I'm mentioning Instagram. Who's familiar with Instagram here? Right? Lot of people. So these are, I know these aren't B2B examples, but I bring them up because most people are familiar with them just because these are B to just examples.

Dan Olsen: Same concepts apply for your B2B products as I was saying, but, but Instagram was one of these products that when they launched, there were already a lot of other photo sharing apps in the market and yet they quickly became number one. And if we look at it through the Keto model value prop grid, I think we can basically reverse engineer why that was the case. So you guys remember when they came out, like what are some things that they did to drill out, delight or outperform the other photo sharing apps filters good. Is that a solution or a problem? That's a solution, right? So what was, if we do, why is that create value? What value did the filters create for you?

Speaker 3: Um, what about in your name?

Dan Olsen: Yeah, they make your pictures look good. That's right. Right. So, so, and they had a, and would you say that was a delighter or performance? I think it was a delighter. Yeah. I think the number one thing I get is that your filter's delighted by making my photos look better. That's right. Cool. So we've got their delighter. Any other delighters or performance, how did any other way they outperform the other photo sharing apps or the things they did to make your photos look good?

Speaker 3: [inaudible]

Dan Olsen: Share easily. Yeah. Yeah.

Speaker 3: [inaudible]

Dan Olsen: Yeah, Zach's turning his phone. Right? So when you take a picture, you can take a picture of this way landscape or you can take a picture of this way and you remember there were kind of annoying, like your pictures are suddenly square, like why are you making my pictures square? The reason they did it is if you were to try to put these kinds of photos in these kinds of photos into a feed, these kinds of photos would have to get shrunk down and it wouldn't look as good. But when they're square, you don't have to shrink any of them down. They all can be the same size and the feed looks nice. So that was a secondary feature that supported the benefit of making your photos look good when it was in the feed. Right. So we've got those as delighters. There was one way that they outperformed. And the typical way to know you're talking about performance is if you can measure something and quantify how they were better. Is there anything you can think of how they did something better? Yeah.

Speaker 3: Is [inaudible].

Dan Olsen: Yeah, the I, yeah, I think they're different people had social media stuff. Yeah.

Speaker 3: A low time.

Dan Olsen: Yeah. Times. So if you took a stopwatch and you talk like how long does it take the postmark or upload my photo, that's the key of a, of a save time benefit. You take a stop, watch it with the other apps, it takes about five, six, seven seconds for the other Apps to upload. But with Instagram it took like three to, you know, two or three seconds. Right. That was it. So they outperformed, but the funny thing is how did they do that? They actually did it with a clever UX hack and the guy wrote a post about it. You can find that online. What they did is all the other apps, uh, they waited, you would take a picture in the app and then it, and you'd look at it and there'd be a button that would say like post or share. And they would wait until the user pushed that button before they started uploading it.

Dan Olsen: Or The Instagram team just said, you know what, like 90% of the time the people were uploading a photo anyway, let's just start uploading it the second we can. So what they did is they started uploading it and then if they didn't upload it, they didn't push the button, they would just ignore it on the back end. Right. And I'm sure they had good network and compression and all that jazz, but that basically was it. So by the time you checked out your photo and push the button, it like two or three seconds later. And so their perception was that it uploaded faster. Cool. So let's put this into our grid, right? I want to show you this with the grid. So we had our mustangs or performance or delighters, we have other photo sharing apps. They have Instagram. This makes sense for what we're talking about, right?

Dan Olsen: We didn't even talk about the have. But obviously if you have a photo sharing app, you need to let me share my photos. Everybody does that on the performance, you know, post my photos quickly. We have low and because of their clever UX hack we have high and then I'll make my photos look good. We have, you know, no versus yes. Right. And again, back to the dynamic nature, do more and more products. They were the first one to really have filters, but now like most of them have filters, right? So they became, it went from being at the lighter to like you pretty much need to have filters these days. All right, cool. And does anyone remember ox? So these actually back to the unique differentiators, right? This is the Combo. That was what I was saying about having a powerful combination of a clear outperformer like uploading faster and a clear delighter that explains kind of how they were able to get number one in the marketplace in a crowded market.

Dan Olsen: And again, if you look through these lens, I haven't, I don't have time today, but I have in my other workshops and stuff. What was an Uber example as well? Is anyone remember what Instagram's tagline was back then? Back in the early days, I wouldn't expect anybody to, but again, it's in the same article. The guys shared it. Their tagline was fast, beautiful photo sharing. Right? And the cool thing about this tagline, did they pack a lot into just four words? They packed in there must have photo sharing from their value prop. They packed in their performance fast and they packed in their delighter. Right? So that's like a very, that's the other cool thing about value prop. Not only does it help you inform your feature set and how are you gonna win, but it can also help you have very clear and compelling messaging as well.

Dan Olsen: So I think that Instagram, clearly they knew what they were doing, um, when they made that tagline and how they're gonna win and beat the other photo sharing apps. So to sum up to master the problem space, you know, remember with no power comes great responsibility. Um, don't jump to solutions. Start in the problem space, avoid solution pollution. Uh, that temptation by asking why, uh, define your problem space with benefit ladders. Again, I think that's one of the main value adds you can do as a pm on your team. And then you can use a value prop creating keto model. They showed you to answer those questions. How will my product be the best? Um, as I mentioned, I run a meetup down in silicon valley, a down in mountain view. Um, you can go to that URL. Our next one is on November 8th with Barry O'Reilly, the author of Lean Enterprise. He has his new book unlearned coming out. We have dinner. So if you're up for checking it out, go for it. And then, um, here's my information, others, the meetup, your all again, I'll announce the book winner on Twitter and I'm happy to answer a few questions, uh, before we begin that going to get the next speaker up here. Thanks.

Speaker 1: [inaudible].

Dan Olsen: Yeah,

Speaker 1: Nothing. [inaudible]

Dan Olsen: Um, well you know, VCs, you know, VCs are famous for when entrepreneurs come in and they say who's your competition is like nobody, they don't like to hear that answer. And I think the reality is there is that people are doing today so you can use the same thing. You can stack it up. I mean, a lot of times save time tends to be one of the benefits cause the manual hack or the manual work thing is just going to take a lot more time. Right? So, um, if you focus on exactly how you're going to be better than the manual hack, you should be able to articulate with the customer benefits of saving time, um, or other benefits that are distinct to your solution. Yeah, I mean, um, yeah, and I think by doing customer discovery interview, so yeah. Yeah, that's what I would say. I think you can use the framework to, to, to get at how are you going to be more productive for them.

Speaker 3: Yeah. [inaudible] [inaudible] [inaudible]

Dan Olsen: Is new. What,

Speaker 3: when you tax the tax [inaudible] so how can I apply these principles? [inaudible] you're starting a new product or [inaudible] product and [inaudible] product.

Dan Olsen: Yeah. TurboTax is pretty mature. It's been around. It was on dos back in the day. Right? So the cool thing about them is the tax laws of course change every year, but they find new ways to add value. So going back to that problem space definition, right, of several years ago, for example, they did things like, oh, they, they said, hey, you're going to get a tax refund. You want your money now instead of three weeks from now. And so they created a problem. They talked to people, they realized some people want their money quicker, they're willing to pay for that. And so they offer that service. So it's definitely not just a static, you never get to the point where you're like, Hey, we've solved all the problems for the person within our context. You may have nailed certain parts of the problem space, but the question then becomes, what's the next incremental part of the problem space?

Dan Olsen: It's going to add value. So audit defense, early tax returns, talking to a person like upselling, like, yeah, we're going to help you TurboTax. If you have questions, you can go and do that. Right? So and what does end up doing is a lot of times those end up helping you segment your market and charge more for those incremental services. And so even so for any new incremental service or feature you're going to add, you got to go through the same exercise again, no matter how kind of mature your product is, you know what I mean? So I think TurboTax actually is a great example of how they found continually find new ways to create more value within the domain of tax and not just saying, oh yeah, it's just about doing your tax return. And so I think that's the trap that people fall into is, is, is drawing their problem space too narrowly. And I think it's actually because they're not drawing that constraint and problem space of drawing in and solution space. They said, Hey, we nailed these 20 features. We've got the longest feature checklist of anybody we're kind of done. But if you go back to the problem space and say, know what we're all about is helping people with everything related to their taxes, you will find additional opportunities to, to fill that mission, I think. Yeah,

Speaker 3: you put your product in editor's face and then maybe think about it that way.

Dan Olsen: Yeah, you could. Sure. Definitely. That's a good point. Yeah. Yeah. Yeah. And I think, I think, you know, by talking, you know, in any way you can talk to your customers, you're going to find things that you're not doing as well as you could or adjacent needs that you can, that you can find definitely.

Speaker 3: Yeah. Slide on here. [inaudible] and gone through this process already. But any chemo [inaudible] still not,

Dan Olsen: I don't know man. I mean I, they're not user stories. Like if you say build an API call, I don't think anybody would say that's and who thinks that's a user story? That's not a user story. It's a task that's an engineering task. Um, theoretically there's no real problem. If, if what you said is true about people being rigorous, I would argue though that it's great to have your devs know the why behind what you're doing. You know what I mean? Like cause you know, as smart as we are as pms, if we're the, I just heard you say the PM came up with the solution. Well I would want the PM designer and does a developer to come up with a solution together. And between the three of them, they might have a better one. Right? So the a common way to have have the problem and the solution is your support sub tasks.

Dan Olsen: And so what best practice I've seen is the PM writes a user story with the reason why, you know, kind of this problem space. And then the engineers put in the tasks what they actually are going to do and then you have that tight mapping between the two. So, but to your point, hey, if there's really good tight mapping and that thought work has gone somewhere else, I hear you. That's not as bad as just jumping right in. But I still think it's, it's helpful. Um, if the rest of the team knows the why, because there's always going to be little decisions they need to make on the margin and implementing a feature. You know, you can't fully spec everything out to the nth degree and it helps them to know why. And they may know something you don't, you may think you may have come up, well you think is the best solution. I'm like, Hey, you know what? I just got this new Java script, man. We just got this cool new UI widget. I think this would be even better based on, now that I understand what you're trying to accomplish. You know what I mean? So that's the spirit of it, basically.

Speaker 3: Yeah.

Dan Olsen: All right, cool. Why don't I stop there? I'm happy to answer questions at the break. Thanks guys.

Keep me posted on Empower 2019.