Mastering product strategy and growing as a PM | Maggie Crowley (Toast, Drift, TripAdvisor)

If you ever find yourself saying something like, that's not my job, that's probably a thing you should do. And you know what? It probably isn't your job and it probably is someone else's job and you can spend your life getting frustrated at that or you can just get over and get the work done. And people who are willing to just get the work done will move faster. Their products will be more successful and they probably aren't carrying around all that anger and crappy emotion because as a PM, for better or for worse, and maybe this is not how we all want it to be, but you're oftentimes the emotional center of the team and it's your job to keep people motivated, keep people excited, keep them bought into the project, and you just have to keep that optimism going and it's hard work and part of it can be just like, you know what? Let me take that on.

I'll do this thing. I'll hop on this sales call, I'll implement this with the customer. You just have to do whatever it takes. Today my guest is Maggie Crowley. Maggie is currently vice president of Product at Toast. Prior to this, she was VP and head of product at Charlie Health, senior director of product at Drift, director of product at BevSpot, a product manager at TripAdvisor. She's also got an MBA from Harvard Business School. She was also an Olympic speed skater, which is insane and incredibly cool. And in our conversation we discuss the three most common threads across the best product managers that she's worked with, hired and managed how to very tactically write out a product strategy to share with your team and manager why being data-driven is a red flag for product thinking. Why product content you find online can be dangerous. Her best advice for how to break into product management. Also,

the impact writing online has had on her career and so much more. Maggie is amazing. I'm excited for you to learn from her like I did. With that, I bring you Maggie Crowley after a short word from our sponsors. This episode is brought to you by Productroadmap.ai and ignition Productroadmap.ai is the first AI roadmapping suite. It helps ensure roadmaps drive revenue by instantly aligning product with your sales and marketing teams to capture upsell opportunities.

Built by early leaders from Rippling and Craft, it automatically identifies feature gaps from your CRM data and your customer conversations, adds them to shareable roadmaps, easily prioritized by revenue impact, and then seamlessly closes the loop with sales reps via targeted notifications when feature gaps are closed. As part of Ignition's broader go-to market operating system, Productroadmap.ai can also help create better handoffs and collaboration with product marketing teams by giving both teams the tools to research, plan, orchestrate and measure the process of building products and going to market. Packed with integrations, AI automation and communication tools. It's truly a one-stop shop for product and marketing to bring things from concept to launch.

To sign up, go to productroadmap.ai and use promo code Lenny to get 75% off your first year. This episode is brought to you by Composer, the AI powered trading platform now with retirement accounts, algorithmic trading has historically been reserved for the hedge fund elite. Now with Composer, you can automate your trading with a library of over 1,000 strategies that are easy to understand and tweak using an AI assistant and visual editor. Composer is the first ever algorithmic trading platform where you don't need any coding experience. It includes a full range of trading indicators for you to get creative and a Discord community of 2,500 traders to discuss your ideas with. Composer also has a powerful backtester to see the historical performance of your strategies and you can then invest with a single click. Once you invest, composer will automatically trade for you based on the logic of your strategy. With $1 billion in trading volume

and over 1 million trades executed Composer already has many big time investors using the platform regularly. Head to composer.trade and use the code Lenny for an extra week of free trial on your composer membership. That's composer.trade. Maggie, thank you so much for being

here. Welcome to the podcast. Thanks for having me. I'm super excited. You put out so much content across podcasts, blogs, tweets, I'm sure there's other things I haven't even seen. And so what I've done is I've scoured all of your content as much as I could to find topics that we could dig into in our conversation today. And I thought it'd be fun to start with how to become a successful product manager and what it takes to be a successful product manager, especially long-term in your career. You've worked with a bunch of PMs, you've hired a lot of PMs, you've managed a lot of PMs, and so I guess the question is just what are some common threads you've seen across the best product managers?

Yeah, it's an interesting question mostly because I've worked in startups, zero to one, scaling stage startups, enterprise, all that kind of stuff. And there's a lot of content out there I think on how those roles are different and how PMs are different across those different types of companies. But what I've seen is that there are some standard things that are the same across the role no matter whether you're a consumer, B2B or startup or a large company and in particular about what sets PMs apart from one another. And the things that I look for when I'm hiring or when I'm looking to promote people or when PMs stand out, even when you're not looking are three things.

First, I think the best PMs are really good at breaking things down and simplifying things. So, finding at any moment what is the really truly the only thing you need to do, especially in a big company, there are 8 million priorities, there's 700 OKRs, there's 25,000 projects you could work on, and teams will get bogged down in that complexity. Similarly speaking at a startup, you might think that it's easy to find the one thing to do, but at the same time there's so many fires that are happening and so many things you could do in such a world of opportunity that even just picking one and sticking with it is really difficult. And so the best PMs not only can find the one thing to work on, but they can stay with that one thing long enough to actually finish it. I think that's a really interesting point, because it sounds simple. Also, just this idea of simplifying, but I think there's so much up

there partly because within simplifying is prioritizing and you can almost boil down the job of the PM as they're just prioritizing and telling people what is next. And so I think that's a really powerful point you're making. Prioritization is a tough word because there's so much wrapped up in that and what it means to prioritize. And I've worked for people who wanted to understand the formula for prioritization and why this thing and how can you prove that this is the right thing to work on and not that thing. And then a week goes by and then they want to reevaluate the priority and they want to re-litigate the priority. And so it's so much more than just a moment in time deciding, but it's the ability to stay with it and to make sure that it continues to be the most important thing, that you finish it and actually see that it works and that you can get people to continue to stay excited and engaged in that project.

