The Nils Davis Hypothesis: A Good Story Comes From Solving A Real Problem For Real People

Based on more than two decades of enterprise product management experience, including a stint managing a product for product managers, Nils Davis has lots of knowledge and wisdom. In his podcast, the Secrets of Product Management he shares powerful ways for product managers to create more value by ensuring every product is a solution to a meaningful market problem. And that every team creating and selling products is as effective and motivated as they can be.

In this episode of the Product Science Podcast, we cover how to tell a good story, why ROI calculations hurt innovation, and the 5 questions every PM should be able to answer.

Subscribe for the full episode on Apple, Google Play, Spotify, Stitcher, YouTube and more. Love what you hear? Leave us a review, it means a lot.

Resource Links

Product Manager Grad School

The Secrets of Product Management Podcast

David Binetti

Follow Nils on Twitter

Follow Nils on LinkedIn

Follow Holly on Twitter

Follow Holly on LinkedIn

Questions we explore in this episode

How can a product manager or startup founder determine if a product is struggling because it isn’t solving a real problem or because they are struggling with go-to-market strategies?

❓Nils recommends 5 questions that each pm should be able to answer:

1. Who is the target customer?
2. What problem do they have?
3. What have they tried?
4. How are they solving that problem today?
5. Why is our solution their best alternative among all the choices?

☑️ If you can answer all those with good solid answers, then you have a go-to-market challenge.

How do you get the stories that you can use to convince customers that your solution is worth trying?

🔍 After you’ve talked to many customers to understand the problem, you can recruit some of them to test out your solution.

💬 If you talk to 100 people, you might find 10 with the problem, and 1 who is willing to try your solution. You can offer those first users to try it for free.

🔄 Repeat until you’ve found some that get value out of your solution, and invite those people to share their stories.

🤔 Make sure the middle part where the hero of the story faces challenges is really interesting.

How does the typical corporate approach to the finances of innovation hurt companies and what can be done instead?

🕑 Early in an ambitious new project, ROI calculations often stop the project in its tracks.

💡 Instead, use David Binetti’s Innovation Options - a way of calculating the potential return in a language that works for both finance and product management.

💰 With Innovation Options, you make a small investment first to reduce risk and only make a bigger investment once that risk has been managed.

Quotes from Nils Davis in this episode

Most people don't use user stories as stories, but they get way, way better if you use a story structure for the user story it is much more motivating. You get better solutions from your developers because they understand what they're doing.

It's up to product to provide the information that says, who should you target? What should you say to them? How can you persuade them that other people just like them are really happy because of us? How do you guide them through that? There's obviously still a lot of skill and art in selling, but you don't want the salespeople trying to make it all up.

The reality is that is how lots of these big companies work. They will not create new things because of these financial rules, but they need to move out of this thing about ROI because it always crushes innovation.

The Product Science Podcast Season 5 is brought to you by Productboard

Check out their eBook: 10 Dysfunctions of Product Management

If your product team is struggling, it could be one of the 10 dysfunctions of product management. Learn more about each dysfunction and how a product management system can help you address and avoid them.

Get Your Copy

Transcription

Holly Hester-Reilly:Hi, and welcome to the Product Science Podcast where we're helping startup founders and product leaders build high growth products, teams, and companies through real conversations with people who have tried it and aren't afraid to share lessons learned from their failures along the way. I'm your host, Holly Hester-Riley, founder and CEO of HQR Product Science.This week on the Product Science podcast, I'm excited to share a conversation with Nils Davis. Nils is a product manager, podcaster, coach, and author. His book, the Secret Product Manager Handbook, has been called Nuggets of Products Management Wisdom and Ideas You'll Want To Hang On Your Monitor. He creates lots more nuggets for products managers in his podcast, the Secrets of Product Management, and on LinkedIn and Twitter. Welcome, Nils.

Nils Davis:Thank you very much, Holly. It's great to be here.

Holly Hester-Reilly:I'm so excited to have you. I often begin by asking people to tell me a little bit about how they got into product. So I'm curious to hear from you. How did you get into product?

Nils Davis:Oh, like everybody who gets into product. I went to college for product management and I got a degree in product management.

Holly Hester-Reilly:Yeah.

Nils Davis:That's a little joke. I'm sure you recognize because you laughed. When I got into product management a long time ago, no one even really knew what it was. And so I was a tech writer at a company. It was one of the AI startups in the 80s. A bunch of startups around AI got started and they flew high and then they crashed. But I was in there at one point and I was a tech writer, so I was writing sort of technical manuals about how to program, and I think people noticed that I had a very good sense of empathy for customers. So what the customers needed in this manual as opposed to just saying, here's the names of all the functions you can call with our language. It's like, how would you use that? What context might this work in? What are some options? And I think people noticed that I had had this customer focus. And so when the product manager who was there left, nobody really knew what he had done.Nobody knew what his job was, but somebody said, well, you should become the product manager for this product. So that was how I got into product management. I knew nothing about it. I did not know what it was, but it seemed to suit my personality and the way that I looked at things. Apparently. This is all in retrospect. At the time I had no idea what I was doing, but I knew that I needed to do prioritization and write stories, and we didn't call them stories in those days. That was before Agile really got off the ground. We called them requirements and we wrote requirements documents and all these things. And all during that time I thought, I wish there was a book that would tell me what I was supposed to do. Or maybe these people that are successful know it. Maybe there's a secret book, a secret handbook. So that's why I called the book the Secret Product Manager Handbook because it was a thing that I always wanted when I got started.

