Full Transcript: Dan Olsen on the Product Love Podcast

If there is such a thing as a product celebrity, Dan Olsen is probably it. It was only fitting, then, that we interviewed him on the first episode of the Product Love Podcast. We are now happy to share a lightly edited transcript of that conversation between Dan and Eric Boduch, recorded earlier in 2018 in San Francisco. Whether you love audio or prefer reading, we hope you enjoy it!

You can stream the audio version here or subscribe on iTunes today:

Eric Boduch: Welcome! My name is Eric Boduch, and I am the host of Product Love. Twice a month, I’ll be joined by product people who share their love for the product craft. Today, I’m excited to be joined by Dan Olsen, author of The Lean Product Playbook. In Dan, I think you’ll find someone who is really passionate about building great products.

Dan, thanks for joining me today. I’m here with Dan Olsen, author, consultant, coach, advisor, pretty much everything you would need for a product team. Dan, can we start this off by talking to us about your background, for anyone who doesn’t know it?

Dan Olsen: Yeah, definitely. It’s a real pleasure, Eric, to be on your podcast.

I guess my story starts way back when I was 10, my parents got me a computer, so I started coding then and kind of saw the power of what computers can do. And I was an electrical engineering major, where I learned even more about that, and then my job in the navy– actually, the navy paid for my school, so I actually worked in the navy on submarine design, which I didn’t realize at the time, but it was just very, very technical product management because it was such complex work as far as the parts we were working on. It required a high degree of cross-functional collaboration and getting really clear on requirements, and you know, is this design going to meet the requirements or not? So that was a great job out of school. They also paid for a Master’s in Industrial Engineering that I earned in Virginia Tech, and that’s where I learned about lean manufacturing, which came to play later, when Lean Startup came out.

But after my time was up in the navy, I knew I wanted to go to business school, and I was lucky enough to get into Stanford Business School, so I moved out to Silicon Valley. And while I was at business school, that’s when I first learned about product management as a career. And once I learned about it, I knew that was exactly what I wanted to do. And because I’d never done it, I asked, what is the best place to learn product management? And at the time, everyone said Intuit is the best place to learn. So I was fortunate to get a job there and it definitely delivered on what people said. It was like a post-MBA in product management, UX design, marketing, software development. So I worked there for a while and became a product leader there. And after working there, I wanted to basically apply what I learned at startups. So, I was a product leader at a couple of startups.

Like a lot of people out here on Silicon Valley, I had the itch to do my own startup one day, and I did that. I’m the CEO and co-founder of a startup that was in the personalized news space, like a discovery engine that we launched at TechCrunch and won the People’s Choice Award there. And after that startup, and for a couple of years before I did it, before I had the idea and the inspiration struck me, basically, I’m a product management consultant and I’ve been doing that for nine years. And I basically help companies– I mean, it’s a mix of both early stage, where maybe they don’t have a Head of Product, and I will be their interim VP of product. So I did that for Box, back in 2007, which was a great experience, I’ve done it for other post-Series A and B startups. And then I also worked with later stage, larger companies, more advising, coaching, helping them with their product process, building team skills, helping them recruit, training, and doing workshops. So, that’s basically, in a nutshell, a quick summary of my product management career.

EB: That’s awesome. Let’s dig into a couple of areas there if you don’t mind. Intuit, a mecca for learning about product management, right? What made it so successful? I mean, our Head of Product at Pendo [Brian Crofts] has experience at Intuit. It’s a place that’s known for creating, growing the careers of product managers. What do they do, that was awesome?

DO: Yeah, I think, you know, it’s funny. A couple of talks recently have been focused a lot on culture and its impact on companies. And I think that’s part of it, it’s basically the culture is very customer-centric. I think that’s just the start. Everyone is very focused on the customers, it’s not about the technology. Obviously, we care about what the technology can do, but we’re always in search of customer needs, pain points, or benefits that we can address.

And that, frankly, I think comes from the founder, Scott Cook. So, Scott Cook had worked at Bain Consulting before, but he had also worked at Procter & Gamble. And if you’re familiar with Procter & Gamble, they’re basically, you know, trying to outsell their competitors on things like detergent and toothpaste. So they really thing really, really hard about, what makes our detergent better than the other detergent? What makes our toilet paper better than the other toilet papers? So, they really think about benefits and they really think about differentiation and value proposition. And also, they’re really good at market research, right? As a skill to achieve those goals. So, I think that their product development is driven by that kind of thinking and Scott Cook definitely brought that into it when he started it.

These days there are more software companies that are customer-centric, but certainly, when it started, it was by far the most customer-centric because it just wasn’t how other software companies thought at the time. And I also think, from the early days, he realized the importance of good user experience design, even though that probably wasn’t even a phrase back then. You know, when Quicken, which is their first product, came out, there were already over 45 other personal finance software packages on the market. But the founders, after analyzing them all, realized, “Gosh, none of these are easy enough to use for a normal human being.” And so, they had a hypothesis that said, “Hey, if we can deliver a personal finance product that is significantly easier to use, we think there’s an opportunity to become a leader in the market and succeed.” And so, they had the hypothesis at the time: checkbooks are very popular, what if we made the user interface look and act like a checkbook? Where you just fill in the date, you fill in the payee, you fill in the amount, right? And there won’t be a learning curve for people to learn how to use the software. So that was their hypothesis, they executed it, and you know, within a few months, they became the number one personal finance software package out there. So they joke about having 46th mover advantage. You know, they always talk about first mover advantage and strategy. So, they’ve always been customer-centric, they brought these kinds of leading market research principles, and the emphasis on UX design to the company.