Because I think a lot of when we talk about product, it's like, oh, what should you build? What should you ship? But then you actually have to ship that and that can take a week, a month, three months, six months, a year. And so as a PM, your job is to stay on that and be the person who's beating that drum over and over again, and the best PMs are the ones who can do that and have the resilience and the energy to stay with it. Energy. That's a really important part of that.

I'm going to ask you how you suggest people get better at these things. So, either we can go into how you found you get better at simplifying or we go through all three and then we can come back, however you prefer. Let's just do all three really quick and then we can dig in. Sounds great. So, yeah, first one, simplifying. I think the second one has to do with this point about sticking with something and it's following up on results. So many people in the spec or the one pager or something will say, okay, here's the metric that I care about. Here's what I want to move. Awesome. Maybe they'll even write a SQL query, get a dashboard going, figure out what the number is today, that gets you some extra points, but the really, really good PMs remember to follow up. Because especially when you're in management, couple layers up in management, I'm not going to remember to follow up on that feature, but if a PM comes back to me and says,

"Hey, remember we did that thing, here's what happened." I can't tell you how rare that is and how many times as a leader you might have to ask for that and for the people you don't have to ask that of is one of the best things when I'm looking at PMs and it's easy. It's not hard to do that, especially if you've set up metric tracking or you know how to pull that information or you have somebody who can help you get that. It's pretty easy to do and it's really high value activity. And then the third thing, and I think maybe we'll talk about this later too, is that a phrase actually we were talking about David Cancel before we started carrying the water, and this was a big theme when I joined Drift, and this is about how you can't be a good PM if you're not willing to do the hard boring unglamorous work of customer support, sales, marketing, writing, copy, project management, you have to do that stuff. It's your job. No one else

is going to do it, because at the end of the day, you're responsible for outcomes and results. So, you're the person that has to do that, and if you're willing to do that work, that's what's going to make your product successful, which is what makes you successful.

It's such an interesting list because when you ask most people what you need to get better at to become a great product manager, it's always communication skills, collaboration skills, vision, strategy, and it feels like these are input metrics to what it's normally what people think about. Those things to me, communication, super important, analytical ability, really, really important. The ability to look at a, especially if you're doing something that has a user experience component, the ability to look at that and understand if it's going to work and build up intuition around that, also really important. Those are things that I would see as sort of basics of the role. These are the things that make you great at the role and strategy to me, and hopefully we'll talk about strategy in a bit. It's one tiny slice. You do a strategy, but it's 5% of the work that you do.

Yes, it's important because you want to get your strategy and you need to pick the right products, but at the end of the day, the person who has a good strategy will not be as successful as the PM who ships more stuff, gets more reps and has the ability to actually create impact. So, to me, you could be great at strategy, but if you're not good at this stuff and your stuff isn't getting out the door, you're never going to be that great at the job.

And impact is the other one. Everyone's always like, what makes a great PM? Oh, drive a lot of impact. And again- But they never say how. Right, exactly. It's like, cool, let's do a strategy, let's have impact. Then when I was starting off as a PM, I was hearing this advice and reading about it and I was sitting there saying, awesome, I want to create impact. And I'm looking at my job thinking, now what? Yeah, impact. Let's do it. Where is it? How do I find it? Someone help me.

I love it. Okay, so let's go back to these three and I'm curious just what you found helps you become better at these things and also just an example if you can share. So, say what's simplifying? How does one build that muscle? This is a tough one because some people, a broad generalization that I think comes up in things like when you're interviewing PMs for a job and you say things like are they a simplifier or are they complexifier? Do they make things complicated? And so some of it's a little bit of just who you are and how you think. But having said that, there's one tool that I use that I actually learned from my dad when I was in grade school, which is when you write something, for example, and a lot of what we do as PMs is written, when you write something, read it out loud, literally just read the thing you wrote out loud and half the time you'll realize it's way too complicated, it doesn't

make sense. Or what happens is when someone comes to me and they say, okay, I'm working on this thing, check it out, can you read it? I read it and then I put it down and I say, "What are you trying to say?" And 99% of the time they say, "Oh, users are really struggling with this problem. We found this in research and we think that the way to solve it's to do X", but that's not what the document says. And so my reaction is always, and if anyone who I've worked with is listening to this, they're going to laugh is always, "Just say that. Just say that thing. The thing that you said to me in conversation is the thing you should write."

There's no reason why your pros in a document has to be a certain way. We're not in school. Our goal is to get things done. So, those are just some simple tricks that I've used to help simplify what I've already been working on. And as for how to boil things down and really find the most important thing to do, which is another part of simplification, I think the best thing you can do is just get as many reps in as you can, have people review your work and listen to them. There's a thing that happens I think with PMs where you join a company and then all of a sudden it's like my boss doesn't know what they're doing and the highest paid person's opinion and the founder wants to swoop in and mess everything up, but those people had an insight on the market that you're in that made the company worth founding and they probably know more than you and so you might want to listen to them. And so find people who can review your work, listen

