Launching Great Products Play by Play

Dan: Hi, my name is Dan Olsen. I'm the author of The Lean Product Playbook and a product management consultant.

Suzanne: I'm super excited that you're here. I think the book is really exciting. It's so accessible. I understand that part of that has to do with the fact that you're an engineer, which means you've got a pragmatic approach to presenting information. It is a very pragmatic approach to, how do you ultimately go from idea to execution and at least beat the odds of having a successful product in the market?

So, I thought that we could talk a little bit today about some of the steps in your framework. I think our audience could really benefit from ... well, they could definitely benefit from reading the book, but I think the benefit from hearing kind of some of your unique perspective on the challenges that can come up as you move through each of these phases of the pyramid, as it were.

So, at the beginning we talk a little bit about identifying a target market, and to identify your target market it's a hypothesis. It's "I think I've got something that's good for these people." How do you go from, "I think I've got something that's good for these people," to "Yes, this is the target market that we should pursue."? What are those indicators that we're on the right path?

Dan: Yeah, the tool that I recommend using there is segmentation. Basically, as a way to kind of clarify your hypotheses about who the target customer is. It's easy to kind of say at the superficial level, like "We're targeting SMBs, or we're targeting Millennials." But that's not really specific enough, and so, in the book, I talk about how you can use demographic segmentation, psychographic segmentation, behavioral and needs-based.

So, I think what you want to do is, even before you try to test a solution with those folks, is to be able to make sure you are clear on who they are, and that you can recruit them and talk to them and understand their pain points. And what you want to see is some consistency in the pain points and the problems that they have so that you know that you ... when you kind of hear that consistency, you kind of know that you've defined that target customer well enough.

Suzanne: People ask this all the time, so I've got to ask it to you. How many interviews should I do, Dan, in order to advance to the next step of the process?

Dan: Yeah, people are always looking for some magic answer, and I think ... I also get a related version of the question, which is "How long should I allocate for this process?" The thing is, it's an iterative process, so you're doing discovery. It's like we're on a journey and we're not quite sure how to get to the destination of product-market fit. We don't know how long it's going to take. We don't know how many iterations it's going to take, right?

But what I recommend is talking to people in groups of five to eight, and then pattern-matching what you see. So, when you talk to groups of five or eight people, you're gonna basically try to, in a somewhat rigorous way, capture what are the things that you're learning from them and then, which of those people said each of those things or expressed each of those things, and you want to get to the point where you're basically seeing convergence among the people that you're talking to and between ways if you're showing them a product, what you want to see there's gonna be questions and concerns, and negative comments that they bring up as far as things they don't like, or they don't understand, or things they're missing. And what you want to see is those negative comments, as you basically do a wave, pattern match and address those comments and revise your product, and then test it with the next wave, you want to see those comments go away basically. It's this weird sense of progress.

The people you're talking to in the next wave didn't see your product in the previous wave, so they don't go, "Hey, Dan. Awesome job fixing that registration flow." They just don't complain about the broken registration flow. And so you want to get to the point where you're not hearing too many negative comments, and hopefully you're starting to hear some positive comments as well, like, "Oh, wow. I could really see how this would meet my needs." And I don't know if that's going to take two iterations or three iterations, so the number people total you need to talk to is a little bit indeterminate.

Now, if you've done 10 iterations and you're pounding your head against the wall, then it may be time to pivot, right?

Suzanne: Yeah. I mean, well, the thing about validated learning is it's about risk mitigation. Ultimately, there's isn't a defined, this is when you should go forward. There's just sort of a series of checkpoints and what you're really looking for is, "Do I feel confident based on these two people I spoke to, or these 20 people that I spoke to?," that I actually have identified a real potential problem or constellation of problems that are worth pursuing. You describe that as that next layer up in the pyramid, which is the underserved needs.

So, I'm out there. I'm interviewing different customers. I'm starting to get a sense of the underserved needs, and this really becomes the foundation for the solution that I'm gonna create, but there are other people that are out there in the market also doing things. So, how do I begin to organize which needs are the most important to pursue? Which ones are, in fact, the most underserved?

Dan: I recommend, as a team, brainstorming ... once you pick a certain target customer and a certain area that you want to try to make their lives better in, that's a fun part, where you get to brainstorm, "What are all the different ways our team could potentially help people?"

Then what you want to do as you do customer discovery interviews is come out of the interviews with a sense for each of those needs that we could address, how important is that need to the customer? Even if it's just low, medium, high. It's not anything too rigorous. And how satisfied are they today with how well it's getting met?