And it’s interesting because these days, as product managers and product in general, people are realizing the importance of talking to users, and interviewing users, and doing research well, and yet, there are not that many great places to learn how to do research well. Case in point, at Intuit, we had a PhD on market research on our Quicken marketing team. And so, I learned directly from her how to do interviews well, the do’s and don’ts of user interviews, qualitative research as well as quantitative research. That was a very fortunate thing to have. But again, speaks to Intuit’s culture.

EB: Yeah, it sounds like it was a very interesting opportunity. It sounds like you chose wisely in picking Intuit as the place to have your post-doc in product.

From there, you mentioned other interesting companies, Box, right? As I believe their first VP of Product, or first Head of Product?

DO: well, interim consultant, yeah.

EB: Yeah. That had to be an interesting experience. They made a lot of tough choices and I think chose wisely, in most cases. Choices like, are we going to offer this for free? For how long? How much? Talk to me about that experience. That had to be both challenging and also thrilling.

DO: Yeah, it was.

I mean, when I was there I went to a few of their 21st birthday parties.

For those of you not familiar with their story: four friends from high school decided to drop out of college to pursue this startup in the storage and collaboration space. So, that’s when I was working with them, and it was super exciting, fast-paced. The time from when Aaron [Levie, co-founder of Box] would have an idea to when it would be designed and launched, would be days, maximum. And the reality is, at Box, Aaron is kind of their Head of Product. Kind of like Steve Jobs was at Apple.

So I certainly can’t take a bunch of credit for a lot of stuff they did. I was more an advisor and counselor to him, and I remember the one thing I did do is I ran their first user testing session, because, because they were in their 20’s, they didn’t have a lot of experience. They hadn’t done user tests. And I remember that being super eye-opening for them. Because whenever you do your first user test, you’re going to find bugs and things you didn’t even know about, right? Use cases you didn’t even realize. So it was certainly very eye-opening for them, which was great.

And on the topic of charging, I had– prior to working a Box, I worked at USendit, which is another SaaS collaboration company. And when I joined them, post-Series A they were basically a consumer-focused site, monetizing via ads, and in raising their series A, they and their board wanted to pivot; let’s move to SMB and let’s focus on kind of a direct monetization in this case. So, I was very fortunate to be able to design their freemium model, and all their paid tiers and which features went into which tiers there. And we had a lot of data, because they had millions of users, we had a lot of data usage, so we can basically dial it in. So that was a fun exercise. So yeah, I think you’re right, Box and another similar job of navigating another freemium model well where the general idea there is, you know, by having a free entry-level product, you can get people to come in, and kick the tires, and see how good your product is and how it meets their needs. But then, as people have more advanced needs, or the trial expires, you start monetizing it.

So, that’s one of the beauties of SaaS, working on both of those companies, is if you have a low churn rate, then you’re basically not fighting for a new business every month or every year, like in other businesses where you have to do that. So it just builds on itself. So, it can be a really wonderful business model, especially if you have good product-market fit and low churn.

EB: So, let’s jump next into a topic you presented on in the past, that being market opportunities. Talk to me about your thoughts on identifying market opportunities.

DO: Yeah, definitely. And I think, you know, market opportunities, the way I think about it is just you’re trying to find opportunities to create customer value, right?

Customers are getting a certain amount of value from the products they’re using today, and you’re trying to scan and find more ways to deliver more value. Hopefully, significantly more value. And so, there are a lot of tech companies out there that focus on the technology and the solutions. And there are numerous stories of companies that had some cool technology that they built and launched, and then people called it like, a technology looking for a problem, right?

So, what I found more successful when you’re going after market opportunities is to start with the customer, think about what are the customer needs and benefits and pain points that you think you could address. And then if you did address, would create a lot of customer value. I talk a lot in my talks and books about the idea of problem space versus solution space, where problem is more focused on what is the customer need, and solution is focused more on what’s the product that we’re actually going to build, what is the solution we’re going to build to meet that need?

And I think, again, too many teams just go barreling in a solution space, and you know, talking about designs or building things before they really understand the customer and what the problem is. And you know, if you do focus on customer needs and benefits, and I have a lot of advice on that on my talks, then basically, what comes up is: Great, how do we prioritize which one of these– all these different needs are going to create more customer value? And so, you kind of need a prioritization framework, a way of quantifying or assessing how much customer value can be created if you go after these different customer needs.

And when I was at Intuit, I developed a framework of importance versus satisfaction, that works really well for that. And the way that works is, for each of the customer needs you talk about, you just rate the importance of it, right? And you can think about this two ways. One is, imagine you had millions of users and you could do a formal survey and say, “Hey, how important is this on a scale of 1 to 10?” And different needs, for a given person, different needs about different importances, levels of importance. And across users, the same need with different levels of importance. And then, on the satisfaction front, you simply ask, how satisfied are you with how you’re getting that need met today? Again, you can view it as a survey going 1 to 10, or both of these, you can use as a thinking tool on your team where you just say: “hey, as a team, do we think this is low, medium, or high?” And you know, it’s just a hypothesis at that point.