Holly Hester-Reilly:Got it.

Nils Davis:And that was decades ago, Holly, just have to say that.

Holly Hester-Reilly:Yeah. You mentioned requirements documents, and that really made me perk up because I have come across people who still write requirements documents and I'm curious what your perspective is.

Nils Davis:Well, I always knew there was a better way. Because I'm from High Tech, I understand that you can partition things and that makes them more useful in some ways because you can reorganize them and rearrange them. And so for many years after I got started, the mode that we used was Word. We created requirements documents in Word. Some people put requirements into Excel, which I never understood because there's not enough space to put all the information and it's not structured enough. But I liked Word accept that we would write a PRD and we would work on it and we would release some of the features that were in the PRD, but some of the features wouldn't be released or they'd change. They'd be different from what we wrote. And there was no easy way to slice it up and say, oh, this happened.This didn't happen. Let's start a new PRD, or Let's create a new PRD out of these other PRDs that none of them got fiNilshed, but we now are prioritizing the things that were in them. Meaning, I really wanted requirements to be atomic in the sense that I could recombine them and also decomposable because one of the things you learn is you say, oh, I want to create this big new feature and here's all the things it has to do. And then you start implementing them and you say, okay, five of these things are really important. We can't really have the feature without these five, but these other six, we're only going to be able to do three of them. We have to choose the best three. And so some of them fall off at the end, and so you want the requirement itself to be decomposed.That turned into in the Agile world eventually epics and stories, which I'm not thrilled with epics and stories and how people talk about those typically, and I have a long rant about that. But that was what I was looking for. And then I was working at a company called Net IQ, which was a very successful system management company. And I persuaded the company to start looking at tools for product managers, which there were barely any of, but there was one that had just started called Accept 360. It was called Accept at the time. And they came in and they said, here's all the things we can do. And to me it was like the perfect way of addressing the product requirements document. Requirements were individual, they were directly related to customers. So you could get a customer suggestion, you put it in, you have all of your important customers in the system, so you could refer to which important customer wanted what. You could use that for prioritization.There was even an analytical way to do that. The suggestions could turn into features or multiple features or multiple suggestions could be related to one feature. All of those really powerful capabilities that actually very few tools today support. JIRA doesn't, for example, to many relationships. And then you could put those together into a product plan and you could say, oh, this product plan's going to be these requirements and this is the priority order. And eventually we had stack ranking in there and things like that. So that was really powerful and I was really thrilled with that. Unfortunately, I didn't understand enough about what product management was at that time, even though I'd still been doing it a long time to figure out how to actually go to market successfully with this. So I knew that we had successful customers. I knew that customers loved it.I knew that we loved it. We used it every day at this little company, but we couldn't quite figure out how to tell the market about it effectively. And then some executives made some other decisions unrelated to that product and invested a bunch of money on something that failed. If they'd asked me, I would've told them. And so that company went out of business. But then what happened? So this is getting toward the end of my story. Well, okay, I want to understand why Accept was not successful. It was clearly satisfying a need that people had, but we weren't able to sell it. What's wrong there? And that turns out to be a go-to-market problem. So I got really interested in go-to-market because I consider that to be part of product management responsibility. And so that's what a lot of I've focused on is we had a product that solved a problem, but the market didn't know that there was a solution to this problem.We didn't articulate it, so on and so forth. And so that's the story. And then since then, I've also just been a regular product manager at other companies, but Accept 360 was sort of the formative thing. And then it drove this whole set of thinking into how can we make go-to-market better?

Holly Hester-Reilly:Yeah. So what were some of the things that you realize now in retrospect had been big challenges to getting go to market right back then?