Basically, what we want to do is, life's too short to focus on low-importance needs. You're not gonna be really creating a lot of value for the customers. You want to weed those out. You want to focus on high-importance needs. Within the high-importance needs, some of them are gonna be perfectly satisfied today with existing products, and so, to go after those would be difficult. Not to say you couldn't do it, but you really need to get clear on how you're going to be 10X better. That's where 10X better comes into play.

But if you analyze the market, you can often find opportunities that are high-importance, but low satisfaction, and so that's where there's really an opportunity to create customer value. You want to use importance versus satisfaction framework in my book to prioritize.

And then to your competitive question, that's the next step in value prop, which is really okay. Out of all those ideas for benefits that we could go after, which ones are we actually going to say our product delivers on, and how are we going to be better than the competition? The other ways that people are getting those needs met.

That's where, before I moved out to Silicon Valley and went to business school, I studied lean manufacturing, got a master's in industrial engineering, where I studied the Kano model. The Kano model is a way to classify benefits or features into must-have features, performance features, and delighters.

What you want to do is, for your category, basically create a table and list one per row each of those must-have benefits, each of the performance benefits and each of the delighter benefits. Then what you want to do is create a column for each of your competitors and a column for your own product, and then you want to score your competitors, like low, medium, high, and how well they're doing on each of those different customer needs.

And that's the way the backdrop that you should be looking at before you pick what your product's value proposition is going to be. That's basically the essence of product strategy, and it's super easy to be tempted to say, "We're going to be the best at every single one," and put a high in every one, but the reality is that's not really feasible 'cause of the resource constraints that you have. It's also not a very clear positioning, or very focusing for your company.

One of my favorite definitions of strategy is it means saying "no," to something. If you're saying "yes" to everything, then ... and yesterday in my workshop, I was telling a funny story about an enterprise sales team. They go out, they call on a client, and it's like, "Hey, is your product going to have feature A? If it does, we'll sign the contract." "Oh, yeah, yeah, it's going to have feature A," and they come back and say, "Hey guys, you have to build feature A." And then they go out to the next client. "Hey, is product going to have feature B?" "Oh, yeah, yeah, it will." They say yes to everything, right, because they have a quota and they get paid to. That's the opposite of being strategic, right?

I have a lot of Steve Jobs quotes in the book, and one of them is, he says, for every yes, when they decide on something that's going to be in the product or a product-design decision, there have been a thousand no's before that.

Anyway, what matters the most is, what's the performance benefit that we're going to be the best on compared to the competitors, and what's our unique delighter? You don't really compete on must-haves, so your performance benefit, your top-performance benefit and your delighter are what are your unique differentiators. And you want to get crystal clear on that before you go into the MVP feature-set discussion to make sure that your MVP actually focuses on delivering those benefits.

Suzanne: In your framework, that elusive product market fit is that space in between the identified underserved needs of the customer and those value propositions that you're going to put forth. And this term, product-market fit, gets bandied about a lot, and I think there are a lot of different interpretations. For our audience benefit, what's your definition of product-market fit?

Dan: Sure, yeah. Any time you have a new movement that's going to have new concepts and buzzwords, and so, MVP is another one that's pretty hotly debated. People arguing about what it is or what it isn't.

Product-market fit, people talk about it a little differently. They talk about it, basically, very simplistically as if it's a true or false condition of existence. They might say, for example, "Oh, Box succeeded because they had product-market fit." "Start-up X sadly failed because they did not have product-market fit."

But, if you look out there, there's not a lot of good guidance on what it really means or how to achieve it. That's basically why I wrote this book. After working as a product manager at Intuit, then working as a product leader at start-ups, and having my own start-up, and consulting and speaking to all these product managers, I realized that there was, basically the set of conditions that had to hold true in order to achieve product-market fit, like a set of hypotheses that you had to get right. That's basically what led to the product-market fit pyramid with its five layers.

Suzanne: Right. You've got to get the target market right. You've got to get the needs right. You've got to get the value proposition right. What else do you have to get right?

Dan: Well, once you agree ... once you've done that value prop grid exercise and gotten clear on your unique differentiators, then the next step is, what's our MVP feature set going to be? We want to focus on MVP so that we don't overbuild before we realize we're heading in the wrong direction or made some bad assumptions basically.