So when you do that, basically, the idea is to focus on high-importance needs, not low-importance needs. Because life is too short and you’re not going to create a lot of customer value addressing low-importance needs. And when companies launch a product that fails, and it turns out that it’s because it addressed a low-importance needs, it’s because they didn’t realize that ahead of time, because they didn’t use these techniques that are covered in my book and the talks.

I focus on high-importance needs. Within high-importance needs, though, there are the ones that are pretty well-satisfied today, like high-importance, high satisfaction. That’s basic competitive market. So yes, it’s an important need but customers are pretty happy with how they’re getting that need met today. The example I always think of first here is like, Google internet search. Now, if I ask you, “How important is it to find the information you’re looking for online?” It’s usually pretty important. But if I asked you how satisfied are you with Google, you’d say, you’re pretty satisfied. So, it’s not like you walk around, going, “Gosh, I can’t find anything on Google,” right? And you hear people say you need to be 10x better. So, in that quadrant of high importance, high satisfaction, you definitely need to be 10x better.

The upper left quadrant, which has high importance and low satisfaction, that’s where the big opportunities lie, right? Because people are saying “this is really important, and I’m not that satisfied with how it’s met today.” And those [opportunities] will not persist forever because we work in competitive and innovative environments, where other people are also seeking these market opportunities and trying to pursue them. But if you do this analysis, you can find them, and you can address them.

The example I’d like to share for that quadrant is ride sharing. Especially in the Bay Area. Not necessarily in New York, the taxi system there is great, you can just walk out and get a taxi. But you know, in San Francisco, the taxi situation was not that great. So if I just went through the importance and satisfaction and asked 20 people: how important is it to get to your flight on time? How important is it to get to your job interview on time? How important is it to get to wherever you need to go to on time? It’s pretty important. And if conversely, I said, how satisfied were you at the last, say, five cab rides that you took? We’d probably get low satisfaction because the cabs didn’t show up, or they showed up late, or it was a hassle to pay the person, there are a lot of different dimensions. And so, we can ask it again at the high level, or we can start breaking it down and saying, “How satisfied were you with punctuality? With how clean the cab was? How safe it was? How polite the driver was?” All these different aspects. So you can imagine we would get some low scores on satisfaction there, basically. So, importance vs. satisfaction, again, even as a team, if you just use low, medium, high, it is a great way to filter the different opportunities you could go after to try to find the ones that are going to create the most value, which makes sense to pursue and explore further.

EB: That’s a good lead into talking about, you know, getting that first product out there with some people calling it MVP or maybe a most usable product, or sellable product. But let’s chat about how you think about minimum viable products.

DO: Sure.

The funny thing is you already mentioned two alternative acronyms, right? Usable and sellable.

I think the fact that you have so many variants of the acronyms, because people don’t like the MVP term, just highlights how contentious and misunderstood it is, right? And anytime you have a big movement, like lean startup, you’re going to have buzzwords and people are going to have a range of interpretations. But MVP is like the poster child for the one that people have big debates about. I’ve seen an article called: “A landing page is an MVP” and the person went on to explain why it was. And then somebody read that article and they did not like it and they totally disagreed. So, it made them go and write an article called, “A landing page is not an MVP” and they had a war in the comments about this, right? I think that’s where you see alternative acronyms, because people aren’t always clear on it. I understand kind of both sides that you typically see. The hardcore product people like, how can a landing page be an MVP? I can create an amazing landing page, and sell you snake oil, make all kinds of promises, then you click through and the product doesn’t exist, or it’s not good, or doesn’t meet your needs. So a landing page is not a product, MNP and MVP stands for product, so how can it be a product? It’s not an MVP. That’s one extreme view.

The other view is a looser view, which is, well, an MVP is anything that you can learn from. An MVP is all about learning. So anything I do create to generate learning is an MVP. And I appreciate that point of view too. What I recommend doing and what I cover in my book and talks, to get out of that black-and-white argument, is to go up one level and call them all MVP experiments or texts. And then, of course, the landing page people agree that it’s an experiment test, and by calling it an experiment test, the hardcore people are ok with it as well. So that’s kind of one thing that I focus on.

The reality is, there’s a wide range of MVPs that you can pursue, one of them will probably better meet your needs for what you’re trying to accomplish at any given point in time. And I actually, in my book, in my talks, I categorize them. So I think it’s important to categorize them between product, and what I call non-product or marketing MVP. So again, a landing page would be on the non-product MVPs, and things like a live product or a high-fidelity prototype would be in the product MVPs.

And I also like to differentiate between qualitative and quantitative, because some of them you’re getting qualitative information from, other ones, you’re getting quantitative from. So you end up with a 2×2 of product/marketing, qualitative/quantitative, and all the different MVPs are kind of categorized in there. But at the end of the day, an MVP is just a way to test your hypothesis and what you want to do is think about all the hypotheses your making across your product and figure out which one has the biggest risk or uncertainty. And then say, ok, what MVP can we come up with or use to help try to reduce that risk or uncertainty?