Nils Davis:I think the biggest one was that we really didn't articulate the problem correctly or the value of solving it. I think every product manager knows that having their requirements in Excel or their stories or now in JIRA even that there's a lot of limitations to having your requirements in a system that doesn't understand product management, doesn't understand where you're trying to go with your product, doesn't have a long-term view, doesn't have a way to help you prioritize. So all of these things and product managers are always suffering and they're using other people's tools. So JIRA is not a tool for product managers, it's for somebody else. Word is not a tool for anybody. It's a tool for everybody, which means it's for nobody. So that was one of the things. And we tried to fit into a category that existed. Different ones, none of them were the right category for us.And so I think a lot of it was we just didn't effectively know how to take the successes of our customers and turn those into marketing. And so we weren't good at the storytelling part of this. And if you think about how people make decisions emotionally and they justify the decisions rationally, and so you have to have that emotionally engaging statement that's going to help somebody say, oh, that customer was just like me. They suffered from the same pain I had, and now they got a raise because they brought in this tool, plus which the pain is gone. There has to be multiple aspects to that. And I thought of things like at the time, and this was at the end of Accept anyway, but things like what would a really happy customer write as an Amazon review of our product? And you think about an Amazon review and what makes a good Amazon, it talks about the challenge that the person had before and how frustrated they were.And then they got this product and maybe they searched for a while to find a solution to this problem, that budget of solutions didn't work. And then they found this solution, this product, this book, whatever it is on Amazon. And suddenly their problem was solved and their life was much better and they had these transformations and we're not telling that story. And to be totally frank, almost no enterprise software company does a good job of telling that story even though those stories are there. And of course the other side of it, you can't tell that story if your product doesn't actually solve somebody's problem. So there's lots of products that fail because they're just a solution in search of a problem. There's not a real problem that product solves no matter how beautiful the product is or how spiffy the technology, if it doesn't solve a real problem.It doesn't matter how you go to market because you'll fail. But if you have a product that solves a problem and you don't do go to market right, you're likely to fail. And that's sad because that was a product that had a life, had a future if you did something. And I often see products that just, they do something and powerful and they have successful customers that love them, but they can't figure out how to sell them to a bigger market. And that's not the product's fault. It's the go to market fault. Now, that is also product manager's fault because in my view, the product manager needs to provide the fodder for a successful go-to-market, the stories, the articulation of the problem in the customer's words, because we did all that discovery beforehand when we were thinking about building that product, why did we decide to build it?We could tell a great story about prospects who were having a lot of pain that we could solve in a better way than there are other alternatives. So we have that knowledge. Oftentimes all we tell to the sales team or to the marketing team is, hey, we've got this new project management tool, go sell it. Then they start competing against Microsoft project, which if you're working on an enterprise grade project management tool that is really for PMOs that have a hundred people on 10,000 projects, you're not going to compete against Microsoft Project. You're going to fail if you try. You're going to have way too many leads that aren't qualified. So it's up to product to provide the information that says who should you target? What should you say to them? How can you persuade them that other people just like them are really happy because of us? How do you guide them through that?There's obviously still a lot of skill and art in selling, but you don't want the salespeople trying to make it all up because we have the knowledge. The product organization has that knowledge, and if we give it to them correctly, they can be much more successful.

Holly Hester-Reilly:So if you're a startup that is struggling or is failing, how does a person who's in the midst of that tell the difference between they aren't solving a real problem versus they're not getting to the market?

Nils Davis:Well, I have a list of five questions that I think is really valuable for this situation. And basically this is the question. If you have an idea for a product or if you're building a product, you need to be able to answer five questions in a non-stupid way. You need to be able to say, who is this product for? There needs to be a specific type of person or company that needs this solution, and it might be an individual in a company, but there's characteristics of this person. If you're talking enterprise software, they're not demographic characteristics. They're more about the job and the types of problems they're facing. If it's a consumer product, which is not my area of expertise, but it might be a demographic thing. So you have to know that. You have to know, okay, what are they doing? What is the problem that they have?You have to be able to articulate that and you have to say, oh, it's not that they just are frustrated by something. It has to be a painful problem because they have to spend money to solve it. What problem is this problem we're spending money on? How are they trying to solve that problem today and why is that not good? Why is that not working for them? And what other things have they tried? And ideally you want to find out that they tried a lot of things, they failed at all of them, and your solution is going to solve that problem better for them than all the other alternatives that they could potentially choose. So that's the fourth question. I might be on five already. I'm not sure. Why is our solution their best alternative amongst all their choices? Remembering that their choices can be, I'm not going to do anything.I'm going to take this money that I have and I'm going to spend it on some other problem that is more painful or that I'm more confident of the solution of, things like that. So you have to ask those questions. Who's it for? What is the real problem? And it has to be a meaningful problem that is causing lots of pain. What have they tried? What are they doing about it given that they don't have any solution yet, and why is our solution their best alternative? If you can answer all those with good solid answers, then you have a go-to-market challenge potentially. And particularly if you also have some customers that are successful with it already. So if you have some customers that are successful with it already, that's the basis of your go-to-market, in my opinion. The stories of those customers, what was the pain they were feeling?What did they try? They tried this, all those things failed. They found us. Oh, yay. And they got the promotion or the raise or the recognition in addition to solving the problem because it turns out that increasing sales by 10% is not that motivating to most people. You can use it as the backup information to I was about to be fired and then I got a raise because of your product. And oh, by the way, that's because it gave us a 10% uplift in sales. But if they weren't about to be fired and they didn't get a raise, the story isn't that good. So the story needs to have that kind of human aspect in it. And then you use the stories as the basis for things like discovery calls with new prospects for qualification.Do you have this problem this other customer had? You can use it to say, oh, we have a great customer that had this very same problem as you, and then they solved it. I'd love to show you in a demo how they solved that problem with our solution. Instead of saying, can I sign you up for a demo? You say, can I sign you up for a demo that will show you how your problem will be solved with our solution? It's a much different statement, much more engaging.