As I said, this is where we actually, in my book, we didn't talk about much, is problem space versus solution space is a really important concept. Problem space is where customer needs live, and solution space is where features and designs and functionality and live product lives.

This feature set layer is where we first transition from problem space, our value prop, into the solution space, so when you're basically brainstorming features for your MVP, it's really important to tie them directly back to the benefits that are in your value proposition, right? And then the question becomes, this is one of the hardest decisions. It's super easy again to say, "Oh, yeah, our MVP has to have X, Y, Z and the kitchen sink." It's that discipline to say, "Well, yeah. We're going to have the must-haves, or we're going to have the bare minimum for our value-prop differentiators. Is that enough or not? Let's try it." That's what I call your MVP candidate because you don't yet know, customers haven't told you that it's viable.

In the next step, you ask what else .. is UX design, and I'm a big proponent of actually trying to validate as much as you can before you do any coding or building. You can actually get quite far with today's prototyping tools. Clickable prototypes. Tappable prototypes. You can get a lot of great feedback if you have a high fidelity, relatively high interactivity prototype. You can get a lot of feedback to iterate and change your product and fix your feature set, fix your value prop, fix your UX design before you go and code.

Suzanne: Yeah, I mean, I love the distinction of problem space and solution space. Just by articulating it, it gives people an insight into how important it is to solve real problems as you sort of spoke about. And, I see this all time, and frankly, product people are guilty of it. It's like, if you're a designer, or if you're an engineer, you're already at a disadvantage because you start thinking of a solution and you can start coding it or start designing it right away without stopping to do those first few steps, which is, I think, again why this framework is helpful. It's like, first we walk, then we run kind of idea.

At the MVP, this is in my opinion, another place where it can all fall apart because what I see a lot with founders is that fear of releasing and so you get hung up on, "We need to have this," "Oh, we can't put it in front of customers if it doesn't have X, Y, Z thing."

What advice can you offer at that MVP features-planning stage to, as you describe, really keep it focused on meeting the value propositions and not more than that?

Dan: It's one of the hardest things to do is to have the discipline to say, "Well, let's try the MVP without that in there." As painful as it may seem. One of the things is, I get people that read my book and they come to my workshop, like, "Dan, I love your book. Totally get MVP, but here's why my MVP needs to have features A, B, C, D, and E. Look, I get it. I read your book."

It's almost like you need an objective third-party opinion 'cause you're so close to it, you know what I mean? It's just helpful. A lot of times I'll come in and be like, "Okay. Let's start picking this apart." And there's almost always 80-20 at play. Right? The whole 80-20, like you don't need all those things. It's tough. Look, I've been a founder, too. It's really tough and I ... he temptation to overbuild and not launch it is there. But I think it’s, the converse point is that it's pretty easy to add that if we find out from people they don't like it.

That's the other thing. That's why I'm a big proponent of testing with prototypes. You could learn that in wireframes, and sometimes people are reluctant to test wireframes with customers. But, what you can get is those coarse details of like, "Let's try the wireframe without that feature that we're debating whether it needs to be in there or not," and see what customers say.

You may show it to them and nobody complains. Or you may show it to them, and they go, "Are you crazy? You don't have feature A in here. There's no way I can use this product without feature A." How easy and cheap was that, versus just saying, "No, I don't feel good about it. Let's just build it," and we take three months to build that feature. So easy and cheap to test that risk or that assumption with the wireframe.

Suzanne: Yeah. No, it's absolutely right and you do describe in the book, actually, about how this concept of MVP really stays forever in the process and I think this is important. Yes, there's the official MVP, the first product build, whatever it is, could be a landing page, could be something a little bit more robust than that, but as and if you determine to proceed from there, MVP really almost becomes like MVF. That minimum viable feature, and so, shifting that definition toward more experimental mindset, that's really kind of at the heart of what you're talking about. The definition of MVP is maybe dangerous to hang on too tightly to.

Dan: Yeah, and I think it just gets misused. One of the other things is, I have this diagram that I share, basically from the head of UX design from MailChimp, Aaron Walters, who wrote a great book called Designing for Emotion, and he has another pyramid where you can kind of assess a product as far as how functional it is, how reliable it is, how useful it is, how delightful it is. And what I see, is people know they can't build the whole pyramid in one fell swoop, and they know they have to build a portion of it for an MVP. But what they do is they use MVP as an excuse to just focus on the functionality and it ends up being buggy and hard to use.

Suzanne: Right.