to them and ask them to help you simplify. I'll share a couple other things that came to mind as you were talking, because this is a very hard thing to teach and you kind of have to do it again and again and honestly, I have this one manager who taught me to simplify in my writing and strategy docs one-pagers and things like that, and I think that actually had a big impact on my newsletter success is learning just to strip down as much as you can and anything that isn't necessary. So, there's a couple things that I'll share real quick. One is there's this book I read called On Writing Well, that is one of the most impactful books for writing for me, and the whole book is like, I don't know, 20 chapters and every chapter is more things you should cut from your writing and they show all these examples of like, here's a before and here's an after.

And all these words were cut and nothing changed. They're completely necessary. So, I think that book can help and partly it's just like what is not necessary? You think all these adjectives are important. Another thing I found really helpful is the rule of thirds, I guess the rule of three, of just always having three. Try not to go beyond three when you're giving strategy bets or priorities or things like that. Just try to keep things under three.

Yeah, it's a very sort of business school ex-consultant point of view that I do agree with and share, which is there's always three things or fewer, never more than three things. You have to have a nice round couple and if you have a fourth, you've got to figure out how to squish it in there because it just doesn't look right if there's four. Agree. Yeah, even though I've been guilty of more than three, try hard to avoid it.

Yeah, you're using notion and you have your three bullets expanding and there's sub bullets, but at least you have that top line. That's right. The other thing is I think

that there's just a focus you need to get good at just like, people often want to lump together a bunch of ideas and then every time you do that it just dilutes everything. So, I think there's just a lot of power and pick the thing, pick the thing that's going to have the most impact and cut other stuff that may have some impact but is much less important. I think again, simplification is something and prioritization, which is sort of the same thing, gets tossed around a lot as a thing you have to get good at, but it's really challenging. Getting to the one thing you should do is extremely difficult and being able and having the gumption to say no to all those other things is really hard, because there's probably at any given time, 10 things you should do, but you can't do 10 things, you'll never be successful if you do that in a number of things. And so you have to pick one.

And so it's both figuring out how to get confident in your decision and then B, having the willingness, and maybe I should have added this to my what makes great PMs list, the willingness to make the bet and be responsible for it. And that's what I think separates the PM role from a lot of other roles and why it's such a challenging job when done right is because you have to be willing to take responsibility and it's your job to pick the thing and it's your job to be accountable to your team for picking the thing so you better get it right.

Ownership such an important part of just being a PM. Again, coming back to this interview I just did with an ex Amazon guy, that's one of their principles at Amazon is just leaders, basically ownership, feeling like you have ownership of what you're working on. I agree, but to me at least the word ownership doesn't have the same oh shit feeling as you're making a bet. You make a bet, that means you know that there's a chance that the thing you're working on is not going to work out and you still have to be the one to do the thing, jump off the ledge, drop in on the ski run. So, ownership to me never signaled that risk that I think comes with being a PM. Good point. On the simplify concept, it reminds me at Airbnb, one of the core values at Airbnb for time was simplify. Is this idea that we should always try to be simplifying, and then it turned out the founders realized we're not actually great at this and it's unfair for us to say this is a value for not doing it. So,

they actually cut it as a core value because their feeling was we shouldn't have aspirational values, we should reflect who we actually are, and they actually cut two different values to be more clear, even though they still want to simplify, they're just like, we're not actually good at this, so why are we pretending like we are. I think maybe I'm good at it on paper, but there's been many times where I've been in situations where things are not simple and you just have to keep fighting for it. Someone's trying to think about, okay,

I want to become better as a PM and I'm going to try to start simplifying. What are examples of simplifying? Is it reduce your email length? Is it one pager focus? What are these buckets of things? And then also if there's an example of something you've simplified that comes to mind On what to simplify and more specifics, I would say anything can be simplified and shortened. Maybe another way to say shorten it. Definitely emails. I read them sometimes don't love them.

Make them short. The Minto principle is something that I would recommend everyone do, which is put the headline, the full conclusion first and then you're supporting argument second. I have a newsletter post about that exact concept that people that I will link in the show notes that gives you- Fantastic. The Minto Pyramid principle. Yes, everyone should do that. A lot of new PMs fall into the trap of thinking that they should have some sort of buildup.

Don't do that. Just tell me whatever the thing is, everyone will thank you. Doing things like that, things like you said, limiting your strategy docs, your conclusions, your next steps to three things maximum. I would generally say a rule of thumb would be pretty much every doc you write, you can delete the first two paragraphs that you've written. You don't need them. My dad, again, to go back to my dad when I would write, and this sounds cruel, but I promise it wasn't. When I would write a paper for school, he would just, and this is we didn't really have computers, whatever, he would just take away the first page and he'd be like, just start here. He would go, "Everything on the first page is crapola, don't use it." And he wouldn't even read it, which would drive me crazy. He would just like, "Oh, it's crap. I don't care about that." So, I would do that

and then just get other people, there's probably somebody around you that's good and find people to edit your work and to look at it. I have a little Slack workspace that has three people in it, me and two other women who are product leaders, and we oftentimes send each other our work still and we say, "Hey, I'm struggling with this. Can you read it? Help me make it simpler. Can you help me fix this up?" And we do that for each other. So, find a peer maybe who's in a non-competitive space who can do that for you. I mean I still use those people to help me.

That is extremely cool. Can you talk more about this group that you have? Yeah, I don't know if it's a group. It's like three friends. Shout out Alexa and Daphne. Yeah, I mean the three of us all worked together when we were at Drift. We've stayed in touch and I've just found that in order to be good at your job continuously, you need people who can help give you feedback, and the more senior you get, the harder that is.

