Build Great Products And Strong Product Teams

Dan Olsen is an entrepreneur, consultant, Lean product expert, and author of the bestseller The Lean Product Playbook, published by Wiley. In this podcast, Dan talks us through all things related to the product, product strategy, and building strong product teams.

“How did you get into tech?”

That story goes way back basically to where my parents got me a computer when personal computers came out. Back in the day, I just kind of played video games on it and I learned to code, but it made me very comfortable with computers. So then I became an electrical engineering major. The first job I did out of college was doing nuclear submarine design, which was really fun. Even though I was doing engineering, it really was like very, very technical product management. I didn’t realize it till later. I got a master’s in industrial engineering while I was doing that.

That’s where I first learned about lean manufacturing and some great other concepts, like the Kano model. And then I realized I want to get more on the business side of things. So I decided I wanted to get an MBA, and I went to business school at Stanford. That’s what brought me to Silicon Valley, and I’ve been out here ever since. And it was in business school when I was trying to figure out what to do after graduation (because I had only done submarine design which is kind of a rare job) that I learned about product management.

This new career called product management, and that wasn’t anywhere near as popular or as hot today. Back then it wasn’t as popular and it sounded really cool. But I’d never done it, so I asked people where the best place to learn was. And pretty much everybody at the time said Intuit is the best place to learn. So I was fortunate to get a product manager job at Intuit. That’s kind of how my whole career got started, and then from there I went to startups as a product leader, started speaking at product conferences, and got into consulting. 

So that’s pretty much the evolution of my career. We’ve all got a different path, but that’s how mine started.

“You said that Intuit was one of the best product schools at the time. How did you convince someone there to give you a product management job without previous experience?”

It was a different world back then. So back then going to a business school was like the main path to get into this small field of product management. So lucky for me, they were coming on-campus recruiting, so that was great. They really liked my technical background…I had taken a management and information systems class, (I don’t even know who calls it that anymore) but the cool thing about that class was that we had to spec out a product and potentially prototype it. 

My dad kinda helped me start my IRA right out of college, and the geek part of me loved going ‘what happened to my mutual fund prices today?’. I had this spreadsheet that I was updating. So I decided, for this MIS class project, to create a portfolio tracker. So then when it came to talk to the Intuit people, I told them all about that, and they could tell I was a product geek at heart and had good tech chops.

“How do you go about picking those challenges or problems that you really want to solve?”

The biggest thing I’m excited about is training. When I went to Stanford, there wasn’t even a product management class or elective. You can’t get a degree in product management (though Carnegie Mellon has one I believe, for the few people who can get to Pittsburgh)…there wasn’t really a good training curriculum before Product School existed for product managers.

You kind of learned it on the job, you picked it up. So you’ve got people coming in from design, people coming in from analytics, people coming in from various paths, usually getting an internal transfer within a company. So for me, training is my top goal. I love training and sharing best practices. So that’s why I wrote the book. That’s why I speak. That’s also why I run the Lean Product Meetup, where I bring in top speakers every month. I’ve been doing that for six and a half years.

So that’s the training part of it. As far as the consulting part, usually people come to me with interesting problems and it’s a great thing where it’s a self-selection where usually a lot of my clients are people that have a certain amount of success.

So they’re happy about that, but they want to take their product and business to the next level, and they realized that they’ve kind of hit some constraints because they don’t have the product skills in-house that they need, and they hire me to help them out. So that’s a lot of fun. I really love working with those kinds of companies. A lot of times those are post Series A companies, like I worked with Box back in 2007. They obviously had some success going, but they were nowhere near the unicorn that they became.

I love working with really talented teams that just need help taking their product and business to the next level, by applying some of the techniques and frameworks that I’ve developed in the book.

“Outside of technical knowledge, what other skills do you think are key for product managers?”

Obviously being technical helps, but I think it’s too often that people just kind of say, Oh, if you don’t have a technical background, we’re not even gonna talk to you. I’ve seen plenty of PMs that don’t have a CS degree be successful. But it can help, right? What you want to do is know what’s possible with the technology. You want to be smart in your interactions with engineering and not be some new PM and ask them to build something it’s going to take like a year to build. Right? You want to avoid that. So it’s really more of a credibility thing.

The other basic skills, these days, I would say one is being clear on objectives, and strategy. It’s really easy to fall into a junior PM role and just be executing every two weeks in your sprints, but not understand why you’re doing the things that you’re doing.

So if you’re getting fed user stories like a baby bird and you’re just executing on those, that’s fine. But at some point you need to be like, why are we doing this? How do we connect the dots to what’s going on overall? I think actually one of the most important questions for PMs to ask and think about is, why are we doing this? Why is this the right target customer? Why is this the right item on the roadmap? Why is this the right way to build this feature?

One thing I see a lot is junior PMs assuming that someone else higher up in the food chain knows why. And a lot of times I catch them in their mid career and they realize, Oh my gosh, the emperor has no clothes. Like nobody knows why we’re all running around, just building features because some VP said so, but even they don’t know how it’s tied back to any objective.