And one of the things I’m really a big fan and proponent of is that you really, really can test a lot before you build anything or write a single line of code. And a lot of kind of builder-centric organizations, they just so quickly go to solutions space and code something to try to test the hypothesis. Even if they agree with testing hypothesis, they go to code or building, when the reality is, you know, with prototyping tools you can really move much faster and iterate much more quickly, especially since the tools have become so good these days. So, in the book, I share a few different examples of that, and in my talks as well. Hopefully, that clarifies MVP a bit for folks, and then if you’re pursuing MVP and you’re always doing it by building something, then I would recommend that you investigate other alternatives and investigate prototyping tools because it’s so easy to just get a clickable prototype in front of someone with doing zero coding, and all of a sudden, you realize, “Hey, we’ve got these three things right, we’ve got these three things wrong, and guess what? We didn’t waste any time coding those three things that we got wrong.” So it’s a way to move faster and validate things before you invest in building.

EB: I think that’s great. If you can get data and experimental data faster and use that to inform your product direction, that has to be awesome. Lets you make better use of scarce engineering resources, right?

DO: Yes, exactly! Exactly.

EB: So, one thing I really liked that you talk about in a lot of your talks is this vertical slice, right? When you’re thinking about minimum viable product, or having features that delight on with the competitive features you need to compete. Talk to me a little bit about your approach there, why that’s important.

DO: Definitely, yeah. In my talks and books, I try to point out common mistakes that product teams make. When it comes to MVP, there is two common mistakes. One is, the whole goal of MVP is to prevent you from overscoping your product before you realize whether you’re heading in the right direction or not. Despite that, people still over cope their MVP, it’s super easy to say, “Well, someone might need that, let’s put that in the MVP, let’s put that in the MVP,” right? So it’s a slippery slope.

The second biggest mistake I see people make is what you’re referring to, from the vertical slice, is they misuse MVP as a way to launch something that there’s no way you can really succeed. So, they know that we can’t build all the functionality, so that’s good. But they use MVP as an excuse to not worry about quality. Oh yeah, it has a bunch of bugs, but it’s just an MVP. Or usability or UX design. “Yeah, we know the UI is not that good, but we can fix that later, it’s just an MVP.” So they use MVP as an excuse.

A nice framework to kind of think about this was created by Aarron Walter of Mailchimp. So he was the head of UX design at Mailchimp. And I remember, to this day, the first time I used Mailchimp. You know, I had used a few other email campaign programs software before, applications before, and it was just like, head and shoulders, easier to use, intuitive. So I’m not surprised that he wrote this book Designing for Emotion, and that he talked about this.

And I modified his framework slightly, but he has a pyramid that starts out with functional, and the next layer up is reliable, the next layer up is usable, and the next layer up is delightful. And the idea, is actually a very powerful framework to just assess, “Hey, where are we with our product?” I use it a lot with my clients to say, “Hey, where do you think we’re doing well, where do you think we had the biggest gaps?” And it’s funny, one of my clients, they got this idea. As you know, from the graphic, there are two [pyramids] side-by-side, and it shows how you slice the pyramid for MVP. They didn’t want to write out all four words in the second pyramid, so they just wrote it DURF, for Delight, Usability, Reliability, Functionality, and so we coined it the DURF model, which is a lot shorter name.

So, the DURF pyramid is a great way to say, “Ok, how are we doing with our product?” Or, if you’re trying to do an MVP, you know, what are we trying to accomplish? And so, I have this diagram where I say, you don’t want to do an MVP this way, all they do is they bite off a slice of the functionality layer of the pyramid. The good thing is, they only bit off a slice, they didn’t build all the functionality. But again, they used MVP as an excuse to ignore usability, you know, reliability, and delight. Instead, as you said, you want to do a vertical slice, so it’s true that you only want to build a subset of functionality. But for the subset of functionality that you do create for your MVP, you want it to be reliable enough. You know, it’s not going to be perfect. I’m not saying it should be bug-free and have an amazing UI, but it should be reliable enough, usable enough, delightful enough, so that people can get a sense of your product.

Because if you go and test the former kind of MVPs that only have– they completely ignore the reliability and usability, they never test well. They don’t test well, because it doesn’t matter if you have some amazing functionalities if people can’t find it or figure out how to use it, or doesn’t work the right way, you’re not going to get credit as far as creating customer value goes. And then you know, teams that do that, they go, “Geez, this test is so poor, see, this MVP approach was wrong, let’s go back to waterfall and the way we used to do things,” right? So, people misuse that, and then they misuse the results that they get as an excuse to abandon those kinds of approaches.

EB: So DURF it is, right?

DO: DURF!

EB: So, talk to me about why PMs should approach it that way, both from a DURF perspective, and that just rolls right off the tongue. But also for your approach identifying market opportunities.

DO: Yeah, sure. Well, basically, you know, the number one reason is, you’ll get to a better solution much more quickly, right? Again, I’ve worked with a lot of different organizations in my nine years of consulting to date, and it’s like a bell curve as far as how natural it is for people to adopt these new approaches and philosophies. But I see some people still holding on to the idea of, “Hey, we’re going to write the perfect PRD, we’re going to write the perfect spec, we’re going to get everything right.” You know? And the bottom line is just there’s just no way you’re going to get your initial version 100% right. It’s just folly to even try.