And so having people who can give you another point of view who maybe you can vent to if it's not appropriate as a leader who can give you other experiences that they're going through has been incredibly valuable. And so we just have a little group chat that is focused on product. That is so cool. Is there a tip you could share for someone that wants to create something like this? Is it important for you to have worked with them before? Is Slack a good way to communicate? Anything there that's just like, oh yeah, here's a cool tip.

Slack just worked for us where we are during the day, and I think having easy access to it was important. You could probably use WhatsApp or a literal group text. There are small community, there's one, I worked in healthcare for a year and a bit, and there's a Slack community that somebody organized for heads of products and healthcare startups that is similar to those really, really powerful and a really great space to be in. And so you just have to kind of suss out where these things are. You work with amazing people and there's people around you who are going to become your friends, and so keep an eye out for them and keep in touch with them when you leave a job because you never know when they might become your little Slack workspace.

Oh, I love it. Okay, I'm glad we talked on that. Okay, back on track. The second bucket you described as following up on results, is it just do that. Is there anything more you can add there? I put reminders in my calendar. I mean, yeah, it's just do that. But if you're launching a product, usually you release something and you have that initial push of a couple of weeks where you're finding bugs and you're maybe you're pulling metrics and everyone remembers it, then I would remember two weeks after that, a month after that, six months after that, put a reminder in your calendar to check your dashboard or check the metrics or check whatever it is that you were doing, and you won't forget and then share them with whoever might care about it. And it's as simple as that.

And is the reason this is one of the three things you think are most consistent across great PMs, that it helps your manager see you like, wow, Maggie's so on top of everything, or is it more that you learn from that experience and drive more impact or is it both? It's definitely both. I'm not going to pretend like if you're just great at your job quietly that you're going to get what you want. Just if you're toiling in the background, doing a great job getting results. If you have a great manager, maybe you'll be successful.

Great managers are few and far between, and I am of the opinion that I never wanted to rely on someone else to get what I wanted. And so I would always make sure to share that, always make sure to share my progress because I didn't want to leave it up to chance that someone would notice. So, I would suggest doing it for both reasons. And that's one of those things that people want to pretend that everything's perfect and we're all great and we're always going to get what we want and always going to get that promotion, but you have to work for it.

I love that point. It reminds me what I find one of the most important traits of a great product manager is they create this aura that they've got this, they put something on their plate and they're not going to drop it, that the threads are not going to be forgotten. And this connects to me there. They feel like Maggie's going to tell me what happened with this experiment. I don't have to think about it as a manager. Yeah, that's a really good point. And then you mentioned this a little bit ago, the side benefit is that you learn more. You will go back and learn why something happened or why it didn't happen, and the more that you follow up on what you've been doing and the more you learn, the better you get every time you ship something. To me, the other answer of what makes a great PM is family shipped a lot of stuff. The more you ship, the more you learn. And that's why it can take years to build up expertise because

you just have to ship a lot of stuff. There's a lot of people that are always frustrated. They're not getting promoted quickly enough as a PM. They're not moving off the ladder like, oh my god, I've been a PM for two years. I'm not a senior PM yet. Can you speak more to just that thought and just how long it takes to get actually good? I guess I'll share briefly in my experience, it took me four years to actually know what the hell I was doing as a PM and then things started to really take off. What's your experience?

I would say similarly, it took a lot of years to feel confident that I knew what I was doing. My first PM job was a product management rotation job at TripAdvisor. I had no PM background. It was after business school and I left those two years thinking, yeah, I've worked on four different teams over the two years. I've shipped all this stuff, I'm good. Went to a startup, there was another product person there, they left and I was the only product person at the startup. And I realized really quickly, I had no idea what I was doing. I had no one to learn from. I had only had two years of experience and I was not ready for that job. I didn't feel confident in the decisions I was making. That's why I joined Drift is because that team had all these really incredible product thinkers on it and they were shipping all sorts of stuff. They had all this momentum and I thought, okay, that's where I'm going to go to learn. And so then two more years. So, that's five years

until I really felt like I knew what I was doing. And that's because it takes a long time to ship stuff. And so to people who want to progress, you can progress by job hopping, you can progress by going in and out of startups. But to me staying at that, when I was at Drip, I was there for almost four years. I got to see two or three cycles of the same product and I learned more from that than I did out of the year or so I spent doing other things each at a time because you got to see the consequences of your decisions and that's rare. And people, myself included, of course you want to get promoted, of course you want to move up. I'm ambitious. Lots of people are ambitious, but for better or for worse, spending the time is really helpful and I think allowed me to move faster later because I had just spent the time grinding it out for a while in order to be better later.

So, is that advice you often give of go deep into a company or a product versus just bounce and track a bunch of different companies or depends? It depends. There are lots of really good reasons to bounce. I've done it, many people have done it, but I was surprised at how much I value that experience of having stuck around for a while and how much I learned from it was something I hadn't expected going into it, especially because you don't hear that point of view as much or as I wasn't hearing that point of view as much when I was thinking about the sort of arc of my career, but I'm glad that I did it. And then of course people always want to get promoted, always ask that question and my answer is always create impact and that can take time. At my first job, I was there for nine years and then I started a company for a year and a half and then we sold to Airbnb, and then I was at Airbnb for seven years. So, I'm very much on that train of just, not that I intended for that to happen,

but I definitely went deep and I think there's pros and cons, but there's so many pros to that, so many reasons. Okay. Let's talk about the last part, which is the third point you made,