Holly Hester-Reilly:I guess one of the things that comes to mind for me is that those five questions are really good at getting at a value proposition. They're really good at saying, what is this about? But how do you get those stories? How do you get those reference customers?

Nils Davis:Well, hopefully when you went out and did market discovery, you started to hear the first part of these stories, the bad part, the tragedy version of the story. You talk to a customer and they said, I have this thing. I've tried all these solutions, none of them worked and now I'm tearing up my hair and I'm holding on by the skin of my teeth or by my fingernails. And then you say, oh, you hear that enough? And you say, oh, I think there's a product out here to be created. Let me create it or let me create an MVP or let me do something right and see if I can solve that for that person or for people like that person. And then once you have a solution, you go back to that person or people like that person and you say, look, here's the thing. You can be our first customer, you can get it for free and if you'll give me a good story, whatever, that's how you do it.You start with the first customers and you make sure that they are super happy and that aligns with that the way that they got to happiness aligns with what you actually can deliver to other customers whom you don't know personally already. And that's easy for me to say that. Just go talk to the people that you talked to before. Obviously, we know that even finding the problem initially, that's going to take hundreds of conversations. You're going to find maybe tens of people that have this problem. You're maybe going to be able to sell one or two of them on the first version. But that's all part of the job.

Holly Hester-Reilly:Yeah. And I think that's one of the things that when I work with clients that they often have a hard time with is figuring out what are the numbers of these things that make sense? Is it taking them way more customer conversations to find that early reference customer than it should or are they on track for success?

Nils Davis:It's hard to find these problems. If they were easy to find, there'd already be a solution to it. And of course, the reality is that we may think, oh, I used project management as a domain a lot because I've worked in that a while. There's lots of people that need project management and are on project management pain, but they're often in other kinds of pain as well. So even if project management is a big pain for them and you discover that, they may not be ready to buy a solution because they've got another pain that's actually funded, and so they may be spending their money elsewhere. So even if you find a great problem, getting that first customer still becomes a challenge.And I'm not an expert in these numbers, but I always like to think in terms of orders of magnitude. You talk to a hundred people, you find 10 of the same story, and that's a good signal if you can do that, and then you can maybe close one of those people. That's the way to think about it. It's just like in any marketing effort, you're going to send out a hundred things, you might get 10 responses and you might make one sale. It's a decent rule of thumb. It might be off by an order of magnitude, but it's probably not off by two orders of magnitude, and it might be half that number or twice that number, but it's in that ballpark. It's just an easy way to think about the world. Then you don't have to do much math.

Holly Hester-Reilly:Yeah, it does simplify it. I like it.

Nils Davis:I was a math major, so I try to not do math. I try to do simple math.

Holly Hester-Reilly:Oh, is that how that works?

Nils Davis:Yeah. The more you know about math, the more you know how to simplify things, I think.

Holly Hester-Reilly:Okay, that makes sense. I could see that.

Nils Davis:The more you trust the simplifications, that's the thing. The less you depend on the actual numbers and the more you depend on their ratios and relative sizes. And because the other thing is I was also a physics minor, and the thing about physics is there's a huge amount of uncertainty in everything you do in physics.

Holly Hester-Reilly:Yeah.

Nils Davis:Not as much as in product management, but in physics you do an experiment and you expect to get the answer supposed to be five because you know that this experiment has been done thousands of times before you, and the answer is five, but you get 4.7, 5.2, 4.39, and you just have to say, oh, there's a lot of uncertainty in the world. So I'm just going to say I'm going to go with five as the answer to this later on, and I'm not going to worry about the fact that yes, there is variation, but it's actually not that important to the ultimate answer of five.

Holly Hester-Reilly:It's interesting to hear you say that because it makes me think about how I like to follow the principle of significant digits that I think about. Okay, if I were reporting this with significant digits, then I would have to think about how many zeros after the decimal or how many zeros before the decimal and how many actual digits that are non-zero communicates the right level of fidelity.

Nils Davis:And also how many arithmetic operations you've done on that number to get to that point. Because the number of significant digits you have always goes down for every operation. So if you start with a pretty accurate measurement, but then you multiply it by an inaccurate measurement, then the result is pretty inaccurate.

Holly Hester-Reilly:Exactly.

Nils Davis:So whenever I see somebody put up something that says, oh, 73.7% of the respondent said X, and they talked to 300 people, it's like that 0.7 doesn't have any meaning. In fact, the 73 it's probably means is the actual rate.

Holly Hester-Reilly:Yeah. Exactly. I feel like it's a useful concept in product management for us to think how we're communicating our learnings and our findings.