Dan: Right? People use MVP as an excuse for shortcuts in that. Now the interesting thing is, how do you think that's going to test with customers? It's not going to test well. If they can't find your feature or figure out how to use it, or they run into bugs, it's going to get in the way of them seeing the value that you've built. It doesn't matter if you have the world's best flight booking engine if nobody can find it or figure out how to use it. It's great that you have these algorithms that can find the shortest flight.

So, it's true that you only want to bite of a bit of the pyramid, but for the functionality that you do put in your MVP, you should make sure it's reliable enough and usable enough. I don't expect it to be perfect, but it needs to be reliable enough and usable enough so that you can get a good signal when you test it with people.

I see MVP misused, and then what happens, people go, "Oh, this MVP thing doesn't work. Let's go back to waterfall." They use it as an excuse to kind of shoot everything down.

And then you mentioned feature. This process can be obviously used at the product level. It can also be used at the feature level. And I think that, in a sense, because the scope of a feature is smaller, it can be easier in a sense. Okay, we're adding a new feature. We already have a product, we already have customers, so you already have the people to talk to, let's just go and ... and in those cases, you tend to see people more often use wireframes or clickable prototypes to test things before they're built.

Suzanne: Yeah. It's strange that we're more comfortable to do it later. Now that we have a fully functioning product with customers, we completely embrace this idea of presenting wireframes or clickable prototypes, but when we're starting at zero, it feels like there's more at stake somehow. I always think, isn't in spending your life's savings on a bad product idea the highest stakes of all?

Dan: Well I think one of the things that comes up is if people embrace these kind of lean concepts and customer-centric contraps. "Great, I'm up for it. I don't know how to find the customers."

One of the reasons that you see existing businesses do it, is they have thousands or millions of customers. It's super easy to say, "Hey, let's go get some customers and talk to them." Right? It's just the availability of customers to talk to, facilitates and makes it lower friction for people.

Suzanne: Yeah, but if you can't solve that problem in discovery, how do you expect that you're gonna actually solve it in business? And, this is another place that I see founders go wrong a lot, is they focus so much on getting the product right and they haven't spent any of that early-stage opportunity focusing on how do we find those customers. In fact, I think you can be using MVP’s almost concurrently that even as you’re testing out the value propositions with the real product, with real prospects, you could be testing out your strategies for finding and acquiring those segments that you've identified early on.

Dan: Definitely. I think the feedback loop of trying to recruit target customers is learning in and of itself because you're not gonna be 100% right at first. And thinking, "Okay, SMBs that meet this criteria are our target market." And you go try to reach them, you may realize there are issues reaching that particular audience, or you will learn what are the ways to talk about these pain points or our value prop that resonate with them that get us better turnout for our recruiting?

Suzanne: How do you know when you've got to product-market fit?

Dan: Hmm. A lot of my book is focused on when you're kind of building a new product and it's very qualitative. I'll give ... most of the book is talking about qualitative techniques. I don't really talk about actually using A/B testing analytics until very late in the book, like after you've launched. Now, if you're at a big company that has a large install base, then you can do A/B testing right away.

But, it's mainly a qualitative exercise and I think you really need to get in there and talk to customers to really understand what their needs are. It's really about talking to people. There's no shortcut. The appeal of "Let's just go do an A/B test." I understand that it's quick and it's nice to have numbers, but there's no real way when you're building a new product, you've got to talk to people. That approach of basically talking to people in depth, the one-on-one understanding what they're all about, interviewing them, I like to give that personifier by calling it the Oprah technique because she's the best at sitting down with people and getting to know what makes them tick and really understanding them.

And then the other technique, the quantitative technique, it's all about analytics and numbers. There you don't actually care what any particular person says. You just want to know what the averages are and what the statistics say. That's what I call the Spock technique.

And so, they're both valuable techniques. In the qualitative, it's basically like we were saying. You're talking to your groups of five to eight and you're hoping ... you want to see negative comments go down and the positive comments go up. Right? You can ask people, "Hey, would you be willing to pay $10 for this or not?" It's always iffy because that's people saying they would pay without paying, but it can be an indicator. In the example I share in the book, the first time I ran it, nobody had any interest in paying us. But then we iterated it, and the second time people said, "Well, we need a 30-day trial, but if your product did this, I'd gladly pay you 10 bucks," and I believed them. You can kind of tell that they were really interested.