which is carrying the water, I think is how you described it. Yeah. This one, there's no tips and tricks. It's just do the work. If you ever find yourself saying something like, that's not my job, that's probably a thing you should do. And you know what? It probably isn't your job and it probably is someone else's job and you can spend your life getting frustrated at that or you can just get over and get the work done.

And people who are willing to just get the work done will move faster, their products will be more successful and they probably aren't carrying around all that anger and crappy emotion. Because we touched on this earlier as a PM for better or for worse, and maybe this is not how we all want it to be, but you're oftentimes the emotional center of the team and it's your job to keep people motivated, keep people excited, keep them bought into the project, and you just have to keep that optimism going. And it's hard work. It's really hard work to stay positive and to keep people amped for that thing. And part of it can be just like, you know what?

Let me take that on. Let me grab that, whatever. I'll do this thing. I'll hop on this sales call, I'll implement this with the customer. You just have to do whatever it takes.

It reminds me of one of your lessons that you shared, in one of your podcast episodes. It was one of your PM lessons of 2021, and the lesson was, when in doubt it's your job as a PM, which I think relates very much to which it just shared. Can you speak to that? It might actually make sense to put this in the context of the other roles that are part of the team. So, as an engineer, your job is to write the code to really reduce this down and build the thing and make it work to spec. As a designer, maybe your job is to design the thing, design the solution, design the user experience. Obviously there's lots more complexity in that role. Design your amazing engineering, your amazing TLDR, caveat, whatever. But as a PM, you don't have that thing, right? It's not like, oh, my job is just to write the one-pager. That's not true. Your job isn't just to pick the problem. Your job is to deliver a business result. And so you're uniquely positioned to have to fill in all the

gaps because no one else is incentivized to do that. As an engineer, you can finish your work and hand it off and say, I did it, and the good ones care, but you don't have to care. As a PM, you're not going to do your job unless that problem gets solved for the customer or the user at the end of the day. And so your job is to make sure everything happens for that product. It reminds me of another interview you did where you talked about how a lot of the PM job sucks.

It's not as glamorous as people often think, and most of the job is these really boring, annoying things. I guess, is there anything you want to add there of just a lot of people want to get into PM, they're like, oh, I'm going to run the show. It's going to be so great. I'm going to be a product manager and tell people what to do. But that's not how it is. It's just one of those things that people, and when I joined product, it was just sort of becoming a cool job. It wasn't the hot job on campus when I was in business school. That was more private equity, venture capital. And now there's a sense of cachet around it. But again, it comes back to that earlier point, which is you do get to do cool stuff. You get to decide what gets built. That's cool. You have a lot of ownership like we talked about. You could see it as you have a lot of power, but at the same time you're responsible.

And so with that comes this responsibility to get it right, to make the right bets, ship the right products, get them out the door. And so there's a lot of bullshit work you have to do. Again, project management is one everyone hates on. QA is a really good one. You should QA your products. That's great if you have a QA team, you should QA them. You should know how they work. You should implement with your customers, you should be able to sell them, you should be able to find users. All that stuff is stuff that you should be able to do, and none of it is above you.

If someone is listening and they're not a PM and they are not convinced to not get into product manager, they still want to become a PM, what is your best advice for selling that is trying to get into product management of how to actually break into product management? I thought about this one a lot and I consulted the Slack workspace team. Because it's been a long time since I've tried to get into product. And so I didn't know what was going on these days because it's hard and I don't know if things have changed. I went to business school and that's how I got in. There was a program that took MBA students.

I think there are some entry-level programs out there, big tech companies, if you can get them, I think they're really hard to get because they're very few and far between. And so the most common two paths that I've seen are people who switched laterally within a company. Again, challenging but can be done. Or people who joined startups. So, when I was at my last startup, I did hire someone who was coming out of business school who hadn't been into product into a PM role. And I can't say I wouldn't do it because it was awesome and she was amazing, but it takes a lot of work.

The reason why people don't do it is because as a manager, it takes a lot of work because there's so much that these people need to learn. And what we ended up doing is she and I spent four months working together in a WeWork in person to help her onboard really quickly into the role, which was so rewarding. And I loved every second of it, and I wish I could do that again and again and again. But to get that, she basically just hounded me. Christina, if you're listening, you emailed me a lot. We talked a lot and we waited until the time was right and then you finally convinced me to do it. So, I don't know. I don't if there's a reliable path that I can say this is what my advice would be other than try a startup network. See what you can do.

And you've made up this point elsewhere, which I think is an additional key piece is once you have a PM title on your resume, everything gets easier. As a hiring manager, I'm just like, I look at a resume like, oh, they've never been a PM. This isn't the role. It's rarely that someone wants someone that's never been a PM. Yeah. And I tell people, I do unsurprisingly talk to lots of people who either are in product or want to be in product. And that's one of the things I always tell them because if they're deciding between roles and they have an opportunity to do something, and my advice is always, if you can get someone to stamp you with the product manager role, take it. Because to your point, it's what we screen on. It's for better or for worse, it's just like you have to get that first job. And then once you get that first job, it all gets easier. You can get in and then you can talk about your

experience because then the second question I have is, what have you shipped? So, it's like, have you been at PM before? What have you shipped? And it's fascinating how quickly people can't answer that question. And the people who can are always several steps ahead of the people.

Let's shift topics and talk about product strategy. Many people are told you need to get better product strategy. You're not great at strategy. A lot of people are also just confused, what is strategy? How do I get better at strategy? How do we describe a strategy? And you have a really great explanation and overview of how to think about this stuff. So, I'd love to hear your take on just how do you actually write out and describe a strategy.

