Coffee with Jackie Bavaro
This week, we’re getting coffee with Jackie Bavaro. Jackie is a PM at Asana and the co-author of Cracking the PM Interview.
It’s likely that you’re familiar with Jackie’s blog, The Art of Product Management, which inspired “Cracking the PM Interview”, and an incredible resource for PM’s.
How did you get into product management?
I went to college wanting to do something where I combined software with something else in the world.
I studied Computer Science and Economics at Cornell, and always imagined working at some traditional company with this superpower of knowing Computer Science. While I was at college, one of my friends was an intern on the PM program at Microsoft. He was like “Jackie! You should apply to be a PM at Microsoft”. I’d never heard of product management and was like “It’s got the word manager in the title — I‘m a sophomore — I can’t be a manager!”
I showed up to the first interview and figured out through the interview what a PM does. I got that internship knowing nothing about product management. After my internship, I came back for another summer and then joined that team full-time.
That painful experience helped me understand the implications of the decisions you make as a PM.
How did Microsoft lead to where you are today?
The biggest changes in my career have been more serendipitous than planned. I was in Seattle at Microsoft — I loved my job, loved my team but my partner and family were in New York. I had a choice to make: do I stay in Seattle or move to New York and give my relationship a chance? I gave it chance and moved there — we’re married now so the chance paid off!
When I came to New York, Microsoft didn’t have any product jobs so I went into Microsoft consulting services. That was really interesting — I had built a product and now I had to be on the other side helping customers deploy it. I got to be face-to-face with the bad decisions I’d made! That painful experience helped me understand the implications of the decisions you make as a PM.
The big thing I learned there — as a brand new PM — is that I had built features with the mindset of “This is the way the world should work and if you use our product this way, everything will be well”. When I went to customers, I learned that they have a way they want the world to work. They’re looking at all the tools and asking “Which is going to get me the closest to that?”
They would pick our tool, bring it over and say “Let me customize, let me change it” — they’d tear it apart, do things you’re never supposed to do with it to make it try and fit the thing they wanted.
Realizing that people weren’t going to adapt to your tool, and that your tool had to adapt to them was a really great learning.
After a year and a half, I wanted to get back into product so I switched to Google in New York, and ended up moving to San Francisco. When I had been at Google for 3 years, someone I used to work with at Microsoft reached out saying “Hey, I’m at this company, it’s really great, we’ve got a great team and we’re building something really cool”. That was Asana.
My mindset was “Get out of my way people, I’ve got a plan, I’ve got stuff to do!”
What are the key lessons you’ve learned so far?
On collaboration
On a personal level, I’ve learned to be a lot more collaborative. I came to Asana thinking about the product and all the different things we were going to do. I put together a plan, then people would come to me with an idea and I’d say “No, we’re not doing that.”
One day someone came to me and said “Jackie, when you say no, you might be right but it makes people feel shut down, which isn’t a good feeling for a team, and you’re missing the point of what they’re saying.”
That was really good feedback to hear — I worked with a coach and learned that when someone comes to you asking for a feature, you don’t have to say “Yes, I’m going to build that feature” or “No, I’m not going to build that feature”, you can say “Let me understand what problem you’re trying to solve. Yes, I agree with that problem!”
Going back to the “No” — at the time it came from having done a lot of work on a roadmap, and being protective of my time. I had this feeling of not wanting to get into a big discussion. My mindset was “Get out of my way people, I’ve got a plan, I’ve got stuff to do!”. I realized that the protectiveness of my time was coming at the cost of us being a cohesive team.
It was really hard to switch away from saying no all the time. My coach challenged me — for a week — to say “Yes” and then figure out what the next sentence is. It made a difference really quickly. I started to realize that there’s a lot you can start off saying yes to.
On working with designers
I’ve gone through a variety of ways of working with designers. At Microsoft, we had very few designers, they sat in another building and they came in at the end to make things “pretty”.
When I went to Google, I expected the same thing — I would plan it all out and not understand why the designer would say I was stepping on her toes. I really didn’t get it at all and then my boss said, “You need to bring your designers problems not solutions”. That was a big switch.
On reducing scope
Related to that, I’ve become better at scoping over time. At Microsoft, we were told “If you’re working weekends, you’re doing stuff you don’t need to do — figure out what your team doesn’t need to do.”
I used to cut scope by having a big list of all the things we might do, figuring out the bottom 10% — the least valuable — and cutting it. That’s a way to cut scope but a lot of the time you end up cutting the polish and delight, which results in a product that doesn’t generate user love.
At Asana, I’ve learned to achieve tight scoping by scoping our goals. Rather than trying to achieve a great product for every single use case in the world, we pick one targeted use case and make sure that what we’re building works really well for them. That allows us to scope in delight.
I thought that if I’m willing to tell it to one person, then I should be willing to tell it to everybody. And if I’m not then that’s a sign that I’m giving away something that’s too secretive.
Do you have any habits that have helped you to be successful?
Yes! I use Asana for everything — that grew out of the book “Getting Things Done”, which is an incredibly valuable book.
When I started as a new PM, I quickly had five teams I was responsible for. Trying to remember all the different things I was supposed to do each day, for each of them was really difficult. I was mainly working out of my email inbox and just trying to keep on top of it. There was a lot that I didn’t have time to get to — it was a huge mess.
Reading “Getting Things Done”, I took away 2 things: 1) write everything down so your brain isn’t constantly worrying about what you’re forgetting, and 2) if a task comes in that’s really quick to do, do it; otherwise decide when you’re going to do it.
Doing that, I started becoming a lot more responsive. I noticed really quickly that it made a big difference to how I worked with my teammates — people would ask me more questions, come to me for more things, even people from other teams. As someone in their first year of PM’ing, it helped me gain credibility on the team because I was so available. That reinforced wanting to keep that up.
As I’ve grown, I try to see the managerial relationship as two different people with different roles and areas of expertise.
How did “Cracking the PM Interview” come about?
When I was at Google, I interviewed a lot — over 100 people. Friends would ask me to speak to friends who wanted to apply for a PM role. I’d tell them a bit about what we were looking for in the interview, and share things that didn’t feel confidential but that would help them understand why we ask particular questions.
Then I learnt about network effects and how they hurt diversity. If I have a network made up of people that are a lot like me, and I am willing to share all the “secrets” with the people that are a lot like me, then those people have a huge step up to get this job compared to people who aren’t in my network. That felt really unfair. I thought about the best way to combat that and so started blogging about it. I thought that if I’m willing to tell it to one person, then I should be willing to tell it to everybody. And if I’m not then that’s a sign that I’m giving away something that’s too secretive.
At first I had this fear that if you tell people what you’re looking for in these questions, it’s going to break the questions — now that people know what you want, they have the answer key — and you end up hiring terrible people.
That doesn’t happen. It turns out that by explaining what you’re looking for and what structure you’re going through, it gets people to the point much faster and you can still tell if people have the things you’re looking for. I kept blogging and then Gayle, who wrote “Cracking the Coding Interview” saw my posts and contacted me.
Great product managers are there to fill the white space.
What advice would you give yourself if you were starting out today?
There’s something I’ve done more and more as I’ve gone through my career, which I wish I had done more when I was younger — I’ve started treating my manager as a peer.
When I started, I was like “Okay, my manager has all the answers. They’ve hired me because they can’t do it all, and so all I need to do is absorb all the answers from them so I can say the same answers”. That view creates a huge power and expectation dynamic.
As I’ve grown, I try to see the managerial relationship as two different people with different roles and areas of expertise. My job is to become the expert in the thing that I’m doing. It’s not that I’m this small person, doing this small thing and my boss is going to make all the calls. It’s my responsibility to come with everything (proposals etc), share it, and ask for feedback.
That changes what I ask for. For example, in 1–1s I’ll be like “Hey, here’s this cool strategic plan, let me show this to you.” as opposed to “How do I do this?”. When you’re new there is a lot of “How do I do this?” but quite quickly you get to a point where your manager doesn’t know how to do it either and you’ve got to figure it out together.
What do you consider the traits of a great PM?
Great product managers are there to fill the white space. Teams are all different shapes and sizes — some of them have designers, user researchers, engineers, and sales people so the white space to fill is very narrow. Then you have teams with just one engineer so you have to fill a lot of white space. This means the traits of a great PM can change a lot from team to team.
It’s important to be willing to fill the white space, and be curious and brave enough to figure out the white space.
I think the best PM’s take inspiration from the rest of the world and bring it in.
What books do you recommend to PM’s?
- My book! “Cracking the PM Interview” — it covers both getting a job in product management, and how to advance your career.
- “Getting Things Done”
- “The Design of Everyday Things”
There’s only so much reading you want to do about product management — I think the best PM’s take inspiration from the rest of the world and bring it in. I read all kinds of books on science, psychology, and politics.
Reading something that you’re interested in that seems as far away as possible from product management will give you this extra perspective — you’ll be able to draw these connections and pull these things into your product.
I left coffee with Jackie setting myself a challenge — to say “Yes!” and then figure out the next sentence this week. And to practice Jackie’s tips from “Getting Things Done”. Thanks for grabbing coffee, Jackie!
Are you setting yourself a challenge for this week? I’d love to hear below, on Twitter, or over email :)
FYI — Asana is hiring generalist PM’s — head to asana.com/jobs to apply. Pro tip: read Jackie’s book beforehand ;)
‘Coffee with’ is all about learning from badass women. If you enjoyed this interview, it would make my day if you share it with others that might too.
The next Coffee with will be published next Wednesday. In the meantime, learn from Merci Grace, Anna Marie Clifton, Cara Meverden, Jessica Barnett, Ellen Chisa, and Suzie Prince here.