Nils Davis:Yeah, definitely. Do you know the work of Douglas Hubbard? He wrote How to Measure Anything?

Holly Hester-Reilly:Oh, How to Measure Anything. I'm familiar with the book.

Nils Davis:Okay, so great book, How to Measure Anything. So I'm not a big metrics fan generally because of uncertainty.

Holly Hester-Reilly:Okay.

Nils Davis:My big takeaway from that book is something that he said is that you can measure anything, but you have to understand that you potentially may have a lot of uncertainty and you should understand how much uncertainty you have in that measurement, and it may be arbitrarily expensive to make a particular measurement. So a lot of times it's much more cost effective and mostly as accurate to make an educated guess on something where you'd have a lot of uncertainty or high expense to make that measurement. So I combine that with the fact that for most of the things that we can measure, they don't directly measure the things we want to know. If you measure metrics on your app, except in certain very specific cases, they're never going to tell you how to grow your revenue by a factor of 10. They might help you grow your revenue by a factor of a 10th, which is even still a lot, but factor of 10, that's thousandth percent.A factor of a 10th is 10%. 10% growth is fine. But as a product manager, I'm not that interested in 10% growth as a rule. I'm much more interested in doubling growth over time. I want my product to grow by a factor of two in a few years or a factor of 10 in a few years. And so metrics aren't going to help me with that. Analytics are not going to help me. What's going to help me is my brain, which is a super good computer. We always forget that. My brain is super good at recognizing patterns in the world. The problem with my brain is it is too good and it sometimes recognizes patterns that aren't there.So I can use my brain to help me figure out what the heck's going on, but I also have to put a check on my brain. I have to do crosschecks to make sure that I'm not seeing something that isn't actually there. But our brains are way more powerful than our analytics tools for big picture things like that and for making sense market discovery, like you get data from market discovery, our brains aren't going to make that correlation. There's no tool that's going to make the correlation for us.

Holly Hester-Reilly:I find that I spend most of my time in Google Slides and Google Docs rather than Analytics. I definitely look at analytics and I use them in making decisions, but at the end of the day, they're an input to a decision making process that doesn't happen on its own.

Nils Davis:They're one of the things you can use also to crosscheck. I have this intuition that this is happening. Can I find data? And it's in a little way of using motivated reasoning, but you're also looking for data that will disprove your idea. Can I find data that validates or invalidates this idea that I have?

Holly Hester-Reilly:Yeah.

Nils Davis:That's a useful thing to do. There's not going to be much data that's going to tell you if you have an intuition that you should go into a new market with your existing product. There's not going to be too much data that's really decision making ready for you to make that decision. There has to be a lot of intuition involved in that.

Holly Hester-Reilly:That's always the place where you have a lot of imprecise measurements involved. In my experience that a lot of estimates that are just directional orders of magnitude information for you.

Nils Davis:I love the concept of innovation options. This is something a guy named David Benetti, I think that's his name, came up with. It's the idea of making incremental investments. You start with a small investment to reduce some risk and then if you reduce that risk, you make a bigger investment, which has been obvious thing to do. But what David did, which was really powerful, was he financialized that whole thing. He put into terms like investment options in the finance world, because finance people understand investment options. I'm going to put a little bit of money down in order to take advantage of a deal that might or might not happen, but if it happens, I have to put more money down, but then I get a good return. And so he uses that concept for driving innovation. You start with a small investment, you reduce the biggest risks, and then if you've shown that you can reduce those risks, you get a bigger investment, reduce the next risk.And it's a way that you can start with a really small set of investments on a billion dollar idea. And at every moment you can decide, am I actually making progress toward the billion dollar idea or is the billion dollar idea bad? So you don't need to get the $100 billion of development funds upfront. You don't need to get that until you've pretty much figured out that we can get the $100 million back at any rate and have the upside of a billion.

Holly Hester-Reilly:Yeah.

Nils Davis:It's a really powerful idea and it's just a good mental model for thinking about how to proceed. For many of those kinds of projects, an ROI calculation will always kill it because the ROI is never there and for 10 years. But think about if Steve Jobs had said, I want you to do an ROI calculation on the iPhone five years before he started developing it. They'd had 27% ROI hurdle in the first three years that would never have built... You have to treat it in the way of we're investing, we're reducing risk. This is going to be a billion dollar idea. And in fact, for them it was way more than a billion dollars, but it's going to cost us a huge amount of money, so let's hedge our bets before we get there and it will never look good from an ROI perspective until we shipped it for five years.

Holly Hester-Reilly:Yeah, I'm a big fan of that shipping a little bit, investing a little bit, de-risking a little bit and investing a little bit more. I wish that it was easier to get adoption of that within company. I find that small startups have an easier time with it, but the bigger the company, the harder it is for them to actually practice that kind of investment approach.

