Getting2Alpha
Getting2Alpha
Dan Olsen on rapid prototyping and smart MVP development
Intro: [00:00:00] From Silicon Valley, the heart of startup land. It's Getting2Alpha, the show about creating innovative, compelling experiences that people love. And now, here's your host, game designer, entrepreneur, and startup coach, Amy Jo Kim.
Amy: Dan Olsen is a seasoned product manager. And the author of the Lean Product Playbook, a soup to nuts handbook for doing faster, smarter product management.
Dan also runs the Lean Product & Lean UX meetup meetup in Silicon Valley, where he brings together cross functional teams who want to learn about creating great products. He's an articulate proponent of a disciplined and lean approach to product development. And he knows the power of choosing the right mental model to organize your thinking.
Dan: I used to play poker and the answer to like, okay, here's a hand. What should you do? The answer is almost always, it depends. And then you get into like, well, if this, then that, if this, then that same thing with these frameworks and mental [00:01:00] models, I think mental models are very important and huge. If you have the right mental model, it can make viewing a problem or situation so much clearer than if you don't.
Amy: If you want to understand what lean product management is, this interview is for you. Listen in and learn how an experienced and successful product manager approaches customer discovery, rapid prototyping, and smart MVP development.
Welcome Dan to the Getting2Alpha podcast.
Dan: Thanks. It's a pleasure to be here talking with you.
Amy: So briefly just tell us, what is your current role and focus professionally?
Dan: So I'm a consultant, uh, coach and speaker in product management, UX design and lean startup. I'm usually an interim VP of product for my clients.
I'm very hands on and, um, I usually work onsite, you know, with the teams. I also give workshops and coach teams and I'm a speaker at [00:02:00] events like you are. And we all just run into each other at a lot of events. And I also started two and a half years ago, a meetup just to share, you know, bring in great speakers and share ideas called the Lean Product, Lean UX Meetup in Palo Alto.
We have monthly events. So those are the things that keep me busy most of the time.
Amy: Awesome. So give us a whirlwind tour of your background. How did you first get started in design and tech? And how did you decide what to pursue along the way?
Dan: Sure. Yeah. So that's kind of why the story kind of really starts.
Back when I was 10, my parents gave me a computer. So I kind of grew up with computers and like, as. The age of computing kind of became more popular. So I've been very comfortable with digital technology from an early age. After college, I actually worked on submarine design, which was a lot of fun. And I realized I loved kind of designing and building systems that had a lot of complexity in them.
And after doing that, I decided I wanted to go to business school to kind of build on my tech background. And so that's what brought me out to the [00:03:00] Valley 20 years ago. And when I was at business school, I realized there's this thing called product management, where you get to basically do that and define products.
And, uh, I asked everybody, where's the best place to learn product management. And back then everyone said Intuit. And so I, uh, interviewed and got a job at Intuit. And I worked there for five years and it was great. It was like a post MBA in product management, marketing, UX design, product development. And after working into it, my plan was to work at startups to take what I had learned and apply them at startups.
So I helped a friend with a bootstrap startup in Madrid, Spain, which was a lot of fun out of his apartment. I'm actually have Spanish. So that was a lot of fun. And then I, um, worked as head of product management at Friendster back in the day. Which was exciting. After doing a few startups, I also started my own company, which was a lot of fun.
I did that for four years. And after that, I basically, um, got into helping companies as an interim VP of product and being a consultant.
Amy: Wow. What was the most surprising thing you learned from working at Friendster?
Dan: Well, two things, uh, [00:04:00] one of them is in my book actually is I created this hierarchy of web user needs, which is like Maslow's hierarchy, but for web users, because at Friendster, unfortunately, um, we had issues with the site being up and with the pages loading quickly enough.
And so a lot of people at the company would spend time talking about, we should have this feature, you know, we should do this biz dev deal. And I kept trying to reiterate like, hey, those things don't matter if the product's not up. Um, it's funny cause I just, I don't know if you've been checking out Pokemon go at all, but in the early days of Pokemon go, they were having uptime issues too, and just had, gave me flashbacks to Friendster.
That was one thing I learned. The other big thing I learned is when it comes to social products. You know, a lot of times people talk about network effects and tech products and social products have an even stronger network effect than typical digital products do. So typical products basically have like Metcalfe's law.
But for social products, there's things called Reed's law. So what's interesting is the more people you have, the more valuable your network becomes even stronger than other technologies. And so [00:05:00] the biggest, most important feature for any social product is not actually any functionality. It's how many users are on it, basically.
And so it's like a, it's like an unspoken feature. It doesn't matter how good your feature set is. If you don't have enough users when it's a social product. So those are two of the main things that I learned there.
Amy: Those are awesome things to learn. So you are the author of a well known book called the Lean Product Playbook.
It's a great book. We'll link that in the show notes. I have three questions about the book. Let me ask them and then we'll go through them one by one.
Dan: Sure.
Amy: The first is what is it that first prompted you to write it? What was that impetus? And then also how did writing it deepen your understanding of product development?
Cause it must've. And then the third question I have is, in truly in product fashion, how did you decide what to include and what to leave out of the book?
Dan: Those are great questions. So what prompted me to write is basically, you know, I have invested heavily in my [00:06:00] career and learning about product management and UX design.
And, uh, trying new things and iterating and actually being a consultant. Accelerate. One of the interesting things I kind of stumbled into being a product consultant is it accelerated my learning because I was working with multiple startups, right? And so just being a one company and seeing one instance, I saw multiple ones.
And so I basically from my career and from my MBA and from my work experience and from my consulting experience started just crafting together kind of like theories and processes and frameworks that became helpful and just iterated those over time and improved us over time.
I also started speaking a while back and putting those ideas on slides and talking about them with people and, and I would iterate them based on the questions I would get from the audience, you know, entrepreneurs and product managers, designers would ask me questions. And I would, the next time I gave the talk, I would add some slides that would address that.
So, um, the book was just basically like a natural evolution of speaking and consulting where I just kind of. You know, came up with these ideas and [00:07:00] frameworks for how to think about building great products and achieving product market fit. And I, you know, I just, I'm a big believer. That's why I started my, my, my meetup as well.
I'm just a big believer in sharing best practices and people sharing examples and advice and comparing notes, um, like you and I are talking about, like, when you have a group setting, that, that's one of the most great ways you can learn is from learning from other people.
Amy: Right. In a curated group setting, especially.
Dan: Yeah. In a curated group setting. Exactly.
Amy: And the art of that curation is something that I have to say, I think you're really good at.
Dan: Oh, thanks. I appreciate it.
Amy: So how did you decide what to leave in and what to leave out?
Dan: Well, um, basically, so I said about, you know, the thing, and it's funny cause someone we were just talking about was basically said, wow, you, I had some people read my book.
I'm like, wow, you tried what they said and they got it. You tried a single book to explain like how to do product management end to end. And that's basically what I tried to do. And it's, it's 335 pages, so it's a little on the longer side, but I wanted, part of the thing is, [00:08:00] you know, the, the core part of the book is what I call it, the lean product process.
It's a six step framework that you can follow to go from an idea. To, you know, going down a path of iterating towards product market fit. And so I wanted to, I had to convey the whole process. So it's, you know, a chapter for each of those steps. There's also some introductory material about problem space for solution space.
It's really foundational and important. So that's in there. UX design is critical. You know, I think it's just so important. You can have the best product strategy and the best idea for features and what to put in your MVP. But if you fall short on UX design, it doesn't matter. So I have a whole chapter dedicated to UX design in there.
And so that's the core of the book is that, you know, how to iterate. And then, you know, from my talks, I knew you. An end to end case study is invaluable for people like they, you know, they, they hear you talk about the six steps and they kind of nod their heads and they get it. But when you show them an end to end example, they really get it.
So there's a whole chapter on an end to end example. And then once, you know, at that point, and I'm a big advocate of trying to validate as much as you [00:09:00] can before you start coding, I wanted to not leave people hanging there, but then talk about, okay, how do you actually build it? Once you validated your, you know, the product, your MVP, how do you actually build it?
And so there's a whole chapter on agile development that covers both scrum and Kanban, which are like the two most popular ways of doing it. Just so you know, as a product manager, it's important to know how those, how those are supposed to work so you can work effectively with developers and then. The final two chapters are just basically, you know, once you've launched a product or you have a product that's live, you can use metrics to improve it over time.
And so there's two chapters again with the case study. So that's where I drew the boundary on like, I want a comprehensive, you know, soup to nuts. If you have an idea, how do you validate it with customers? How do you build it and launch it? And how do you optimize it with metrics? The things that I left out.
We're basically things more related to team, like team structure. There's, there's a little bit in there, but like, you know, how, what are the skills that you need and how did the different functional groups, PM design and dev, how they work together effectively. I didn't have time to get into that [00:10:00] too much.
And then the other adjacent topic, I didn't have time to get into it was just marketing. You know, how do you message your product? How do you, how do you market it? How do you talk about it effectively? Um, and those are just things that. In the grand scheme of things, just those stuck out, didn't make sense to be in the book.
Uh, you know, I have some talks on both of those topics, but I just wanted it to be that kind of comprehensive single resource that covered everything end to end, uh, when you're building a new product.
Amy: So how did your understanding of product management change as a result of writing that book?
Dan: Well, the cool thing was, like I mentioned, I've, you know, I've been developing these ideas and iterating them and improving them over time on how to approach product management and building great products and frameworks.
And what it did is it gave me time to take a step back and reflect and really refine and polish and iterate them further. And it's so funny if you go, if I go back and look at my old slides, they're like earlier, cruder iterations, but. It didn't, it wasn't as polished. So for example, in the book, I [00:11:00] created a framework called the product market fit pyramid, and it's a five.
Level pyramid is a way to think about product market fit that came out in my, in my talks, right before I started writing the book, it was like this molecule, like there's a molecule out there, like a three person molecule, like customer problem, solution molecule. That's what it was before. And then it really iterated to this pyramid and it gave me a chance to reflect and come up with the best way to visualize it and convey it.
So that was, that was really cool. And then also I, you know, I knew that I'd worked with a lot of different types of MVPs. And it's funny because you see all these debates online about what is an MVP and what's not an MVP, like flame wars, like someone, you know, there's literally a blog post that says a landing page is not an MVP.
And then the response is landing page is an MVP. So, um, and in my mind, I've seen a lot of teams get tripped up on that. And so I created a framework that like categorizes all the possible MVPs. That both of those people can be right in a sense. It's like, well, that's a product MVP versus a marketing MVP.
[00:12:00] MVP versus a quantitative MVP, you know? So let me kind of take a step back and synthesize things and create these higher level frameworks that are really powerful.
Amy: Well, it's interesting cause that really intersects with the research. On high performing individuals and teams, at least I know from high performing individuals that having the right mental model often is one of the key differences.
Dan: Yeah.
Amy: Between being able to really knock it out of the park.
Dan: I agree. I agree. And it's funny, it's someone else, like about a couple of weeks ago, someone had a tweet. It's like, hey, you know, like product management, like someone has shared a collection of frameworks. Like this is just great. You have to know which one applies when, right.
It's kind of like, I used to play poker and the answer like, okay, here's a hand. What should you do? The answer is almost always, it depends. And then you get into like, well, if this, then that, if this, then that same thing with these frameworks and mental models, I think mental models are very important and a huge, if you have the right mental model, it can make viewing a problem or situation, uh, so much [00:13:00] clearer than if you don't.
Amy: And the reality is your model. And my model and the lean startup model and, you know, what Marty Kagan does and it's all very similar.
Dan: Yeah.
Amy: You know, it's all different lenses of viewing the same fundamental process, which is iterative, experimental design and development.
Dan: Yeah. And that's what, that's that one of the funny things along those lines, you know, I'm a hard, I was electrical engineering major.
I'm kind of a, I pride myself on being, you know, kind of relatively scientific and you see people increasingly talk about the scientific method applied for product development, and I think there are definitely some parallels. It falls a little short, I think, because people are people. It's not like these immutable laws of nature or anything like that, but it's more statistical and probabilistic about how do people respond to what you're putting out there.
When you see thought leaders sharing similar ideas, you can't help but feel like there's some fundamental underlying truth that's being uncovered. And, and the thing I remember this happened earlier in my career, when I was at [00:14:00] Intuit, I developed a framework that I covered. That's key in the book about how to really make sure your, what you're building is going to add customer value called importance versus satisfaction.
And you basically try to assess, you know, the need that I'm, the customer need that my, this feature or product is going to, Address how important is that? You know, is it low importance or high importance? And then how satisfied are people with the current alternatives that are out there and you want to build things that have high important needs with low satisfaction.
I developed this on my own as a product manager into it, trying to figure out how to prioritize all the different feature ideas we had. And then I remember picking up Anthony Olbeck's book called What Customers Want. I was randomly at the, at the Stanford Business School library and his book was on the shelf, was promoted there.
I grabbed it and I'm like, Oh, he has his own importance versus satisfaction framework. This is amazing. You know what I mean? So I'm like, there must be something to this important satisfaction. And then like the Kano model. So I studied what I didn't mention also. Between undergrad and going to business school at night, I did a master's in industrial engineering where I learned about lean manufacturing.
And that's where I learned about the [00:15:00] Kano model, which focuses a lot. It doesn't focus on importance, but it kind of focuses on satisfaction. And so you see people, you know, focusing on these concepts. And so that was another thing that I did in the book. It helped me really. Take that importance versus satisfaction framework and actually make it quantitative and more rigorous, but you're right when you see there's more commonality to what everybody's saying is like, hey, articulate your assumptions or your hypothesis, figure out the fastest way to test them, you know, avoid investing too much before you validated figuring out what the highest risk are, you know, iterating, being customer centric, getting out of the building.
Those are all common concepts that you hear again and again.
Amy: Yep. And then there's specialization and differentiation that's happening within that space. But it's funny. It reminds me of when I was in college and I took comparative religions class and I went, Oh my God, they're all talking about the same thing.
And yet they fight.
Dan: That's funny. Yeah.
Amy: So you talk to a lot of different product creators [00:16:00] and you give talks, you give workshops, you work deeply with teams. What are some of the most common mistakes that you see product creators, particularly first time product creators making in the early stages when they're testing their ideas and bringing their ideas to life?
Dan: Well, one mistake I see actually, even before that, one of the most common mistakes I see. People jumping into solution space too soon before they really clarify or understand the problem space and the other example after example of startups where it's like, you know, a founding team, they come up with an idea, they start designing and building the product right away.
And then they launch it and then they realize it doesn't resonate with people. And then, you know, hopefully they realize, wow, we skipped a step. We didn't get clear on who's this for. What's it going to do for them? How's it going to do that in a way that's better than what's out there? And so that's a big thing, you know, and that's why like the first chapter in the book after the introduction is just problem space versus [00:17:00] solution space.
So, and I'm, I'm excited that you hear people talk more about problem space and solution space more and more at conferences and in talk. So that's great. But that's the first one is, hey, before you jump into solution space, be aware, one, be aware when you're jumping into solution space or transitioning into it.
And two, before you do try to get really clear on the problem space. That's one. The other one, when they're testing, what I found is, And it's kind of, I understand it's a, it's a pragmatic problem is, but sometimes people will follow the right exercises, you know, come up with some wire frames or prototypes to get feedback, but then they don't talk with the right people.
They either talk to whoever's available. It's like, Hey, let me just grab whoever, you know, let me talk. One is the mistake people make as friends and family, but even if they don't do friends and family, let's talk to whoever's available. Like I'm, you know, I'm at a coworking space right now. I could just go randomly grab people in the hallway and say, Hey, what do you think of this product of my wireframe?
But that wouldn't be good because the whole point is it's built for a specific target customer, right? And that's why in my product market fit pyramid, the bottom [00:18:00] layer is the target customer, because everything depends on them. So that's it. And so people talk to whoever's available. Um, which I understand sometimes it's just hard to find the right people.
And the other is not being rigorous enough about defining the target market. You know, I'll ask, I'll talk to the people and be like, yeah, we're focused on our, I remember I actually, I was a judge at the D school for a competition. And I was, you know, and I was basically, instead of focusing on what the product designer was, I was like, Oh, who's this for?
And what does it do for them? And I remember asking one group of college students, who's this for? And their answer was millennials. And I didn't say anything to them, but I'm ahead. I'm like, Oh my gosh, that's a huge group, you know, that's definitely not segmented enough or targeted enough. You know, it's like millennials that work, millennials that don't work, women, men, like what needs do they have busy millennials?
Like, you know, just, and as I, as I got to know their product, I could start to think of other facets or segments we could add on to millennials. And it happens again and again in pro whether it's defining your product or your feature or your [00:19:00] problem space or your customers. It's like peeling an onion.
And most people just stay at the superficial high level and really, really good products and good product teams keep peeling layers and getting more and more insight and more detailed insight are able to refine that.
Amy: That's awesome. When you're working with teams deeply, um, bringing these projects to life and working with them on project management, how do you approach early testing and iteration?
Dan: Um, well, I'm a big, big believer in test before you code, because it's just human nature. One is it's more efficient use of resources. Secondly, it's just human nature that once you start coding and building something, it's gonna basically, people are going to be beholden to it and want to adhere to it because they invested in it.
Um, and even if they don't emotionally, there's just a practical standpoint of, okay, well, we built, we built the code this way and the objects this way, and now we need to pivot, you know, 90 degrees. Uh, let's just try to reuse this. And so in a way it adds constraint and baggage and tech [00:20:00] debt in your solution space before you've gotten clear on your problem space.
So I like to basically work with teams to explicitly articulate hypotheses about who's this for. You know, what are their, what, what customer needs is it going to solve? Well, let's score those on importance and satisfaction. The other thing that's cool about the Kano model, uh, for people that are familiar with it, is it basically classifies needs or features into one of three categories, must haves, performance benefits, where more is better, and delighters.
And so it's a, it's a great lens, speaking of mental models, a great lens to think through as you're talking about features you're building, categorizing in one of those three categories. And then basically, you know, brainstorming a lot of different ideas. And then the tough part is probably the toughest part.
Where there's the most uncertainty is getting your MVP, right? It's like, great. We did all that rigorous thinking in the problem space. We know who we have hypotheses, clear hypotheses, who it's for. We have clear hypotheses about what needs it's going to meet for the customers. We have clear hypotheses about how it's going to do that in a way that's better.
Now we need to figure out what's that feature [00:21:00] set that we're going to test in our MVP. And that's where, you know, you can not put enough in. And then it won't test well, or you can, what most people do is, is put too much in. And the funny thing is MVP was designed to precisely prevent you from putting too much in, right?
It's like the opposite of a team of developers go into a cave for 18 months, head down and then emerge. And launch their product and then realize nobody wants it. The whole point is to like build the least, least amount that you can test it. So that can be tough. Uh, and I always tie it back to the value proposition.
You know, the other thing is sometimes people in our MVP, they'll put all the must haves, but they won't have any of their differentiators, like their delighters or their, or their outperforming the features that are going to outperform. So that's a mistake that I see people make. And then a big, probably one of the most, the most popular figures in the book is the MVP slide that basically uses.
A modified version of Aaron Walter's pyramid that talks about, uh, a product at the bottom of the pyramid is like it's functional, you know, it needs to have a certain level of functionality needs to have a certain level of [00:22:00] reliability. It needs to have a certain amount of usability and a certain amount of delight, basically.
And we're, we're basically, it's funny. I, someone just emailed me. It's like, I love your DERF framework, like the D U R F it's called the DERF framework for short. And what most people do, what other mistake I see people do is they will use MVP as an excuse to launch a buggy product that has a bad UX, you know, and they just say, Oh, it's just an MVP.
And when you test that it doesn't test well. And so the bottom line is, yeah, you don't want to build the whole set of functionality, but the part that you do build, it has to be usable enough. You know, and reliable enough. And I'm not trying to have my cake and eat it too. And say, you're going to have some MVP that's like, you know, pixel perfect and bulletproof, but that's what we do basically.
And then we come up with, once we get clear on what our MVP feature set is, then we get clear on a wireframes, you know, to bring the user experience to life. We stay in low fidelity on purpose to iterate until we're happy. And then once we're happy that we take it to high fidelity, you know, working with the visual designer.[00:23:00]
And then I will take those visual design. Once we're happy with the visual designs, the mock ups, then we'll basically throw them into a tool like InVision. I love InVision and make it a clickable or tappable experience. And then we will recruit target users based on that persona definition that we had.
And I'll moderate the users through those high fidelity clickable prototypes. You get a lot of great feedback when you do it that way, and then you iterate, um, and then once you're getting to the point where you're getting a positive response from people, no major negatives and less negatives as you, you know, I recommend doing these in waves of five to eight people at a time, you know, and then pattern matching and addressing the top issues, then doing it again.
Once you do that with high fidelity, clickable or tappable prototypes, you can feel pretty confident going into development after that, that you're going to be building something. Um, that people want
Amy: looking back at the projects that light you up the most. What do you feel is your superpower as a product creator?
What's your sweet spot?
Dan: So one of the superpowers is [00:24:00] basically being comfortable and an expert in the problem space. And in many ways, my book is really the core of my book is how to think about. The problem space and do so rigorously and explicitly. And so, um, asking questions, asking a lot of white questions and like, who's this for, you know, um, what needs do they have that aren't met?
How do we articulate that? And I, and I, and it's messy in the problem space, right? The toughest part of a product, I just actually met with the startup team. That just an hour ago that spun out of another startup and they're like, yeah, that startup was great because we were working in the payroll space and all the customers knew what they wanted.
They knew it was a very mature market category. So it was very clear how to improve upon what was there. Now, as the new spin up, we're starting with a blank slate. Blue sky and we don't know what to do. So basically in those environments, creating structure out of nothing, you know, putting a soft person idea there that we can then build and iterate on.
And, and basically creating [00:25:00] frameworks of how to think about the problem space and the competitive landscape. That's a superpower of mine. And then I think just rigorous, ruthless prioritization, you know, um, I will make people rank order lists. And then we'll decide, okay, what's most important. And, and that's when we'll use that to basically make our product decisions for our MVP and also for our future sprints.
And we get really clear on what's, what's important. The other thing is interesting is, is helping people with MVPs. It's, it's kind of this funny thing. I have, I have so many entrepreneurs that have come to me and said, Dan, I read your book. Bend your talks, love what you have to say, understand that MVP, you know, can't be too big.
Here's why my MVP needs to have X, Y, and Z in it. And then I'll sit down with them like, okay, tell me more about it. And invariably I'll be able to find a way like, well, did you think about this? What about trimming this? What about this? Like there's always 80, 20, you know, the 80, 20 rules always at play.
But when it's your baby, when it's your product, it can be really hard. So it's almost easier for someone else to kind of [00:26:00] challenge your MVP and come up with ways to make it even smaller scope. Um, so that's something I, I often help people out with too.
Amy: Scope down. Yes. That's actually a game designer's credo.
You know, that's something I learned in game design is scope down and find the fun early.
Dan: Yeah.
Amy: And that can really help focus your MVP too, not so much find the fun. What's the core loop?
Dan: Yeah.
Amy: Cause you can get really lost in the onboarding.
Dan: Definitely.
Amy: You could go nuts with the onboarding.
Dan: Yeah.
Amy: But if you don't have a core loop, you got a leaky bucket.
Dan: Yeah, that's the other thing I do. So in the metrics, in the metrics, um, chapters, I build on Dave McClure's startup metrics for pirates, our framework, and, and basically talk about that too. I mean, I have so many, it's so funny. I just give a talk at the traction conference in Vancouver about growth.
And so many people will try to pour gasoline on a fire, like pour water into a leaky bucket without realizing they have a leaky bucket. So I think again, you hear people use leaky bucket metaphor and it's like, [00:27:00] okay. You need to make sure your product market fit is good enough, you know, and your conversion rate is good enough before you go wait, you know, spend all this money that you'd otherwise would waste, right, on acquisition.
So, advising people that like, you know, and actually, and in the book I focus a lot. And one of the insights I had too, in writing the book is, you know, everyone's trying to achieve product market fit. There's actually a quantitative metric that is a direct measure of product market fit. And in the book, I talk about the difference between like kind of Oprah techniques, which are more qualitative, which are really important.
Like in the problem space, when you're trying to understand customers, customer needs, you have to use Oprah techniques. You can't survey your way out of that. There's no way. I mean, I see people trying to use surveys way too early. And that's why the, we were talking about the meal girl, the problem with surveys article.
I see people misusing them all the time. In fact, in my book, I strongly advise against using it by NPS net promoter and Sean Ellis's survey are probably the two that. That I would recommend using unless you have someone who's really good at surveys, [00:28:00] but the quantitative side, I call the Spock methodologies.
And basically if you want to have a quantitative measure, product market fit, it's basically your retention rate over time. Like you pick a certain time out and then we talked about in the book, I talk about retention curves and cohorts, but basically whatever your, you know, the retention curves flatten out over time, right?
They can go to zero. If you have no part of market fit, they'll go to zero. If you have a decent level of part of market fit, they'll taper out at around 10 percent say. And after 90 days, 10 percent of the people that signed up are still using it. And then, you know, some other product might have 20 percent and some other product might have 30 percent whatever that terminal percentage is.
That is the quantitative measure of your product market fit. And so basically retention is what you should be focused on first. It's kind of like what you're saying, find the fun, make sure you're creating value that people are sticking around and retaining once they are, then you can focus on acquisition.
So you're not sending people to a leaky bucket.
Amy: And there's actually a lot of bad information out there about how to drive retention. [00:29:00] That's basically based on Skinner box, operant conditioning techniques, but that's perhaps a topic for another day. And I would, I would love to have that, but yeah, totally.
So that's awesome. What, uh, bouncing off what you just said, whose work are you paying attention to these days? What trends are you following? What are you seeing that's new and stimulating to you?
Dan: Well, what's interesting, yeah, I mainly try to stay abreast of how people are able to create, again, without coding, create high fidelity, high enough interactivity prototypes, you know, of their ideas.
So once you've done this great thinking in the problem space, You know, you have to build a prototype to test it with people. And so I'm, I'm just amazed that there's constantly new tools coming out. And it's interesting because I, you know, a lot of times for my clients, I'll interview and recruit designers and I always ask them what tools they use.
And. You can kind of date designers from what tools they [00:30:00] must use. So yeah, some of them are like, yeah, I use OmniGraffle. And that was kind of the cutting edge tool years ago. I'm not saying it doesn't serve its purpose for certain things, but as a wireframing tool. You know, uh, that was kind of the efficient frontier.
And then, you know, balsamic came along, which made it really easy to make it be clickable. Or they deliberately make it low product, low fidelity. Um, so I think that was an improvement in tools. You've got tools like InVision. Now you've got a mobile optimized tools like Flint Hill and Marvel. And there's just more and more of these doing Adobe just came out with their tool.
Uh, so it's an exciting time. It's, you know, it's never been easier to create kind of a representative prototype that's high fidelity, high enough interactivity to test with people. And so that's kind of what I, I look at the tools and then I also look at the methodologies and processes that people are, are following to do that.
Like, you know, we were just talking before we got on the interview about the design sprint process. That's very exciting. A lot of people very excited about that because it's kind of a, you know, [00:31:00] methodical way to get feedback. And just looking at, you know, the, you know, reading the typical product. Blogs and websites and hashtags on Twitter and, and, and seeing what kind of, uh, the successful companies are doing, it's a really exciting time.
Cause also everyone's sharing what they're doing. People are more and more transparent. They're sharing their wireframes, their clickable mock ups, you know, what the test results were, more and more case studies you see, and you know, the other cool thing is, um, increasingly you see designers creating videos, right?
So instead of just showing you static wireframes. They'll create a little video of them clicking or tapping through so you can kind of experience the user experience, you know, higher fidelity way of seeing it as a passive observer.
Amy: Cool. So what's coming up for you on the horizon that's exciting?
Dan: Well, you know, I continue to work with companies.
I really enjoy that. Uh, on my book front, the Lean Product Playbook, I was really excited because the audible version Recently came out that was like the top customer request that I had from product market fit standpoint Um, and I can [00:32:00] totally relate as someone who's very busy, you know, I have kids i'm working a lot Uh increasingly rely on audiobooks to listen to to read books basically, so I was really excited that came out. And uh the, I also was excited.
It's got translated in a few languages. So I think the chinese version is coming out this fall. There's also going to be a version for India and Turkey coming out. Aside from that, um, just continue to run the meetup. You know, I've got monthly meetup in, in Palo Alto. If anyone's interested in checking it out, it's just meetup.
com slash lean dash product. We have monthly speakers. Amy Jo Kim was a speaker. She rocked it. Everyone loved your talk on how to apply game thinking to improve their product. And then I'm giving a workshop. I try to do public workshops. I haven't done one in a while, so I'm going to be doing one on Friday, September 16th in Palo Alto.
Um, the URL for that is productplaybook. eventbrite. com. And basically it'd be a half day workshop where we'll dive into a lot of the stuff that I was kind of covering at a high level here in [00:33:00] this interview.
Amy: That's exciting. Um, so we'll definitely give you a live link to that in the show notes. Dan, thank you so much for joining us and sharing your tips and insights and stories.
It's fascinating.
Dan: Thanks, Amy Jo. It's always great to talk with you. It was a pleasure.
Amy: Look forward to seeing you soon.
Dan: Me too.
Outro: Thanks for listening to Getting2Alpha with Amy Jo Kim, the shows that help you innovate faster and smarter. Be sure to check out our website, getting2alpha.com. That's gettgetting2alpha.com more great resources and podcast episodes.