Anyway, I'm Dan Olson. It's a real pleasure to be here at Productize Conference for the first time. I just want to give a big thank you to Andre and the Productize team. They've been putting on a great conference. So hopefully you guys can join me in a quick round of applause.
Thank you, guys. Thanks. Conference has been great.
Lisbon has been great. I'm excited to be here because I actually grew up like less than 400 kilometers away in Spain. So it's awesome to be back. And I'm excited here to talk with you today and share some advice from my book on the Lean Product Playbook.
Tim made a lot of great points you're going to hear again in my talk. But I actually want to start out with one of the most closely guarded secrets in the product management community. I just go straight to the important stuff. And that is the product manager's motto. And does anyone know Spider-Man has a motto?
Does anyone know Spider-Man's motto? So yell it out if you know it. With great power comes great responsibility, that's right.
So the product manager's model, it's similar, but it's just a little bit different. And it is basically, with great responsibility comes no power. So we're all laughing, but we're crying a little bit on the inside, because it's a little sad.
But anyway, product managers, as we saw from the Atlassian talk, they're responsible for a lot of things, right? And one of the things that we're mainly responsible for is achieving product market fit. And product market fit was actually coined by Marc Andreessen back in 2007. It became very popular with the lean startup movement. And anytime you have a buzzword like product market fit or MVP, we just had a whole talk on MVP. MVP is probably the most hotly debated term out there.
People having violent arguments about, this is an MVP. No, that's not an MVP, right? Product market fit, people talk about a little differently. They talk about it almost simplistically.
It's like, oh, Facebook succeeded because they had product market fit. Startup X, they failed sadly because they did not have product market fit. So it's basically like synonymous with true or false success.
And it's not super helpful if you're responsible for achieving it, right? And if you Google product market fit, you won't find a lot of good guides on how to do it. And I found in my career after working as a product leader at Intuit and then as a product leader at startups and then helping companies and then being a CEO and founder and talking to groups like this or product managers for many times, basically I started to see a pattern of like what had to be true, like the conditions in order to achieve product market fit.
And basically... That's why, basically, I wrote the book, The Lean Product Playbook, that Renee mentioned. It's basically a guide on how to achieve product market fit.
And my background is engineering, so if I want to achieve something, I want to, like, create a rigorous framework. And so I have a framework and a process in that book. And I'm actually excited. That's why I wrote this book, to kind of give you a tactical how-to guide. I'm excited to give away a few copies.
If you guys want to enter the raffle, just send a tweet. My Twitter handle's at Dan Olson. You can throw in the Productize17 hashtag, and I'll announce the winners later on Twitter. But basically, the key framework in the book is the product-market-fit pyramid.
And it's a pyramid, and it has five layers that's hierarchical that build on each other. Let me explain it to you real quick. So the bottom two layers are the market, right? It all starts with the target customer. Whose life are we trying to make better?
Who are we trying to create value for? Whose pain points are we trying to address? And literally, everything builds on top of that.
So if you change the customer you're going after, then the whole pyramid falls down. You have to start over again. The next layer up is for that customer, what are their underserved needs? What are the needs that that customer has?
And within those needs, which ones are underserved? And we'll talk about that more in a minute, but we don't want to basically address ones that are already well-served, if we can avoid that. But these two together are the market.
And if you look at a marketing textbook or an economics textbook, it'll say the definition of a market is a group of people that share a set of common needs. So that's the market. Now the top three layers are where the product piece comes in.
And that's really where you have more control. That's where you basically form your hypotheses and execute. You don't control the market. You can pick which market you want to go after, but you can't actually control the market.
So I like to represent your product as these three key hypotheses you have to get right. The first is your value proposition, which hopefully builds on the underserved needs. Like, okay, out of all the needs that we could deliver and address for a customer, which ones are we going to say our product does a really good job at?
And more specifically, how do we plan to be the best in the market? How do we plan to have our product be better and different than the other products that are out there? That's basically where product strategy lives.
The next layer up is feature set. Okay, great, once we're clear on our value proposition, what's the functionality that we need to build to deliver those benefits and customer needs, basically, right? And that's where the concept of MVP comes in, so that we don't overbuild before we realize we're going in the wrong direction. We want to validate exactly like Tim said before we invest too many resources.
And then finally, after we're clear on our functionality, then comes user experience design. And that's what actually brings the functionality to life for your customers, and that's what they use and interact with. And when you see the pyramid this way, basically, you've got the market, you've got the decisions and hypotheses you're making about your product, and product-market fit is just how well are the decisions you're making up top, how well do they resonate with the market that you're going after. And once I created this pyramid, I realized, you know, this is just a way to work through your key hypotheses.
I can create a prescriptive process that you can follow step by step, and that's the lean product process. And all you do is you start at the bottom of the pyramid with getting clear on your hypotheses about who your target customer is. You work your way up to what do we think their underserved needs are.
Then we work up to what do we want our value proposition to be, how are we going to be better or different. What's that MVP feature set that we need to build? What's the user experience design? And I'm a big proponent actually of valid testing or validating before you build your code.
You know, with clickable and tappable prototypes, you can actually do a lot of great testing, improving or disproving your hypotheses. So there's a sixth step, which is once we have a UX prototype, or if we have a live product, then we close the loop, and we go and we actually close the loop and talk to the target customers that we started out with in the first place to see where we're at with product market fit. So those are the six steps of the lean product process. I don't have time to go in depth in all of them, but I'm going to cover the key steps here with you today and close out with an end-to-end case study of it being applied for a real-world product.
As I said, the first step is determining your target customer, and I should say that this process can be applied for a new product. Obviously, if it's a new V1 product, you can apply this process. You can also apply it at the feature level. So if you're building a new feature for an existing product, it's really clear that you can apply that. Also, if you're building like a V2 product, you can apply it.
And you can even apply it if you have a product where you haven't used any of these techniques already. You'll find ways to assess where you're at in creating customer value and improve your product market fit. And I just want to acknowledge, especially if you're building a new V1 product, you have a blank piece of paper. It's like, okay, who's your target customer?
There's a lot of anxiety and uncertainty. I just want to acknowledge that. It's okay to start out with some rough tentative hypothesis about who you think your target customer is and then iterate it later. Because the first two steps...
are so intertwined and related that as you get out there and talk to customers, you're going to revise who you think your target customer is. But let me show you and explain why it's so important. Because what happens a lot of times in product management, whether we're talking about a target customer or we're talking about a product requirement that we want to deliver, is there's often a tendency to stay at the high level, the superficial level. And it sounds like a good answer, right? I was judging a competition once and I asked the group, who's your target customer?
And they said millennials. And at first I was like, wow, that sounds pretty good. It sounds specific.
But then I thought, like, how many millennials out there? There's millions of millennials out there, right? And their product had to do with a certain product category. They could have easily revised it even further. But let me show you why it's important.
That once we talk about a need, let's talk about, say, the need for transportation within 100 miles or 100 kilometers of your home, right? You may need to get to work every day, to get to school, to get to the store, whatever it is. This is a need that a lot of people have. And if we just stay at that superficial level, we're not going to be able to create a lot of value.
But when we look through that need through the lens of a specific... customer, then we'll see that the detailed needs, even though they share that high-level need, the detailed needs and preferences are quite different. So let's take two different customers that have this need.
On one hand, a soccer mom. Soccer is very popular in the States. People play football, as you guys call it here, on the weekends, and parents drive their kids around. And then let's take a second type of person who likes to get around, a speed demon, someone who likes to go fast, right? And imagine we did 20 discovery interviews with soccer moms, and we said, hey, tell us what's important when it comes to transportation.
And they might bring up things like, well, I'm carrying my children and all their equipment and their friends, so it's got to be big enough to hold all that stuff. The car has to be big enough to hold that. I'm driving my children around. They're really important, so I want the car to be safe. And I'm actually doing a lot of driving to all these different places on the weekend, so I'm thinking about how much money am I spending on gas, and I'd like the car to have good fuel economy.
Those might be some of the examples of the detailed needs that we hear. If we interviewed 20 speed demons, we probably wouldn't hear any of those things. We'd hear things like, well... what's important to me is that the car go really fast and that the car looks cool and that it makes me look cool when I'm driving down the street.
And those would be the things that they might care about. And you end up with very different products as a result, right? They both serve the big need of transportation, but they are optimized for the product market fit for that target segment, right? And I like to talk about cars, but think about all the different shapes and sizes of cars that you see on the road out there. They've done a good job of understanding those target segments and optimizing the product for that.
The second step, once you get clear on your target customer, is identifying their underserved needs. And this is a key concept when you're talking about customer needs that I found really helpful, is problem space versus solution space. Who's heard of problem space before?
I'm really excited you start to hear people talking about it more. I've been talking about it for a long time. Let me explain the two and we'll talk about why it's important basically.
But problem space is a customer need or problem or benefit that you want your product to address, that it should address. So if I said, hey, I want to know what your problem is. I want to create a way for people to easily share photos with their friends.
Letting people easily share photos with their friends is in the problem space. So a well-written product requirement, a well-written Agile user story would be in the problem space. In contrast, in solution space is a specific implementation, either a product or a design, that's intended to address that customer need or requirement.
So if right after I said, yeah, I'd like to create a way to make it easy for people to share photos, and I said, and by the way, last weekend I coded an app that does it, that app would be in the solution space. Or if my friend Mike was a designer, he said, Dan, I created a design for you, here's a mock-up for you. That mock-up will be in the solution space. So that's the difference.
And what happens is we live in the solution space. Most people work in the solution space. The solution space kind of pulls you in.
In many product teams, they just rush right into solution space to start building or coding without getting clear on the problems. And so you want to make sure you spend enough time in the problem space before you proceed to the solution space. The example I like to use to highlight this is when NASA was sending astronauts into space, they knew that the ballpoint pens that we use here on Earth wouldn't work because they need gravity.
And it wasn't NASA, but one of NASA's contractors, Fisher, the head of that company, said, you know what, I think we can invent a pen. that's going to work in space without gravity. And he went off, and he spent a million dollars of R&D, and he invented a space pen.
I have a space pen here. I haven't had a chance to make sure it works in space, but they tell me it does, so I'll trust them. Faced with the same challenge, the Russians gave their astronauts pencils. And you can actually get a Russian space pen. It's a pencil in a box.
It's like a joke, kind of poking fun at this. Why do I bring up this example? I bring up this example because, one, obviously, if these both equally met the need, of being able to write in space, and the one that didn't take a million dollars and all that time and effort, is a better solution, right?
Better ROI. The second reason I bring it up is, even when you're trying to be focused on the problem space, it's so tempting that the solution space just kind of finds ways to creep in. When the head of the Fisher Company said, you know what, I think I can invent a pen that writes in space, he actually was polluting his problem space with a little bit of solution space.
So when he said, I think I can invent a pen that writes in space, what was the solution space pollution that he had? Anybody? Penn. Yeah, he said Penn.
He like embedded the solution in the problem statement, right? It would have been better if he had just said a way to write in space. Just be a little vague, a way to write in space.
And then, you know, from Lean Startup and the Toyota Production System, we have the five whys technique. Hopefully, you're familiar with that. We say, well, why is that important?
Why, why, why, right? And we said, well, why do astronauts need to write in space? We might come up with a better answer, like, well, they need to be able to write information down and refer to it later.
That's an even better way of articulating the requirement. Like maybe then we don't even have anything to do with writing and we have some kind of series system where you talk to it and it reads back to you or something like that, right? So that's the other reason that I bring it up basically is that how does that play out in our feature teams?
When you write a JIRA ticket and it says build a drop-down, build a menu, build a wizard, drop-down menu wizard, those are solutions, right? And so you want to use the same five-wise technique and say why are we building that? Well, we need a way for the... customer to pick their destination city.
Okay, well, let's say that is the problem space in the ticket, and then we'll say maybe a drop-down is the best way to do it, maybe it's not. Let's talk about more of a software example. So I used to work at Intuit. One of our big products is TurboTax. It helps people do their taxes.
It's a software product, so it's in the solution space. It competes with another software product, TaxCut, that's in the solution space. And what you want to do is, like I said, start in the problem space and then map over.
If I had to ask people, hey, what does TurboTax do at a high level, again, at the very, very high level, people would probably say something like, it helps me prepare my taxes or helps me do my taxes. And we can map back and forth. The other person that really helped me appreciate this problem space concept was Scott Cook.
He's the founder of Intuit. And he would give a talk to groups of product managers and he would say, who's the biggest competitor to TurboTax? And we would all raise our hand and hope he picked us. And if he picked us, we'd be like, it's TaxCut. He's like, no, you're wrong.
It's pen and paper. Because more Americans were doing their taxes with pen and paper. So that's the other thing about the problem space.
It helps you really understand what is true competition and substitutes for the need that you're addressing. And those market layers of the pyramid, the needs, they don't change anywhere as quickly as the solution space and the products, right? In the book, I talk about the desire to the need to listen to music on the go that started with FM transistor radios. And then we went to Walkman. And then we went to MP3 players.
And we went to iPods. And we would just use our phones now, right? So the technology solutions came and went, but the fundamental need to listen to music on the go was the same throughout the whole time. So what I advise is, before you get in solution space, let's spend some time in the problem space. And this, again, is too high level.
It's good to have an umbrella concept of what you're trying to focus on. But this is the fun part as a team, where you get to do divergent thinking and brainstorm what are all the different ways. This is what we did in the workshop yesterday.
What are all the different ways that we can help people with their taxes? And we might brainstorm things like, well, computers are good at math, so it can help me check my taxes and help me avoid mistakes. It can help me file my taxes.
Instead of printing them out and going to the post office, I can push a button and file them online. It can help me maximize my deductions. It can ask me questions about, hey, what did you spend money on this year? And you may be able to deduct things on your tax return.
It may be able to help me reduce my audit risk by looking at what I'm filing and saying, hey, this looks kind of risky, right? And so what you want to do is brainstorm as many of those as you can. We're not saying we're going to do all these in our product, but it's good to explore the problem space. The other thing is good problem state statements have this kind of format. You notice these all start with an action verb because it starts doing something for the customer.
It's creating value for the customer. It's also written from the customer's perspective. My taxes, my deductions, my audit risk, right? So that's how we've gone on kind of in the problem space, write statements that are like that. And when you do explore the problem space, basically...
You want to brainstorm, you know, dozens and dozens and peel the onion and get a very rich definition of what you could do. When you do that, the problem space is messy, I should mention, by the way. If I had time, I'd ask everybody here, you know, what benefits they would want. You'd give me a whole range of answers, and it'd be hard to make sense of that. So I just want to acknowledge that.
But what you find is you find that there are clusters of related benefits. For example, let's take these three benefits. Help me prepare my taxes, reduce my audit risk, and check my return. If I did five whys with the customers and said, why is it valuable that it reduces your auto risk?
Why is it valuable that it checks your return? We get them to go from the more detailed level and get them to move up to higher level reasons for why they like it. So you can envision a ladder.
We call it a benefits ladder. And those five whys, we might end up with a story like, well, that it's all about empowerment or confidence. And the narrative might go like, well, before TurboTax, I'm just not good at math. I didn't know the tax laws. I was kind of scared and intimidated to do my taxes.
but with TurboTax it just walks me through and I get everything done, right? Fundamentally, an empowerment or confidence, an emotional benefit. There could be a completely different benefit ladder for other benefits about saving time.
It has nothing to do with confidence. Saving time, preparing. Like before TurboTax, it took me three days to do my taxes. Now it only takes me, you know, eight hours and save time filing. And we could have a third different ladder called save money where it basically saves money.
And so this is what a problem space definition looks like. Basically, you don't need more than one level, but you just basically organize all the different benefits that you could potentially do. Now, if you follow my advice and you do this, you're going to end up with a lot of different benefits that you could do. We obviously can't do them all.
And basically, we're going to have to prioritize. The other thing I want to illustrate with TurboTax is that you actually, I've spent all this time talking about TurboTax without talking about any features. And you can actually spend a lot of time in the problem space if you focus on it.
It turns out that... TurboTax has a feature mapped with for each one of these benefits, right? And so the other side benefit is you want to have that clear mapping. If you have the clear mapping and you have a well-named feature, then just by somebody looking at the name of the feature, they can figure out how it's going to create value for them pretty much, right? If you follow my advice, as I said, you're going to have a lot of things you could do.
The next question becomes, great, Dan, now we need to converge and prioritize. The framework that I like to use for that that I developed is importance versus satisfaction. So I want to explain that real quick.
Importance is on the y-axis. It's for the need that we're talking about. How important is it to you? For a given customer, right?
And if I had like three different needs, one might be low importance for you, one might be medium, one might be high. And if I ask someone else, they might have a different answer for that. And then on the x-axis we have how satisfied are people with how those needs are getting met today with whatever they're using today. Again, low, medium, high.
And you can envision this as like a rigorous survey with, you know, quantitative methods. Or you can also just envision it as a thinking tool for your team where you just talk about low, medium, high, and you plot things where they are. But let me divide this in a quadrant so we can talk about the different parts. In the bottom left, we have low importance of user need, right, and low satisfaction with what's out there today.
In the bottom right, we have low importance of user need and high satisfaction with what's out there today. At the end of the day, neither of these quadrants are really worth going after because it's a low importance need, right? Why would you spend your precious? time and resources going after this.
And people don't do this on purpose. By not doing these kind of lean user-centric techniques, they think they're creating something valuable and important and then they only realize after they launch that they didn't. In the upper right quadrant, we have high importance of user needs, so that's better. It's something that's really important to people.
But we also have high satisfaction with the current alternatives. People are relatively happy with what they have today. That's a competitive market.
And I'm not saying you shouldn't go after that, but you need to be like 10x better. You need to be really clear on how you're going to be 10x better. than the established player that's up there.
The first thing I always think about up here is like Google search. You know, how important is it to find what you're looking for online, the information you're trying to look up. It's pretty important. But it's not like people walk around going, gosh, I can't get this Google thing to work.
I can't find what I'm looking for online. It works pretty well for people, right? And then finally in the upper left quadrant, we have the high importance of user needs, so that's good. And we have low user satisfaction with current alternatives. That's where opportunities live, basically.
And they may not be there forever because other companies are trying to find these opportunities and pursue them as well, but they do exist when you look at things this way. The company that occurs to me up here is Uber. They've done a lot of things right to get to the scale of business that they've gotten to, but I think an unspoken reason why they've been successful is that they're fundamentally addressing an upper left quadrant need. If I said to you, how important is it to get to your flight on time at the airport?
How important is it to get to that business meeting? How important is it to get to... you know, whatever meeting you have, it'd be pretty important.
And actually, the taxis in Lisbon have been pretty good, but back in San Francisco, they weren't that good. They wouldn't show up on time. You know, you can imagine asking questions about, hey, how satisfied were you with your taxi ride? How clean was it?
How safe did you feel? How polite was the driver? How easy was it to pay the person? You can imagine some low satisfaction scores on those. So that's an example of an upper left quadrant.
And what I like about this framework is it's meant to be a visual framework. So what I'm trying to say is, If there's a product represented by this red dot that addresses a need with that level of importance, with that level of satisfaction, then that rectangle created by where you plot it is a proxy for how much customer value that feature actually creates. And if there's another product represented by the green dot that addresses a need with that much importance, with that much satisfaction, then it creates that much more value.
And when you see it this way, you realize that... The opportunity to create value is just the area to the right of where the best product in the market is that meets that need. And that's why the upper left quadrant offers the biggest opportunity because of the most area to the right. And if you have an existing product, you can apply these techniques to basically create more value by improving the satisfaction with which you meet that user need. Now, if this seems kind of like theoretical or conceptual, this important versus satisfaction, let me show you some real world data.
This is from a product that I worked on, and we had 13 key features, and we had a lot of users, so we actually surveyed the whole user base and had statistically significant data. And so now, instead of high, medium, low, we have importance going all the way up to 100, and we have satisfaction going all the way to 100 as well. And each of these dots is one of those 13 key features plotted with its importance and satisfaction.
And the number to the right is the satisfaction number, just so you can more easily see it. As the PM for this product, the first thing that jumped out at me was this thing up here. I'm like, great, people are telling us this feature is 100% importance, and we're getting 98% satisfaction.
I was excited about that. My second thought was, I'm not going to spend any of my development resources on this. I'm going to go find something else that's going to create more value rather than messing with that.
And, you know, we had a cloud of features here, and we had this one here. But basically, this one was the one that was in the upper left, right? Had relatively high importance and low satisfaction.
So we used importance and satisfaction to prioritize that. And I was excited a few years later that I discovered the book What Customers Want by Tony Olwick. And he also has a quantitative approach for importance and satisfaction that is similar to the one that I came up with. So that gave me a lot of encouragement and confidence. And if you like this idea of getting quantitative about it, I'd recommend checking out his book too.
All right, so once we get clear on what the underserved customer needs are, the next step is to define our value proposition. Okay, which needs are we actually going to claim our product delivers on and how are we going to be better? and different than the competition. And before I moved to Silicon Valley to get my MBA, I actually studied lean manufacturing.
And one of the things that I learned in that program is the Kano model. And you're seeing it applied more in product management, which I think is great. But I like to use Kano model as a framework to articulate our value prop.
Let me explain it to you real quick. On the x-axis, we talk about how fully does the product meet the need, from it doesn't meet the need at all to it fully meets the need. And then on the y-axis, It's as a result of how much the product meets the need, how much user satisfaction or dissatisfaction does it create. And if this sounds a little complicated, don't worry. The Kano model is really simple.
It breaks everything down into one of three categories of benefits or features. The first and easiest to get your head around is a performance benefit or feature. This is simple. More is better.
More creates more customer satisfaction. Less creates less. If we were in the microprocessor space and our chip was 10% faster than the other chips, right, we would be outperforming them. Chip speed would be a performance benefit.
Sticking with cars, let's say I was looking at two cars and they were pretty similar, and then I suddenly realized that one of the cars had a better fuel economy than the other one. All other things being equal, I'd pick that car because fuel economy is a performance benefit for cars. That's performance. Second category is must-haves.
So having a must-have doesn't actually make anybody happy, but not having a must-have makes people unhappy. Again, sticking with cars, say I was buying a new car, I walked into a showroom and I saw this... car and I loved the way it looked and I read the specs, I loved the features that it had, but then I looked inside and I realized, hey, it doesn't have any seatbelts.
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 car B has 100 seatbelts, I don't say car B is 20 times better, right?
Once you have one seatbelt per customer, you're pretty much good to go. And then the third category is delighters. So not having a delighter doesn't cause any problems. But having a delighter or a wow feature can really create a lot of customer satisfaction and value.
Not today, but when the first cars came out with GPS navigation, it was a delighter. Right before that, people were printing out Google Maps or MapQuest and getting lost. And then all of a sudden, the people with GPS, they just put in where they're going and it changes how they get from point A to point B.
But as we know, more and more cars got GPS navigation over time. Garmin and TomTom came out with their add-ons, and now we all just use our phones for GPS navigation. So that just tells you that this isn't a static picture, that these needs and features migrate over time so that yesterday's delighters become today's performance features, become tomorrow's must-haves. And the pace with which that happens depends on the level of competition and innovation in your space.
But what we want to do is use these three categories of must-have, performance, and delighter as a way to articulate our value proposition. Which again is which user benefits are we going to provide and how are we going to do so in a way that's better than our competitors. So the way we put the Kano model to use is we list one per row. What are the must have benefits for our product space, for our product category? What are the performance benefits?
What are the delighter benefits? So that's step one is you list them all. Step two is you create a column for each of your key competitors and then you create a column for yourself.
Step three is you rate your competitors and it can, you know, it doesn't have to be anything too complicated. You can go high, medium, low. If you happen to have a quantitative measure, you can use that.
But so here's our competitive situation, let's say. Both of our competitors have the must-have. Competitor A is the best at performance benefit one.
Competitor B is the best at performance benefit two. They're both so-so at performance benefit three. Competitor A has a delighter of their own.
This is the backdrop upon which we should be figuring out what's our product strategy, what's our value proposition, right? And I think that very few teams actually go through this exercise to ensure their... delivering a differentiated product. There are a lot of Me Too products that are out there.
And this is also an important point where it'd be really tempting and easy to say, hi, hi, hi, hi, hi, we're going to beat everybody at everything. But we don't have the resources to do that. And some of you in the workshop know what I'm talking about.
But we can't do that. We don't have the resources to do it. And secondly, it wouldn't be like a focused message for our company or for the positioning out in the market, right?
So this is where you need to say no. One of my favorite definitions of product strategy is saying no. And there's a great Steve Jobs quote about that as well.
So let's say this is what we do based on this. We say, of course, we're going to have the must-have. We're going to deliver somewhat on performance benefit one, but we're not going to worry about being the best at it. We're going to say no to performance benefit two.
We're going to say no. We're not going to try to spend a lot of resources there. And we're going to try to be the best at performance benefit three. Maybe we've identified a market segment that really values that benefit.
Or maybe we have some technology ideas as to why we can deliver higher levels of satisfaction. And then we have our own idea for our delighter. What matters the most from this exercise is what's called your key differentiators.
They are basically the performance benefits where you plan to be the best in market and what are your unique delighters. That's what really matters. And as we go into the next step of the lean product process of our MVP, we want to get clear on this.
We make sure our MVP has those elements in it. Because otherwise, if we test our MVP and it doesn't have those elements in it, what are we really testing? We're not going to be testing must-haves. You're not going to have a differentiated product with that.
So that's why we want to get clear on this going into the next step, which is MVP feature set. And I don't have time to get into a whole lot. You know, we just had a great talk from Tim on MVP.
But I do want to share with you one mistake I see teams make that basically I like to explain with another pyramid from Aaron Walters. He was, if anyone used MailChimp, the email program, he had a delightful user experience. I remember when it came out. Aaron Walters was the head of UX design for that. He wrote a book called Designing for Emotion.
And this is a modified basically the framework that he created. But it's a way to think about a product as far as how functional is it, how reliable is it, how usable is it, how delightful is it, right? And the idea is you color in how much at that point in time your product realizes of each of those layers.
And one of the things I like about this too is that, you know, usability was a hot topic of discussion maybe, you know, 15 years ago. These days most people understand that, hey, people need to be able to use your product and it's important for it to be usable. And now the conversation is shifting more towards delight.
So if usability answers the question, can people use your product, Delight answers the question, do they want to use your product, how do they feel when they use your product. So that's kind of the point of his book and this framework. But the idea is we can use this framework to think about how we approach MVP and color in what we plan to execute on for our first MVP.
And what a mistake I see a lot of teams do is they know they can't possibly bite off the whole pyramid at once and they know they can't bite off all the functionality at once, but they use MVP as an excuse to do this, to build a subset of functionality but say, you know what, it's okay if it's buggy. It's just an MVP. It's okay if it's not easy to use. It's just an MVP. We'll fix it later.
Like, let's just get it out and test it, right? It's okay if it's not delightful. How do you think when you test an MVP like this with customers, how do you think it does?
It doesn't do well. Because just having the functionality isn't adequate. People have to be able to use it and it needs to work well enough, right?
So it's true that you only want to build a slice of the pyramid for your MVP, but it should look more like this, where for whatever subset of functionality you are biting off, you basically are making sure... that it's reliable enough, useful enough, and delightful enough. I'm not saying it's going to be perfect.
It is an MVP, right? But you can't completely ignore those other aspects of it. So just please keep that in mind when you're doing your MVP so that you're really testing your product and your value proposition.
The next step would be great. We're clear on our, in the book, I have a lot more guidance on how to determine what your MVP functionality should be and break things down. Don't have time to get into that.
But once we get clear on what that feature set is, the next step is to create, is to do user experience design to create a prototype and figure out how it's going to work. And as I said, I'm a big believer in testing with clickable, tappable prototypes. And the tools have made it really easy these days. The final step, once we have our MVP prototype or we have our live MVP or live product, is to test it with customers, right?
And now we've come... worked our way all the way through. So that UX prototype or that product that we've built is a manifestation of all the assumptions and decisions we've made along the way. And now the point is to go take that and close the loop and test with customers.
And again, I don't have a lot of time to get into it, but I have advice on how to run those good sessions with customers. So I want to close out with a study of this being applied end-to-end. It's for a project that I did called MarketingReport.com. My client was the CEO of a small startup and they already had a product in market and he had an idea for a new product and he wanted me to validate it. And it was a small team, me, the CEO, the VP of marketing, and a UI designer.
And he had very limited dev resources so he wanted me to validate that there was a business opportunity there and he gave me the constraint that we can't do any coding. You need to do this without any coding and I said great. That sounds good.
And the idea was a marketing report. Does anyone here get junk mail at home? A few people, it looks like. Yeah, a lot of hands, right?
So they found you guys too. They get us in the States pretty good. So the idea was we all get junk mail.
And say I get a piece of junk mail and it's for cat litter. You know, save money on cat litter. Why did I get that?
Well, it's because in some marketing database somewhere in the cloud it thinks that Dan Olson has a cat. And they may be right and they may be wrong. That's why I got that. And they were all analogies to the credit industry. The CEO would work in the credit industry.
And so if you think about the credit industry, not today but a while ago, you would apply for a loan or a credit card and... You'd send in your information and they would look you up in some secret database in the cloud and come back and say, yes, you're approved or no, you're not, based on all the data that they had on you. It was a similar idea as let's empower people to see the data as to why they're getting the marketing mail that they're getting.
That was the idea. I said, okay, sounds great. Identifying a target customer, you guys just saw everybody gets junk mail, so it was basically a broad consumer offering.
Step one, consumer offering for a broad customer market. Step two was, okay, let's get clear on the problem space and the solution space. The top idea was, learn why I received the junk mail I received. That was the top problem space statement that they were really interested and focused on.
And the top solution space ideas and map to that were a marketing report, which was similar to a credit report that consisted of a marketing profile where it would show you all the data that they had on you that was being used to send you the junk mail that you got, and a marketing score which was meant to be similar to a credit score, some kind of numerical measure where higher was better, basically. So that was the core idea. And one of the executives, in addition to the core idea, said, well, what about money-saving offers?
Like, maybe I can say, you know what, I don't have a cat, I have a dog. Can I just tell you I have a dog and opt in to get dog food coupons to save me money? So he thought people might want to opt in for money-saving offers.
He had a hypothesis that people might want to compare their shopping and spending with other people. And then because social networking was hot at the time, we just put social networking in there. So pure kind of tops-down thing. The other executive wasn't interested in any of those three things. What they were more interested in, again, were interested in the core idea of why am I getting the junk mail that I'm getting.
But then he wanted to help people actually, what if we just explored just reducing the junk mail that people get? And then we brainstormed that, hey, if we're saving all this paper, we can help people, you know, we can say that we're saving trees or being environmentally conscious. And so I iterated this to get to this point.
And I guess, okay, is everyone's idea on the board? They said yes. And I looked at this with an eye towards MVP. And I said, you know what? This is way too big for a single MVP.
So what I did is I actually created two different MVPs. The first was I took this functionality plus this functionality, and we called it the marketing shield because it was shielding you from junk mail. And then the second MVP was this core green functionality plus the blue functionality, and it was called the marketing saver because it was trying to save you money. So then now that we had defined our feature set, we moved to the next stage, creating our UX prototype.
This is an example of the landing page that you would get to. I call this medium fidelity. We didn't obsess about the design or worry about it too much, but it gives the basic ideas.
And then when you click in, this is the page that you got to. And it had like four blocks on here. And the way this would work is you basically would, we would mix and match the different features to the two MVPs.
And when you clicked on one of these Learn More buttons, you would go to a page where you would interact with that feature. So it was a prototype of about eight or nine pages. And I moderated people through the clickable prototype.
And what did I learn? Here's that same chart now, color coded. with red, yellow, green.
Nothing was a slam dunk. There were tons of questions and concerns throughout the sessions, right? So green doesn't mean, yeah, they liked it.
Green means, well, we understood their concerns and we think we could address them if we iterated and we think there's enough underlying value there. So the first thing is, did we get any green? Yes, we did. There's no guarantees you're going to get green when you run this, right? The second thing is, is there any green in the main area?
There's no green. So it's like, I'm glad we tested something else. And this happens all the time. People go out with a certain idea and a certain hypothesis for a certain target market. And they go, that's not too interesting, but let me tell you about something else.
And then finally, the red. I'm just as happy about the red. Do you guys know what a marketing score is? I don't either.
But I know it would have taken a lot of resources to buy a data feed and all this engineering time and effort to create the algorithm and the score. and all this effort to train users on it, but because we saw that people don't want it, we didn't have to do that. So part of being lean is avoiding that waste. So we basically had a pivot, right?
You talk about a pivot. We started here, and we had decided we're going to pivot to there, we're going to pivot to here. And we decided to pivot to reduced junk mail. And because we hadn't coded anything, we had no problem just throwing away our prototypes and starting from scratch. And what we did is we started from scratch, and we went through the six pages of notes I had from the customer sessions, and we made sure the new prototype addressed every single question or concern.
And we pivoted to junk mail freeze. So marketing report about Dom completely gone. And we learned all kinds of stuff. We learned that not all junk mail is the same. We learned that there are certain types of junk mail that people really, really don't like.
And it's the financial related one. Cash advance checks, pre-approved credit card offers. Because people were afraid people were going to steal money for their account or somehow take their identity.
I also learned other things. And this is what happens when you go out and talk to people. I would ask people, hey, tell me what happens when you get your junk mail.
Like, all right, let me tell you, Dan. I get my junk mail and I go to the shredder and I go shred, shred, shred, shred, shred, shred. They shred their junk mail for five minutes.
I'm sure some of you do that. That's 30 minutes a week. That's 1,500 minutes a year. So there was a whole save time benefit that we didn't even have on our problem space map. So we added that the second time around.
And little things like people said, are you going to save trees? How many trees are you going to save? So we said, oh, we're going to save 43 trees just so we answered their questions. And it was like night and day difference. There were still some questions and concerns the second time around.
And both times we asked people, hey, would you pay $10 a month for this? And it's always iffy to ask people if they would pay, but we saw a marked night and day difference. The second time around, people said, well, I need a 30-day trial, but if your product did what it said, I would gladly pay you $10 a month.
And then after the trials were done, I give them the payment for their time. Thank you very much. Almost every single person asked, so is this product live now?
Can I go use this? I said, no, sorry, we're still building it. It's not quite live yet.
They're like, hey, can I give you my email? Can you email me when it comes out? Like nobody did that the first time around.
So we were excited by the progress that we had made in that one round. To sum up, to close out here, again, the lean product process starts out by getting clear on your target customer. Figure out what you think the underserved customer needs are with importance and satisfaction. Use the Kato model to define your value proposition, how you're going to be better or different in the competition.
Get clear on your MVP feature set so you don't overbuild before you confirm whether you're going in the right direction or not. Use UX design to create the prototype so that you can go out. and test with customers and basically learn and iterate.
So, obrigado. This is my contact information. I'm looking forward to doing Q&A. And we'll be doing a book signing at the afternoon break.
Thanks.