And the metaphor that I think of is like a bull’s eye, like an art street bull’s eye. Like, they keep thinking that, hey, you know, if we just keep spending more and more time, we’re going to get closer and closer to that bull’s eye. It’s just like it’s the wrong mental model, you know?

There’s actually a fair number of product teams that quote Donald Rumsfeld. In his talk, Donald said there are known knowns, there are known unknowns, and there are unknown unknowns. That is to say, there are things we know we know, there are things we know we don’t know, but there are things we don’t yet know that we don’t know, right? And that’s the bottom line, that makes the whole bull’s eye analogy just go away. There’s no way you don’t know what you don’t know. So you can spend way too much time prematurely optimizing things. Now look, I think you need to still be vigorous to a certain extent. You obviously want to move fast and be rigorous enough, and not just throw spaghetti against the wall. But the bottom line is, you don’t know what you don’t know yet.

And so, what you want to do is get in front of customers with a high-enough-fidelity prototype as soon as you can. And that prototype will basically, you know, embody all the hypotheses that you’re making. And what it reminds me of is, since I used to work on submarines, when a submarine fires a torpedo, they don’t need to get the direction exactly right, to like, the second decimal point. The way it works is you kind of shoot it in the general direction of the target, and the torpedo turns on its homing, and it kind of fine tunes its course. That’s how I view iterating with customer research. You want to get a prototype and get out there and talk to customers in the general area that you’re trying to pursue. And then if you do a good job conducting the interviews, and you learn, and you iterate, they will guide you in to where you’re going to create the most product-market fit, basically, right? So, don’t obsess too much about premature optimization before you get in front of customers. That’s kind of the main lesson.

Going back to why it’s valuable is, as you said, those engineering resources are very valuable. They tend to be the scarcest resource, and it just goes back to lean principles of like, let’s not waste their time. Let’s not have them building stuff that we don’t have a high degree of confidence it’s going to create customer value. Instead, let’s go mitigate the biggest risk and uncertainty, to make sure that– to a certain degree, you’re never going to be perfectly sure, but that hey, before we go and ask them to build this– because conversely, if they build the wrong thing, now you’re starting to incur tech debt. Right? And if, you know, three months later you’re like, “Oh, we realize we completely have gone about this the wrong way, it should work this way.” It’s like, well, we built the database this way, we built the object model this way, with already existing APIs, can we just reuse of those? It’s human nature to not want to throw away the work, and the reality is, you will start building in technical coupling constraints from day one. So it’s just better to validate without coding as much as you can before you start building.

EB: Those are great lessons. I mean, you use some awesome examples. Is this what drove you to write The Lean Product Playbook?

DO: Yeah. I’m really passionate about sharing best practices on how to build great products, you know? When I became a product manager I wanted to learn how to do it really well, and I was fortunate to work at Intuit, which taught me a lot of great things. There just weren’t a lot of resources out there, to be honest. I joke with my business classmates, “Hey, remember that PM class we took at Stanford?” Because there wasn’t one. It’s not like there’s a lot of PM classes you can take and things like that. And back then, not even that many books and resources, right?

So, I think it’s great to show our best practices, and have a dialogue, and just elevate how everyone is doing this. I basically got into speaking, someone asked me to give a talk in 2007, I really enjoyed it. So I really like talking with groups of people that are building products, whether it’s public settings or private, within a company. In 2007, I would get questions, “What about this? What about this? How do you use this with this? What about this?” So I would just add more content and add more and more slides and hear more and more questions. You know, between consulting, and speaking, and working my own products, to develop all these kinds of frameworks and best practices, and basically, the book gave me the opportunity to refine it and extend that even more.

For example, the product market fit pyramid, which is the key framework in the book, there were earlier, kind of rough prototype versions of that framework, but they weren’t yet in that form. So it was really nice to be able to sit down and write, and extend certain things, and create new frameworks. Someone jokingly said — or half-jokingly said — product management is all about frameworks. Thinking how to think about things. And then I joke, yeah, you just need a framework to figure out which framework to use in which situation. But they are powerful mental models.

My book has over 50 figures and tables in it. Like the DURF pyramid, or the iceberg for UX design. These metaphors that really let people quickly get up to speed on whatever topic it is and keep it in their mind. So basically, I just like sharing best practices. That’s also why four years ago I started a monthly speakers series meetup here in the Bay Area, called Lean Product, where I also bring in top speakers, because I think we can’t have enough good resources to help people. If you think about it, it’s still also a big spread, you know? There are all these best practices in books and talks, but then you go out there and there’s so many companies that are still not doing it that way. So there’s still a big gap to be closed in my mind.

EB: Yeah, absolutely. I mean, part of this podcast is trying to close that resource gap a little bit, right? The books you’ve written, the slide shows you have online are awesome, there’s lots of great resources people can leverage. And then they need the skills, right? So, what do you think are the big, important skills for PMs to be successful?

DO: Yeah, I think it’s a great question.

I think about this a lot, and partly, because when I was in Intuit, I interviewed tons of PM candidates, and for my clients, I’ve interviewed lots of PM candidates. So I interviewed a lot of PMs and reflected on what skills they need to succeed. So, some obvious ones are like, they need to be customer-centric, right? The PM needs to be the most customer-centric person in the building and be the champion of the customers, that kind of goes without saying.