Sure, yeah. And another thing that happens, and I'll give the outline, but another thing I hear, especially as you get further in your career, and unfortunately if you're maybe an underrepresented person in tech, is that you need to be more strategic. And so that's feedback that almost always happens, especially if you're a woman in product, in tech who's knocking at the door of a leadership role. You've probably gotten that feedback. And so I made it my mission to figure out what the heck is this thing? How do I do it? How can I do it in a way that is demonstrable so that I'm never getting that feedback that's like, oh, she's not strategic. And so what I did was something that I kind of did in the background because I had an engineer who I worked with who really wanted to understand why we were doing what we were doing, and he was not satisfied with sort of a surface level answer. And he was just pushing and pushing and pushing.

And so what I did was I just wrote out a Google doc and I started with like, okay, and not fancy, these are just bullets. What is the mission? What is the point of the company? What are our goals? Maybe we have some sort of high level framing of what we're working on. And then I had this big section that was just the landscape. And in that section I put in what's going on with our business? What's happening with our products? What's our point of view on the market? Who are our competitors? A SWOT analysis, key risks that we might be facing. Just dump that all on paper. Then what are the current quarters business goals or however you do planning, what are the current things that your company's working on? Then I put in, all right, that's sort of the context that we're operating in. Then I wanted to understand where are we. So what is an honest accounting of the current state of your product, the business overall, and then the

specific area that you're working in. What works, what doesn't work? What are your customers saying? Bottoms up feedback, users, customers, teams, what are your support tickets? Get that all out on paper. And then really importantly, where are your technical hurdles? What are the big pieces of tech debt? What are your engineering and technical teams always harping on that they want to invest in? Are there some big things coming down the pipe that you need to think about? Just get everything on paper. And then usually in the process of writing all that down, you'll start to see, okay, I kind of get where we are. I kind of get what the challenge is. And then you write a section that's like, what's the opportunity? From all of that, what's going to bubble up as the top one or two opportunities for your team? Where do you want to play? Where can you win? Where's the unique? Based on your unique competitive advantage, where do you think you all should

be and why? And then based on that opportunity, what are the challenges? So, what's going to be the hardest about taking advantage of that? What has to be, another way to frame it is what has to be true about the world for that to work? That's a one that's been helpful. And then what would you do? Take a swing at writing down your solution, what you would need to build, how might it work? Anything that you have, this is where I would say three bullets, maybe what you might want to do and then a plan. If no one else had an opinion, how would you go about it?

How would you sequence it? What would you do? How might you get the team to work on it? What would your team have to look like? How much would it cost to do it? All that you can start to layer in all that kind of stuff. And then I just share the doc. Share it with everybody. There should not be any secret. And you should be able to walk all the way from your company's mission down to the individual priority on your team and see the logic chain and why you got there. And if anyone doesn't agree with it, they can call out where their disagreement lands in that landscape.

But at least then you've put everything on paper, you understand how you got to where you're going, and then you can have an argument about the different pieces and points of data and feedback that you're getting, but at least people understand how you got where you got. And then it doesn't become like, I don't agree with you. It becomes, I don't agree with this point. This is such a cool way of doing it. By the way, is there a template that we can point people to that has this sort of- There's not, I've only ever done it in a loose Google doc and then it just grows and changes. I can maybe try to write up those bullets, but it's just like I just make headers and then I just start dumping content in it.

Yes, that's all people need. If you end up creating that before this comes out, we'll throw it in the show notes. And if not, people can just bother you on Twitter and ask Maggie, where's that template that we talked about? Yeah, I'm happy to write it on a piece of paper and take a photo of it and send it around. There you go. Just make it really grainy and an artifact. We found Maggie's template. This is awesome. So, I've never heard of a version

of this with so much depth into the landscape, and I think that's so smart because so much of conflict and disagreement comes from you just don't have the same information or the manager, exec or whatever doesn't think you have the information. So, if you just lean into, here's everything that I know and here's what's happening, and if you disagree with this goal, tell me, and then it'll change the plan. Right. And yeah. Part of it's also that typically speaking, when you're doing a strategy, you're doing it at a higher level. So, I don't think every product needs a strategy. Every feature doesn't need a strategy for example, you don't need to do this if you're working on a tiny slice of a product and you have user feedback, don't overcomplicate it, just do the stuff that makes sense. But especially as I've gotten more senior in my career, the questions are bigger and the impact is broader and the timelines are longer. And honestly,

it was also because I wanted to get it right. I didn't want to make a bet on something and put a bunch of resources against a problem and get it wrong. And so this was also homework that I wanted to do for myself to know that I was going to do the right thing. For some reason, I'm always paranoid that other people have more information or doing it better than I'm doing it. So, I was like, okay, I have to write it all down and then make sure I got it right and share it with everyone and make sure that they agreed with me so that I didn't screw this thing up. And it just was such a useful exercise that I kept doing it. And of course people don't read it. People only read a tiny section. You'll run into the same problems you run in with everything else, but at least I knew that I had done the work and if people cared to engage with it was there.