Nils Davis:To oversimplify a lot, and I've already told you how much I like to simplify things, it's really because they're using an ROI argument to the financials instead of using an innovation options approach or something more appropriate to this type of investment. Startups aren't expected to make money or make profits for a long time. That's the nature of the business. But if you're in a business and there's a finance person to say, I need an ROI on this in five years and it needs to be positive and it needs to pass our hurdle rate, otherwise we're going to invest the money elsewhere, they're never going to create anything new. And the reality is that is how lots of these big companies work. They will not create new things because of these financialization rules or financial rules. I don't know if maybe financialization is the wrong word, but they need to move out of this thing about ROI and hurdle rates because it always crushes innovation.In order to have a $100 million dollar business, you have to first have a million dollar business and then a $10 million business. And even if that's growing fast, that first set of million dollar to a hundred to $10 million, that looks slow and it's often not profitable. And then five years later you're $100 million dollars and suddenly creating cash. But it didn't look like that initially. And that's a big problem for ROI based financing of projects. And it means that most big companies cannot create innovations because that's how they go about it. They could fix it. That's a simplistic thing to say, but companies that do create innovations, they create a bucket of funding for innovations that doesn't have ROI stuff on it or it's different at any rate. And they innovate using that money. They don't take money out of the big bucket. They use the innovation money and they're more likely to be able to innovate if they do that.

Holly Hester-Reilly:They plant the seeds and they have that money set aside for planting seeds, knowing that some of the seeds won't grow and some of them will.

Nils Davis:I think a lot about predicting the future about how all the things that management wants product to do are really predicting the future things. And I don't know about you, but I'm pretty bad at that, at predicting the future.

Holly Hester-Reilly:Yeah, I don't think I'm so great at it either.

Nils Davis:If I were a lot better, I would not be doing product management at all. I'd be doing something else where my skills at predicting the future would instantly give me a giant return. But as a product manager, I have good intuitions about what should be done. And I'm good at looking at as we make progress, are we going the right direction and de-risking and all those things? So the point is that creating innovations is all about predicting the future. Funding startups is all about predicting the future.One of the reasons that I really go to market is if you have validated that you have a product that people need in the market, then in a lot of ways go to market is execution as opposed to predicting in the future. You still have challenges with things like a competitor coming in and having a better value prop. But if you have a product that solves a problem for a set of people and you've validated that, that means you've done a lot of the work of predicting the future and now you can go execute on that factor, which I like. I guess there's a sort of more of a safety aspect. It's fun to get out of the uncertainty part of product management a little bit and think about the execution part because all the rest of product management's super uncertain.

Holly Hester-Reilly:That's fair. So much of it is uncertain, and I don't know about you, but I guess one experience that I have is being so much more comfortable with uncertainty in my professional life than I am outside of it, which makes me feel like it's really ironic. Wait a minute, this is what I do.

Nils Davis:That's funny. I'm a little different from that. I really like novelty in my personal life, and so we're always figuring out last minute things to do. And I particularly, I'm not that good at planning for the future. People ask, can you come and do this thing with us in November, whatever weekend that is? Yeah, of course we can because I'm confident there's nothing on my calendar because I haven't planned anything. Although of course the reality of the world is that whenever somebody says, can you do this thing on this future date? That is the one future date where you do have something.

Holly Hester-Reilly:That is the way the world works, right?

Nils Davis:That's like Murphy's Law. It's not exactly, but it's like one of those. There should be a law.

Holly Hester-Reilly:It's Nils Law.

Nils Davis:I'm sure there's a law. I'm sure I'm not the first to notice it.

Holly Hester-Reilly:What are some other areas that you found in your writing and in your podcast that people struggle with that you have experienced yourself?

Nils Davis:Well, I think one of them, I've touched on it already, which is storytelling. I'll tell you a little story. So my wife, her family is storytellers. They would going into the store could turn into a story. It's not a very interesting story, the story about going to a store, but they always did it in the form of a story. And we did not do that in my family. We did not do storytelling in my family. And so many years I struggled with this and I even tried to learn things. I got books about screenwriting and things like that, how to tell a story, blah, blah, blah. And I never figured it out. And then I started going to this... It was a networking group for older professionals. And one of the things that they had in this networking group as a set of workshops about how to get a job basically, but one of them was how to tell your story, how to tell the stories of your accomplishments when you're in a job interview.And they gave a little simple framework and suddenly everything became clear to me. So the simple framework was there's a problem, you solved it, and there was some kind of results, which seems that's pretty obvious in retrospect. I did not have that structure in my mind, and I've taken that structure and I've gone a long way with it because it's not just that there's a problem, but there's a problem that has a personal impact on someone. Like I mentioned, it's not that sales are declining or you're not hitting quota. It's that if I don't solve this, I'm going to get fired or a bunch of people are going to get laid off. What's interesting to me is that what I was really good at was helping people when they were telling these stories about what they did for the job interview type things, which of course it's a similar structure for if you're telling a customer success story to find out, okay, let's dig down the what really happens if you don't solve this.So if you're missing quota every quarter, what happens? Eventually the company goes out of business. That's a big disaster. Now, it might not happen right away, but it's a big disaster. And so you want to dig down into that terribleness in the story because as I said, improving sales by 10% inherently is semi-interesting, but not that interesting. And so then what did you do to solve it? I did this and I failed and failed until I got your solution. So the solution has to be... That middle part has to be interesting and engaging. It has to be challenging and have obstacles and have things where you failed. My favorite example, well, it just is the one that always comes to mind, is the movie Die Hard. Do you know the movie Die Hard?