The other thing that’s pretty obvious is that you need to have good communication skills. You are in a central position, interacting with other functions, kind of like the UN translator. When the devs say this and you need to explain it to the business stakeholders, you have to translate that. So, you need to be able to empathize with devs, designers, stakeholders, put yourself in their shoes. I think good PMs are able to get out of their own shoes and truly empathize with other people.

But beyond that, there are things that I think are the less obvious, the things I think are the most important. One is what I’ve coined dynamic range and let me explain that. This basically has to do with forest versus the trees. Some people are really, really good at minute details. Other people are really good at the 30,000th view, or the big picture, of what’s going on. And so, dynamic range is thinking about where are you most comfortable and strongest along that dimension, right? Some people are limited to the top, high-level things, some people are limited to the details. I think good PMs are able to span a wide range and connect the big picture with the details. They can listen to their GM, their CEO, the executive team, as to the why — here is what we’re trying to accomplish as a company, as a business unit. And then they can turn around and translate that down into, what does that mean for this particular feature team? What does that mean for this particular PM? For this particular engineer? So that’s what I call dynamic range. I was fortunate, at Intuit, to study Myers-Briggs. For those of you that are familiar with it or are interested, there is one particular dimension to Myers-Briggs, intuiting versus sensing, that this ties into.

And the other thing is, it helps connect the details of what people are doing. There’s no way the CEO can be there in all those meetings, right? And so, if team members understand a why — why we’re doing what we’re doing and what we’re trying to accomplish — then they can independently make decisions and you have a much better alignment. So, I think I am especially sensitive to this because I was fortunate to work in my career at two organizations that were good at this, what’s called shared vision. Like, everybody understanding what’s the overall mission, the high-level thing we’re trying to accomplish. And then what’s called line of sight, which is like, how do my actions or what I need to do to contribute to that? So, where I worked, designing submarines in the navy and at Intuit, were both really good at that. That’s one.

The second really critical skill is prioritization, right? There are so many ideas coming at you. You have ideas, your devs have ideas, executives have ideas, customers have ideas, competitors have ideas, right? So there’s way more ideas than we can possibly execute against. And some are obviously better than others. So you have to prioritize because you have limited resources. So I think first and foremost, being able to make calls, right? Some people just get kind of frozen, like deer frozen in headlight, when they’ve got a list of 30 things and they have to prioritize it, they just can’t make those tough calls. So, step one is being able to make those calls. But the advanced version of that is actually being able to explain the rationale behind why you prioritized the way you did.

It’s not enough just to say, “Yeah, I put them in high, medium, low order.” By the way, I like to use the term “rigorous prioritization.” Early in my career, I saw MRD’s and PRD’s that would have like, 10 high features, 15 medium features, and 20 low features. And as a product team, you’re like, “Ok, there’s 10 highs. Which one should we do first?” You’re kind of punting on the question.

I’m a big fan of rank order prioritization. It’s fine to do high, medium, low, but within the highs, rank order them from one to ten, so we know exactly which one should be done first. We could always change it later, it’s not locked in stone, but that’s what I mean by rigorous prioritization. But again, what’s most important is, you can explain to somebody, “Here is why I made this one number three and why I made this one number two.” And I think that you basically need to have the rationale and mental models to be able to explain it to people.

And then the final point is, again, it’s important to be rigorous, but you also have to be flexible. At any point in time, I like to have the rank order priorities, but then, as we get new information, we need to be able to change it, right? We’re going to add something in. “Oh Jesus, this just came in from my competitor or something, and we need to make that number three now.” So you can’t be locked in stone and say, “No, no, we made a list of the top 10, you know, you can’t change it.” So you always want to have that clear rank order list but be flexible and mindful when you get new information that it should change. So again, dynamic range and prioritization, I think the two are the most critical skills for product managers.

EB: I noticed you didn’t really mention any technical skills.

DO: No.

EB: Do you think product managers need to [have these skills], especially in software? I mean, we’re both computer engineers, right? Is it necessary?

DO: Yeah, that’s the funny thing, there’s the debate out there, right? And there are definitely companies out there of that School of Thought. “If you’re not a Computer Science or Electrical Engineering major, we don’t even want to talk to you,” and you won’t even get the job interview. I think that there are way too many companies doing that in situations where it doesn’t really apply or add a lot of value. Now, I do think, obviously, if you’re working on a very technical product, that’s different. Or if you’re marketing to developers, or building products for developers, perhaps that will help you have more customer empathy.

I’m personally not of the school that all product managers should be able to code. What I will say, though, my general advice for product managers is: you live in a value creation chain, right? Think about making products as a factory. Upstream of us [PMs] are execs and customers, marketing, and things like that. We take all the input from them and we figure out what the product roadmap and definition should be. And then downstream of us, we have UX designers, visual designers, developers, QA.

I’m always a big fan of getting really knowledgeable about the adjacent people that you work with. So, UX design would be great to learn. And development. Not necessarily because you’re going to be the world’s best Python coder. I think what’s valuable is to have enough technical knowledge to accomplish a few things. One is that you can have credibility with the tech team. If you go in there and they say, “Oh, that’s a JavaScript there,” and you have no idea what they’re talking about, then you’re not going to be viewed as credible or knowledgeable. And that’s kind of not what you want.