In that particular case, after the test was done, I said, "Great. Thank you so much for your time. Here's your $100 check. Almost every single person that second round was like, "So, is this product live? Can I go use this now?" I was like, "No, no, no. We're still building it," and they're like, "Can I give you my email? Can you email me?"

So that's like an indicator, right?

Suzanne: Yeah.

Dan: The fact that they're proactively saying, "Hey, spam me when this product is out," is an indicator. But, a lot of times when I'm talking about the Oprah technique, I'll get questions from Spock-oriented people, being like, "How do you really know Dan?"

So that's where ... actually when you get in market, at the end of the day if you want to know it, it's your retention rate, basically, is how you know it. And the way I sell it is this, is like, you build a product, hopefully following this methodology, it's for a certain person to solve a certain pain point in a way that's better/different. If they actually get in there and use your product and kick the tires and they don't come back, then it means that you didn't meet their needs, right? They tried it, didn't quite do it for them.

If instead, they come in and they kick the tires and use your product, and then they come back and they use it again, and they use it again, and they use it again, that indicates that you have product-market fit.

So, the actual behavioral measure of that is retention rate. What matters the most when you have a retention curve, it starts off at the beginning, you immediately lose a big percentage of people that never come back, so it may start at 60-, 50-, 40-, 30% on people that ever come back and use the product. Then it decays and goes down. For most new products, it actually decays to zero. We use the metaphor of a leaky bucket, right? The water in the bucket is your customers. If that retention curve goes down to zero, like say in 90 days, that means that all that water that you worked so hard to build your product and get all those people in there, eventually leak out.

Conversely, if you've got product-market fit, that retention curve will eventually flatten out at some asymptotic level. It may be like 5% or 10% 90 days out, but it flattens out and you manage to hold onto that water, those customers. And I do this awesome exercise where I throw three cohort curves and I have everybody vote, and everybody always votes for the one that has the highest terminal value of retention rate.

I'm like, "Wait a minute. Did you guys have a meeting without me and agree to vote on that one? Did you guys have PhDs in retention rate?" They just know. Once you see it, you realize, "Oh, the higher percentage of people that come and use this product, the higher level of product-market fit we have."

For those people that are really yearning for a solid definition of how do I know? That's how you know.

Suzanne: Yeah. And that's where you can kind of put the gasoline on it, right? Because if you're spending so much money bringing a ton of people to the product, but you're losing them all out the bottom, then it's sort of not worthwhile. I always say, get a funnel built, even if it's kind of like the most janky funnel that exists, because the rest of it is the game of inches and that's where the-

Dan: Right.

Suzanne: The Spock method, as you described, becomes hyper-valuable is to say, "Well, okay. Could I get one more month of lifetime value if we just did X and Y." In the beginning it's much more manual, it's much more precious, it's much more about just getting people to stick around for sure.

Is there a sense, I mean you've worked with so many start-ups and again, this is another one of those unknowable questions, but, something about you just makes me want to ask you all the impossible questions.

How long should I expect as a start-up to really be in this trying to get to product-market fit? ‘Cause the media creates these false expectations that's like tomorrow you're going to get funded and then you're going to be Facebook. What is that timeline of just iterating on is this need? Is it this feature? Is this working?

Dan: Yeah. Well, yeah, it's interesting. In hindsight, it's like, "Oh my gosh, Twitter became huge overnight." Everything's overnight, and you're like, "Wow." All of a sudden it just came out of nowhere and you go back and you realize, no, they actually, the founders were working on this for years maybe and like iterated and things like that.

It's hard to give it a precise time-frame, but I think part of it depends on the skills on your team, and assuming, let's say, assuming you have all the skills you need. You have a good product-management person, a good subject-matter expert, a good designer, a good developer. Let's say you have those skills, right? You go out there and form your hypotheses, and you go and you test. It kind of comes down to how many times ... do you need to pivot or not, and how many times do you need to pivot? Let's say best case scenario, you don't have to pivot. Let's make this the best case scenario-

Suzanne: Yeah, let's say that. That sounds good.

Dan: You don't have to pivot. You have to iterate and ... there's an iteration of pivot. Pivoting means you are fundamentally changing one of those key layers of the pyramid, like, "Oh no, we're going after the wrong target customer." If you change a target customer, all the layers of the pyramid above it build on it and you're basically starting from scratch again in a certain sense.

Now, maybe you pivoted 'cause you found that that need that you thought this customer have, this other customer has, maybe you can keep the need the same, but you need to kind of revisit everything.