Holly Hester-Reilly:So embarrassingly enough, I don't know it very well. I've seen bits and pieces, but-

Nils Davis:Okay, so quick summary. So John McLean, he's a cop. He's flying to LA to meet his estranged wife and they're going to try to get back together. She has been kidnapped in the meantime by some bad guys in this high rise in LA. So he goes to meet her, finds out she's kidnapped, there's all these mercenary terrorists in this building. He has to fight his way up and down this building barefoot and all this stuff. He eventually overcomes all that, and the end is they get back together. Well, in the middle, of course, most of the movie is this fight up and down. So it's all full of obstacles. You think, oh, he's going to make it. Oh no, he is not going to. Oh, he is going to make it. Oh no, he is not going to make it. That's what makes it thrilling and gripping.And if you think about any good story that has that structure, it may not have people about to be killed, although I like thrillers. So a lot of times that's the stakes, right? But I think about any great story and it's going to have a structure kind of like that. There's some obstacles. I can't go through them. Oh, I have to figure this out. Maybe there's a guide that helps me get through, or something like that. Our customer success stories and our own success stories need to be the same way if you want them to be engaging. Like I talked about when I started in product management, I didn't know what I was doing. That's a big obstacle. I didn't know the impact. I tried these things. Some worked, some didn't. And so you want the end of the story needs to tie into the problem.So the problem is solved and instead of getting fired, I was promoted or I was recognized, or I was given credit for the transformation, whatever. So there needs to be some kind of a personal gain or transformation in addition to the business transformation. And that's in a customer success story. So you put these pieces together. That to me was, so I learned this storytelling structure. I started to really go to town on it. And that's a lot of what I talk about now. In fact, if you think about the fundamental framework or the activities that we do as product managers is we try to find those stories, the tragedy stories, and we need to understand all the things that went on, all the obstacles and challenges and failures that they had. And of course, for our prospects, it's a tragedy because they haven't had the transformation.Our product is the solution that they come to say, try to solve it, can't solve it. Then they find our solution and they can solve it. But that's not the end of the story. That's the end of the middle of the story. The end of the story is, and they got the promotion and they increased sales by 10% and so on and so forth. And so if you think about what we do as product managers, we go out and try to find those stories. That's market discovery, finding the tragedies, then we create a solution to those stories. Of course, that's a solution we eventually sell to them, but for us, that's the product or the technology that we build. And then we go to market with that and how do we go to market with that? A lot of it is through the stories, so it all ties together.So finding market problems, creating solutions, taking the solutions to market, that's what we do as product managers. And that's very similar to the structure of a good story. So I force those to be tied together. But I think there's a lot of synergy between those two concepts. And when I talk about being problem driven, or sometimes people say we shouldn't be called product managers, we should be called problem managers because we find problems and then solve them, which if it weren't a terrible name, that's a good idea. But then that brings you back to what is the fundamental use of a problem is to tell a story if you think in terms of marketing or go to market. So it all ties together for me.

Holly Hester-Reilly:That made me think too, the other thing that I often hear is that we should call ourselves risk managers.

Nils Davis:Another great thing to talk about, but it's only one part. It's like problem manager is also only one part, and we're not even problem managers. We're problem finders and then problem solvers and then problem fixers for our customers. But risk is a really important thing too. I don't talk as much about risk, but I do talk about risks in my podcast and in the book, because that's always a really great leverage is to put your initial investments on reducing risk because it's one of the ways to get out of the uncertainty problem.

Holly Hester-Reilly:I like to use risks to direct the discovery work that we do. But you're right, there's a lot to product management.

Nils Davis:So much.

Holly Hester-Reilly:So what is something that you feel like you went some portion of your career before you realized?

Nils Davis:I thought for a long time it was about the features. To be honest, it took a long time for me to get to the point of it's not just about the benefits of the features, but it's really even further back about problems. And that took me many years. I'm sad about that because it was like some opportunities missed, but in some ways I was intuitively on the right track, but I still was thinking about features. But I always was thinking about what the features did for the customer, using the customer as a touchstone or the load stone of what needed to be done, but I wasn't articulating it as effectively as I could have done. So that was a big thing. That's what the book was about. That's one of the big reasons I wrote the book was because I wanted to articulate that for other people after I figured it out.

Holly Hester-Reilly:That was one of the big secrets.

Nils Davis:I think lots of product managers still focus on features.

Holly Hester-Reilly:Absolutely. There's so many people around product that focus on features that if you are a products manager who focuses on problems, you spend a lot of time communicating why you're focused on the problem and trying to bring people's attention away from focusing on features.