Because nobody reports to us as product managers. It’s the whole influencing without authority. A key part of how you influence is by being perceived as knowledgeable. And they don’t expect you to know more about JavaScript than they do but knowing the difference between client-side things and server-side things, and this is a database change versus this is a UI change, is super helpful.

I actually recommend people start just by learning HTML. I mean, HTML is not hardcore coding, it’s very lightweight. But it will give you a big appreciation. Another thing is just get your own website up and running. Even if it’s WordPress. Just get some lightweight website, because it will make you appreciate things like HTML and CSS. I don’t think you need to go super deep, like going and investing, you don’t need a degree. Coding boot camp, maybe, if you’re really passionate about it. I would just say, pick up some lightweight stuff.

One of the other areas is actually SQL, or database languages. And this ties into another skill that people are increasingly wanting PMs to have, which is analytics or statistics. Or as machine learning and AI become more and more popular, people want PMs to ideally have that expertise. And so, SQL is a very specific language, you don’t have to learn all these other languages. You just learn SQL, and then all of a sudden, you can get data that you need out of databases, which is very helpful as a product manager, to look at analytics and things like that.

So anyway, back to what you said, I don’t think you absolutely need it. There are certain, obviously, technical jobs, technical products, where you do. But I think far too many companies over-index it. And I think that they’re just being lazy and using it as a shorthand. It’s like: “if you’re a CS major, then of course, we’re going to be able to work well with developers.” And there’s one other aspect too, which is that you want to avoid situations where you go make a request to developers, and what you’re asking for is going to take, like, a year. So being somewhat technical enough to know that the scope of what I’m asking for, I think it’s about a week, or it’s about a month, or it’s about six months. So that you’re not making these asks that are kind of out of line.

And again, these companies presume that if you have a CS degree, you’re going to be an expert in all that stuff, which also isn’t true. You can have a CS degree and not work well developers. Sometimes you get ex-developers who become PMs and they still try to be developers until the developers have to code stuff, that obviously doesn’t work well. So, I think what matters the most is the thing to talk about: customer empathy, communication skills, prioritization, and being the expert on the customer and the market in your company. When you get to that point, then that’s the knowledge, that’s the unique value add you bring to the team, to kind of help contribute to the overall customer value that’s being created.

EB: And I think you touched on a trend I see too, which is picking up adjacent skills, whether it’s UX design, or UX research, or like you talked about, analytics. Having PMs that can both capture data, understand data, and know how to act on data, it’s a big trend I’ve seen. What other trends do you see in product management?

DO: I mentioned how in business school I learned about product management, it’s what I wanted to do, and so I got into product management at Intuit. Very soon, I realized, oh my gosh, there’s this whole field of UX design and it’s really, really important. Because I can write these great product definitions in words, and then we can fall short on UX design. Conversely, there’s opportunities to create great UX’s here.

So, I went out of my way to go and learn it. I took classes in it, I read books on it, I partnered with talented designers to suck as much as I could out of their brain to learn about it. Not because I wanted to become the world’s best designer, but for a couple of reasons. One, so that I could evaluate designs better. When a designer would tell me what’s the design, I could critique it. And I think that’s kind of the levels you go through. One is kind of ignorance; you can’t really evaluate too well. And then second is, I can critique it. I can’t create a design myself, but I can critique it and point out things that I don’t think are going to work well. And then eventually, mastery, you say, “I can create some stuff myself.” And again, maybe it’s lightweight, and you’re never going to be as good as the designer.

But I think, in general, building skills that the adjacent functions have, whether it’s UX design, marketing, UX research, or dev, or analytics, just helps you have a better dialogue and conversation with them, more empathy for how they think about things, and more understanding of what’s possible and how much it’s going to take. Out of all of those, I think UX design is the one that PMs should most readily embrace. I work with a lot of startups, and in my book and talks I talk about the design gap that exists. What that means is, you have engineers and you have PMs, but there’s really no designer. And a lot of startups have this, a lot of big company teams have this. They may have designers, but your particular team is understaffed, or doesn’t get the resources.

And the reality is, when it comes to design, there’s two very different types of designers. There’s the interaction designers, who focus on, information architecture and interaction design. They might be doing more wireframing. And then visual designers who focus more on fonts, colors, images, things like that. And so, many places have a design gap. Good PMs fill the voids that are around them, whether it’s customer support, or QA, or marketing. Again, we’re in this middle position, and they’re often unstaffed, or understaffed, or under-skilled functions adjacent to us. And to kind of complete the value chain, good PMs will fill in as they can, as needed in there.

So definitely, in startups, it’s very common that if the PM isn’t creating wireframes or design, nobody in the company is. And so, you go from having PRDs or Jira tickets, Wiki pages and words that the poor developers have got to figure out what the heck to code, what UI to code from that. It’s not their fault, right? No one is providing the UI guidance. So, if you just suddenly add to that equation of PM who can create basic wireframes in say, balsamiq, you’ve gone a long way towards working through some of the UX design issues that are going to be there, right? It may not end up looking super pretty, with the best colors and the best fonts, but at least by working through wireframes, you work through usability issues, navigation issues, and things like that.

