Cracking the PM Career with Jackie Bavaro
Cracking the PM Career with Jackie Bavaro
So you got a PM job, now what? What does success look like in product management? To answer that question, Maggie sat down with Jackie Bavaro, former Head of Product for Asana and author of Cracking the PM Interview, about her new book: Cracking the PM Career. While the specifics are unique to each company, Jackie outlines all the key skills PMs of all levels need to be successful. Trying to figure out how to get that next promotion? Check out this episode for details on how impact, scope, and autonomy are the real secrets to PM success.
Check out the book here: https://www.crackingthepmcareer.com/
Like this episode? Leave a ⭐️⭐️⭐️⭐️⭐️⭐️ review, hit the subscribe button, and share the pod with your friends! You can also connect with Maggie on Twitter @maggiecrowley
Maggie: Welcome to Build, this is Maggie. Today I have Jackie Bavaro on the show. She was the head of product at Asana. Before that, she was a PM at Google. And I know her as the author of Cracking the PM Interview and now a new book Cracking the PM Career. I used her first book to get my first job in product, so I was really excited to get Jackie's take on what she thinks success in the product management role looks like now, after I guess literally writing the book on it. And where she thinks the PM role is going over the next 10 years. I hope you enjoy it. Jackie, welcome to the show.
Jackie: Thanks for having me.
Maggie: Yes. I'm really excited to talk about the book, and to get into some specifics about the PM career. But where I want to start is, I'm curious what the original goal or the original audience was for the book. I spent some time going through it over the past week or so, and I couldn't decide if it was more useful to a PM charting their career or to a manager who's trying to mentor their PM. So who was the first audience that you started with?
Jackie: I'm thrilled that you noticed that. The goal that I set for this book is I wanted it to be the book that mentors recommend to the people that they mentor. And the reason for that, is that I wanted to make sure that the advice we give people in their career as they grow matches up with what their managers and mentors want from them. It wouldn't be any good to have a book that PMs love, but it turned out that it was all the wrong advice.
Maggie: Yeah. I love that. And it was super timely because we were working on updating our career ladders. And so it was helpful to go through skill by skill and think about, okay, well, what does this mean? What does this look like? I totally saw that. I'm also curious, of course, as you're going through this type of thing, you had to make some calls about what the right answer was for the PM role. And I know that that does vary widely company to company. So where in the book do you think that you've really gone out on a limb and pick the side? Or what do you think is going to cause the most discussion?
Jackie: Yeah, there's a few things in there that can be controversial. I come down a little bit against outcome based roadmaps. I come down slightly in favor of homework assignments. A lot of these, me and my co- author we negotiate exactly where to draw the line. For example, when is it appropriate to negotiate for a higher level, when you're interviewing at a company and when can that be risky? The one that I think is the most unique viewpoint that I've added in here is around career ladders. Is I come down on the side that most companies have career ladders that are unintentionally misleading. So a large company you'll join and they'll have this career ladder that says," This is what an APM looks like. This is what a PM1 looks like. This is what a senior PM looks like." And a lot of the times they will describe the skills, maybe common actions that a person at that level takes. And sometimes PMs will think, Oh, if I check off all those skills, I'll get promoted. And that's not how it works. And then other times those career ladders will be self- referential and describe the scope. They'll be like an APM owns a feature and a senior PM owns a feature area. And that also doesn't tell you what to do. The controversial point of view that I have here is that the reason those are misleading is because your skills as a product manager are not actually what determines your level. That as you want to advance, grow in your career, the skills are the ingredients, but you have to put them together and bake a nice cake out of them. Which means that you have to take all of those skills that you've mastered and bring them together to actually deliver impact autonomously. And so it really is about your scope, your impact in your autonomy that contributes to your advancing. And so that means that if you just pay attention to the career ladder, you might misunderstand which things are important or misunderstand the weight, or just misread the way that a particular line in the career guide, what it was meant to apply.
Maggie: Right. Yeah. And I felt that when I was going through this exercise to up day hours, that I wanted to make that clear and I added at the front of it. I basically just copied and pasted the contest and I credited you. The context on impact, autonomy and scope and clarifying what drives promotions versus what are the skills. But I still think in some sense, yes you need to have, grow your scope, become more autonomous, have more impact. Sometimes I think it can feel as a PM that you don't have control over what impact you can create because you get assigned to a team and you're not always in control of what opportunities come your way. So my take on it was, at a minimum, you can use this guide to understand what the skills are that you should have and the better you get at these skills, the more likely it is that you're going to be able to have that impact that you want to have.
Jackie: The fact that your impact is usually limited by the scope you're assigned. And to get a larger scope, you have to really earn credibility and earn people's trust, and show that you can deliver at whatever that scope is. Even if you set your sights very high, make sure you really nail the work that you're supposed to do, so that way you will get a chance to the next time to get a larger opportunity.
Maggie: Right. Yeah, and I also thought that being able to say, okay, here are the skills that you should have at each different level of PM that you are. And then also another thing that I did on ours was at least I went in and put some specific examples of what that might look like at Drift, or we know where I work. To try to bring it to life even further, because I think part of what is hard about it is. You can read that section or read a career ladder and it's okay, cool, I'm doing these things or I understand the words on this page, but what is that... Now I'm going to go talk to my team, where's the showing up in that conversation.
Jackie: Yeah, sounds great.
Maggie: So I want to go back to your point about outcome- based roadmaps because something I've been wrestling with a lot. And I've had Marty Cagan on the podcast in the past. We talked about creating empowered and autonomous product teams. But I also understand the reality of having an executive who's like, what am I going to get? What am I getting from this roadmap? So can you take me through your opinion on the outcome- based roadmap and why you ended where you ended?
Jackie: Yeah I'd love to. A lot of this comes with a context of how your team is set up. And for example, if you're at a big company or if you're at a start up. If you have founders and executives that are very involved in the strategy or very hands off in the strategy. So some of it depends on who is creating the roadmap and who are they handing it over to? If we take the point of view of somebody who is maybe a senior PM, who is setting their own roadmap and setting their own goals, and they're able to actually propose what goals they want to work in. That's the situation where I think a roadmap that combines outcomes and outputs works really well together. So the outcomes are sort of the goals, the things that you're trying to achieve. And for some teams, pure outcomes can make sense. So specifically for a team like a growth team or a monetization team, one of these. A team that focuses on optimizing, they might literally not know what projects and what growth experiments they're going to run over a quarter. And still, I think it helps the rest of the company, understand what their team's doing if they can add in a few examples or ideas of what work they might be doing. But for them, the thing their team is creating really is that like 5% lift in user engagement. And if you think about being the sales team or the customer success team, you might not really care whether they did that by rewriting the setup screens or by adding invite buttons everywhere or whatever the small changes they did were. When you think about other teams at the company, teams that are building new functionality, new features. If you're at a larger, even a small company, but you're at a company and you're working on a team where you need to work with lots of partner teams, it does actually matter to them what you're building. The details of what you build will affect the size of the team you need, the kinds of engineering resources you need. Do you need a front end engineer or a back end engineer? It will affect like you need to invest for future years. It'll affect things like sales targets. So if we say that we are building a feature, for example, if you have several pricing tiers. If you're building a feature for free users versus premium users versus enterprise users, the types of salespeople that your team hires ahead might change based on that. And the kinds of sales, financial targets that they set, which will affect the salary and the take home pay of all of the people on those teams. So to come to those teams and say," By the way, we're going to launch something that improves revenue by this much next year." Well, first of all, if you've got a sales team, the revenue increase does not come purely from product. It comes from this combination of product and sales working together. And it does matter to the sales team and the customer success team and all of these other and the marketing team. It matters to them what you're launching. So for example, of what you end up launching is a brand new feature with integrations and partnerships. The marketing team might want to do a large launch event for that. That might be the best way to get into the world and they need know in advance, that'll be happening. Whereas if they think that's what you're building, and instead what you do is an iteration on the current feature and then something that won't be newsworthy, that can send all of their plans astray.
Maggie: I totally get the point and it's interesting. It's one of those things that, when I'm reading the ethos behind outcome focused roadmaps, I totally understand it and I love it and it sounds awesome. But then, there are these moments that you're describing where when you put it up against reality, it just doesn't work that well. And it's honest, it doesn't feel as practical. And one of the things that I've tried to do is say, okay, here's the OKRs for the quarter. These are the KRs that we really want to hit, or we think are going to be the right things to focus on, or try to measure our success at. And here's an example of the themes or priorities that we already know about in the product. That's going to be where we're focusing that work to give people a sense of we're going to focus on this product or this area, and probably do these things. But I want to make sure the teams have room to decide that that's not the right thing based on what they learn from their research.
Jackie: Yes. Yeah. I think setting expectations for how set in stone, the plans are, is really important. And depending on the people at your company, sometimes they can understand those caveats where you say," Here's what we think we might do, but we might change our plans at any time." And some companies they'll be like, that's what you said you're going to do. I'm going to tell all of our customers and promise and write it into sales contracts. So in those cases, you might need to hold back some of the details, so you don't get overcommitted. But at many companies you can tell people that this is a chance of what you'll build. And I do think it is quite different if you're the person, if the person creating the roadmap is the person doing the work, I think you're in a different situation and I think that's one where it's good to talk about outcomes and outputs. If you are in a world where the head of product assigns the roadmap to other people, I think in that case it is good to find a way to emphasize to the team that they don't need to build the solution you wrote down as is. Sometimes the solution as is, is a metaphor or a stand in for the problem you want to solve. So we had this experience at Asana, where one of the things that customers asked for all the time was a Gantt chart. And they kept saying," Oh, we want a Gantt chart, we want a to Gantt chart." And so, sometimes in some of the early stages on our roadmaps, we would say, and we were pretty sure we weren't going to build a Gantt chart. We would say something like," We'll, build something that solves the customer need for a Gantt chart." So something like a Gantt chart, something that the outcome is that they'll stop asking for Gantt charts and they'll be happy. But the best way to describe what that might be was something like a Gantt chart. It was a little bit more output focused. And we were pretty clear that what we were going to do was going to be a new feature in the product rather than something like improvement to calendar view.
Maggie: Right. Part of what I've tried to do and learn to do in the past is to put a name around that area of work that you want to do. That hints at the type of thing you're going to build, or the problem that you're solving for it but doesn't, overcommit on this, how specific it has to be. And then that allows you to go to your other internal teams like sales or marketing and say, yeah, we're going to build X thing and they get it. They can work with it and they can plan for it, but it doesn't tell them exactly what the feature set is going to be.
Jackie: Yeah, that's great.
Maggie: So we're talking about roadmaps and one of the other areas that I was really excited about in the book is you dig into strategy and what that means and a lot of detail, which I love because that's definitely the thing I hear. It's one of the most requested topics for the podcast. Is what I hear from PMs all the time, I want to be more strategic, I want to do strategy. But what I've always heard from strategy is, you have your vision and your strategy, but you broke it into having a vision, a strategic framework and a roadmap. So we've been talking a little about roadmaps, but can you give me a little bit more detail on what the strategic framework is? And what's an example of it and maybe who is the person who's putting that together.
Jackie: If you're used to hearing vision and strategy, the strategic framework is probably what you might've been calling strategy before. I use the word strategy to encompass all three. And so when you take them together, the vision is your inspiring picture of what the future looks like. And your roadmap is your at a high rough level, your step- by- step plan of how you're going to get there. And I think of the strategic framework in a lot of ways as being the spec for your strategy. It's more of like, it's usually tends to be a document with bullet points and headers. Some of the things that it focuses on, one of the most important ones, is going to be, who's your target audience? Who's... what market are you trying to win? And then it can lay out your principles, your frameworks, your strategic bets, and just the details of what are the potential approaches that could have been, which one are we choosing and why? So, for example, when I worked with some people on a framework for the platform for a developer platform. One of the things that we had in our strategic framework was our approach for how we were going to prioritize work on the team. And the strategic bet that we made is that rather than going directly after small third party developers, we were going to focus on what we call second party developers. So developers at our customer. So people, if there was a customer and this whole company is using Asana, there are some engineers at that company who want to customize Asana to their own usage. So they're not building an add- on that they're going to sell to the rest of the world. They're building something for their own company usage. And we had a nice diagram in our document that showed how we would consider what the second party use cases were. And then think about what platform features did we need to enable those use cases. Then as like a third step, how could we turn those platform features into something that would work for third party developers? So there was a very specific prioritization framework and a philosophy for how we were going to approach it, prioritizing platform features and how they ought to be developed. What parts ought to be customizable, who our target audience was there. On top of that, we also in that strategic framework, laid out our portfolio, our roadmap portfolio bundle in there. So basically what percentage of our work did we want to have going towards second party features? And what percentage of our work did we want to go towards third- party features? So in that way, we could say, and I won't park towards a technical debt, which was the one that we thought was pretty important. Because there, I think one of these things that's pretty interesting is so many teams run into this roadmap trouble of... that is essentially, how do I prioritize apples against oranges? How do I prioritize revenue growth against user growth? How do I prioritize orange debt against new features, against iterations on current features? And what I've found is the best way to resolve those challenges is to think about, at a portfolio level, what percentage of your portfolio do you want towards each of those different goals? And if you keep that discussion, you bring all your stakeholders into the room and you say, should it be 50, 50 between these, should it be 30, 30, 30? How should we break it down? That can be a pretty productive conversation. You can usually get your team to agree to those breakdowns. And then you can discuss what are the top things in each of those buckets.
Maggie: Another way that I've thought about that or I've seen our teams do that is, having a really good conversation with your technical counterparts about what your expectations are for how your platform needs to scale over the next quarter, two quarters a year. What are these, bring them into the sales forecast, make sure they understand adoption patterns, because then I think if you empower the team and you say," This is what we're expecting. Let's scenario plan and figure out what might happen and how do we plan against it." I've also found that to be a good way to bake that into the plan even if you don't have a good allocation of budget between those two things.
Jackie: Yes, I love that. If you have technical debt, if technical debt can be tied closely to product features, then you can put them on the roadmap together, which works really well.
Maggie: Yeah. And another question I had was, it's the lines between the plan and the strategy get really blurry for me sometimes. Do you have any frameworks or rules that you use or rules of thumb that you help people use to understand the differences between those two things? Because I think there's examples that you can read about this. Three constraints that someone set that is a perfect strategic framework, but it's never quite as easy in my mind to do that in my own life, so I'm curious how you've helped people with that.
Jackie: Yeah. So when I write up a strategy, I'll usually have the one document that will then link to both the vision and the roadmap. And the vision usually at some point it gets turned into some presentation with fun illustrations and walks the person through a day in the life. And that's the thing you talk about at all hands. The strategic framework covers all of that middle area of the writing. And the roadmap, I also often include in that document, and that is really like, here's what the next quarter looks like. Here's next half of the year after that, the next year after that. And that roadmap is so important because that is how you advocate for resources for your vision. But yeah, in terms, when I say strategic framework, I am not directly referring to something like the Porter's five forces or anything like that. My belief is that a lot of the time, what you really do need to do is create the right framework for your team. And the way that I think about doing that is I think I'm preemptively answering the questions other people are going to bring to me. So if I know that one of the founders has a favorite feature that they really want to get onto the roadmap, and I don't think it's the right choice, I'll make sure that my strategic framework includes some principle or decision- making criteria that explains why that wouldn't make it onto the list.
Maggie: Got it. Yeah. That makes a ton of sense and I think I love that idea of thinking through what questions you're going to get or what constraints you already know, and using that to help guide the plan. I also think it's really easy, definitely myself included as a PM, looking at what I'm supposed to be doing. I mean I'm supposed to be writing a strategy and getting really caught up in what it is and what it isn't when really it doesn't. As long as it's useful to the team and it's helping your businessship, the right things that probably doesn't matter. Like did you do the roadmap the right way? So it's probably a reminder I need to keep for myself.
Jackie: Yeah. That's a great point because I think once you have something in writing or something created, now you can start sharing it with people and hearing their feedback and learning is this answering the questions you have? Are there other questions that you have? And that's exactly that it just has to serve, it has to answer the questions other people have and fill the role that they wanted to fill. And that can be different from person to person and team to team. So once you show it to them, you can be like," Hey, is this on track or is there anything missing that you think ought to be included." And then you'll find out exactly what your manager's view of a strategy is.
Maggie: Right. Yeah, I also think that it just depends highly on the personality of the people you're working with. But I also love when you have an early version of something like this and you take a really strong point of view on something that maybe someone else isn't expecting. And those are such great conversations if you share a first draft of, here's what I'm thinking for the year on this product. And this is my number one biggest insight, and this is what I think we have to focus on if that's a really aggressive stance. You can create really good conversations with that.
Maggie: Okay. So another part of the book that I wanted to talk about is another thing that I think is really important for PMs, but unlike strategy doesn't come up as much, or is I don't hear as much. And that's the intangibles about how PMs need to operate. So in particular, you included a bunch on personal mindset. So I'm curious why you did that and what the reason was for adding all that stuff in there?
Jackie: Yeah. So, one of the important things about product management is that just being great at product or execution or strategy is not enough to be a great PM. Product management is so much about the relationships you build, the way you influence without authority, the reputation you build and the way that you're able to facilitate teams working together well. So I wanted to make sure to really emphasize that.
Maggie: I don't think I've ever said this word out loud, but equanimity.
Jackie: Yeah, equanimity.
Maggie: Great. I think that's something that is so important. And I think over the past year with all the things that have been happening and people being remote or not remote or whatever, I think it really holds people up and gets in their way. So, is that something that you had experienced with PM's or yourself in the past that made you want to include that specifically?
Jackie: Yeah. So I first heard the word equanimity when I joined Asana. It was one of the company values and in parentheses they put chillness. Being a chill person. And so I hadn't really understood it that well at first. One of the reasons I included it was this experience I had as a PM, which was, I always want to be a really good PM, be the best PM for my team, really help my team as much as possible. There was one point in time when things got really hectic and really busy and really stressful. And I was like, I can do this, I'm not going to let anyone down. Okay. People can do a question on like you, okay, your question, here's your answer. Next person, your question, here's the answer. Oh God, I'm so busy, I'm so stressed. But yes, your answer here and your answer here. And finally, one of the designers pulled me aside and she said," Jackie, I can tell you're stressed. And it is not good for the rest of us." And it was a huge aha moment for me because I had thought that I was doing the right thing by pushing through my stress and not accepting any of my emotions. And I really had overlooked what impact that would have on my team and how they would feel seeing me so stressed. And that, maybe at that moment, the best thing I could do for my team was to go home and take a nap. And then I have coached other PMs that I've gotten to share that story with. Especially because so many PMs are ambitious high achievers and might even feel guilty for taking some time to themselves. So, I love the fact that sometimes the way to be the best PM is to take care of yourself.
Maggie: Yeah. I totally agree. And for me, it also shows up in other areas, not just managing my own reactions. I think there's definitely being aware of how you interact with different people on the team and what makes you successful or not and planning for that has been really useful for me. But then also remembering that everyone, sometimes you need to be the person who's just lightening the load a little bit. And you don't have to take it too seriously. And I always remind myself to try to have fun in the meetings that I'm in to make sure everyone knows that this is not do or die. We're working and it's important, but we can still be okay.
Jackie: Yeah. PM's often can get very focused on the thing right in front of them. But so much of the time that the most important thing as a PM is not to make the current project as successful as possible, but to make your entire team as successful as possible over the next two years. And that involves... sometimes it's okay to let a mistake happen, now. If that means that somebody is learning, if you gave somebody an opportunity and they learned from it. Or if it's just able to empower people and give them a chance to make their own mistakes and move forward.
Maggie: Yeah. I love that. We're getting close on time here and I want to make sure I have a couple of questions I want to ask you, just about the PM role in general. So it's come a long way. You obviously you wrote the Cracking the PM Interview book, which full disclosure I used to get several jobs. Now you have the second book, where do you see the PM role going? If you were to write the next edition, five, ten years from now, what do you think is going to be different about the job.
Jackie: Oh, great question. So, I expect the PM role to expand a lot over the next 10 years. For example right now, most product managers are in software tech companies, a few in hardware tech. But I think that as people start to see the value in the role and the value of product thinking, I think that many more companies will start to get a role that looks more like the tech product manager role. I could imagine it at various consumer goods companies and things like that. So I think that a lot of the future of PM ends up, I think back 10 years. I feel like the biggest change that I've seen in the PM role is around things like rapid prototyping and early validation. So A/ B testing for example, was not a big thing 10 years ago, and now is as a core part of many PM's jobs. So on that lines, I can imagine a lot of progress there. So for example, today, people can often do A/ B tests where the engineers write brand new code, or they might be able to do a usability test where they have a file from Figma. One of the things that's more on the cutting edge is how do you create those rapid prototype front ends that can still connect to the real code back ends? And that enables a new type of early validation because for a lot of products, you need to have real customer data or real back end data for your validation to be useful.
Maggie: Yeah. I think that's a really interesting take on it. I'm curious also to see how other parts of the role gets spun up into different new roles. I think sometimes in some companies that the PM role is super broad and I also wonder about like the specificity of our skills.
Jackie: I will be very happy in the future if there are many people who are something/ product manager, engineer/ product manager, founder/ product manager, designers/ product manager. I think that even small companies that don't have room for a full- time product manager could really benefit from that approach.
Maggie: Yep. Agree. Okay. So last question. What is the best career advice that you have ever received?
Jackie: The best career advice I ever received, was actually while I was researching the first book. My friend Fernando was telling me advice that he got from his manager which was, to always articulate your frameworks. What he meant by that is, if somebody comes to you and they have a question and they're like," Hey, should this button be blue or green?" It would be easy to be like blue and move on. But instead, if you articulate your framework. If you describe what's the thought process and the reasoning that went behind that decision, you're like," Oh, this is a primary call to action. And our primary call to actions, as you can see in our design guide is always blue. So it should be blue." It does a few things. One is it shows off the quality of your thought process, which can help you get advance. And it shows off the consistency behind your decisions. So if in a few weeks the design guidelines change and now the primary buttons are green, it'll make perfect sense why the button changed from blue to green and you won't look like some capricious PM who's always changing their mind. And third, is it empowers your team. Is that once you start articulating your frameworks, now the next time your engineer is building another dialog, they won't have to ask you what color the button should be because they understand the framework of how to make that decision.
Maggie: Love that advice. I've heard it, put it a different way, which is show don't tell. So as long as you're showing your reasoning as acting at the same thing that you just said, that you're going to be much more effective. I've always thought about it more in terms of, as a manager, giving feedback to people that I work with. Never just saying this is good or bad, but saying why and then if it's a spec, I will write a new paragraph as a comment just to show them like what I actually meant. I just think it's so important to be able to show your work in that way too. Awesome. Well, Jackie, thank you so much for coming on the show. I love the book. I'm really excited that I got to check it out and it's already been super helpful to me.
Jackie: Yeah. Thank you so much. My pleasure.