So it’s kind of funny, you start to realize, Oh my gosh, I’m the one that needs to provide the Why? Like, it’s my job to figure out what should we be doing? And why? So that’s an aha moment. I think as PMs get through their career, they realize, we’re the ones who figure out why at some point in our career. So that’s really important. And then that naturally leads into prioritization. There’s always way more ideas than what can be built. 

“What do you think are some best practices for new PMs to get up to speed during the first month?”

You don’t want to come in hot and be like, Hey we’re doing it all wrong. Here’s how you need to do it. I just finished my certification.

Yeah, you definitely don’t want to do that. The number one thing I think you want to do is to listen a lot. You just want to just be a sponge, just soak up everything. Because you may have a range of PM training, but you don’t necessarily have any experience yet.

And no matter what, you know, books are great, blogs are great, videos are great, classes are great…But until you actually get in the trenches and are practicing and get your hands dirty with product management, that’s when you really start learning it to the next level.

So the other thing is you want to meet with everybody because with any new employee, your schedule starts out empty pretty much. So you can say, I’m the new kid on the block, can I get coffee with you? Can I just meet with you? Can I just understand what you do and how it fits in? Everyone will give you that benefit of the doubt when you’re new and just be like, yeah, I’ll meet with the new kid, whatever. As soon as you get busy, then your calendar is going to get full.

[As a product manager] nobody reports to us, and we’re going to have to beg, borrow, and steal to get things done. So let’s build all those relationships early on. The other thing is also to note who to go in the organization, where to go for certain questions, because things are gonna pop up and you’re gonna be like, Ooh, I don’t know anybody in marketing. And then it’s going to be a cold call to marketing instead of, Oh yeah. I had coffee with that one person from marketing. Let me go follow up with them. So take the time to just meet with as many people as you can, that you’re going to be working with or in your extended cross-functional stakeholder group.

The other thing I think is be a team player, and let people know you’re a team player. That you’re not going to come in all arrogant and say, ‘here’s what we need to be doing. Here’s how we should be doing it.’ Even new CEOs, good CEOs, when they come into a new company, they listen first. They don’t just come in and say, ‘Oh, we’ve got to do it this way’ because the reality is you need to tailor techniques to the situation.

When I went into my first startup, as a product leader, I couldn’t just take the exact same process we did before at Intuit…I had to adapt it. So listen first, and then as you start to observe opportunities to make improvements, then you can start to say, Hey guys, what do you think about trying it this way?

You obviously need to get up to speed on the domain. There’s always your product management functional skills that you need to have, which in my opinion are most important. But then there’s your domain. For example, if you’re working in legal software, you’ve got to learn about legal software. Or you’re working in bug tracking software, you need to learn about bug tracking. So you need to get up to speed on the domain.

And then I think the biggest thing in the back of your mind is that you want to establish your credibility. You are the new kid on the block. Everyone’s looking at you and judging you. And so you, I hate to say it this way, you don’t want to be too risk averse, but you wanna avoid making any statements like, ‘Oh, we’ve got to do this.’

And then it turns out that you were completely wrong, and you just shot your credibility in the foot. You’re eventually going to have to make recommendations and calls. I’m not saying don’t, and just sit on the fence and waffle. But just make sure you know what you’re talking about when you do pick that first battle to fight, and then demonstrate your knowledge and how you can add value.

I think about baseball, and someone kind of catching the ball when it goes between the other people, you run and get the ball so it doesn’t slip through the cracks. Do that. And then people will be like, wow, that new PM, they’re stepping up and adding value. That’s how you earn credibility.

You’re not the CEO of your product. If you go in there, like I’m the CEO of the product guys, that’s not going to go well. That metaphor is okay, some people hate that metaphor, some people love that metaphor. But if you take it too far and take it literally, that’s not the case. What they mean is you need to be thinking full-scope about the product.

“Speaking of full-scope, how do you think PMs should balance having a general knowledge of everything about their product (design, data, etc), without being a micromanager? Where do you draw that line?”

The reality is, in some of my other talks I’ve talked about the set of skills it takes to really deliver a great product. It’s not just PM. You need PM, but you need interaction designers, you need visual designers, you need front-end coders, you need backend coders. There’s a lot of skills. There’s the saying that nature abhors a vacuum. And a good PM abhors a vacuum.

If there is some skill gap, (like QA, it’s not sexy to have QA teams anymore) it falls on the PM’s shoulders. So the good PMs will sense where the gaps are and fill the gaps.

Now that can end up leading to a long job description and then working tirelessly around the clock and things like that. So you want to try to, in the long run, figure out how you can invest in those things. But in the short run, you’re going to do it.

I also think a PM should embrace learning a fair bit about the adjacent functions, right? So if we think about dev, I see a lot of PMs saying, I’m going to go take a Java class. But you’re not going to be coding Java, that’s not what’s helpful. What’s helpful to know is, ‘is this a front-end change or a backend change?’ ‘Does this require a database change?’ Those kinds of things.