When I interview PMs for startups, I will ask: “do you wireframe or not?” And if they say no, it’s a pretty strong negative mark against them, for startups. One, because they haven’t done it on their own, but two, also because it shows to me a lack of intellectual curiosity. Again, about learning about adjacent fields. Maybe if you say, “Yeah, I played around with Balsamiq, I’m not the best at it.” That’s much better than saying, “No, I never tried.” I

And the other one is UX research. Again, it’s really exciting to see in the last couple of years the importance of talking to users going up, but then, more and more people, they want to talk to users, but they feel like they’re intimated, or they don’t know how. So there’s two extremes: one is people being overconfident saying: “Yeah, I can talk to users,” and not doing well because they don’t know best practices, and do’s and don’ts. The other extreme is, “Oh no, we need a professional in UX research, I can’t possibly interview a user.” But what I would say is it’s not rocket science, it’s like riding a bicycle. You just get better at it the more you do it, and it’s honestly one of the most learnable skills.

You know, UX design you’ve got to learn some new tool, like Balsamiq, or Sketch, there’s a lot going on that you have to learn. UX research is probably the easiest thing to get better at quickly, just by doing it and by taking notes, and reflecting on it after the fact. Then a lot of it comes down to just how you ask the questions. That literally comes down to not leading the witness, so to speak. Being objective and not trying to guide them towards the answers that you want and asking open-ended versus closed-ended questions. And I talk about that on my talks and books, but I would just encourage people, if you haven’t done user research, or you’re feeling intimidated by it, and you want to get better, there are definitely easier ways to do that.

EB: Just jump in and get started, right? Just like riding a bike.

DO: Yeah.

EB: So, we covered a lot today. What specific advice would you give to young and aspiring PMs out there?

DO: In addition to what we’ve covered today, just reflecting on product management as a career, it’s largely experiential learning, I think. There aren’t that many classes out there. Even then, you kind of need to live through it. It’s kind of on-the-job training. So you basically learn a lot from others.

At your company, what that means is that your manager can really teach you a lot or not, basically. I was very fortunate at Intuit, I was kind of walked into a product machine, and so I learned from everybody, but I especially learned from my managers and peers. I would say, and it’s kind of harsh, but if you’re not getting the kind of PM learning and guidance that you need or want from your manager, perhaps seek out other sources, other mentors, even if they’re not your direct manager. And if those don’t exist, and you’re really like, “Man, I really want to get my PM skills improved,” maybe you need to go to a different team, with a different manager.

You could also learn from good designers that you work with and good developers that you work with. So learning from other people is key. There are never tons of books on PM, but there are more books than there used to be. Meetups are a great way to learn from other people too, you know. There are more and more product events, conferences, meetups, videos online. At my meetup, each month we bring in top speakers, and we always record it for people that can’t go to that. And then blog posts and podcasts like this one.

When I interview PMs, one of the questions I ask is I’ll be like, “How did you learn PM?” And some people have a very weak answer, like, “I don’t know, I just started doing it.” And other people are like, “Well, I learned from this manager, I read these books, I went to these events, I watched these videos and I read these blogs.” It just shows me that they’ve got the intellectual curiosity, they’re trying to improve their craft. So those are some of the ways you can go about trying to grow your PM skills and career.

EB: Awesome. The important question I always ask people. And I ask this on interviews too, it’s always interesting to hear what people have to say, and which direction they take this. But three words to describe yourself.

DO: That’s a funny question. It’s tough, but I do like the succinctness of it. So, I basically came out with promoting PM excellence, because if you kind of see the common thread through all the stuff that I’ve talked about today, that’s kind of what I enjoy doing, is promoting PM excellence.

EB: I think those are great three words. Anything else you’d like listeners to know about?

DO: It’s been a pleasure talking with you guys.

Since it’s a podcast, just giving people some pointers online. As far as my book, The Lean Product Playbook, if some of the ideas I’ve discussed sound interesting and you want to learn more, just want to let people know that in addition to hardcover it’s also e-book and audio book. I love books, these days, the only way I’m able to consume as much is through audio books. In addition to the English version, there’s Chinese and Turkish versions. And if people prefer those languages, and Polish and Thai coming out soon as well.

The meetup I mentioned a couple of times. As I said, I do run a monthly speaker series in Mountain View, it’s actually at the Intuit headquarters in Mountain View, it’s called The Lean Product and Lean UX Meetup. I started it four years ago to share best practices. We’ve grown to over 6,000 people now. Just had Marty Cagan there, Thursday night, which was great. It’s free to join, and if you want to learn more, you can go to meetup.com/lean-product, and learn more.

And on the consulting front, if anyone is interested in learning more about coaching or training, you can check out my website, dan-olsen.com, you can contact me there. And if any of you listeners out there have read the book and have any feedback on it, please reach out to me, it’s always great to hear from readers.

And as far as other resources, I give a lot of talks, I make it a point to post the videos and slides on my website, again, dan-olsen.com, if you want to check those out. A lot of them — having a slide to go along with the audio helps a lot as far as explaining the framework. And if you just go to dan-olsen.com, it also has pointers to the meetup, book, and other info. So yeah, those are some of the URLs I share with folks, and it’s been a real pleasure talking to you about product management today, Eric.

EB: Awesome, this has been great, I greatly enjoyed it. Thanks again, Dan.

DO: Thank you.