There is no single, well-defined path to becoming a product manager. There are more questions than answers when it comes to figuring out which skills are necessary, what books or blog posts to read, or which courses to take.
Dan Olsen, the author of “The Lean Product Playbook,” former product leader at Intuit, Friendster, Box, and the US Navy (he worked on submarine design) shares with us some insights on what it means to grow as a product manager.
The Show
You can also listen to the audio directly:
Or listen via Spotify’s player:
You can find Dan on the following sites:
Make sure to sign up for Dan’s upcoming Lean Product Management online workshop on April 20, 2021.
The podcast was produced by Den Delimarsky. Music by Wataboi from Pixabay.
Listen
You can also use the official podcast RSS feed, and add it to any podcast application or service.
Feedback
If you haven’t already, make sure to subscribe to the show and leave a review or a rating, wherever you are getting your podcasts. I really appreciate your feedback and am working to make this podcast more useful for you, the listener, with every episode. Ratings and feedback make it so others can easily discover and enjoy the insights you listen to here!
Transcript
Den: Hello folks, welcome to our weekly episode of The Work Item podcast. I’m really, really excited about our guest today, who is Dan Olsen, who is a product leader, he has been writing this book, it’s called The Lean Product Playbook. Big fan. Welcome, Dan!
Dan: Thanks Den, it’s great to be here.
Den: So, Dan, why don’t you tell us more about what you do, because you have such a broad spectrum of activities. I’d love to learn more about you.
Den: Yeah, thanks. Yeah I… These days I do have a broad spectrum of items. First and foremost, I largely am a product management trainer, so I teach workshops to product teams, both private companies and public. And sometimes it’s just product people, sometimes it’s cross functional teams. So that’s what I spend a lot of time doing. About me on that, I speak at conferences and also at company events. Increasingly, you see companies having like internal product management days, like once a once a year or once a quarter. So I speak at lot of those. I spend some time advising CEOs and product leaders on product strategy, on building their orgs, on training their people on applying the concepts from my book. And then I also organized for seven years… This month is actually seventh year anniversary of the Lean Product Meetup that I run. It basically, what used to be in Silicon Valley, now it’s online, so it’s actually been cool. One of the advantages of taking online, as we got people from around the world. We just crossed 10,000 members, so it’s one of the world’s largest product communities, and each month I host a speaker, and then once a year I also help plan an event called the Product Leader Summit with some friends as well. So that’s kind of most of the stuff that I do. I think most of what I got.
Den: That’s quite a bit. How did it change with the coronavirus pandemic? Because you mentioned that the meetup shifted to online.
Dan: Yeah, well and the workshops - everybody wants you to fly to them when you’re doing private workshops, so you know, the last trip I took was to Dubai to train Careem, which got acquired by Uber for three million… Three billion dollars. So you know, that was the last trip that I did. So before the coronavirus, every two weeks I was flying around to different places. Actually was working with another client. They had like six different offices around the world. So I was flying around. You know, mainly the States, but also Ireland, to train their people. So all that is now going online. So as a result, I am not traveling, so I don’t have any jet lag, so that’s the advantage. It’s actually a good thing. I didn’t realize I was kind of traveling a little too much, and it kind of wears you out, so it’s kind of nice to not have travel. I was a big Zoom fan before the coronavirus. I’ve become an even bigger Zoom fan now, and so it’s been good, and I’ve adapted the workshops. You know, I do think you know when there’s challenges like that and you can’t do things in person, there are also opportunities. So I’ve managed to adapt the workshops to make… Have all the content be online in Google Docs, you know, and the interactive exercises and make them even… Interactive is not, you know, it’s always nice to get together in person, but we try to replicate as much as we can. And then on the meetup. Yeah, I mean, I was sitting there and I was like, well I guess I have to take it online, and then as soon as we published our first event a year ago, it was a year ago that we took it online. All these people texting me and messaged me, and said hey, this is great. I’ve always wanted to go to your meetup but I couldn’t because I don’t live in the Bay Area, and so it’s been nice. It’s been really good and I think that we’ll hopefully keep that going, you know, ‘cause just have a larger footprint and have more people come, so. The other cool thing is we’re not constrained. Like our room, we used to hold it at Intuit, the headquarters, where I started my product management career, and the room can only hold 180 people. Well, in December we had over 500 people for our event, so it’s like the physical constraints are gone, right? So, and again, people can come in from all over the world and ask questions, so. It’s been good.
Den: You ever feel like you’re gonna go back to the previous mode of operation, or is this going to be a hybrid?
Dan: I hope so, no, I hope so. I mean, I hope so, and I think I think there will be a desire. You know, there’s a little bit of overhead that we didn’t want. You know, I played around with streaming the event before - just didn’t quite pick up. I think everybody’s used to streaming into events now, so I think when we do go back, hopefully we’ll go back, we’ll keep the live streaming going, and have it be a hybrid event where, you know, if you’re in town, if you’re here, you can go to it live, and if you’re not, we’ll still keep it virtual. So I think it’s worth doing that, given the success we’ve seen.
Den: Right - there’s certain benefit of just… Human connection. Seeing somebody in person.
Dan: No, you know, it’s funny Den, it’s like a big part of that meetup, obviously people come to see the speaker, and the kind of speakers we got are the kind of speakers that you don’t… You get at conferences, they like, you know - top authors and things like that. They wouldn’t go to a meetup normally, but then a big part of it is the networking. Before the speaker we have like 30 minutes. We have dinner, and people hang out, and then afterwards people hang out forever. I’ve tried to replicate that at our meetups online with Zoom breakout rooms, but it’s amazing the number of people that suddenly leave and don’t stick around for the breakout rooms when it’s digital versus, you know, versus in life. In real life. So yeah, I agree that would be nice to get. That’s the main component that I’m… That people miss, and that I miss, but it’s been good. It’s been good.
Den: That’s great. I am very hopeful about 2021 and beyond, so…
Dan: Me too.
Den: I want to get into your career, because you are a product leader and again, I’ve read your book many, many times, and you have a wealth of experience. What bootstraped it all. Where did you get started?
Dan: Yeah, well, thanks for reading the book so many times. I appreciate it. I honestly think that the very beginning of the story probably goes back to when my parents bought me a computer when I was in fifth grade. They bought me a computer, and so I was just very comfortable. You know back then I had an Atari. I’m older guys, so I had an Atari 2600 that I liked. You play some games on it, and then I got a computer and that was like, you know, the ultimate game machine, so you’re playing computer games, but you also naturally just learn to code back then, you know, and so I just learned to code. I’d code things, I’d play around with things that design fonts, I’d, you know, just trying to make a game, things like that. So I was just 0very comfortable with that. And then in college I was an Electrical Engineering major, and I was into computers, so I focused on digital systems and computers. So again, I got to, you know, learn how computers work and things like that. Then the job that I got after school, I was in the Navy and I got a job designing submarines, and so that job was a very technical job that dealt a lot with design and requirements and things like that, which is great. And then I, while doing that job, I got a master’s in industrial engineering at Virginia Tech which kind of widened my appetite for the business side of things. So Industrial Engineering is a great degree, it’s engineering, and so you’re learning about operations research and things like that, but you’re also taking business-related classes, like economics and things like that. So, it was… It was great as a kind of a steppingstone to go, you know, what I really want to get more involved on that side of the world. And then I got, after my time in the Navy was up, I kind of figured I wanted to go to Business School, and then I went to business school, and that’s when I was like, OK, I discovered product management as a career choice, and once I realized that it was available as a career choice, I liked that. Sounds like what I want to do, and that’s kind of what led me down the path of product management.
Den: It’s interesting that I hear that story a lot about engineers going into product management. Do you feel like product managers need to be technical to be successful?
Dan: They don’t, they don’t. It’s funny. I want to clarify. So, there’s like, you know, being an engineer, I’m an electrical engineer by training, my work in the Navy was actually a lot of mechanical engineering, and there’s chemical engineering, and biomedical engineering. So those kinds of engineering. In the software world we use engineering for software developers interchangeably. So there’s all these different engineering backgrounds. So the question I usually get is like, do you need to be able to code? Do you need to be like technical from a computer science standpoint? And I don’t think you do. I feel like a lot of companies… Some companies started that trend of like, hey, we’re only going to hire PMs that have a CS background or EE background, and I think it’s just kind of… It’s kind of a… It’s a blunt instrument, and I think the logic goes – well, we want the PMs to work well with engineers and we want them to be respected by the engineers, and so if they have a CS degree, that’s much more likely to happen. And you know, that’s not true. I mean, you could have a CS degree and still not be respected by engineers. You cannot have a CS degree and be respect. You know. Probably the odds are you’re going to be more respected by engineers, but I think it’s a little extreme to say you have to have it. You have to be able to code right or have a CS degree. I think that’s also extreme. I do think in certain technical disciplines if it’s… If your target audience is developers, if that’s who your customer is, you’re building developer tools, for example, then it’s probably a lot more relevant, but just kind-of a general rule, saying we only hire PM’s that are… That have a CS background, I think that’s a little too extreme. You know, there’s a lot of people, especially they got into PM earlier, you know, that would be the path to get in, and you know, for my path, my transition point was Business School, which was a more common transition point for a lot of people back then as well. So I think it helps, but you don’t need it, and I think what I would say, and I’ve thought about this a lot actually, because for those of you that are technical and got a CS degree, it’s like, OK, you learned how to code in Java. You know, you did it for ten classes, and I’m not going to minimize it, but you learned… You learned, you know, how to do a bubble sort. You learned about complexity theory, you learned about a lot of stuff, and learned how to do some stuff in Java, and then you went, you got your first CS job, and wanted to do Python and JavaScript, which you’ve never done before, right? And do a server architecture, which you’ve never done before, because you just wrote some acronym… I mean, and it’s gotten a lot better. Don’t get me wrong, obviously there’s certain degree programs that are actually building real working web apps and things like that, but academia tends to lag, right? And in the old days, you’re learning C. It’s like, hey, I’m learning how to program in C, and then you’re going to be a web developer. You’re not doing any C. So, you know, I think what’s valuable is just to understand - hey, what’s on the front end, what’s on the back end? How do these things interrelate? When I am requesting a feature or a change, what is that… What are the implications that impact the front, and the back end, the database? Like what’s required? And you just want to avoid asking for something that you think is small that’s really going to take six people weeks of effort. Avoid those kinds of mismatches, so you don’t have… You don’t lose credibility, you know, that’s what I think. And I think that if you are technical, it helps you, you know, problem solve better with developers if they’re like “Well to do that, it’s going to be really tough. It’s gonna take a lot of time,” and then you can hopefully be like “Well, what about this? What about this,” right? At the end of the day we’re not the ones coding it, but it can help you partner more effectively with them. But again, it’s not critical. I don’t think. I have seen plenty of PM’s… And the funny thing is, I’ll say ‘cause you started your question with engineering background. Some of the best PM’s I’ve had on my teams are mechanical engineers, actually. And I have a theory about that, coming from submarines. The other one - I also had rockstars that were architects. And I think that architects and mechanical engineers… What’s interesting is - you have to focus, and in engineering in general, you have to focus on what are the requirements, and you’ve got these rules like Mother Nature and science. Then constraints that you have to operate against, right? And so I think that they’re used to kind-of, maybe their brains have been trained in that kind of discipline of what are the requirements for the objectives? What are the constraints? What are the tradeoffs, you know, to come up with the optimal solution?
Den: So do you think that it can be harmful? One of the things that I’ve noticed myself, being a computer science graduate, and I consider myself technical, but what I’ve noticed is when you have a problem, your brain just kind of instantly jumps to that solution. I know how to implement this.
Dan: That’s right.
Den: I know exactly how it should work, when product managers should generally be thinking a little bit from a higher altitude. What do you think about that?
Dan: I agree, it can do that, right? And I’ve seen a comparable thing on the design side, is if you have a PM that came from design they might just create the mockups themselves. And it’s interesting because in the PM world, you know, one of the beautiful things about the meetup or any PM conferences is - PMs actually get together and they get to compare notes. PM can often be a very lonely job in the sense that you have no one to compare notes with, right? Because you are the sole PM and then of course you’re working with dev, and design, and QA, and other people, but you typically don’t work on a day-to-day basis very closely with other PMs, so it’s kind of like this “divide and conquer” thing so you don’t get to, you know, compare notes much and you… A lot of good PMs, they build up this mindset of like “I just gotta do it my… If I want to get it done, I gotta do it myself.” ‘cause I like to say - no one reports to us, right? I joke about the Spiderman motto, you know, with great power comes responsibility. The product managers’ motto is - with great responsibility comes no power. No one reports to us, right? And so you end up like, you know… And I also like to say good PMs fill gaps. If there are gaps on the team, like we don’t have a designer, who’s going to do the wireframes? The PM will jump in and do it, right? So sometimes people get that trained mind setup – “I’m just going to do it myself” either on the design side or like you said, on the coding side. Even without coding it, being like “Here I found this, you know, third-party tool you can use. I found this API, or, you know, here you go” and I do think to your point, even if you can go that far into solution space, you need to be mindful of really the roles of the partner and, you know, there’s going to be a Venn diagram overlap. Whether it’s the PM and the designer, the PM and the developer. It’s fine for the PM to be involved with, you know, co-creating the solution and things like that, but you don’t want to dictate or mandate the solution, you know, to your design partner or development partner. I think the best thing is - at the end of the day, what is each of those, you know, which of those three disciplines you bring to the table? And I think the best product teams are where you’ve got strong PM working with strong design, working with strong dev, and the three of them in a Venn diagram are working very well together. If you just take a step back and say what does each of those parties uniquely bring to the table. The developer is obviously the one that’s going to build it, and they bring the technical expertise to this table. The designer is the one who’s going to design the user experience and, you know, make it easy to use and make it pleasurable. What does the PM bring? If the PM is just doing one of those two things, what unique value are you adding? Not much. So what is your unique value-add? As I like to say, designers design, developers develop, and PMs define. Our job is to define who really is our customer and what are their needs. As you said, the problem space. Define the problem space so that when we partner with the designers and developers, that we’re working with them on the solution space to those problems. So I think that’s the unique value-add, and I think some PMs, because they’ve… If they’re very capable in design or dev, you know, and they’ve learned this, you know, just do it yourself self-reliance kind of thing, they can fall into that trap of not relying on it… Now, it also, it’s variable. Sometimes on a team you won’t have a designer. So say your PM is good at design, you’re going to do the designs, and that’s going to fill that gap. And that’s going to work. Say, you know, eight months later, you’re on a different team, and all of a sudden you’ve got a rockstar designer. Well, you don’t want to do the same behavior. You don’t want to say, hey, miss designer, here’s the mockups for you, so you have to adapt to the situation. You may have to adapt to the team situation. It’s OK to fill gaps when there aren’t people there, but when you have capable people there to work with, you want to make sure you’re contributing your unique value-add that you can.
Den: I will echo the sentiment that influence authority is hard. When you have zero authority and tell people what to do and how to do things…
Dan: Right.
Den: Yeah, convincing is hard and you have to bring your A game, you have to bring data, you have to bring insights. You have to bring customer knowledge that other people don’t have.
Dan: Yeah, to take those two points together, if no one reports to you, and you go to the designer and say here you go, here’s the design, I want, you know, here’s the design I want you to… Here’s the design we’re going to go with, they’re gonna have a negative reaction probably to that, right? So, it’s one thing to try to get them to do… Come up with the design and work with you on the design, but you can have, you know, instead of a neutral reaction, you can get a negative reaction if you try to dictate things to people.
Den: It’s a tricky one, but we digressed so much from your career because it’s an interesting topic, but I do want to go back to that a little bit. You worked at Intuit, you worked at Friendster, Box, you started your own company. You’re advising a lot of people. What are the biggest lessons learned throughout your career that helped you be where you are today?
Dan: Wow, it’s a big question. Yeah, I mean, one of the advantages of being a consultant is you do get to see a lot of different teams in a lot of different companies. So it gives you a much bigger data set to kind of pattern match. So as far as the question is, what are the biggest things that helped me get to where I am, is that what you’re saying?
Den: Yes. So if you think of things that helped you, and lessons learned along the way.
Dan: I got to give a lot of credit to Intuit. In fact, probably most of the credit to Intuit, so as I mentioned, in Business School you have two years. The first year you don’t have to worry about too much, but then second, you gotta figure out what you want to be when you grow up. I actually worked on Wall Street during the summer just to check it out. ‘cause I was somewhat interested in that, but then it kind of confirmed that I was more interested in staying in tech, but I wasn’t quite sure what to do in tech. I just knew I wanted to do tech, but that’s pretty general, and then I learned about product management. And so when I did, I realized that, hey, I’ve worked in the Navy for five years designing nuclear submarines. I’ve never done professional software development in a commercial setting, let alone product management. So I asked everybody, hey, where’s the best place to learn product management? Since I wanted to learn, because I’ve never done it before, so I focused on a place that was going to teach me and everybody said Intuit at the time. And so I was fortunate to get a job at Intuit, and it was… Basically, I walked into a product management, product development machine. I mean, they’ve been doing it for years. The other day I was just thinking about what are some of the oldest software products that are still around. It’s like Microsoft Word, Adobe, Intuit Quicken. Quicken is like… And TurboTax. You know, but there are very few of these products that have been around for so so long, so Intuit actually… Quicken started in the DOS days, right? So the reason that’s important is just… And their founders had a certain kind of consumer-centric marketing, right? Scott Cook, the founder of Intuit, came from Procter and Gamble, a consumer-packaged goods company, where you know their job is to convince you that this brand of toothpaste is better than this other brand of toothpaste, right? So they think a lot about marketing and what the consumers care about. And he brought that to Intuit. And so, by the time I got to Intuit, it was… The Quicken product management was basically like a well-oiled machine that I just walked into and was a sponge and just absorbed. And it was kind of nice ‘cause we were doing one year product cycles. You know, like Quicken 98, Quicken 99, Quicken 2000, and a one-year cycle is a nice time frame where you’re in each phase. The requirements definition phase. You know, the coding phase, the design phase, the user testing phase, the launch phase, and the planning phase for the next one. You’re in each phase long enough that it’s not super rushed and you can get good at it and do it well and before it gets old, you are on to the next one. And so I learned so much there, and I think one of the other things we’re going to talk about later perhaps is user research. We had a PhD in user research on our Quicken marketing team. And so I got to learn directly from her best practices and what not to do on user interviews and on surveys and things like that, right? Intuit is a pioneer in user research. We would do follow-me-homes, right? We had the usability lab well before usability was… Everybody else realized how important it was. And we would do beta testing. I think in one of the first, you know, kind of public betas, private betas that we would do. We would get thousands and we would mail CD ROMs to these people to get them to test the software and report bugs to us. So very customer-centric, product development, product management culture, and also now that I think about it, also just on the management side of the business side, right? How they manage the P&O, how they did people management, how they did growth and development. So all those things and I credit not only just the general kind of Intuit culture but also my general manager that I had at Quicken, who took a lot, invested a lot in development of everybody on the team, so I would say that. And then after that I was at startups, as you said, which I was excited to do. ‘cause Intuit, you know, at that time it wasn’t a huge company, but it wasn’t small, and I wanted to apply at startups and I realized this is kind of like the Wild West. You know, there are no rules, there’s no structure and you gotta figure it out. You have to adapt your processes, and so that’s what I really enjoy. Is adapting processes and frameworks for the situation. But then I learned, you know, I think at startups, just learned that it’s really important to a lot of startups - you don’t have people that necessarily been there, done that before. You have first-time developers or first-time product managers. Things like that. So bringing that product leadership and vision up, here’s what we’re going to do, and coordinating everybody, and communicating can really make the difference between success or failure at a startup. So, and then I’d say the other big lesson I’ve learned is that, the quality of the people you work with really matters a lot. It really matters. I would rather have fewer people that are really talented, and I would rather wait to recruit a good person, great person for my team than just say, “Oh we need somebody, let’s just hire and go,” right? So it’s funny, when I went to start my start up, I was like “Alright, great I’m going to talk to all the developer, my developer friend, rockstars from Intuit and from startups.” Unfortunately, none of them were available at the time for various reasons, I’m like “Oh no. What am I going to do?” right. So I was hoping to have a CTO co-founder, but I just didn’t have one because no one was available. But same thing in design. If you get a rockstar designer, it’s going to just change things tremendously. Or rockstar developer on your team. Just one. Having just one rockstar, in any functional area on your team. You hear about people talking about 10X coder. It’s true - there’s a 10X employee for every field, basically.
Den: And it’s hard to identify those. It’s hard to interview for that. That’s one of the things that I feel like… But it’s so, so important. I’m 100% with you. But there is one point that you kind of glanced over, and this is something that is not a typical career path at all. You mentioned that you’ve been involved in submarine design. I don’t know any other product managers in my career that worked on submarines. What did that experience teach you and how was transitioning from that to product management?
Dan: It was great. You’re right, and I’m glad you went back to that, because that actually was also foundational for product management. The way this works, I had a Navy ROTC scholarship, and the way that works is they kind of help you out with school, and then you have to serve in the Navy. Well, you have to decide, you have to apply for where you want to serve in the Navy, and the Navy has ships, and it has airplanes. You can be a pilot like Top Gun, right? Now, I got to fly an F-18, that was a lot of fun during my training, but I decided to go more for the submarine world, and then within the submarine world there’s the headquarters of the submarine world, where they design the submarines. It’s a place called Naval Reactors. It’s a very special place. It’s kind of like NASA for submarines. Much smaller. I think we had like 300 or 400 professionals that work to headquarters there and it was started by someone who is one of my heroes. His name is Admiral Hyman Rickover, so if you’re interested, there’s a few books out there. Anyway, he basically singlehandedly, when nuclear energy came out in the 40s, was discovered, he said, “You know what I think would be a great energy source for a submarine.” ‘cause before that submarines had to refuel, they had to constantly get fuel. You have to surface and get fuel - kind of blows your stealth if you have to service and get refueled. “Oh, there’s the sub! We could all see it.” So he said, “You know what? I think this would be great.” So he created a very special organization. So long story short, I applied and I was selected for that, and it was great, and I didn’t realize it at the time until I got to Intuit, and I was doing software product management. I didn’t realize I was basically doing highly technical submarine product management, even though I was an engineer working on technical things, very very technical system designs. At the end of the day, it was just very technical product management. What does that mean? Well, it meant that the way we structured the org, we would divide up responsibilities, and we all talk about the importance of cross functional teams, right? We all know - for a good software product you need PM, needs to coordinate with design, and user research, and engineering, and QA. That’s what I mean by cross functional. You divide and conquer. Different people. It takes a village of skills to deliver a successful product. Well, same thing in the submarine world - there are people that work on the system design. There are people that work on the component design. There are people who work on material science. There are people that work on supply chain, they divide it up into about twenty different disciplines. It was just like the… And we talk about a matrix organization, and a lot of times people have a hard time, ‘cause the matrix isn’t clear and it’s hard to get buy-in and stakeholders, and things like that. This was the most efficient, effective matrix. In hindsight, I didn’t know it, ‘cause it was my first job out of college. The most effective and efficient matrix organization I’ve ever worked in, and so it taught me how to work cross functionally. Of course, in order to get this done, I’ve gotta go get agreement from these other people, right? So it taught me this… Working on a very, the other thing I think is working on a very complex product, right? There’s a nature of, when you judge a product manager’s work – well, how complex was it, really? Just working on a little feature, or were you working on a major product with a lot of interrelated systems and coupling and things like that and dependencies? And so early on in my career, I worked on submarines are very complex, in a very teamwork, collaborative, good matrix organization. And the last thing is - they really delegated a lot of responsibility. This organization you came in as a 22 year old college grad, you reported to a group head, who reported to a section head, who reported to a four star Admiral who is the third most senior Admiral in the Navy. So very flat management structure, even though it was in the Navy, it was more like a technical organization, so it was no “Yes sir, no sir,” there’s no rank baloney. It was a technical meritocracy, which I think a lot of us subscribe to have our companies be. So for all those reasons, and just working with very sharp people. The last thing I’ll say is because I started there, when you think about a product, think about the amount of time you spend in three categories. Designing it, building it and testing it, right? You can think about design, Dev and QA for software, and most of the time, most software products, I would say like most like 80 plus percent of the time is spent building it, developing it, right? Well, when you do a submarine, it’s actually the opposite. It’s so complex that you need to put so much thought into designing it. The “designing it” takes like five times as long as building it, and so it really hammered into me the importance of clarity of requirements and thinking in the process. We would always get clear on the requirements. I would work on system designs and we wouldn’t even… We would be working with conceptual models of what the design would be, not even talking about what the real, what the solution or real system was going to be. But talking about what the requirements were, so this is some of the takeaways. So long answer, but it was a very special place that did, I feel like, prepare me for product management because we did have a very effective matrix org, we were doing cross functional collaboration very well, and it was a very complex product. We spent a lot of time thinking about design and requirements.
Den: I think the risk profile is also vastly different than any tech product.
Dan: Yes, that’s true. That’s why I like to jokingly say, you know, waterfall does make sense for submarines and space shuttles. You don’t want to have like that “Let’s launch the MVP! Oh it sank, let’s iterate to submarine 1.1.” Yeah, the stakes are higher, definitely, because then it was kind of nice to go from that to one, two, or like a CD-ROM package with a one year product cycle. So the other thing I didn’t mention is - from the time you say, OK, here’s the high level objectives of the submarine, to when it’s actually designed, built, tested and in the water and ready to operate. That’s twelve years. So twelve year life cycle for the dev process, then to go to a one year product is great, and now we’re all in the web and mobile, where it’s like every week or two. We’re pushing a new release so I’ve seen the full spectrum, and to your point, you kind of adapt. You need to adapt your processes based on the risk profile and the other factor is how easy is it to change things, right? When you’re literally welding steel plates together, if you make a mistake, and go “Oops, we need to iterate.” It’s really hard to iterate. Or you spent two years designing a specialized pump. You can’t go “Oops, we gotta change it now,” right? But if it’s a software bug, you can just patch it and fix it in an hour, right?
Den: I will never complain about waterfall again. Hearing that twelve years is the time frame. But for more than a decade now, you’ve worked as a product manager, trainer and consultant. What led you to this particular decision? Because as a product manager, you can always choose to start working at some other corporations, some other company. Maybe start another startup or anything of that nature, but you decided to say no. I’m going to help people become better at product management. Why is that?
Dan: Yeah, well honestly it was a bit of luck, random chance, and what happened is after doing a few startups after Intuit, that were web startups, I realized that the web is here to say, obviously, and many of the future products - they’re going to be web products. And while I’ve been coding since I was nine, and I know how to code and I’m a EE major, and I know all this technical stuff, I don’t know how to code this web stuff, so in 2005 I decided that I’m just going to go and invest and take classes in HTML, CSS, JavaScript, PHP, Unix, Apache, and Photoshop. And just like invest and just learn the web stuff, so that I’m more comfortable and more knowledgeable about it. And while I was doing that, I got an offer to be a VP of product for a startup, and I really liked the team and what they were doing, but I literally was taking 20 hours a week of classes. I was just “Let me just get this done.” I wanted six months and finish it and then I can go back. And so I said, “Hey guys, I’d love to work with you, but I can’t do it full time because I’m taking all these classes. Can I be your interim or part-time VP of product?” and they said yes and so that’s how I became… I’m basically, for 30 hours a week, I was effectively their VP of product, but I just was doing it as a consultant instead of as an employee, and that went really well, and then there was another startup. They needed a VP of product, and so it ended up being a similar situation, and I realized, well, this is great. I’ve discovered this opportunity where I can work with, you know companies to help them. And at the time it was often a post-Series A company, so they had… It was a great space to work in because they had enough going on that they had enough traction and enough team to raise an A round, but they didn’t have anybody in product management. And so, you add me to the equation, and I can add a lot of value in doing that, and so that was great. And once I did it two or three times, I realized - this is a great. This is awesome. I’m constantly meeting new amazing entrepreneurs and people; I’m seeing what they’re doing right. I’m helping them do things better. I’m cross-pollinating, learnings across different companies, so it was great. And for example, in those early days, also, that’s when I worked with Box. I helped them out as interim VP of product post-Series A, I ran their first user test that… They had never done a user test, and so I ran the first user test which was very eye-opening for them. So once I got… After doing two or three, I was like “This is great. I can make a career out of doing this,” and there were a lot of advantages to that.
Den: So you’re the expert in the product management space. There’s a lot of folks that are listening to the show that are new in their career, they are still exploring the space. What do you think are the things that are missing the most, based on your experience, in the product management space?
Dan: Skills that are missing the most?
Den: Skills or specific abilities or maybe just focus areas where folks are just missing them or they’re just kind of the obvious unknown.
Dan: Yeah, I mean, we talked… That’s the thing about in our discussion here. We talked about like some people, when you think about the PM job - it’s a unique job in the sense that to be successful you do need a wide range of skills, right? That may not normally be focused in a single person, right? You need to be able to listen well, like for user research is critical, right? And I know some larger companies. You might have a user researcher, or user research team you can lean on, and that’s good, but in many situations you don’t. And even if you do, I think you have to have a certain level of involvement and knowledge about user research. You need to be a really good listener to do that. You need to be a good listener to get stakeholder buy-in and get that cross-functional collaboration. Communication is key, so not only did you need to be a good listener, you need to be able to articulate your points. We talked about influencing without authority. If you’re not good at that, you’re dead in the water. You could have the world’s best ideas, but if you can’t convince anybody how great they are, it’s never going to see the light of day. So you’ve got… And it’s funny ‘cause we start out with these soft skills of listening and communication. You also need to be able to come up with the vision and to point the team in the right direction. And it doesn’t mean you dictate the vision. It should be co-created with the team, but someone’s gotta drive it, right? Who’s driving this? Do you know who’s leading us? It’s leadership, but it’s not formal leadership right? It’s informal leadership. The other critical skill is prioritization. I mean, it’s just… There are always way more ideas floating around than you have resources. So prioritization is key, constant prioritization, and I mean like rank order. I remember the first time I saw a PRD and there are 15 highs and 15 mediums and 15 lows. I’m like “Well, that’s good that we did high, medium, low, but up to 15 highs, what’s the top one? Which one should dev work on first?” You know, if you’re just punting on that, you’re leaving up for judgment, right? So, I call it ruthless prioritization, rank order constantly rank ordering things. Anytime I see a list from anybody, the first question I ask is, “Is it prioritized?” And if it’s not, I’m like “Go prioritize it, and then show me it when it’s prioritized.” Don’t show me randomly ordered lists, show me a prioritized list. So you gotta be flexible, but you gotta reprioritize a lot, but you should always at any point in time, be crystal clear on the priorities, and when changes happen, that’s fine. Change priorities and then make sure everybody knows what the new priorities are. So those are all important things. And then I actually think the longer, again, in my career, I think “Why?” is the most important question that PMs needs to ask and have the answer for. Why this feature instead of this one? Why should we do… Why this? Why that? Why? And then one thing I see a lot of times, it’s funny, I always laugh, is like somebody is often a PM or might be a developer. Somebody on the team would be like “Why are you doing this?” “Well, you know the VP said that we should build this. We should do this.” I’m like “Yeah, but do you know why? How’s it going to value?” “I don’t know, but I’m sure they know they would do. They know, they’re the VP, they know.” And it’s so funny how a lot of times people just assume that because it came down from on high, that someone must have done the due diligence and must have thought it all out, and must know what’s going on, and a lot of times it’s just not the case. The emperor has no clothes, it’s just like no, there’s not really a good case for that. So now we obviously need to ask why in a diplomatic way, but that’s really what it’s about, and it’s funny ‘cause a lot of times I’ll jokingly call PMs reality messenger. Not joking, I’ll call them reality messengers. It’s like, OK, we’ve got three devs. They’re going to code as much as they’re going to code, however many hours they are going to code. We can give them this set of things to ask them to code. Same thing with the designers. What is the set of things that’s going to maximize the ROI on their time? That’s really what it’s about. And so it’s not quite at the level of physical science or engineering, ‘cause there’s a lot of uncertainty, and gray, and fog, but it’s basically - how do you make sure that what you’re launching is going to create customer value? So you have to build up insights. You have to be able to build a model of customer insights and be able to articulate why. Why we should go out for this opportunity and why these are the right features, and why this is the right call for an MVP, and why this is the right roadmap, and this is why this feature can wait and why this one can’t. There’s so many “Whys.”
Den: The big thing that I see, you talked about customers, and this is where PMs usually come back to engineering teams and say, “Well the customer asked for the button to be green. Let’s make it green,” but nobody bothered to ask why. Is it a discoverability problem?
Dan: Yeah.
Den: Is it a velocity problem? What’s the actual problem? It’s interesting.
Den: Yeah it is, and it’s funny because I think it’s one… It’s not common for customers to be so dictatorial on the solutions. They can be, for sure. But they will most likely just give you negative feedback and say “I don’t like this” or “This doesn’t work for me. It’s confusing.” Sometimes you do get people say “I want you to build exactly this for me” and this happens a lot with startups, by the way. Startups - they’re trying to survive. They’re trying to generate revenue. The salesperson has a call with IBM, and it’s like IBM says “OK, if you build it, then we’ll sign up for your product” and they’re all excited. “Oh my gosh, we got IBM. We got a big contract, but they told us what to build, we gotta build this.” The number of times I’ve seen a startup build what was specified by a big company client, and then it not get used or actually create value - it’s sad. The number of times that happens, and what you realize is - you thought you were doing the right thing by just saluting and saying yes sir, yes ma’am, we’ll build exactly what you asked for. But the problem was - they didn’t even realize what they wanted. They were in the solution space. They didn’t ask the wise. You see what I mean? This happens all the time, and so you have to ask. Again, you gotta get “why” and clear on the problem. That’s the whole problem space vs. solution space that that I talked about in my talks.
Den: And a lot of these things are covered in your book - The Lean Product Playbook. So, tell us more what inspired you to write the book, because at some point you might have decided that you know what, I need to put this on paper.
Dan: Yeah, well, you know, the book is a lot of work, so writing a book is a lot of work, as I’m sure a lot of other authors can attest to. The genesis of that would be speaking, basically, giving talks on product management, sharing lessons learned and sharing frameworks. And I started speaking in 2007. Actually, I just had BJ Fogg, he’s a Stanford researcher. He just recently spoke for the second time in my meetup. In 2007, that summer is when Facebook launched their F8 app platform. It was amazing. He pivoted very quickly, and so you know, let’s do a Facebook app class and like that Fall. Very fast for academia. He did that class, and so one of the co-professors who knew me said, “Hey, you know, why won’t you come in and talk about product management to this class of students that’s going to be generating Facebook apps?” And also, because I had worked at Friendster, he knew that I had done viral loop optimization. I probably was one of the earliest people that had done viral loop optimization, and so I came in to speak, and so as the first time I ever put slides together in my life, was in 2007. I look back at those slides now - they look like… They’re horrible, but it’s the first slides I put together. And then from that I started speaking at Web 2.0 conferences. I mean, it’s before there were even product management conferences, more like web conferences or tech companies or entrepreneurship conferences. And I started speaking at all those events, and generally spoke more and more, and just kind of. You know, what I would do is great. It was very iterative. I’d give a talk. I’d see what resonated well with people, what didn’t. I’d see what questions… Mainly the questions I would get. “Well what do we do about this?” And then between that and my next talk, I’d add some new slides. Go into that topic. I’d be like, “Well, a lot of people ask about UX design. Let me go into that.” And so that kind of… The slide where… And the frameworks kind of developed over time in concert with the consulting, ‘cause I mean, the parallel - I’m consulting with all these different companies, seeing all these different challenges and helping them solve them. And then I was teaching a workshop. One of the pivotal moments was teaching a workshop, and I had a really bright class. There’s a lot of people that were bright and very enthusiastic. And they were very specific, and they wanted me to spell out a process. A step-by-step process like “OK, what do you do first and then what do you do?” I remember writing on the whiteboard and running… First time I had ever kind of tried to string together a process of what you do when you’re trying to develop a new product. I remember kind of going, running out of room on the whiteboard, and that made me start to think about a process. I wanted to… always kind of wanted to write a book, but it’s a lot of work so I never really got into doing it. And then Wiley reached out to me and said, “Hey, have you thought about writing a book?” I’m like “I actually have, I just haven’t gotten around, haven’t committed to doing it,” and so that led to the book being written, which took fourteen months. I was working pretty much full-time while I was doing it, so it’s doing nights and weekends, and I got published in 2015.
Den: And it’s a timeless piece ever since. To that point, and talking about the book, a lot of the ways you outlined in the publication around the thinking about the product, the separation between the problem space and the solution space, things like the cohort retention curves - super important for any product management organization. How do you see, in your experience, those frameworks evolve over time? Because one of the things that I’ve seen often, product managers snap in this mode of saying “I followed this framework because the book says so” and that’s it. How do you see them change over time?
Dan: Yeah, it’s funny because I think frameworks are very helpful in product management. As we know, you can’t get a formal college degree in product management or anything, right? I mean, I think actually CMU now has a Masters. You can get in it, but for all practical purposes, you can’t. And it’s funny, the other day someone said “You know, PM is frameworks” and then I was like, “Yeah, you need a framework to know which one to use,” which framework basically. Because they apply in different situations. And that’s the thing about a lot of these frameworks, is a lot of times the answer is what’s the ideal framework is, it depends on the situation in the context, right? So as far as how they’ve evolved, I mean, I do see some people… I’m always delighted when I see someone take something and just run with it. Like importance and satisfaction, for example. I came up with that framework at Intuit when I was trying to prioritize features for the next version of Quicken, and I had… Because we had that market researcher we had quality, primo survey results, and we had lots of users who had big sample size, and I was analyzing that data, and slicing and dicing it. And that’s kind of how I came up with importance and satisfaction. Well, the other day someone reached out to me and said “I read your book, I loved it, and can I show you what we’re doing?” and they had done all this amazing importance versus satisfaction analysis. So that was really exciting to see. The other thing I will say is - it did take fourteen months to write the book. It’s 335 pages. It’s very comprehensive. My goal was if I’m going to write a book, I wanted to cover all the things you need to know about product management. I mean, I have other things in my talks like marketing and messaging, that I didn’t even include in there. But one of the things is - in writing the book, it was like a deadline. It’s like having a deadline, it’s a very waterfall process. You have a deadline, right? And so there were certain areas where I was hoping to maybe extend some frameworks. And the other thing, to go back, is some of those frameworks were created while I was writing the book, so some of them existed before the book in my talks, but the product-market fit pyramid - I created that while writing the book, and the lean product process I created while writing the book. One area where I didn’t have time, I ran out of time, was in the value proposition area, as far as having some public examples of that. I have a generic example, but in my talk since then I’ve given public examples applying that, reverse engineering the value prop grid for Instagram and Uber. So that’s kind of extensions of what I’ve done or good case studies. And then one of the things I was really excited about, back to importance versus satisfaction, was… I give a formula for how to calculate the opportunity score. I always wanted to create a visualization that was more just intuitive to see the opportunity score, but I just didn’t have time, and then a few years ago in working with a client I kind of had a little inspiration and I was able to come up with a heatmap visualization. So that’s, again, in some of my more recent talks, but not in the book. So those are the things, some of the things that I’ve done to extend some of the work in the book.
Den: And I’m curious because you’ve alluded to the fact that PMs need a breadth of skills: marketing research, analytics.
Dan: Yeah.
Den: And one of the things that I’ve recently been talking with a colleague as well is that the biggest thing that a PM should be doing is, you have that meta skill of being able to solve a problem. How do you scale your own skills as a product manager over time? What helps you learn?
Dan: Yeah, I do think that fundamentally problem solving, or decision making is the core skill of a product manager. And so as far as how do you get better over time, I also think just kind of intrinsic curiosity. The best PMs I know are very curious. They ask “Why?” Like I just mentioned how “Why?” is really important. They see some anomaly in the data, and instead of just going on “Oh that’s interesting” and moving on, they go “I wonder what that is,” and they may pull that thread. Or in qualitative they get something surprising and they go through it. So I think it’s really that curiosity, and because it does take a village, I found what served me well in my career is - I’ve leaned into learning about the adjacent skills. I just gave a talk in January at the meetup on UX design. I’m in the process of edtiting the video, so I was re-watching it, and I realized - my first few months in PM, I wrote what I thought was a great… I contributed to writing what I thought was a great PRD. Back in the day, when you write the long PRDs and MRDs. But then I realized later in the product cycle - we could write the world’s best PRD, but if the UX design isn’t good, it doesn’t matter. So I suddenly had this “Aha!” moment, like wow, there’s this thing called UX design. It’s really important, that I don’t really know anything about, so I went out and I saw books on it. At the time, there weren’t that many books on it. The inmates are running the asylum by Alan Cooper was out, there were maybe a couple other books out there, really more like HCI, human computer. I took an HCI class while at business school. I leaned into that, and then I went and took a class in visual design. So I use this as an example, and since then I’ve read a lot of books, and I think the point is - by learning about the adjacent functions, and I would actually put UX design at the top, it can really help you be a better product manager. It can help you better critique designs. It can help you have better conversation with your designers. And worst case, if you don’t have a designer, you can help fill that gap more effectively. Now. If you do have rockstar designer, then just let them drive the bus and let them do it. Likewise, marketing - learning enough about marketing, and messaging, and positioning, analytics. Learning about analytics. Just learning. Just leaning in and learning, and being a sponge. You know I was just blown away. I just was doing… I’m doing an assessment for a large organization. I talked to a lot of people, and also I talked to one person, and she pulled up all these amazing dashboards and analytics that she had just taken upon herself to do. And I’m like “Oh my gosh. Every other team should have these too,” you know what I mean. So just leaning into adjacent things, learning enough about… You don’t need to go get a degree in CS. You may not even need a coding class, but just learning enough about technical stuff, frontend, backend, that kind of stuff, to have a conversation. And I think constantly self-assessing and say “Where am I weak?” Like, where are my weaknesses that I could be better performing if I weren’t weak at that, whatever it is. Everybody always has something to work on. There’s always something, there’s always new tools coming out, and that’s part of it too - staying abreast of the latest tools right there. It’s an exciting time to be in product management. Especially prototyping tools. You know, like Figma - that wasn’t around a few years ago. And so now you’ve got these great tools.
Den: It’s interesting how Figma just swooped in and took over all the InVision, and Sketch and Balsamiq. It’s just everything is Figma now, but it’s interesting. I’m curious again, on your point around the breadth instead of depth, you don’t need to get a degree, you just need to be good. What’s your litmus test at knowing “OK, I know enough.” If I identify the weakness, that I’m weak at UX design, or data, or talking to customers, how do I know that “OK, I read some books, I took some courses, I talked to people, but this is good enough.”
Dan: I’ll answer your question, but part of me has a hard time because there’s this idea of continuous improvement, and so there’s good enough, but I wouldn’t say good enough means you should stop learning in that area. It means maybe you can reduce your investment in that, but I like to always be learning, even in areas that I think I’m good. And I would say that another key component. So you read the books, read the blog posts, you watch the videos, you listen to the podcasts like this, but at the end of the day - you have to apply it, and how you really learn is applying it. So it’s like on the job training - you have to apply it. So say you’re trying to learn how to do a good, better job at interviewing users. The best way to get better at it is to interview a lot of users. Actually do it, and that’s what I see a lot of people, they kind of get caught up in learning how to do it, learning best practices. But then actually doing… You have to do it. There’s no… You should learn the theory, by all means, and my book has plenty of concepts and theory, but the point is you need to apply it. And that’s how you really get better at it. And then I think when you don’t have negative surprises and things go well and you get the desired outcomes, that’s how you can feel confident that I’m good enough in that area that I can maybe go focus on other areas that I want to learn and get better at.
Den: Well, and interesting point on that is that sometimes there is that challenge of applicability. So for example, one of the big things that comes up when I mentor folks is folks that want to break into product management, they want to become product managers, but they’re not necessarily working as PMs. They are still in college, they’re in school, and they don’t necessarily have that obvious point of like, “Well, OK, I want to be a PM, but how do I… Where do I apply it? I’m not in an internship or not at a company.” What’s your recommendation for those kinds of things, where I want to learn how to be a PM, but I’m not a PM?
Dan: Yeah, and that’s the challenge. It’s a Catch-22, where people that are hiring PMs want people that have PM experience. And if you’re not a PM, then it can be hard to break into PM so it’s tough. So the number one way is to get transferred into a PM job within your own company. You may be working in customer success, or QA, or design, or something, or dev. There’s plenty of people that go from Dev to PM. That’s the best way. ‘cause for whatever reason, there’s this perceived risk of hiring someone that’s never done it before, and it kind of makes sense, obviously. But within a company, because you’re more of a known quantity, they tend to be more willing to let you jump over there. So, and I’ve seen… I have a friend of mine, who transitioned from one role into PM in a company, and then he was smart. He actually waited till he was a senior PM, and then he left and now he had a senior PM title, so now he could get a senior PM job. So that’s the easiest thing is if you’re working in a company, get them to try to get them to transition. Short of that, just go bug the PM and say… PMs always have way more work than they can do. If somebody came up… If I was a PM at a company and someone said “Hey Dan, I’m really interested in PM, what can I take off your plate? What can I help you with?” I’m sure I could find some work that they could help me out with. Whether it’s going through some user feedback or whatever. Looking at some analytics, running a report, right? So if you can’t formally get the job assignment, then kind of try to saddle your way in there. Just kind of saddle in there by saying “I’m going to start hanging out with them offering to do work, maybe attending some meetings, getting coffee, informational interviews with people that are PMs,” and that builds an affinity. So then, maybe then, when an opening does happen, you’re more likely to be slotted into that position within your own company, so that’s the easiest way. If you’re not in a company, if you’re just a student, or you’re not, you obviously want to read all the things we said. Read the books, read the blogs, watch the videos, podcasts, events, conferences. None of that is doing anything, though. It’s learning. It’s important, but you’re not doing anything. And so I think one of the best things you can do is create a website for yourself, like dan-olsen.com or whatever, johnsmith.com. And I’ll tell you this - one of my other clients, Medallia. I worked with them for a long time, and one of the main things that I did is - I built their product management team. When I joined, they had six PMs. They were all relatively junior, and in general, it’s a great company. They IPOd. It’s a wonderful company. I love the culture they have. Strong product team that we built over time there, but their general hiring philosophy was - hire some smart, high horsepower, intellectual horsepower people, and we’ll… Even if they haven’t worked in that job, we’ll train them and they’ll figure it out. Well, that’s kind of what we had on the PM team. We had a lot of junior smart, generally smart people, but no one that had done PM for awhile. And so I basically was like, OK, well let’s hire, add some directors in, let’s add some leaders. And then we also decided to add some associate PMs. So you see that more often. So that can be a way to break in. Well, we had a bazillion people, and we had just raised money from Sequoia. It was a very hot company. We had people over… Tons of applications for our associate PM positions, and I remember one person in particular stood out because they actually had a website, and they had their portfolio on their website. Now, we’re used to designers having portfolios. Product people can have portfolios too. You put up the roadmaps that you’ve got. Now, you can redact them. Some people are like “I can’t put up there,” fine, just black out anything that’s confidential or sensitive, but show me how you’re thinking. Show me how you do product work. Show me what you’ve done. And now, if you’re like “Well Dan, I don’t have any work samples yet. ‘cause I haven’t worked anywhere.” Well, there are people that have gotten creative there to. Go do an assessment of a product. OK, Instagram just rolled out a new version 2, go do a detailed analysis of what you like about it and what do you think they could have done better. So product teardowns, product reviews, sharing your thoughts. That lets me know that not only are you learning about it, but you’re really passionate about it. You’re demonstrating your thinking to me, and actually so several of the APMs either had websites or had worked on their own side hustle projects, and they showed me. Let me show you the prototypes, and I’m like, great, I can see that they prototyped this thing. They thought about it. They thought about the requirements, they prototyped it. So I would say - show, don’t tell. Show, don’t tell. Don’t just say “I want to be a PM.” Show me how you want to be a PM, and something that you could point to. A website, right? The other thing is - I love it, it’s like I’m interviewing someone. They want to be a web PM. I’m like “Where’s your website?” “I don’t have one.” “You want to be a web PM and you don’t have a website? OK.” Well, now, and I know not every web PM has a website, but we have plenty of other people that are applying that do have websites, and it’s not a big deal, but it’s just a simple filter to be like “This person knows enough about technology and the web to get a simple website.” So simple with Squarespace or WordPress to have a website, and then what do you do when you apply for a job? What do I do? I Google your name. I Google your name. And I end up at your LinkedIn, and I see if you have website or not. If you don’t have a website, it’s kind of like OK, well, you know, it’s not that hard to do. How much are you hustling? You’re not employed right now? You’re unemployed? What’re you doing not making a website right now?
Den: And it’s easy. There’s tools.
Dan: Yeah it’s so simple now with Squarespace. You don’t need to know anything about coding, just…
Den: So we’re getting to the top of the hour, so I have two questions for you. One, if you have a parting advice for aspiring product managers, and the second one, and I know there’s an exciting announcement about your upcoming public workshop. But in addition to that, where can people find you online? So those are two questions.
Dan: OK, cool, so. So on the PM, you said aspiring. At what level of aspiration are we talking about, ‘cause I’ll tailor the advice to that level?
Den: Let’s talk somebody mid-career now.
Dan: Mid-career. OK cool, that’s an interesting point. So we already kind of covered breaking into it, so mid-career is interesting and I’m helping a couple people right now that just got promoted from senior PM or director in a start up to now in a position where they are managing PMs, and this can be a very difficult transition for PMs. I mentioned earlier how PMs, you kind of, a lot of times you get trained that if you want to do something right you just do it yourself. Or obviously, we’re not the ones coding and we’ll hopefully have designers and stuff, so we’re not doing everything ourselves. But in general, it’s like if you wanted to get it done right and on time and there’s no one that can do it, you can lean in, you’re going to just be self-reliant. And so, you get this individual contributor mindset, and then you get… The reward you get for being such a good PM and working way up the ladder, up the career, is now you’re managing PMs, and often times when you first manage PMs, you’re still doing individual work as a PM, so you’re a player-coach, we call it. And so the IC part is not much of an adjustment. Usually you get the bigger, more complex products or teams, and then you give them more junior product people the stuff that is not as complex, and they work their way up over time as well. But the people management part can be challenging because you’re so used to doing it yourself. And I like to remind people, people management is a whole distinct skill set, right? Why would you be anything? Why would you be amazing at some new skill that you’ve never had to do before? All things being equal, you’re probably not going to be amazing at it. You may have some intrinsic potential, but again, like on the job training and actually applying this skill, and seeing what works and what doesn’t, that’s how you get better at it, basically. And sure, of course, by all means, read the theory, read the books, all that. But I think a lot of times people just get thrown in as first-time people managers, especially in startups. I’m talking also about… It happens to big companies too, you get thrown in as a first-time manager without much training, or support, or expectations, and we’re all so busy. Everyone’s so busy running around. And if you think about, again, if I go back to Intuit where I saw good examples of people management and coaching and development, what do they do? They make time each week for a one-on-one. That’s often the first things that goes out the window. It’s “Oh, we’re all too busy, we’re not gonna do one-on-ones.” That’s an important touchpoint for the employee-manager relationship. And the other thing is - to make sure it’s not 100% focused on just the work to be done, but you’re also at least carving out some time for meta things, like how are you doing, what’s going on with your career development, your job satisfaction, things like that. What skills do you want to focus on? Those are some of the best conversations that I value the most. As our GM would say, OK, great, you’ve got your day job, but what are your aspirations and what do you want to develop? For example, I knew I wanted to learn more about marketing and I mentioned I leaned in. And the way we divide our team up at Intuit, PM and marketing - we work together, but we kind of divided and conquered, so we didn’t often get as much visibility into marketing. But I knew it’s important, and it was an area I didn’t know about, so he let me sit in on a lot of those meetings and there was one research project in particular. We did a market segmentation exercise. I’m so glad that I was able to ride shotgun and just observe that and learn from that. So anyway, I think that transition from individual contributor to people manager is a difficult one. I would embrace it, like anything approaching, like anything else, it’s a new thing. Before it happens, try to bone up on all the things. Try to find people that you think are good people managers and have coffee with them, and ask them “Well, what are your tips on how to be a good people manager?” It’s an interesting thing. And the same thing happens in the dev world, you get some rockstar developer who’s an individual contributor and they get promoted to a manager, and a lot of times they are either not good at it and, or they really dislike it. And it’s a very different job. Can be a very different job, especially if you’re going from like 100% individual contributor to zero or very low individual contributor. That’s a very big transition. So yeah, that’s some advice. I would say that if you’re approaching that, just be mindful and think about how to be successful in that new role with those new skills. And then the question about where folks can find out more about my stuff, on my website… I do have a web website. I practice what I preach here, it’s dan-olsen.com, and that’s where I post my speaking schedule, and videos, and blog posts and things like that. I also have an email newsletter people can opt into there. And as you mentioned, I do… I try to… I do a lot of private workshops. I also try to do public workshops where anybody can come and sign up. And my next public workshop is April 20th to the 22nd. That’s another thing with Zoom is - chop up the workshops into like three and a half hour chunks, so it’s like three days of three and a half hours, so like about ten and a half hours total, where I basically cover the book. It’s like the movie version of the book. People can find the link to that from my website. Also, I mentioned Lean Product Meetup, it’s free to join the meet up group - meetup.com/lean-product. You can come check that out. Our next event is March 23rd, so I think this podcast will be out before then. But you can sign up. And then I put all of my talks on my YouTube channel, as well as all the talks of the speakers that I hosted at Lean Product, so we have over one hundred video talks there. I also do fireside chats with my guests, and we just crossed 6,000 subscribers, so it’s it’s probably one of the channels that has the most hours of product management content on it, and it’s just youtube.com/danolsen and you can subscribe and be notified when we post new channels there, and then of course on LinkedIn, so those are places where people can find me, and then twitter.com/danolsen, so all those places.
Den: Excellent. And I can’t think of anyone better than knows more about product management than yourself, so it’s a must, must subscribe. At that Dan, thank you so much for being here with us, sharing your insights and perspectives, and I’m sure that a lot of folks learned a lot. If we’re talking about the analogy of the sponge, this was the perfect environment to be that sponge. So thank you so much for being here.
Dan: Well Den, thanks a lot, I had a lot of fun talking with you. Appreciate it.
Den: Thanks Dan!