So, along those lines, I was going to actually ask, how long do you find this should be depending either on the timescale, say you're doing a quarterly strategy or a year, how many pages should this doc be as any guide? It's long. It gets real long. What is long? The actual content, I end up writing a summary to go back to the Minto principle. I end up doing the whole thing, then putting a summary at the top so that there's one, within the first, above the fold, if you will. You can kind of get the point and the suggestion on what I think we should do or what the strategy should be, should be customizable in that section. But it can go 20 pages just because if you really want to get deep in a competitor or there's interesting market dynamics, interesting technological changes that are happening. Sometimes I'm screenshotting other companies marketing websites and dumping that in there. And that might be some interesting comments. So, it doesn't have to just be words or

it can be all kinds of different things that you might want to put in there. And you made the point that it's not like you expect people to read this whole thing. There's the summary that gives them a conclusion and in theory if they want to really dig into it, they can. But I guess how do you find that balance of writing everything and making it so long that no one's ever going to read it to like this is actually going to be useful to someone and plus here's a summary. It comes back to the reason why I write the document in the first place. And that's for me. So, it's my homework to do my job effectively.

I just make sure to share it. And I find that my, especially my engineering and design counterparts, if you're working in a true triad, will almost always engage really deeply on the doc because they're pretty much also on the line and they want to make sure that when they sign their teams up to do whatever it is that they believe in the thing that you're working on. And so I find that those people will engage pretty deeply. Sometimes you'll have more junior folks on the team that'll just be interested and they'll get really into it too. And then there's some people that'll skim the upfront part and either say, yeah, that looks great, or You're dumb, I hate this. And okay, sure. There's always those people. So, it never really mattered to me that people read the whole thing. It was more I knew I had to do it to be confident in my own decisions and then I could facilitate a conversation, so it didn't really matter.

This episode is brought to you by Eppo. Eppo is a next generation A/B testing and feature management platform built by alumni of Airbnb and Snowflake for modern growth teams. Companies like Twitch, Miro, ClickUp and DraftKings rely on Eppo to power their experiments. Experimentation is increasingly essential for driving growth and for understanding the performance of new features. And Eppo helps you increase experimentation velocity while unlocking rigorous deep analysis in a way that no other commercial tool does. When I was at Airbnb, one of the things that I left most was our experimentation platform where I could set up experiments, easily, troubleshoot issues, and analyze performance all on my own. Eppo does all that and more with advanced statistical methods that can help you shave weeks off experiment time and accessible UI for diving deeper into performance and out of the box reporting that helps you avoid annoying prolonged

analytic cycles. Eppo also makes it easy for you to share experiment insights with your team, sparking new ideas for the A/B testing flywheel, Eppo powers experimentation across every use case, including product growth, machine learning, monetization, and email marketing. Check out Eppo at getepo.com/lenny and 10X your experiment velocity. That's getE-P-P-O.com/lenny. Is there an example of a strategy you were thinking about recently or that you worked on in the past just to give people something concrete of like here's what Maggie thinks of as a question she's going to develop a strategy around? Yeah, I think, obviously this is where product content gets really challenging because obviously I can't really talk about the stuff I'm currently working on. Just tell us all of the secrets.

And that [inaudible 00:45:38] know. The toast PR department would be really unhappy with me. It's questions like, if you're a director of product somewhere, maybe you're running a section of a business and it's annual planning. We're in Q4. What are you going to do next year? How do you answer that question? How do you back up your choices for that? You use a doc like this. Maybe you are realizing that the product that you're working on doesn't really matter, it's not really making an impact. You're kind of treading water. I would use this as a tool to figure out, okay, well what else could you do? So, yeah, quarterly planning, annual planning. If you feel like your team needs to make a pivot or if you think that there's a really interesting new opportunity that your business or your team should go after, is another time I might use something like this. Awesome. This reminds me a little bit of,

I keep mentioning this chat with Bill Carr that I had who is an early Amazon exec and how the narrative approach at Amazon, one of the benefits of that and the reasons they go there is partly for you to realize this is a bad idea before anyone even needs to give you feedback. And that's why they force you to write six pages in depth about your idea and then it goes in these concentric circles through the company. And idea is like, here's okay, and this is just not a good idea. Here's all the reasons why. So, I think there's a lot of similarities there.

Yeah, there are many, many times when if you combine this artifact and process with the point about simplification where through that process you just start cutting so many things because then what happens is, let's say you've gone through this exercise and you're like, okay, I know exactly what my three things are that I want to work on. Then there's a moment where you take the strategy and then you look at your roadmap and they're never the same. And the roadmap is just bloated with all of this random stuff that like, oh, well, we have to do that because of this, or we have to do that because of that. This thing we're still working on, this is like six months delayed, so we're still going to do the thing. And then all of a sudden you've got 90% of your resources committed to things that don't track against your strategy.

And it's a really interesting moment as a leader especially to sit there and go, well, what do we do? What do you do when you have that problem? And especially if you're a PM, you probably don't have the agency to say, scrap the entire roadmap and work on my new strategy. But at least it allows you to think about critically about whether you should be doing what you're doing and allows you to evaluate whether those things are still the most important things to work on.

I'm going to summarize the template real quick, and then I'm going to have another question kind of along the lines. So, if you're trying to create your own little template, you start with the mission of the business, and then I imagine you also share the mission of your team because oftentimes it's a little more specific, if you're working on it like a product team strategy. Then there's a landscape of what's happening. So, you include competitive, SWOT analysis of competition risks, product state, business state, things like that.