The way I figure out how much to get involved is how strong that person is on the team. If I have a rockstar designer on my team, then I’m going to say, great, I’m going to give them much more rope and let them do their thing. And I’ll step back and fill a bigger hole that exists on the team. If conversely, say we don’t have a designer on the team, then I’m going to have to step up and maybe do the wireframes and things like that. So it just depends on your team.

Thinking back to the micromanaging thing, again, people don’t report to you and you need to be careful on how much you’re directing versus what your credibility is like. What’s your currency, how much currency have you earned, to be able to say, you know what, I’m going to make a big deal out of this thing. I’m going to fall on my sword for this thing. I remember one time, there was a very specific thing I found, so I picked that as my battle for the quarter that I thought would make a big difference. And I used the gravitas and credibility.

The other thing is to let people try first. You can be a little too risk-averse and go, maybe the designer can’t handle those wireframes, so I’ll just do them to be safe. You’ve got to give people a shot first, so let them try and then see how they do. If they fail, then you can say, we have an issue here, and you can try to fill that gap. It’s tough but I think PMs should learn about the adjacent skills as much as they can. You should learn a little bit about marketing, you should learn a little bit about finance, a little bit about UX, a little bit about dev, a little bit about analytics. But it doesn’t mean you’re an expert in all those things.

And sometimes people hear that and they go, ‘Dan, you’re talking about like Superman or Superwoman PM who can know all those things.’ But you’re really just trying to make sure you’re knowledgeable enough to have meaningful conversations with those cross-functional partners. And so you can ask smart questions and add value.

Your job is like an orchestra conductor, right? That’s where this comes in. The UX person knows their world. The dev person knows their world. The analytics person knows their world. Who’s making sure all those worlds are united and make sense, and that they’re rowing in the same direction in concert? That’s the PM’s job. That’s why it’s helpful to know a lot of that stuff. Not for you to go do their job for them, you know? Again, you can pitch in and fill in if you’re in a situation where there’s a hole.

“When you’re an entry-level PM looking at your career options, it’s easy to think “now what?” You could stay in the weeds with the engineers, becoming a product specialist, or take on more of a people management role. Can you talk a little bit more about those different career levels?”

It’s funny because as you said when you start in your PM career, you’re an individual contributor. And then as you move up, depending on the size of your PM team, you might informally coach some other PMs, which means that they come and hit you up for questions. It’s ‘Hey Dan, you know what PRD templates should I use?’ and ‘I got this question or issue, what should I do?’ And you’re going to be a coach… And it’s not quite a formal manager, PMs don’t have a lot of management layers there. It’s not like a 20-to-1 fan-out ratio. We’re kind of like Jedi, you got one or two padawans max.

And that’s when you go from being an individual contributor to being a people manager for the first time. That can be a very difficult transition for a lot of people. It’s the same thing in the dev world. Imagine you’re a rock star developer. And your manager says ‘you’re doing such a good job, we’re going to make you a manager.’ And now you’ve gone from doing a hundred percent geeking out coding, doing brilliant stuff, to now having one-on-ones with all these people. You only get to code maybe 10% of the time. And then people realize, be careful what you wish for because your job just totally changed. In PM there’s this individual contributor track where you keep getting more and more senior experience, like you said, going up to the principal path and there’s a management path back on the PM side.

It can be a rough thing because I think a lot of successful PMs are like, ‘Hey, if you want it done right, do it yourself.’ They learn to minimize risk, and do a lot of things themselves. We want to try to delegate when we can, but PM’s become very self-sufficient. And so then when they become managers, they’re used to that self-sufficiency habit and just doing things themselves. So they might find themselves, for example, writing user stories and backlogs for someone on their team where they need to delegate that.  You’re never going to get out of that trap. You gotta basically figure it out.

Actually, I was just working with a client yesterday and the PM got promoted to the lead and they hired a junior PM. So the way they’re doing it is the experienced PM is handling the more complex, larger scale products. And then the junior PM is handling the less complex, less scope products. That’s a way to do it. And then they can manage and coach.

The other thing is, who taught you PM skills? Who taught you people management skills? You know, in corporate America, people get put in manager’s jobs all the time without any preparation or training. And it’s very different where in a sense that person is your product and you want to coach them. You have one-on-ones and we’re also busy executing. Who has time for one-on-ones? Who has time for growth and development discussions? But they’re really important. And that was another fortunate thing of working at Intuit – aside from learning amazing product management and marketing fundamentals and market research fundamentals, they just had good people management and general managers there.

We had goals, we had objectives, we had growth and development discussions, you know, and it was all tied together and related with one-on-ones. So part of it is that if you’ve never seen good people management in action, it can be hard to emulate. But it’s an important skill to pick up, and you can just measure it basically with your employee side and just like you have NPS for products, you can have, they call it EPO, the NPS employee net promoter score, right. How happy is your employee? As a manager, now your main job is to provide the whys for them. If there are obstacles or challenges in their way, to help them get past those obstacles and challenges, be a thought partner for them.

We’ll be back next week with even more of the latest insights from the Product Management world.