Suzanne: Let me just pause you there 'cause that's such a powerful visual that I don't want to get lost for our users 'cause people talk a lot about pivoting and do use that term incorrectly. But, I like what you're describing. It's kind of like with development, the cost of change increases the deeper in the foundation you go.

Dan: That's right. Yeah.

Suzanne: Same, I guess, in the pivot. If you go way back down to that core layer of, "No, we're going to go after doctors in the Midwest now, instead of Millennials on the West Coast," everything else is subject to change.

Dan: And a lot of companies start out B to C and pivot to B to B. That happens a lot. And when you do that, ... a lot of things change. A lot of things change if you do that. That's like the extreme that you do. And it's also a subtler version is a lot of people ... two of my client, Box and YouSendIt. They both started at B to C, and then they pivoted to SMB and then they worked their way up enterprise.

If you, in the pursuit of improving your business, you could deliberately be changing who it is in meeting your goals and trying to drive higher revenue per user and bigger markets, right? You might be changing it, and so that's an adaptation that you have to do.

When you're doing B to C, there's no sales team, right? It's all about more online marketing and things like that, and as you get up to enterprise, now you need a sales team. Things can change.

But going back to, let's assume ... so there's iteration, where you're just like, "Hey, we didn't really change. We're just refining what we've got and making small iterations," not pivoting. Gosh, let's say, maybe a few months to do good discovery and get really clear on your target market. Maybe a few months, I'm saying a few to be a little vague, like one to three, maybe, right? To create some initial designs and run them by-

Suzanne: Including testing.

Dan: Yeah, and then test them with users, and rinse and repeat. I mean, I guess a counterpoint is the example that I share marketingreport.com in the book. It took us four weeks because we weren't doing any coding, right? And because we did it very methodically. It took us four weeks to get to basically a set of clickable mock-ups, a prototype that we felt pretty good about, that we had validated with customers and they said basically, "Hey, we would pay 10 bucks a month for it."

So that's ... now there was no coding yet, so now the question is, how long would it take to code that? That's another variable. It's hard to say how long it would take to code. It depends on the complexity and scope of your product. But, certainly I could see it being done in a year if everything's great, you don't need to pivot, you have the skills. You start out at a good starting point, less than a year.

Realistically, one of those things is not going to be true. You're going to be missing some skills on your team. You're going to have to pivot something. Things are going to take a little longer. There's difference of opinions about which direction to go between the founders or the board, and so you have to sort that out. Sometimes you're exploring multiple directions. You're getting distracted by things that don't really matter.

Suzanne: Or you're bootstrapping, so you've got all that velocity of going to your other job.

Dan: Yeah, or you've got to go focus your time and energy on fundraising or whatever it is, right?

Suzanne: Sure.

Dan: Yeah.

Suzanne: I think it's probably a relief certainly for some of the entrepreneurs listening and going, "Oh, good," because some people are at it a long time and there are those other variables, and I think it is important to be real about the ... it's fun product, but it’s challenging.

Dan: Well, conversely, what I see too is people that ... they're afraid to commit to a direction. I live in Silicon Valley so I go to some tech happy hour, and someone's like, "Hey, how's your start-up going?" "Oh, it's great. We're pivoted to chatbots." I'm like, "Oh, cool."

I see the same person three months ago. "Oh, yeah. Hey, we're pivoted to deep learning." They never actually launch their product.

Suzanne: Right.

Dan: So, I like to say, if you pivot four times, you've gone in a circle basically, right?

It's this tough thing of how do I know ... so, one, you've got to commit. You've gotta get in market. Get out there talking to people. They will guide you. If you're just in the building hypothesizing, you can spin your wheels and spin your needle around, or you're going.

It's just important to get out there and talk to people, basically.

Suzanne: Yeah. Well, I think that's again, that's another one of those fear mechanisms that we spoke about with features. It's if I just keep adding features and polishing up the stone, then I’ll never have to run the risk that somebody says no. And it's like, someone's going to say no. I want to kind of get out there in front of it. Same with the strategies.

Dan: Right.

Suzanne: For sure.

I just have a couple of questions left for you, Dan.

The first is with regards to, kind of the work that you do out in the world. So, when you're not busy touring around and giving workshops, and giving talks, you actually consult start-ups. My understanding is that a lot of what you do is sort of come in as the first product manager, kind of fractional product manager. Help to bring a product-management centric viewpoint to the organization, and then ideally, they in-source kind of a team, and then you extract yourself-