And then you share the current goals of what you're trying to achieve as a team slash business. And there's an account, honest accounting of what's happening in the product and technical hurdles and things like that that'll keep you from moving, I guess, achieving some of these goals. And then you share, here's the opportunity I see, how we win and how we actually achieve this opportunity where we place bets and things like that, or we could place bets. Then challenges of doing this, what needs to be true for this to be possible? And then you finally get to, here's what I think we should do, essentially the solution, ideally three bullet points, and then the plan. And I imagine the plan is step one, get sign off from exec. Step two, resource the team. Step three, start on this design research sprint.

Pretty much. Awesome. All right. Amazing. Somebody will create this template if you don't end up doing it. Yeah. There's another- I hope somebody does. Okay. That'd be awesome. If they do, I will tweet it and we put it in the show notes. Great. So many promises already from this podcast. Along the same lines, you also have a one-pager template and process that I think people find really useful. So, how about we chat about that one briefly and then I'm going to go in a whole different direction. Okay. Yeah, I don't think I have much to say about this. That has not been said by many people many times, but whether it's a spec, a PRD, a one pager, I don't even know what else people call it. It's the document that you use to define the thing that you're doing as a product team, and that means product design, engineering, your little squad. And what I think is really useful about this process is that it's the PM's

artifact. So, designers produce designs, engineers write code. What do PMs do? A lot of people might say nothing. In theory, we write at least this document and it can be a pain. I've seen lots of ways where it hasn't been done very well, but when I think it's done really well and when it's really effective is it's a tool that allows the PM to start with why. And if you structure it correctly, the most important section in my opinion in the document is the first part, which is like what is the background and context? What is the problem, why does it matter and why does it matter now? And if you get those things right, the rest gets really easy, but it gives you a chance as a PM to center the team around the problem, why that problem exists, whether it's created by your own product or it's something the user is experiencing and why that problem is worth solving. That's a part that I think people sometimes forget to think about and

why it's we're solving right now versus all the other problems you could be solving and then it can become the home base of the decisions that you make along the way. So, I think it's best when you have those sections and then also best when you write down on this day, we made this decision or we decided not to do this or we decided only to solve this part of the problem, not this part of the problem. Keeping a running list of that and a link off to all the different artifacts and research and things is helpful for a team. So, just to summarize, what would be the headings again, just if someone's taking notes and wants to create the rule template?

I don't think these templates have to be really complicated. It's like background and context. The problem. I would literally write why this problem matters and why this problem matters now. Don't make it complicated, just answer those questions and if you can do that, and then again, it's only really helpful if then you bring that document before you go any further to your team and you use it to have a conversation and you get the smart people around you to take shots at it. I should have mentioned this earlier with the strategy. The first person I go to is typically speaking my engineering counterpart and I say, shred this, go through it, rip it apart, vomit comments on it, tear this down how it gets better. And as a PM you can't be precious about your work. You need people to poke holes in it. The why this matters now point is so interesting.

I don't often hear that and I think it's such an important part of specs and plans and strategies because there's so many things you can do and there's certain things that are perishable that you can only do now. That if you don't do now you miss up the opportunity. And so I think that's a really interesting element that most people don't include and it reminds me of, I think I've done enough podcast episodes now where I'm just connecting all these things as people are talking. [inaudible 00:53:16] the John Nash thing happening where Karri, the founder of Linear talked about this concept of side quests as a founder. Because he's so good at staying focused and I was just like, "How do you stay focused and just get stuff done when you have so many people coming out?" He's just like, "There's the main quest and then there's the side quests and side quest I don't need to do right now. There's the main quest which is

build up really successful business." And I feel like this is a good example of that in action. Yeah, I love his take on quality and taste too. Yeah. What a gem. Yeah, big fan of that. But yeah, I mean it's really hard to stay disciplined, it's hard to stay focused and to your point, there's a million things you could do at any given time, especially if you work at a bigger company. And so the why now is an important question to answer because if not, somebody's going to ask you. So, you may as well think about it.

Yeah, it's interesting why now comes up a lot in investing in startups but rarely in product building and it feels like it should. Although I will say in the research I've done, why now ends up not being that important for startups being successful or not. So, I think there's a two sides to that coin. Anyway, I'm going to move on to a different topic and this

might become a new thing that we do and I'm going to call it contrarian corner. I asked you if you have contrarian opinions about things before we started recording this episode and you had some really good ones. So, there's a couple topics I'm going to chat about and we'll see if this becomes a recurring theme and you're laughing and nodding your head, what are you thinking as I say this? I'm thinking about when I had a podcast, you would do a show on a topic and we would click the end recording button and then every single guest would be like, I had no idea what I was doing. I made it all up, it was waterfall. None of that matters. I didn't know what I was ... People would say the wildest stuff and I would sit there as a PM and just think what. We just talked about this framework, we just talked about this thing and that's how you're supposed to do it. And then they would get off the official part and just say, yeah, it's wild. Nothing goes

the way you want it to go. We're all just kind of making it up as we go. And so I hope that you get more of those takes in this part of the show. I'm very sensitive to that point right now because someone just tweeted about how they're just finding that many of my newsletter posts about how companies write product are the ideal version of what they do and I rarely or they rarely share, here's all the challenges we're having, which I think there's truth to that, but I also get into a lot of failures on this podcast. Actually, I think the podcast is a lot more of just here's things that go wrong versus the newsletter. So, I'm just like shit, I need to do more of that. So, I love that you mentioned that and let's see what we can get into.

But I guess maybe before we get there, is there an example of something that didn't go just along the lines of some sort of failure slash mistake?