Nils Davis:You can really differentiate yourself as a product manager in group of product managers if you talk about the problem.

Holly Hester-Reilly:Yeah.

Nils Davis:I saw this yesterday. Somebody gave a presentation and it would've been really easy for them to take a little part of the first part of their slide and say, here's a picture of the person whose problem we're solving, and here's the expectation of the problem and the pain it's causing them. And then everybody else would've stayed awake for the rest of the presentation instead of falling asleep. I don't think anybody fell asleep. But that's the thing about the story is that it has a lot of benefits. It keeps your audience engaged. It gets them emotionally attached to what you're talking about. It keeps them awake.

Holly Hester-Reilly:It's a super valuable skill.

Nils Davis:Lots of power, and it's not that hard. That's the thing. That was what was so amazing to me when I finally learned that structure was, oh, not only is it not that hard, here's a list of questions you can ask to get to all those things, and I have ways people can get that list from me, but the structure is really simple. You can use the same structure in your user stories. User stories have this word story in them. Most people don't do them as stories. Most people don't use user stories as stories, but they get way, way better if you use a story structure for user stories. They get much more motivating. You get better solutions from your developers because they understand what they're doing. If you think of Dan Pink and his book Drive talks about motivation 2.0, which is about mastery, autonomy, and purpose.So mastery is your developers. It's about being a skilled developer and learning skills and using them. Autonomy is about you give them a problem, they can decide what to do about that problem, they can decide the best solution to it. Obviously, they're going to talk to me about what the solution is, but I'm not going to tell them the solution. They're going to figure out how to solve it based on me presenting the problem. But the really important one there is purpose. Why are we solving it?

Holly Hester-Reilly:Yeah.

Nils Davis:Simon Sinek I guess said start with why, which I think that's a simplistic thing to say, but this idea of why are we doing this feature? How is it going to impact the customer?

Holly Hester-Reilly:It's amazing how when you talk about it, it seems so obvious, but so many tickets end up being written that don't do that.

Nils Davis:Exactly. It's very easy to do, but it's actually not easy to do if your product doesn't solve a real problem.

Holly Hester-Reilly:That's true.

Nils Davis:So that's the thing. You have to have that real problem there in order to write a good story because a good story is about solving a real problem. People always use that example when they're talking about user stories of let's write the user stories for logging in. That's not a good user story. Everybody knows how to log in. In fact, I can usually get that from a library. I don't need to write user stories about logging in. Now you could say, let's think about I want my users to easily be able to authenticate to my app so that they can do something. Well, not only does that suddenly not become a login story per se, it allows the developers to say, oh, I just read about this cool thing where we can have the person put their hand in a certain format, and that's always unique to every person and whatever.I don't know. I'm just making that up. It gives them the ability to create something that's actually innovative and to solve the problem of I need to make sure that this person is the person that they say they are, and then I can give them useful things. They don't have to log in. I don't care about logging in. That's a technical solution to a problem. It's funny how terrible a lot of product management examples are. That's yet another funny thing, Holly. I have many funny things.

Holly Hester-Reilly:On that note, where can people find you if they want to follow your funny things?

Nils Davis:So I misrepresented myself. I'm not that funny, but I do have a podcast and my podcast is called The Secrets of Product Management, and you can find that at secretsofpm.com and there's 121 episodes as of this moment as we record. And so I keep adding more and when I say we, it's me. I do it all. And then I also have a book, the Secret Product Manager Handbook, which you can find on Amazon, or you can go to secretpmhandbook.com and get a link to my book and to many other articles about product management. I've got stuff on all kinds of different topics. Go to market persuasion, storytelling, discovery, a lot of high level thinking about product and why we exist, what's the value of product management, what's the business value of it, which hardly anybody ever talks about, which shocks me, but I've been talking about it for 10 years.

Holly Hester-Reilly:Awesome. Definitely. Our listeners should check out the book, and if you want, you can go to the show notes to find the links.

Nils Davis:And I'm on LinkedIn and Twitter and all the places, and I'm easy to find. Nils Davis is pretty much me everywhere.

Holly Hester-Reilly:Awesome. That makes it pretty straightforward.

Nils Davis:Yeah.

Holly Hester-Reilly:Thanks so much, Nils. It was a real pleasure to talk to you today.

Nils Davis:Holly, I had a great time. Thank you so much for inviting me and I look forward to future conversations.

Holly Hester-Reilly:The Product Science Podcast is brought to you by H2R Product Science. We teach startup founders and product leaders how to use the product science method to discover the strongest product opportunities and lay the foundations for high growth products, teams, and businesses. Learn more at H2Rproductscience.com. Enjoying this episode? Don't forget to subscribe so you don't miss next week's episode. I also encourage you to visit us at productsciencepodcast.com to sign up for more information and resources from me and our guests. If you like the show, a rating and review would be greatly appreciated. Thank you.

‍