Dan: That's right.

Suzanne: And say thank you. So, my question is, when does an organization need you, or how are you helping them to understand when they need you? When is the right time for a start-up to bring in a product person?

Dan: Yeah, I basically consult full time. I'm often an interim VP of product. There are two types of situations I help companies with. One, actually, it's less than the start-up focus work that I do, but it's actually a later-stage start-up or a bigger company that realizes they're not as lean and agile and customer-centric as they want. Sometimes I go in there ... in that case they usually have a product team or product leader, and I'm brought in to help elevate the skills, assess the skills and coach, and improve the skills on the team itself. So, that's one set of engagements.

The ones that I do more is usually joining a start-up. It's almost very frequently post-Series A. And I think that ... so I did this at Box. I did this at YouSendIt. And like you said, I'll come in post-Series A. Usually they don't have anyone who's really been in product management. Maybe one of the founders has been wearing that hat, but they're not really ... don't have deep expertise in it. Like one of my clients, the founder's really a smart guy, a great guy. After they raised the funding, he had to focus on other operational issues, and so the devs were kind of like sitting there twiddling their thumbs a bit, going "Okay. We used to be able to have meetings with you every week, but now you got too busy."

So, one thing is if, as a founder or CEO, you used to have a little bit of bandwidth or product and now you suddenly feel like you don't. A PM's job is always to make sure the devs are working on the highest ROI stuff and that we've got ... that we stay one step ahead of them on the backlog, that they always have something meaningful and valuable to do. If you feel like, "Gosh. I'm just not able to do that anymore 'cause of other demands," then that might be a good time to bring someone in.

Conversely, the other thing I see is sometimes you have CEOs that are big picture idea people. And they go, "Okay, we just want to do this thing," and they get on a whiteboard and they wave their hands and they kind of draw some stuff, and they say it verbally. And then, here's the dev sitting there. He's like, "Okay, great. Go build it guys." That's a big gap between a CEO that's kind of verbal high-level vision on a whiteboard, and then the poor developers have to figure out, "Okay. What does that mean from a feature set?" And often there's no designer in the equation either, so it's like ... that's just a recipe for disappointment. And then three weeks later, the CEO is like, "Okay, what you got?" It's like, "Um, well, we're not really quite sure what we need to do," right? So, filling that void.

What I do too, what I learned early in my career is UX design is super important. That's why my book, even though it's not a UX design book, has a chapter on UX design because it really matters to build a successful product.

Again, you can have the best functionality, but if UX design is poor, it's going to get in the way of people seeing the value. So I also will basically create Balsamiqs and create wireframes. And I usually partner with the visual designer, but um ... to help fill that design gap that's there as well.

And then, I usually help them ... I'm kind of like a CEO whisperer. I'm like, "Okay, tell me your thoughts about your product strategy. Tell me your roadmap ideas." Then I'll formulate them in a real roadmap and iterate, and then they go, "Oh yeah, that's what I want to do over the next nine months." I'm like, "Great." Then I'll turn around and I'll write short product briefs on each one, and I'll write the Jira tickets and sit with the dev. But before that, I'll actually create wireframes and go and test with customers, conduct the research and iterate. So, it's a lot of fun.

Then usually by ... usually it goes from Series A to Series B, about 12 to 18 months, and when Series B rolls around, they're like, "Dan, thank you so much. We have an awesome roadmap. We have our MVP out. We’ve got our analytics in place. This is great. We understand product management now. Now we want to hire a full time VP of Product." And then I'll help them formulate the job description. I'll even help source them. I have a very strong network. And then I'll transition that person, and then ride off into the sunset and work on the next client.

Suzanne: I think all of our listeners are going to want to reach out to you and be like, "Can I be part of your network? You're the guy that just gets everyone PM jobs, right?"

Dan: Yeah, yeah. Well, it's actually funny. I actually recently ... so, there's a lot of demand, I kind of operate at the VP level. Usually the CEO or product leader brings me in. There's a lot of demand at the senior PM level, so I recently actually added a senior PM consultant to my practice, so that's pretty cool. To be able to help clients, and he and I, when we work at the same client, we can kind of tag team. I can engage with the board and the exec team about strategy. And he can work more with the engineers and designers on tactical execution.

Suzanne: Super exciting. If we're interested in those consulting services, where do we go?

Dan: My website is dan-olsen.com. D-A-N hyphen O-L-S-E-N dot com, and I've got blog posts there, I've got my videos from my talks there. I also run a Meetup down in Mountain View-Palo Alto. We have 6,000 product managers and designers. I bring in top speakers every month. That's highlighted there.

My official consulting site is olsensolutions.com, but either site you can learn about it.

Suzanne: Okay. Awesome. Just one last question. So, I think what I love about the book, as I've said before, I know I'm gushing a little, is how practical it is, and for entrepreneurs. I think that my practice is just gonna be giving one to every client that comes in the door and say, "You go away and read this and then come back when you kind of want to talk."

But, I imagine a lot of the folks in your audience, certainly a lot of the folks listening in are product managers, and product managers subscribe to these ideas, they're going to read your book if they haven't already, and then they're gonna really subscribe to the ideas.

What advice can you offer to somebody who is a product manager themselves, whether its VP of Product or Senior PM, and they want to be lean, and they want to take this practical approach to getting to product-market fit, but they don't have the buy-in, or the philosophical buy-in from the key stakeholders? Aside from giving their stakeholders as a copy-

Dan: Sure, sure.

Suzanne: What would you tell a PM to solve that problem?

Dan: Yeah, and usually, I think it's good to think about, what are the underlying reasons why they're in that situation. It's typically because they may be the only, or one of the only product-management-focused people there or people that have experience in that.

If the CEO was a product-backed person, if you're at a start-up, for example, you might not be having some of these debates. You've got to recognize that a lot of it probably comes from somebody not having worked in a place where they've done these practices well, and so they just don't know what they don't know. I think it's largely an education thing.

Then that comes down to your credibility. If you're just like, "Hey, I'm like the lowly PM trying to tell these people how we should be doing it, what best practices are," sometimes there might be a credibility issue or they just won't listen to you as much as they should.

So, that's where a third-party ... pointing at third-party benchmarks or experts can help. It's like, "Okay. Well, let's see how Slack organizes their product teams." There are a lot of ... whether it's Intercom or Slack, a lot of companies are actually sharing how they do the art and science of building products, and so then it's not just you PM at the company. It's like, "No, look. These guys are doing it." There's enough pointers out there and people talking about it. There's enough consistency, like when you hear a lot of the top product speakers talk, there's a lot of consistency about focus on the customer, problem space, UX design matters, get out of the building, talk to customers. It's a lot of commonality there, right? So, hopefully that can help.

The other thing, for bigger orgs especially is, I get that same question from a lot of product leaders and they feel like they keep beating the drum and no one's listening to it is, potentially do like a little brown bag. Just bring in outside experts, whether its consultants like me or authors or speakers, or a VP of Product from a different company that's not a competitor. Just kind of like do it more socially versus like hit people over the head with it. It's like, "Oh, let's do a brown bag." Maybe get them to come to a product conference, like we’re here at INDUSTRY. Maybe get some non-product person to tag along to get a little understanding and empathy.

I'm definitely sympathetic to that, to that cause. Sometimes the biggest motivator is failure. It's like, "Hey, we tried for nine months to launch that new product, and just we fell flat on our face. Can we at least," I don't mean to rub it in, but rub it ... say to people. "Maybe it didn't work out, maybe we need to try something different."

So fear and failure can be good motivators 'cause if things are going well people are reluctant to change. I think it's either fear and failure, or showing people that there's a better way by pointing to other people out there that are kind of crushing it and saying, "Oh, look how they're doing it. Can we agree that these guys are successful? Why do we think they're successful?"

I think a lot of it, too, is just asking why. I think why is one of the most important questions. If a stakeholder wants to do a certain thing, it's like, "Oh, hey. Can you help me?" Not say why in a challenging way. "Hey. Can you help me understand why you feel that's important?," and you'll see if they have a solid foundation of a pyramid as why, or was just like no, it's just there’s not much behind it there.

Getting socratic and using the same techniques. Say, "Well, great. What's your ... it sounds like there's a hypothesis behind why you want to do that." What is a hypothesis? And they go, "How might we get evidence to support or refute that hypothesis?" If you can try to get that.

And at the end of the day, look, if you're in a place that fundamentally doesn't care about the truth or this scientific approach, maybe you need to go to someplace that does, you know?

Suzanne: Yeah, absolutely. Dan Olsen, author of The Lean Product Playbook. We'll put the links in the shownotes. The book has already been recommended by so many of our guests. 100productmanagers.com/resources.

Thank you for being a part of our show.

Dan: Thanks a lot. It's been fun.