**Welcome to today's episode of the Product Growth Podcast!**

I'm really excited to have somebody whose content I've been reading for years. I'm sure you have too—Melissa Perry. Thanks for being here!

**Melissa:** Thanks for having me!

So, because the book has been out for a couple of years, can you define for us what is the build trap?

**Melissa:** Yeah, definitely! The build trap is a scary place—spooky! Where it's right before Halloween here, so we'll be spooky about it. It's where organizations are building and building and building, but they never stop to think about whether they are building the right thing for their customers.

You notice it a lot in organizations where they'll focus on a laundry list of features they want to release, but they're never connecting it back to the outcomes. They're never asking, "Is this really solving a problem for our customers?" I think all organizations end up in the build trap at one point or another. If you end up there too early as a startup, you fail; you will not succeed. But large organizations can spend years there because they just have enough cash to burn.

**Interviewer:** So, is the build trap the same as the feature factory? Is there a difference we should know about or a nuance there?

**Melissa:** Yeah, John Cutler coined the term "feature factory." I think about them similarly, and we talk all the time about this. The feature factory is part of how a company operates. I believe the build trap is more like a moment in time for a company. You could be stuck in the build trap but get out of it. If you're a feature factory and you never want to turn away from being a feature factory, I think you're stuck in there forever. Both of these things you can get out of; it just takes some willingness to try.

**Interviewer:** Okay, and what are the biggest elements? Let's say somebody wants to work with you and they say, "Okay, help us get out of the build trap." How are you going to approach that kind of sequentially to help them?

**Melissa:** The first thing I look at is whether we are actually solving the right problems for our customers. Do we have any idea of what those are? Sometimes organizations knew about it at one point and they started building towards them, but as they went through rapid growth, all the customers were requesting features. They didn't come up with a process to really say, "Hey, actually, let's sift through this and make sure that we want to double down and prioritize on the stuff that really matters."

Instead, they'll be bending to the whims of the largest customers and the people yelling. They're worried about churn, of course, of these big accounts, and they'll just kind of turn into this waiter mode of, "You know, take everything in; it's customer feedback, so let's just go build it."

So, one thing that we do is take a step back and say, "Who are our customers today?" It could have been somebody else before, but who are our customers today? Do we still want to go after those customers? If so, what are the biggest problems that we could be solving for them? That needs to start at an organizational level, you know, from the suite, really understanding where they want to place their bets and how they want to prioritize. But also at a product manager level, where they are looking at everything they're building and able to connect it back to the why of the whole organization.

When I first started working with companies, it depends on where they are. It could be that they're going through a gigantic transformation. I work with a lot of Fortune 50 companies that are doing digital transformations. In their case, they usually reorganized into agile teams. They've got a bunch of product people or product owners or people acting like product people. They don't know what to do with them, but there is usually a huge gap in the C-suite about product management and then also all the way down to the teams.

So, there's no product strategy behind everything. It's more like, "Hey, we just want to cut costs and build software," and that's usually where a lot of them start. In those cases, I come in and usually work with the executive teams. They are trying to figure out why they're not producing results. They're like, "Hey, we're investing in software; what are we getting for it?" That usually starts that conversation.

Then I show them, "Hey, you actually need a product strategy. Product management is a discipline; it's a role as well. There are many levels to it." So, we need an executive product leader, and we need VPs of product, and they are doing these different things when it comes to strategy and helping to deploy that down to the teams so they can figure out what solutions to build.

We can't just look at the teams and say innovate; it doesn't work that way. With that, we usually go into looking at product strategy, defining roles, training the product managers, making sure that we have the right team structures, the right people in the organization, and getting the product operations set up so that it can scale. There's a lot to it, and usually when you're doing a digital transformation like that, it takes many, many years. It's not just, "Oh, this year we'll do product." It doesn't work that way.

**Interviewer:** This episode is brought to you by Interpret. Interpret unifies all your customer interactions from Gong calls to ZenDesk tickets to Twitter threads and App Store reviews, making them available for comprehensive analysis. As we've profiled in the newsletter, it's the trusted choice of product organizations like Canva, Notion, and Descript. They rely on Interpret to drive forward their voice of customer programs.

What makes Interpret special is its ability to:

1. Build customer-specific AI models that provide more accurate categorization.

2. Connect customer feedback directly to revenue impact so you can prioritize confidently.

3. Uncover insights with their Wisdom AI co-pilot, so you have an intuitive chat interface to access your data.

So, if you want a custom model built for your organization, get in touch with the team at interpret.com/productgrowth. That's interpret.com/productgrowth.

**Melissa:** So, that is usually the route that those companies come to from product management. But then you also have your growth stage scale-up companies, and they usually go through this inflection of the build trap as well. As a smaller startup with one product line, they found product-market fit and they start scaling really rapidly, but they never put into place a robust product management system so that they could keep up with the feedback, monitor where they are, and make sure that they could make strategic decisions quickly.

Usually, they get to a point around like 20 to 50 million in ARR. They're growing like crazy, and they've hit this part where they want to go into multi-products. They're like, "How do I do that? How do I expand into my next product?" When you ask that question, it comes back to, "What are we doing now? How are we investing? Where's that focus?"

With them, we're usually introducing the concept of a CPO to help bring that together. A lot of times, especially with VC-backed companies in those phases, it's about connecting that product strategy back to the outcomes we want to achieve on the timeline we want to achieve, to show that this product roadmap and this portfolio is going to reach our growth goals in this amount of time.

There's a lot more in there. Those companies typically have a bunch of really good individual contributor product managers and a founder with a lot of product sense. It's more about how do we do product strategy at scale? How do we do it from a financially backed objective as well? How do we make sure we tie that back into the outcomes we want to achieve? How do we deploy that? And then how do we start building the infrastructure to make sure that we can measure things at scale?

A lot of these companies come back to, "Can we measure that we're doing the right things? Do we know that we're doing the right things? Do we understand our customers? Do we understand their problems? Are we placing those right bets?"

**Interviewer:** Okay, so there were so many different elements in there. I want to break down first the one that you mentioned in the definition, which was this focus on outcomes instead of outputs. I think this is probably the one element of all those stools that I feel like the pendulum is starting to almost swing in the other direction again, especially with founder mode. Especially with a lot more teams thinking, "Okay, we know what to build." Actually, we don't want our PMs to own outcomes; we want the executives and people who might have a better vantage point of business strategy to still help define some of the outputs, and the PMs will be accountable for what outcome we think will come for those outputs. But we're going to be a little bit more dictatorial, a little bit more founder mode about the release. How do you think about that? Is that one of the principles that is a little bit more flexible?

**Melissa:** I hate founder mode. I think it's so misguided in the way that it's explained. I think founders are special people who understand risk and they can find product-market fit. But companies go through different phases of growth, and just because you're really good at going from zero to one does not necessarily mean you can take a company from 20 million in ARR to 150 million in ARR to like a Facebook size, right?

I think the founders that do succeed in doing that listen to people and learn, and then they take that back. They consider it, and they figure out how do we apply it to our companies. Founder mode comes from founders who are very heavy-handed into the weeds, right? They want to dictate the solutions. They found that their company scaled like crazy, and they don't have a handle on it. I'm pretty sure that's where that came from.

As I read all those notes, they're thinking that the best thing that I can do is turn into command and control. I look at this as a symptom of did you hire the right people and whose advice were you listening to? It wasn't everybody's advice. A lot of the companies I think that run into trouble scale like crazy. They're scaling with money, right? They have the revenue side, but they also scale their people like crazy and think, "Hey, if we just add more people to the pile, we'll just keep making more cash," right?

That only works when you have a strategy. So what happens is they dictate down all the decisions—not dictate down, sorry—they look at their teams and say, "We hired all these people; innovate bottom-up." But there's no strategy at the top, and I've come into so many companies, whether they're growth stage, kind of like those scale-up SaaS tech companies, darlings of Silicon Valley, and enterprise companies where there is no strategy from the leadership team, but they're mad at everybody for not performing. But you didn't give them any guidance.

Sometimes the strategy is really, really low level, like, "Go build this feature," or "Let's go innovate on this new thing," and I want to put all of my money and my effort on this new product. Okay, so what are you going to do with the old product? Is there any strategy? Why is the old product losing money? Well, there's no strategy for it. Who's coming up with that? Do you want to come up with that, or do you want to hire somebody who can come up with that, right? If you don't care about it anymore, so they look at all these things. They're not organized really well, and then they go and they blame it on how people scale and say, "I need command and control to get back on top of it." I don't think that's right.

The other side too of this is that I have tremendous empathy for founders who are in a position where they're looking at their company and they don't feel like they have a handle on it because they probably have never done this before, right? They've never done strategy at scale most of the time. They've never led a company of that size before, so it's got to be overwhelming, and nobody sat down and taught them how to build a corporate strategy or a company strategy. It is a science, and you can do it, but they probably either didn't want to listen to somebody about it or they didn't do it themselves, and that's the gap there.

So it's not necessarily about going back and micromanaging people; it's like how do you provide direction? If you have junior people, let's say you hired the wrong people or the people in your organization are junior, you do need to provide more direction as a leader, right? I think about it as tightening constraints. It's like, "Hey, we don't want to go here, here, here, here; lay in this bucket," right? But it's not about dictating down all the solutions. If you have a very mature team, you can usually give them a little more leeway.

So I think it's about getting the right people in the right place and also understanding how your company is growing and focusing on that strategy as a leader. I've seen a lot of CPOs actually successfully come into these companies that are founder-led, who are the founders or the CEOs, and I've done this myself as well, and we help them build that strategy, right? It's not like I'm looking to dictate all the decisions here, but let me help you get this into a good form so that you can deploy it down to your people and they know where to go. That works out really well. They usually have immense knowledge about the subject matter, the history of the company, all these things that need to go into that. It's just a matter of being willing to learn.

But I see everybody talk about founder mode as a reason to not have product managers or product people, and that's never going to fill that gap.

**Interviewer:** So you said there is a science to building a strategy. Break that down for us.

**Melissa:** So typically, when I've been working with organizations, either through boards—I do a lot of board work these days—and on product and product strategy, I actually do it from the whole company level. Because what happens is there's almost always a thesis behind an investment when I come in. Even for large organizations, they'll have a thesis on what they want to do, where they want to expand, but it's not usually communicated down in a way that's going to allow us to connect all the things we're doing in product back up to what those outcomes are.

So when we're thinking about product strategy, there's two sides to it. It's about looking at that company strategy and where our priorities are, and then saying how does our product or our portfolio of products develop and grow to help meet these objectives in there? And then what are we going to build to actually do that? So what problems are we going to solve to build that to do that? And then how do we design the right solution?

There are multiple layers. So when I talk about strategy, I talk about first the company level, and that's about setting the vision for the company—how we want to be differentiated—something that's tangible that we can get behind. I see a lot of company strategies and visions that are just like, "Be the best, make money." The whole team is like, "Okay, how?"

I could go to McDonald's, pick up a shift, and then give you the cash that I work there, but I imagine that you don't want me to grow the company this way. So that type of weakness at the company strategy is usually a reason why a lot of product strategies fail to begin with. We have to go back to the top and say, "All right, do we have a strong company vision? Do we know where we want to play? Do we know how we want this to evolve? Do we know what problems we want to solve? Do we know how we want to be different than what's out there?"

Even to set the company vision, we need to know a lot about our customers. You need this both for your product vision and your company vision. If we're not sure about that, we look at who we have as customers now. Who are the personas that we're actually solving it for? Typically, we gather a ton of data about where we're winning, where we're losing, and I look at stuff like win-loss data coming in from sales. I look at usage across the products by personas or cohorts, whatever we're going to segment by.

We get a bunch of hypotheses, and then we go out and talk to those segments and try to figure out, "Why are you buying us? Why are you not buying us? What do you like about this? What are the problems that you have? How are you growing? What's the market conditions you're facing?" All of this research, and we bring it back and distill it into where are the opportunities to actually place our bets.

For example, in a lot of growth stage companies I work with, they're trying to get bigger. A super common play in the corporate strategy part of it is to go upmarket. They all know they want to go upmarket, but the question is how? If you're solving problems for SMB businesses, a lot of times companies will try to jump ahead and do something with enterprises, usually because one enterprise comes and knocks on their door and says, "Hey, I want to do this."

So they jump into it and say, "Yeah, big deal, let's do it." But if you go back and look at their product, you have to answer questions like, "How much effort and investment is it going to take to get our product ready for the enterprise? Once we get them, can we keep them? Can we retain them?" That comes back into questions about product strategy.

So product strategy and company strategy feed off of each other because we want to prioritize things at the company strategy level, which I call strategic intents, that help determine how we're going to do our product strategy. For example, if one of our strategic intents is to go upmarket, we want to say, "Go upmarket. Where are we moving from SMB into midmarket? If so, where do we want to start? Are we going into the enterprise? Are we not playing in the enterprise?"

Then by doing this, what are we targeting? Is it new logos? Is it new team expansion? Is it getting new individuals? Is it growing in different ways? What are we trying to do, and where's our goal? We want to lay out those strategic intents as an executive team, and they usually cover everything.

If you go upmarket, it's not just affecting product; it's also affecting sales. If you don't have a sales team that knows how to sell into the enterprise, you've got to hire one, though, if you want to go into the enterprise. It's a very different skill set than SMB companies, which might be a product-led growth play.

So you have to look at what are the things that we have in our organization, the capabilities we have to be able to make these strategic moves. Once we prioritize that at a company level, we can go back down into product and then say, "Is our product well-positioned to meet these new goals from a company level?"

Again, we're sifting through data; we're trying to figure out where we are now. We're pulling a current state of the organization and a product together. We're evaluating where we're weak, we're evaluating where we're strong. We look at the current customers, we look at their problems, we look at what's on the roadmap, and that's how we start to sift out what the product strategy should be.

So maybe our product vision or portfolio vision needs to evolve to be able to meet the needs of the company of where that vision is going or where the strategic intents prioritize. So we might have to redo the vision. Okay, let's do some work; let's figure out what's going to win there.

Other times, we have to prioritize what problems we're solving. For example, if you're going upmarket into the enterprise, a really common one from a product perspective is security and integrations. Do we even have integration capabilities? If we wanted to do that, what's that like? How do we actually think about it? Where do we prioritize it? Those types of things will feed into product strategy.

So when I look at product strategy, we need to do it from very much like we did with the company. We do it from a product perspective. What's our current state? Where are we today? How does that compare with where we want to go? What are the gaps we want to address? What's our new vision? What are we trying to be for our customers? Who are we going to solve? What type of product do we want to be?

I see a lot of product visions where I know we talk not about getting into solutions, but some people don't even know they're building a platform, and it's a platform. It's like if you want to build an extensible platform, you should probably say it's a platform. You know, out there, just tell people what you're building.

These types of things and these types of decisions help guide the teams on what we're going to do. You don't want to give as much direction in that product strategy to the team about, "Hey, I want you to build this widget that allows integrations." But maybe your product vision is about being extensible and being able to ingest data from different sources. That's a great key to say, "Hey, integrations is something we want to look at."

So we look at that vision, we look at then what it takes to meet that vision, what problems we want to solve, and then the teams are going to go find out how to solve those problems, right? Should we do it in this way or that way, or what is it—a workflow?

So all of that takes a lot of data to get to that place with product strategy. It also takes a lot of decisions, and it takes a lot of alignment. One big mistake I see with companies when they make strategy is they go into a room, they come up with this new vision, and they just deploy it down to teams, and then they go, "Go!"

When you do good strategy cadences—and I base a lot of mine off of Hoshin Kanri, which is a strategy deployment process—what you're doing is at each level of the organization, you should be saying, "Hey, here's the direction that I want to go in based off hard data and facts. I did my analysis, I did my research, I talked to customers, I did all this stuff. This is where I think we should go."

You deploy it down, and then the next level of the organization is supposed to go, "All right, what do we have to do to get there, and can we?" That takes a lot of communication both up and down at every level of the organization and across. You want to make sure that if you're doing something in product, engineering can actually handle it. If you're doing something in sales, product's got it on the roadmap, right?

So we should be aligning across the organizations when we build these strategies and making sure we're going in the right direction before we commit.

**Interviewer:** Okay, so I think that one of the big important areas here is building in like the company strategy versus the product strategy, and the company's strategy comes first. So how do you like to see that company strategy portrayed, or what are some examples you've seen, maybe of like public company strategies we could refer to for people to say, "Okay, this is what good looks like"?

**Melissa:** It's a good question. I haven't seen many strategies out there in the level of detail that I'm talking about that look amazing, but I do use Intuit as a good example for banks. I work with a ton of banks to show they've done a lot of explaining how they're moving into a platform. Intuit doesn't even talk about being a bank anymore; they talk about being a financial platform.

Of course, there are banking products on it, but they're opening it up so that people can come in and integrate with it, and they can share data across different places. They want to be a platform you can build on. That was a deliberate strategy shift away from being a bank.

So I go and I read their corporate things; I look at their strategy of how they explain it on there. Is it like 100% perfect best practice? I don't think any company has 100% perfect best practice strategy, but I like that it's extremely clear. It's very easy to see where they're going and what they're doing, and they talk about the choices they made to get there in a great way, right?

So they have a great vision for where they want to go. I think that really challenges how other financial companies or banks that are making transformations can think, right? I love using it as an example because I'm like, "Hey, they don't even call themselves a bank anymore. Think about what you could do. Think about what you could be if you wanted to go that way." But that's also a choice, right? And strategy is about making choices.

Intuit said, "I want to go in that direction." I think any good strategy clearly says, "This is our choice, right? This is where we want to go." It doesn't just leave it open-ended.

I think a couple of frameworks that people commonly use for strategy that I've seen, at least in the stage of companies I tend to work with, which is still more that growth stage, less these enterprise banks, like the two or three—like the number one is sort of the three horizons model. I feel like everybody these days is using that. The number two is kind of the McKinsey way, right? They have like a 30-page beautifully crafted slide deck that has really, really good market sizing that's super accurate, and they understand the market share of each player amazingly well.

So that's like a second. And then the third I've seen is like these canvases that I don't know if you've seen, but like the business strategy canvas or the lean strategy canvas. I'm curious about your thoughts on those frameworks, if any of them are useful, or what might people lean on to create this corporate strategy?

**Melissa:** Yeah, there are many different ways to actually communicate it. I like the three horizons model to start thinking through where are we now? What are we thinking about doing next to expand on our engines of current growth? And then where do we want to innovate or disrupt, right?

I think that gets people out of the mindset of we have to keep doing things the way we're doing, or we have to leapfrog innovation into something crazy and new, right? It helps them think about it in evolving terms. It also helps people project if they're going to get disrupted, especially if you're in a legacy business. That's where I think that comes in.

I don't think that's like a perfect strategy model, though. That doesn't explain everything, right? It's one tool that helps you think through how you want to present your strategy. I would actually argue too that Netflix, which I think has a great strategy as well, and Gib Biddle has written about it a million times, like I point to that one as a good strategy too. They were thinking about the three horizon model probably when you were thinking about, you know, getting big on DVDs, then pivoting into streaming, and then original content. They disrupted the whole industry by doing original content.

So if you can see those things ladder up, you can bring it back to a bunch of these models. I think these models were developed by looking at a bunch of people who did it right and then saying, "Hey, this is a great way to grow."

When I look at this stuff, I think about them as tools and what's right for my company. What I found works really well is I have people write memos, similar to the Amazon-type memos. I think those are fantastic. But my memos are about describing the vision of where we want to go, describing the current state and what's broken, what's working, what's great right now.

Then we talk about what we're going to do to reach the vision, so we outline our initiatives there or strategic intents at the company level, and we give a little context to it. We put outcomes in it; we describe why we prioritized it, and we also talk about what we're not going to do or what we're going to stop doing. Usually, that's enough to get it out there, let people have that pre-read, and then we follow up with some kind of strategy meeting.

We'll put slide decks together. The slide deck should be more communication. It depends if you're communicating to teams or investors; it's a good point.

So let me segue this to teams. We're taking that and we're trying to provide clarity on why we made these decisions, what are the signals we're seeing, what's different about what we're currently doing, what are we going to stop doing, what's new, how should you think about going forth in building these things, what problems do we want to concentrate on, what problems do we not want to concentrate on?

Typically, in that slide deck—and this is just usually because somebody's talking over it, that's why it's a slide deck—in this presentation, it's outlining all of the stuff that was in the memo but giving a little bit more detail. This is where you might want to use more visuals to communicate things too.

So this is where I would pop in some graphs, show some trends, maybe show a mockup of what it could be if you're going to innovate like crazy and just say, "This is potential, but I'm not saying that this is the right way to go, but this is what we could be." Customer interviews are a great thing to pop in there, a couple of quotes here and there to show them what they're doing.

That's how I would present that. What happens is all of these memos get broken down into roadmaps. So what happens is when we do strategy, when we deploy it, we have many different communication tools. What we have to look at it like is these are communication tools. They are helping everybody digest the strategy, and it's helping us align back to the strategy, but it's not the strategy itself.

So when we are developing it, we want to figure out how do we communicate it to people on the outside of our organization? How do we want to communicate it to investors? How do we want to communicate it between executives or down to employees? We want to choose those different frameworks to write, and that's where people will look at canvases to develop it.

All of those different things may be viable options for your company. It's about what helps people understand. I personally like the memo followed up with the slide deck, and I find that that's good. But no matter what, if you're a leader, you're going to be repeating yourself on the strategy like 80 times.

I laugh sometimes when leaders are like, "Man, I've said this like a million times. Why do I have to say it a million and one?" It's because the rest of the company didn't do the work to figure out the strategy, so they usually weren't as heavily involved—the people who weren't as heavily involved, let's put it that way. They don't have as much context as you do.

So if you're not repeating yourself 100 times, then it's not sinking into other people, and that's why as leaders, you've got to go over and over and over and make sure it's digestible in different ways. So that's where all these communication tools become really important.

But I think canvases, value proposition canvas, McKinsey 3 horizon model, a bunch of Gib's models on his blog—all of these are great ways to start to think about what should our strategy look like and where do we want to place our bets and how do we want to communicate it? But then I think you just have to pick what's going to be best for your company and culture and commit to that.

**Interviewer:** And then originally, there was a lot of, I think, distinction in your description of corporate strategy and product strategy. So what does a product strategy look like ideally? What are the ways to communicate that?

I think this is the one where a lot of the guests we've had on the podcast talking about product strategy—whether there's Rby MAA, he likes to have like 25 visuals as his rule of thumb to have, or we had like Benjamin Humphrey. His thing is like it needs to be a mega Figma prototype, or we had Meta people who were all about Mark Zuckerberg's videos that he'll create. If you remember, for AR, he had that amazing video of how he was like embodied presence.

I worked at Epic Games, which also was all about the video. They'd create the 30-second trailer with the special artist team, and then we would actually go build it later. So how do you like to think about how to tell the product strategy story for the teams?

**Melissa:** I think there's a lot of power in a prototype and the videos. I like that idea a lot, and we do incorporate that into it if we're going in a completely different direction. So if you're thinking about revamping your strategy or expanding it into new things, I think there's a lot of value in visuals of what it could be for the customer.

I think the big thing is trying to make sure that those don't look like they're done right or that you have to commit to exactly what's on that page because that locks you into something that might not be validated already. So it depends on what kind of validation you already have.

With the company I'm working with right now, we're going back through the product strategy. We have a clickable prototype of where we want to go in the future. We're still validating every piece of it, but putting that in front of the board members allowed them to go, "Oh, okay, I see. We're combining two products into one platform."

They're like, "Oh, I see how this comes together," because there's usually a lot of legacy knowledge and experience of those products being separate or the way that things used to be that people can't even picture in their head what it might be like for the user when it comes together.

So I do love doing that, but a prototype will not be enough to actually communicate a strategy. So that's where you have to add on context to it. So that's why I would say do a lead-in on slides or in your memo about where we came from, what it was like, show some visuals of the current product, show what was breaking, and then you can lead into a prototype or a video or something to demonstrate where you want to go.

But then you have to break down what that actually means because people will take different things away from the video. Like, what are we prioritizing here? What are we not prioritizing in this product strategy? What customers are we prioritizing, right? Does this product strategy actually speak to everybody? Are we moving from B2C to B2B? And if so, what places are we targeting? Who are the new customers on this?

It's probably not showing a full picture, so you still have to put context behind it, and I think that piece is really important. So a product strategy to me should really explain who are the customers that we are going to go after, and that should match up to what the business is. But it might be a little bit more tangible about certain products or certain things tailored to different customers, right?

We might want to explain that in the product strategy or how we're helping each one of those achieve their goals and solve their problems. We should have a lot about the problems that we want to solve and then how we're uniquely going to solve it. What is our way and our value proposition that makes us differentiated from the competition to do that?

Then you want to paint a picture of what that could be, and then you want to go back and let the teams roadmap their way into it, right? That's where we start scoping out how do we get there over the long term, which is three years, five years. What does that mean for the evolution of our business, and how do we start taking little steps towards that?

I think that part is really powerful.

**Interviewer:** You've in the past talked about five layers of product strategy. Do you still use that mental model, and if so, what are those?

**Melissa:** I've been talking through it a little bit. So it's actually not five layers of product strategy; it's five layers of strategy in many companies. The way that I think about it is at the top, you've got the company vision, and then you've got the strategic intents for the company. Those two layers help make up a representation of the company strategy.

Now, of course, there's going to be a lot more than just behind the math of those strategic intents, but the idea is that everything we do from a product initiative standpoint should roll back up to one of those unless we're doing maintenance work or tech debt. Those things I consider like different buckets. This is what I'm talking about for engines of growth.

So if we're prioritizing engines of growth and we're prioritizing ways that we want to evolve the business, that's what we're doing as strategic intents. Occasionally, I do see people say at the strategic intent level, especially at staff companies, "This is a rebuilding year; we're going to re-platform," in which case maybe a lot of stuff rolls back up into that. That might be a company decision to slow growth and focus there; that's okay.

But typically, it's things like move upmarket, expand geographically, or rebundle our products into a platform—something like that. Things that are about how we want to grow and how we want to scale. Then we go down into the product strategy, and the product strategy, if you're in a really large organization, there's usually a product portfolio strategy that your CPO is going to own.

They are looking at what's the vision for this portfolio, and then what are the initiatives for a portfolio? So things that cut across all of our products, and they should be thinking about how do these products interact with each other? How can we get more value out of these products if we think about them working together?

How do they all come together to create a story about what we're selling? One big issue I see a lot of companies do is not consider that entire portfolio. So there's nobody looking at all the products, or somebody looking at each individual product, but they're not thinking about how does this come together, and can we leverage it to make our products even more powerful?

Like, what if we took data from one of these products and helped integrate it into the other product if that helps solve problems for customers? That should go into our portfolio vision if it allows us to get there. So that's why you need that portfolio vision.

Then each product has its own strategy that kind of goes back to the portfolio vision. If you don't have multiple products, then you just have a product strategy. The product strategy here is about, again, vision for the product. Where is it going to go? Who's it serving as a customer? How's it evolving over time? What are the problems we want to solve? What are the goals we want to hit?

Then underneath that is usually the initiatives, and I think of initiatives—product initiatives—as big problems we want to solve. So what are the big problems we want to tackle? It's not a specific feature set; it usually starts as, for example, if you're in e-commerce and you're moving upmarket, it might be looking at creating better ways for our customers to market their products, right? Help our customers market their products better.

It's a big bucket, right? Underneath it now are going to be what I call product options, and these are the solutions that you could build to actually reach that. I call them options because I don't want people to be locked into a specific solution before they validate it. But what it does is it starts as a problem and evolves into a solution.

So maybe somebody looks at that and says, "Hey, actually, loyalty programs is a great way to market this." It's more of a retention strategy—scratch that. But maybe for marketing, it's integrations into the tools they're currently using. Maybe from a marketing standpoint, it's that they don't know how to market their products or they don't know what other companies are doing, and we should give them guidance on our platform about how they might be marketing or how companies our size reach their customers.

There are all different solutions, but it's about what's your context, and does it actually come back to the vision of your company and your products, right? Does it match that? And that's how we would choose what to do on the product option front.

So at each layer of the company, what we're trying to do is provide direction for people to go out, but you want your teams to basically be able to say, "Should I be providing direction to these people? Are we trying to be an expert platform where I'm helping small businesses? Is that our customer? Do they need guidance? Or are they expert e-commerce sellers where we just have to give them the tools and then let them run with it?"

These are the trade-off decisions that we make around product strategy and around what we want to evolve, and that all comes from who we want to target and who do we want our customers to be. So that goes all the way back up to the company strategy, and that's how I think about the different layers.

What happens in a lot of companies is when they start scaling, they will start to make—I've seen this happen at a million places. When I first came into athenahealth, this was the same thing. We had like one person reporting into one person reporting into one person reporting into one person all the way up the organization, and everybody was trying to figure out what was their piece of strategy that they owned.

Because there were so many levels there, they weren't collaborating around things that probably just took a team to figure out what's an initiative versus what's an option. So I say five layers of strategy because there shouldn't be too many levels, because then you're just getting into these nitty-gritty things, and then that's how you end up with product owner waiters, where everybody's just like, "I'm the product owner for the API, and I write user stories on how to log in every day, even though people can log in."

That's what we want to avoid. So we want to keep it high-level enough with enough scope for people to go out and figure out what to do. So that's why I say there are that many layers. You've got a company strategy with strategic intents, you've got a portfolio strategy with portfolio themes, you've got a product strategy with initiatives, and then you've got your product options. So it's like four main buckets.

**Interviewer:** Okay, I think I just had a moment in your answer, which I'm curious if you agree with or not, which is that maybe the advice we've been giving product teams is one size fits all, but we're kind of boiling it together for what fits most use cases. When you don't have a Brian Chesky at the helm, you don't have a Steve Jobs at the helm or a Tim Cook at the helm, this is probably the best way of working where you're empowering your teams.

Now, if you do have a Brian Chesky or a Kieran at Linear or you like Benjamin Humphrey, I mentioned the COO and founder of Dovetail, if you do have that product-minded founder, maybe that's the place where you can break some of the rules we're talking about here, where you can go beyond problems. You can actually dictate some of the features to teams, especially if you're in a more innovative space. I'm thinking like a more of a category creation space.

I wonder if that's where you break the rules. You kind of take on the Steve Jobs, Brian Chesky hat of, "Let's dictate the features." But otherwise, if you're a big bank doing digital transformation, you're much better off empowering the team to go solve problems and do discovery in that problem area.

**Melissa:** Yeah, I think it depends on where your creativity centers are. Are they lying with your leaders? Maybe there's a question too about how do you create creativity centers? If you have a Steve Jobs, right, he's looking at how the market's changing, where it was going, he's predicting things before they became. But a lot of that's studying technology trends; it's also studying user behavior—like what people want.

It doesn't mean that you can't build that into your organization. So where is it going to come from? And then do you allow people to bubble that up if you're in a larger organization? But I'd look at it too as like we've got a—this is a point too about Apple, right? You had a Steve Jobs. What happens when Steve Jobs is gone? Now, where's your creativity center?

Not that Apple's not creative, but how do you replace that? And I think when we think about strategy deployment and creation, we have to be making sure that we are creating those areas across an organization. I do agree with you that it's not one size fits all.

So this is the model that I teach. I do a lot of digital transformations; this works really well for growth stage companies too. I've done it a million times with them. Sometimes you just don't need as much overhead; you don't need as much creation on here. I tell people, "Don't go crazy. If it works, it works, right? Stop when it works."

That's how you should really be looking at it. When you look at the founder-led, this kind of goes back to founder-led mode. What happens when you have this genius at the helm? You should listen to the genius, but you should also figure out how does that genius teach other people how to think like they think?

And that's again where if you're making all the decisions for everybody and you're not trying to replicate what you're doing and helping other people see where that puck is moving or giving them the opportunity to by setting the direction, how is you create it so that it doesn't fail when you're gone, right?

To me, if we go back to founder mode and we're saying, "Hey, all these companies scaled and it didn't work for us," did you create it so that people could help think like you? Did you create it where you had creativity centers and you could bubble up things and you could provide direction, and your leaders knew how to provide direction? Did you hire the right people, or did you not?

So I think in some areas, it's really hard to replicate somebody who's got so much foresight like that, but it doesn't mean that you can't try in those areas. I do think if you take all that decision-making and you solidify it into one person, it's really hard to scale, right?

**Interviewer:** How do you think about scaling if one person is in the weeds making all the decisions?

**Melissa:** Second piece of this too, if we go back to founder mode, like listening to Brian Chesky on his podcast about this, I firmly believe in companies we have two modes, right? We've got a time of crisis when everything is going off the wheels, right? It's like things are not going well. Usually, there's no strategy, or the strategy is not working; things are just chaotic. Everybody's going in the wrong direction.

We may not have the right people, but things aren't good. Let's put it that way. Things are not going well. Then we've got times of happiness and success. We're growing; things are going fantastic. Nobody thinks they have problems when things are going fantastic.

So they never take that time to set up what they need for if they hit a crisis. But then when they hit a crisis, a lot of times they go back and say, "Oh, it was because of the people, not because I didn't set up an engine for us to recover from crises or to keep growing," right?

So when I look at what Brian's talking about too or what anybody was talking about with founder mode, I go, "Yeah, that does actually work." So in this case, founder mode works in a time of crisis.

So let's say that your organization is taking a nosedive and nobody knows how to come up with great ideas. You didn't build that creativity engine. You, as a leader, need to provide more direction. This also happens if you have a junior team.

A lot of companies that come into as growth stage companies, we hired a bunch of product managers, but they were not professional product managers. They were usually like early-stage people who got in there and kind of learned as they went. When you hit another level of growth, they might not be senior enough to make a lot of decisions for themselves, and then you have to kind of step in.

You can't give them a super large scope of a problem and just say, "Go innovate." You have to teach them what great product looks like. I think people can come up with that when they've seen patterns over and over and over again, which is why you hire great product leaders, right? That's why you hire any great leader, whether it's sales, product, anything. They've seen the patterns; they've done it before; they have the history.

But you do have to provide more direction because you don't want everybody going in the wrong direction, right? So in this case, we would tighten scope a little bit and say, "We're going here, and I need to get this back all in the rails. So let's all go in this direction."

I firmly believe that this is a bet we need to take. I need to lessen distractions, less of everything, right? And go this way. When you have a company in that situation, that's the right thing to do.

In a lot of turnarounds, I've been involved in a lot of PE takeover turnarounds or whatever companies, I see this all the time. It's like, "Hey, we came in; things are not working. Let's flip this company." You need strong direction on that. You need to come in with a plan, and the plan is usually not easy. People are not happy about it. Usually, that's where everybody starts grumbling, like, "This person's dictating it; they're not giving me the opportunity to go after problems; they only give me solutions."

Sometimes that's what's needed in that moment to get it back on the tracks. But when you return to growth and you want to go back to successful times, if you don't lessen the constraints, you won't find innovation anywhere else but yourself, right?

**Interviewer:** I think that the one group of people that might not be nodding their heads are those early-stage PMs that we sometimes hate on in these discussions, where we say, "Yeah, they weren't able to rise to that strategic level; they weren't able to advise." It's because you hired these junior PMs.

So if you are one of those junior PMs and maybe you've gotten this feedback or if you haven't gotten this feedback, you can just see this in yourself that you're not necessarily—you know, you can forecast this future. Maybe you've been acquired by PE, and you don't want to be one of the people who's getting described that way. How, as a junior PM, do you actually impact the strategy, and how do you become more strategic?

**Melissa:** It's a good question. I probably was one of those PMs. I was at an early-stage company; I had a little bit of product management experience under my belt, but man, I was arrogant as hell and thought I was an amazing product manager, right? I probably thought I should have been the VP of product, and I look back on it now and I was like, "Man, that was naive," right?

Because the amount that I've learned in the past 15 years since then is insane. I had no idea about any of these things until I got the exposure. But that doesn't mean that you can't get the exposure, right? That doesn't mean that you can't go learn from other people.

So if you were in this position and you've only done this for a couple of years and you do get feedback that you're not strategic, you're not thinking far enough ahead, the first thing you need to do is take a step back and say, "Okay, is it a skill set gap? Is it a communication gap? Is it a knowledge gap? What is making people say this?"

Sometimes it is a skill set gap. Study other strategies. I love watching other companies and how they grow and what makes them tick, right? Like how do they get into it? Is it a product-led growth phase? Is it, you know, like watch Figma explode. Why did Figma explode? It's like, "Wow, they took this problem, they solved it amazing, and then they made it easy for people to get on and start using it."

Product-led growth. Look at the patterns, and then come back and see if those patterns apply to your company, right? Compare and contrast. I like studying patterns. I do it in the way that people work; I do it in the way that organizations scale. I do everything. If you start seeing patterns in strategy, you're going to start to pick up on what might work for your company versus what might not work for your company.

So that's what I would start with. You write a great newsletter on a bunch of strategy and how people do that. Lenny writes a great newsletter on it. Study what other people do; listen to their stories. Then you go back and you try to apply context to it. It's not just about copying what other people do. A product-led growth strategy doesn't work for everybody, right? Don't just copy what these companies did.

Instead, try to figure out why it worked for them. So what was set up so that that was the way that they could grow and that was the way that they could work? What were the conditions for success? Do you have those conditions, right? Are you targeting the same people? Are you going after a different market? Are you going after a different geography?

Give you a great example. I'm working with a company in Germany right now. The way that companies in Germany buy products is extremely different than the way that they do it in the US, and product-led growth models don't work super well in Germany because most people don't have a credit card.

Yeah, it's still a cash-based society, right? So those types of things where if you look at these—if you look at how other companies did it and just want to copy it, you're not deeply understanding the context, right? And it's so important if you want to be more strategic. You have to understand context, and you have to want to understand context.

So dig into it, right? So you can observe this from a lot of other places. Then you bring it back to your organization. What I tell a lot of people is when they are frustrated—and I just sent out a newsletter on this this morning, actually—a lot of people get frustrated because the company strategies are fuzzy or they're reporting into people who don't have a very strong strategy, and they recognize it.

They recognize that there's a gap, and they're not getting what they need. Sometimes they don't know what they need, but they just know they're not getting it. What I say to them is start asking questions, right? So it's a really easy way for you to get involved, to start making sense of what's going on and where the priorities lie in the organization.

Now, ultimately, it is the executive's job to prioritize the big initiatives for the company. So whether or not you agree with them, they're going to prioritize it. Then you're going to decide if you want to be there or not. But you can find out what their priorities are, and you can do that by asking them questions.

"Hey, I know you really want to build this feature. You passed this down to me. What's going to happen? What do you think will happen when we launch it, right? What metrics do you think will change? Is this like a retention play? Is this a growth play? Where did you hear about it? Right? What customers were talking about it? Can I get in touch with them just so I can see a little bit more?"

You take it from a perspective not of challenging. I've witnessed a lot of people go back to their leaders and be like, "You don't know what you're doing; strategy sucks." I've actually seen it. It's awful. You're going to get fired. Don't do that.

Don't just start screaming that your leaders are handing you solutions and they're not handing you problems, right? Instead, ask questions. Be humble. "What do you think will happen when we do this? What do you expect to happen? What do you hope will happen? Do we have any success metrics? How'd you come up with this idea? Tell me a little bit more about it because I desperately just want to build the right thing, right? That's all I'm humbly just asking for more information because I want to make sure that I get this right for you and I build you the right thing."

They'll give you some information, and you might learn that there's gaps. When you learn there's a gap, like maybe it didn't come from a customer, or let's say it came from one large customer, you take the initiative to see if it applies to other customers, right?

So you got handed this thing; you just figured out what the problem is that they thought it was going to solve. That's where product managers need to take initiative and then say, "I'm going to validate this with other people and just make sure it scales and we understand it well."

So you go out and do it. A lot of companies, I hear product managers say, "I have no time for discovery. I don't have time to do all these things." Things like, "Make time. Take some initiative to go out there and figure out if this is the right thing to build."

I did this a lot in my younger years when I was an individual contributor product manager, and it worked. The CEO would hand me features to build, and I would be like, "Okay, what do you think this will do?" And you'd tell me, and then I would just go run a bunch of experiments.

Then I went back and I was like, "It didn't work. Can we talk about it?" And you'd be like, "Oh wow, I definitely thought that was going to work." I was like, "It's just not working, but I found something that did work. Do we want to do this?" Yeah, go do that instead.

I just wanted to do this thing. Those things start to surface up conversations, right? I just found out from like this is a story from Open Sky when I was there. It was a growth stage company in New York City, and this is over 10 years ago now.

We had that where the CEO was giving us—giving me a bunch of features to build, and I would go test them. I was running a bunch of experiments on this, and all my experiments that were supposed to be increasing sales were failing. What I found out later, because I didn't hear about this at the time—and like I said, I was an arrogant little IC contributor, and I was like, "I got to go move on to bigger and better things," and went somewhere else.

All my experiments actually pivoted the entire company, and then it got sold to Alibaba. My stuff, combined with the other things they were learning, made them look at it and say, "Hey, I don't know if this is sustainable. We should look at a different pivot." They made that pivot with the company, and then they sold it to Alibaba.

The stuff you do as an individual contributor PM, it matters, but it matters if you're getting it into the hands of the right people, and it matters if you take the initiative to go do that. I look back on it and say Open Sky was one of the best teams I ever worked with. It was just all those in hindsight, right? Like over 10 years later now, I can go back and see all the pieces coming together, but I just couldn't see it when I was in IC.

**Interviewer:** Yeah, for me, I've had to coach a lot of PMs who report to me on this because I will perceive—and usually also my boss will perceive—they're not strategic enough. It always starts with that time element you mentioned, which is like you're already working, you know, oftentimes 50 to 60 hours a week, unfortunately. The PMs on my team always did that.

They're usually in this kind of people-pleasing mode where they basically have become internally focused. They want to please me; they want to please their design partner; they want to please their engineering partners; they want to please my boss or the founder. Maybe there's a VP of sales or VP of marketing, one or the other, breathing down their neck.

So they have like this constellation of people who they're like super focused on, and just pleasing those people realistically is going to take like 80 hours a week. So they just get to 55, and all of them are somewhat lukewarm about them is what ends up happening, right?

This, I think, is the reality most PMs live in. And so the coaching for me was always around, "Okay, how do we first, with all of these people, reduce the amount they're expecting you to do?" Especially with your design and engineering partners, like how do you give enough context to your engineering partners for them to go solve the corner cases on their own?

How do you go empower your designer with a very lightweight spec, maybe even just notes on a Figma document instead of a 40-page PRD, right? How do you kind of lessen the burden, especially on this immediate team that you have, in order to go do the strategic work?

When you're handed a feature, ask, "What is the problem we're going to solve? What are the metrics we want to achieve?" And then go to discovery to actually solve that problem and achieve those metrics and come back to those executives, whoever the VP of marketing or VP of sales breathing down your neck, and say, "Hey, this is what I've learned."

I feel like that's like this—that's how you impact a company permanently like you did at Open Sky. But I think most people, they're just struggling with that time, and so a lot of it is about going to your counterparts and helping offload some of those responsibilities we put on ourselves.

**Melissa:** Yeah, this is a big topic I talk to new product managers about, especially product owners who went through a scrum training and nothing else. That's typically the people who end up taking my classes in a lot of the large organizations I work with. But I also see it in smaller organizations too with the product managers.

People set the context sometimes when they're looking for a product manager as, "Your job is to keep the developers busy," and that is the worst context you could ever set for a product manager. Like, that's not your job. Of course, you will keep the developers busy if you're scoping out things and discovering problems and prioritizing them, right?

That's an outcome from doing your job—the developers will be busy. But I also say, "Why are we hiring developers who are not cheap, by the way? No developer is cheap—and then not trusting them to make a decision?" If you give the developers the right context, they should be able to make very small trade-off decisions, big trade-off decisions as well, honestly, if you set them up well.

So I say the best thing that you could do if you're feeling overwhelmed—like I get a lot of questions on my podcast about, "Hey, my developers, you know, they want me to spec out everything. They won't work on anything unless it's like super spec'd out." I'm like, "Well, what are you doing to build context with them before it comes to breaking down stories or working in scrum?"

What I found from going into a lot of organizations and training their entire product teams is that especially people who come from the scrum background, they focus on putting stories in a backlog, but they never figure out, like, what's that product vision? What's the product vision? How do I build context about it?

How do I describe all the problems that we're going to go solve? How do I paint the picture of what we're building for the developers so that when it comes down to a decision, that's usually a super simple answer? They can just make it themselves and keep going, right?

And that's the part where a lot of junior product managers miss. They just don't build context about what we're doing as a whole and where we're going with their teams. If you do that, you can actually just trust your developers to go build things, right?

If you have the same with the designers, right? You work with the designers; you make sure that they understand the context of the customers. A lot of times, they're involved in user research, so they're hearing it. You're telling them about the priorities at the business side; you're talking to them about design trade-offs; you're talking to them about where, you know, what the rest of the teams are doing.

You're helping them bring that context. They're going to go out and help mock it up. They should be working with the engineer as well to make sure it's actually viable to build, right? They can have that conversation, and then they should be working with you to make sure that it's meeting the needs of both the business and the users in the way that it gets—in the way that's going to work with everything else, right?

When you do this all together and you build that context, then all the teams can just go work, right? They can get your jobs done. Now you're freeing yourself up. Now you're not just writing 10,000 user stories a day. Honestly, the developers can write the user stories if they have that much context. Let them write the user stories. Who cares who writes a user story as long as they understand where we're going?

You can check it; you can go back and say, "Yeah, that's right." But if you don't build that context, you don't take the time to do that—which a lot of people won't—that's where you're going to get into this mode where you're just answering questions and you're reactive all the time, and you can't actually be strategic.

So when we talk about being strategic as a product manager, like you're saying, I think other people in the organization see that too because you're never talking about what's further than on the sprint. You're never talking about how all the things that you're doing actually relate back up to the business goals. You're never connecting those dots.

Usually, when people get called not strategic, it's because they're very much talking about the tactical work they're doing and like the entire feature lined up and what the developers are doing on a day-to-day basis, where they're not connecting what we're actually building and the outcome of that all the way back up to the business goals and how it's going to drive forward both our users' goals and help them and then also, in turn, the outcomes that we expect on the business.

They're not making all of those things come together. So on a return to kind of like the ideal way of working, which we were describing, we left it. We did corporate strategy; we did product strategy. I think the next thing is going from the product strategy problems to the solutions, coming up with your initiative list as a team.

So what is like the best practice way that you would describe to someone who maybe hasn't even been a PM before? How are they going to go take these problems? What is like the best things they should be doing in order to come up with their initiative list that they're working on?

**Melissa:** It's a good question. I think it's a hard—this is like product sense, right? I'm like, I've been trying to figure out how to describe this because this is a gap I also see in a lot of organizations that take people from the business or project managers, for example, and then turn them into product managers.

This is like one skill gap that I see people struggle with is recognizing what a good product actually looks like in the solution, right? So whether it should be an API, whether it should be a platform, what type of workflow it should be, how we should think about whether UX is important here, UI is important, you know, pattern recognition, and those things.

Some of the UX/UI stuff is, of course, designers will come up with it, but product managers kind of set the tone for how we're going to think about these things, how we want to work towards it, and how we want to structure it.

Now, when you're thinking about turning into a solution, it's about recognizing first what we have, what's working, what's not working, and that's getting into a deep understanding of your users and your customers. So like I don't think there's any replacement for doing user research, talking to your users, but also pulling the analytics.

Like, who's using what? Why are they using it? Having hypotheses about what's working, what's not working, going out and then doing the user research about that. Once you understand your users, you should also understand what they're used to using, right?

You should understand how good products work. So what's frustrating to them? What's not frustrating to them? What do they wish they could do? How do they do their job, right? Like how can you make them do their job 10 times better? Can you like start to see around those corners and think about, you know, what if we did this?

I think the best product managers take that stab and say, "What if we did it like this?" Instead of building a workflow with 40 steps, we used AI and took away 39 of those steps, right? They're able to look at the technology that's coming up; they're able to think about what the need is from the customer perspective, and then they think about how that all gets integrated into the product.

Now, they might bring that back to the developers and say, "Hey, is this like a use case for AI? Can we like slim down these steps?" But you need to have the wherewithal to ask those questions, right? To start seeing those types of trends and seeing where those things become powerful.

So that's where solutioning comes in. But I also think it comes from studying what works really well in certain products, what works really bad. Like I'd say even look at the products you use on a daily basis. I can't stop doing this because it drives me nuts, but I'll just feel like in a cell phone app and just annoyed because the user experience is completely broken or they could have done something so much simpler, right?

I hate it because every day I'm just critiquing things in my head, but you start to see those patterns over time, and that's what's going to make you a great product manager—recognizing the patterns but then seeing if they apply to you.

Now, I went back to a lot of large companies, and a lot of the training I do with them, those product managers haven't seen the patterns before. They've only seen what's internal to their company, and that's okay, but you should also think about what are you using on a day-to-day basis, and can I use things that work in other products to solve the problems that I'm facing, right?

Does that work too? For example, I see a lot of enterprise companies, especially when they build internal tools, they're like, "Oh, it's just an internal tool; the UX doesn't work." I was in charge of internal tools at Open Sky for a while too. When they are hard to use, your entire team is slow, right?

If you actually think about bringing great usability and UX to them, you are going to directly impact the cost and the happiness of your employees in the company. There's outcomes associated with that, but you get to understand what makes a great product and what I can bring in to my internal tool, even if I'm on it, by studying other products.

What works here? What doesn't work here? Can I apply these types of things? Can I bring these trends back in? That type of stuff I think is really important for trying to figure out what's the right solution.

I don't have to say this is where, you know, leaders should be coaching their product managers to recognize this stuff.

**Interviewer:** I think I had a great leader early on in my career who was like, "I want you to go play with all these different products. I love what they're doing over here. Just go study it. Tell me what you thought. What problem are they solving? What did you like about it? What did you not like about it? What was frustrating as your experience?"

We learned from those things, and then we said, "Does any of this apply to us?" But I think even if you're in a complex industry, like I've worked with a ton of healthcare companies, you can still take patterns from consumer products or other products that might solve the same problem that you have and utilize it there.

That's your wow moment for people who are not used to having nice products, right? Having nice things. Then your customers are like, "Oh, this is amazing! This is like what I use at home. This is like my Instagram." But here, you know, they're going to start to look at it, and that's going to be the differentiator there.

**Interviewer:** And I think that the one group of people that might not be nodding their heads are those early-stage PMs that we sometimes hate on in these discussions, where we say, "Yeah, they weren't able to rise to that strategic level; they weren't able to advise." It's because you hired these junior PMs.

Thoughts about how this user experience should happen right, and that doesn't mean that they can't be challenged, right? And it doesn't mean that, um, I want to block anybody as a designer from coming up with something even better.

But if the user experience is not going to be up to snuff to reach the customer outcomes we're trying to get or reach the business outcomes we're going to get, then it's important. Then it becomes a product manager's job.

So I find it really interesting that they don't get editor access in there. Like, I've been in Figma; I don't do as much design these days, so I could barely use it. But my designer in Figma, I'll go in, I'll move some stuff around sometimes, or I'll comment on it, leave comments there, and let them change it.

What I found is really important is like when we sketch together. I would always say for product managers and UX designers, what I've always found is you sit there and you can sketch together wireframes and stuff and kind of talk about what's the importance of it, go back and forth with that, and then usually the UX designer can go off and build it.

So to me, that's the best way of doing it. But I don't think you can say that a product manager can completely advocate or abdicate themselves from UX, right? Like, I trust UX designers, and great UX designers are amazing, right? I trust UX designers to make the best product, but you have to bring the context to them about what that entails.

We're one piece, and I do talk to a lot of UX designers and do conferences and stuff with them. What I've told UX designers who get frustrated with their product managers for meddling is if you're a product manager and you're meddling, do you feel like you completely understand why they're meddling, right?

Like, are they meddling for control, in which case, like, bad product manager? If you just want to dictate things to be dictated to, right? Like, I'm not talking about this mini CEO archetype here, right?

But are they coming back to you and saying, "Hey, your design actually doesn't work because of X, Y, and Z implications here on the business, on the technical architecture, on the stuff over here"? In which case, you have to listen, right? It's not just about pretty design; it's about functional design. It's about getting things that actually will work out there, and that is a product manager's responsibility.

So I tell UX people, like, if you want to be more strategic—and there is this conversation with UX as well about being more strategic, right? We've had lots of designers say, "Hey, we need CXOs and the C-suite; we need all this." I agree. If you want to be more strategic as a designer, you're going to want to learn more about the entire business context, and you're going to want to learn about when design works in those contexts and when it doesn't, and why certain aspects of your design might be better versus not.

That makes you more strategic as a designer. So you don't want to work in isolation; you want to look at the whole. And that's usually what product managers are doing. They're usually looking at all across products, the people who are adjacent with them, their entire product line, all the way up to the manager. They're seeing all these things come together.

I tend to see UX people get isolated to just their team, and they're not considering the full context.

Yeah, I think that that's kind of the counter that the average designer will say. It's like, "We can do sketches, and you can comment, but we don't want to give you editor access in Figma." And it's like, I don't know; I'm in the Nikita buyer camp honestly now, especially that I'm a founder, that like these big tech BMs—your average big tech PM—does not have F editor access. They're basically not being allowed to do management, in my opinion.

You know, this solution part, this crafting of the solution, is often the differentiator. Like, do Linear and JIRA solve different problems? No. Do they even have a different way of solving them? Not really. Like, the magic is just in the UX of Linear; that's it. That's the differentiator.

But if you look at all the Salesforce competitors, they actually all do less than Salesforce. They actually solve fewer jobs to be done, but the UX is what drives it. So it's maddening to me that so many PMs have been on the brunt of layoffs, and they've just never been close to design really their whole career. It makes me mad too.

You know, there was a long time ago—this was always—it's really funny where I feel like sometimes people talk about too the combining of it, right? So you get into these questions then about should product managers and UX designers be the same person? Having done that role, it works really well in small companies if you've got a competent UX designer.

Now, I was never good at visual design; it's not like I got much better at it from practicing it, but I was not great at visual design before. I still think product managers should be able to wireframe and be able to sketch out things in pretty high detail and then maybe work with a UX designer to get better at it.

I do see that work in a lot of companies. Sometimes we don't have enough UX designers to go around, and what I've seen in companies with larger solutions is the product managers will be given all the design tools to basically get their mockups and stuff into decent shape, and then they go back to a UX designer to help them ideate through it or think of different ways to do it or approve it or something like that.

But it at least gets the ideas down on paper, and a UX designer has full power to just rip it up and say, "Hey, actually, I got a way better way to do this now that I understand your objectives." But it doesn't mean that they're not allowed to try, right? It doesn't mean that they're not allowed to get in there, and I do think that's an important part.

Now, some designers—I mean, some product managers, though—have no design background whatsoever. They're more business people, and you see that a lot in companies. Those people probably need to just partner with a super strong UX designer, right? They don't understand the patterns; they don't understand the work. Maybe they understand the business super well and the customer needs super well, and they're very good at translating it, in which case I would say, like, please don't give that person Figma access because they're the type of person who's probably going to be like the CEOs we make fun of, where it's like, "Hey, that button should be red, not orange."

Not their expertise. But the people who do understand UX, right, who do have experience with it—like, what's the danger in giving them Figma access, right? Let them craft and then have a system for going back and forth, right? But it should be collaborative. Like, we should be collaborating in this instance.

And then you have a question too at small enough companies where you're like, if the product manager is a fantastic UX designer, let's say they're just as good as all the other UX designers, does that person do both roles in a certain team? If your scope is small, I think there's no problem having product managers do UX design if they're good at it. Again, if they're good at it and they're qualified.

If your scope is really large as a product person, you have a lot of discovery work to do; you have a lot of analytics keeping up with it. You probably don't even have time to meddle in Figma. You probably just don't have the time to go in there and start to move things around.

But if you trust your team and your team trusts you, you shouldn't restrict access. You just have a working agreement on what to do, right? So part of this, I feel like, is all about context of what makes good teams and what are the skill sets that we have and who's ready to do it.

But I do agree with, don't give Figma edit access to somebody who's got no UX experience whatsoever. Like, they're probably just going to blow it up and meddle, right? But if they do, like, you should have a partnership; you should go back and forth with UX, and UX and product—everything should be a partnership on these teams.

Okay, so let's go into prioritization, and I think you have this interesting concept of cost of delay that maybe not everybody uses. So talk a little bit about how you think about prioritization.

Yeah, so I think about it with cost of delay, and I was introduced to cost of delay actually when I was studying. I did supply chain management and information engineering, and that was the first time that I'd seen it, but I only saw it in a manufacturing context.

Then I met Joshua Arnold and Ozel Mui, and they ran this—Joshua runs a company called Black Swan Farming, and he was applying that to product development, cost of delay. And I was like, "Oh, I did study this in school, and this makes a lot of sense intuitively to how we think about what we should be doing."

And the whole premise of this is that when we order things to be released—so prioritization, right? Let's say we prioritize A over B. There is a cost to delaying B if we can't start working on it with A.

So when you think about capacity planning and organizations, you have to choose whether to do this first or that first. We have those choices every single day in road mapping and product strategy, all that stuff.

What we can do with cost of delay is start to understand what's the impact of each one of those initiatives that we are delaying and what will it be over the time before we can release it.

So the way that I think about it is if I wanted to build product A before product B, right? Like, I'm going to work on this first and get it out there. What is the cost of delay? So how much money or, um, metric share—so like whatever metric you're using on it—could we potentially be losing in, say, the three months that it would take to then get product B out, or the one year it would take to then get product B out instead?

And is that greater or less than if it was reversed for product A? And there's a way to calculate it. So you would usually look at what the impact is of each one of those products. So whether you're scoping it out, you would say, let's say product A, we project to bring in $25 million in revenue after we build it and launch it, right?

It's going to take six months to launch. Product B is going to bring in $10 million in revenue, but it's going to take three months to launch, right? If we wait to do—if we take product A, sometimes we prioritize by whatever is going to make more money.

If we take product A and we say, "Let's do this over six months," we can't even start building product B until six months, so it's going to be nine months before we can release product B and start realizing that revenue.

Is that a greater sum? Like, will we make more money over that time than if we flip it? Or could we start incurring revenue earlier? So let's say we take that three months, launch product B. How much money would we be making per month on product B while we're building product A, right?

And is that greater? So you can calculate this out. If you look up Black Swan Farming.com and cost of delay, it shows you how to calculate it out.

But that's how I think about it. And there's also a qualitative way to do it if you can't back it down into revenue numbers, where you can start to think about impact versus urgency. So those are the profiles, and you can start to move it around.

But to me, this mental model of thinking about how urgent it is and what's the impact on it is really important. And there's also delay models as well, where if we don't release it actually by the end of the year, like we miss out.

So imagine you're in a company that has a sales cycle for your customers that ends in November, and you don't have the product ready to be demoed or shown or anything like that by November. You might have to wait a whole another year before you sell it, in which case, like, that's a high delay, right? Like, that's a high cost of delay.

So now you've got to wait all this without recurring revenue or locking it in. That's the type of stuff that we need to think through when we're actually prioritizing it.

I think leaders really should use cost of delay when they think about any product strategy implications, when they're thinking about any of these big initiative pieces, because you want to make sure that you're prioritizing the really big buckets of work so that it's driving the business forward.

And you can back out and model all these things into revenue and cost numbers and get back to dollars. It takes some financial modeling, but that's what CPOs should be doing, right? They should be financially modeling with their financial counterparts and with their engineering counterparts and with everybody else in the C-suite.

What is the impact of doing X versus Y for a business, and does it help later growth? So that's kind of our master class on strategy, which was one element of escaping the build trap.

If we go back to escaping the build trap, we also talked about setting up product operations, and you wrote the book on product operations. I think the most interesting thing about product operations, for someone who's pretty close to a lot of growth-stage companies, is that right up until about the moment—maybe a month or two after you published the book—product operations was on this like hockey stick, where it was just like everybody and their sister was adopting product operations.

And I feel like recently there's been this turn, and it started with the layoffs that happened in tech, where I feel like product operations departments were the first to be hit, kind of like operations departments broadly—sales ops, rev ops, marketing ops—they were also all, I think, disproportionately hit.

Why do you feel like the role of these—why do you feel like the star of these ops roles has faded? I actually don't see them fade, so I'm curious. I'm curious what you're seeing.

So you—what have you heard from? But it's probably because I wrote the book, so the people are coming to me asking the question. So what are you seeing in these cow stages?

And I'll tell you what I'm seeing. So, like, I generally work with pre-IPO PMs in companies. Like, that's kind of the stage, my sweet spot, and where I worked also in my career.

And what I used to see is like every other time my friend would get a new VP of product or CPO job, he or she would like pretty soon hire like a right-hand man or woman in product ops, and they would help them make impact on the PM team if they wanted to change the PM team into using OKRs or creating a weekly business review or whatever, you know, big ritual changes they wanted.

Or if they wanted to implement a new tool like Amplitude, the product ops person was like their person who was helping them impact their team.

As soon as headcount got super constrained, and particularly like for these companies, VC funding dried up, most of them haven't even raised another round. Basically, all the initiatives that couldn't be directly tied to revenue were cut.

All the people who couldn't directly be tied to revenue ops were cut, and like they had to take on these responsibilities. So now they're rolling out new OKRs; they're the ones making sure all the PMs can do it, or they're rolling out Amplitude, and they're the ones making the PMs understand the tool.

Okay, yeah. So from my perspective, I've seen more and more companies actually adopting product ops now, and from when we first started writing the book till now, it's grown significantly in roles and in companies adopting it.

Like, Anthropic has product ops. Blake Samick, who started at Uber, went to Stripe; he's now the head of product ops at OpenAI. Like, a lot of these companies are bringing it in, and I think it's because when product ops—this is why we wanted to write the book too—I’ve seen product ops get a bad rep in a lot of organizations because people only thought about it from a process perspective.

When I talk about product ops, it's really from a strategy enablement perspective. So can I get the right data into the organization so that product managers and leaders can make decisions?

How do we review the decisions that we actually make? Do we have a good cadence for that? Can we track the metrics that we want to hit? Like, can we track it? Or do we have insight into it? Is it automated? Is it repeatable? Or do I have to like ask a data engineer to pull something out of a database every single time?

Can we get in touch with our customers? Can we get feedback from our customers? Is that customer feedback actually live? Like, how do we harness what we have around the organization?

All of these questions are what product ops actually answers and helps build. So it's like product managers for product managers. Now, you don't need a million of them in an organization; it should not be a one-to-one ratio by any means.

It's about how do we think about standardizing what we do internally in a way that enables people to make strategic decisions faster so that everybody who is, let's say, directly tied to revenue can get there faster, right? Can make those decisions faster, and that speeds up the engine.

And if it's the product leader doing it, they have oversight onto this. They usually say what they want to prioritize, how they would like it to work, put it that way, and then the person goes out and implements it.

They will bring their own context and their knowledge to it. They will do their own discovery work and try to figure out how to solve it, but the product leader sets a direction for it. Product ops people go and get it done.

If a product leader is doing it themselves, what are they not doing? It's usually strategy. It's always what I see. It's usually strategy.

The biggest reasons I see chief product officers or VPs of product get replaced in organizations—and it happens all the time—is because they're not focused on strategy, and they're not communicating up and working with the rest of the executive team.

It's because they get pulled into the weeds of trying to figure out all the nitty-gritty details. Like we just said, like, "What road mapping software should I use, and how do I set it up so my teams actually know what type of format to put it in?"

Or how do I also coach team members, right? Like, how do I coach all my team members, make sure they're doing it, they're getting so into the weeds that they can't actually set the direction for where the company and the product is going?

That's why I think product ops is really important. That's where I've seen it have the most impact. When you're really, really tiny, you don't need product ops. Like, you just turn to somebody and ask a question.

But when you start to scale, if you are scaled, that's where product ops becomes really important. So a lot of large enterprises that I work with, they're doing product ops, and they need it because they've got, you know, 7,000 product managers.

How do you figure out what 7,000 people are working on if we don't even have like a road mapping system? And most of them don't. So who's going to tell those 7,000 product managers and make sure that they know how to write the best initiative in a format where we can reconcile every other level of product initiative against each other and understand the outcomes and say, "Are we making the right strategy decisions there?"

Like, that's the type of things they do there from a process of governance perspective. But then they also go out and they say, "Do we need a Pendo? Do we need an Amplitude? How do I make sure that we get the right thing for our context? Do I go fight with the data team and make sure that we can plug internal streams of data into a Power BI so that people start making their own reports?"

Right? Again, if a product leader is doing that—like a CPO of a large enterprise—like, that's a lot of work for somebody who should be sending strategic direction over 7,000 people, right?

So this is what happens in these companies. If you don't have a team to do it, other product leaders, like directors, sometimes individual product managers, sometimes a VP, they start doing it off the side of their desk, and then they duplicate it across the entire organization.

And then you've got one way of doing reporting and analytics over there; you've got one instance of Pendo here; you've got Mixpanel over here; you've got this over here. But I still don't get the full picture of what's happening across the entire product portfolio, right?

I still don't get all the connectedness that gets brought together with product ops. So that's why I still think it's really important to do that. It's just that in a small organization, like a pre-IPO company, like you're talking about, when I was working with Insight Partners, we did all scale-up companies.

So come in as an interim CPO, and I'd hire a product ops person or find somebody in the organization who knew how to do data-type stuff, and then I'd say, "Hey, I'm going to train you on this." Sometimes it was one person in a 500-person company, and that's all that needed at first, right?

That's all that we needed to just get to where we need to set the strategy, and then we could think about evolving it over time. Sometimes in larger organizations, though, this is a small team, right? They're actually in charge of multiple platforms and analytics and developing those types of things, so you might need a couple more people, but it's still not like a 500-person team.

Okay, that makes a lot of sense. And then Anthropic and OpenAI also make sense in that context because they're hitting a billion and five billion in ARR, respectively. So at that point, you're going to start to have a product portfolio, right?

We already know, like OpenAI, for instance, has a very distinct B2C versus B2B business. And if each of those VP of products is creating their own product ops, you start to get this disconnect.

So what I'm hearing is like there's like these scales. Once you hit scale, ops actually becomes more important, and at scale, companies are realizing that. And so actually, it's still kind of on the upward where more and more people are adopting it.

Yeah, and I'd say like when I was doing this with the scale-ups, like I'm talking about like 20 to 30 million in ARR typically, where we might—that's usually when we hire a CPO, right? So that was like our model with Insight.

And where I look at companies, I say if you're doing multi-product or starting to get more complicated in your product portfolio, you're usually around like 30, maybe to 50 million in ARR. That's typically when you bring in a CPO because you need more strategic direction over that portfolio.

That's usually where I'd be looking to hire in product ops too.

Makes sense. And then when organizations are scaling their product ops, what are the challenges and mistakes they make?

Oh, um, trying to like whack-a-mole problems instead of thinking of holistic solutions, right? So it's okay to build like a manual solution, let's say, to get some data for a CPO or for somebody to make a strategy decision.

So sometimes we have to do that manually, and I did that manually a lot with the team that I ran with Insight. So we'd had product data analysts who were product ops people; they would go in, manually dump all the data out.

We'd help set strategy; we could start to put it into formats where it made sense to the executives, and then we set strategy. The thing you want to do is make that repeatable then because otherwise, you've got one person spending—like sometimes we spend like two months doing it because the data was in such bad shape.

But you've got somebody spending, like, then almost eight months a year manually pulling data out. Instead, it should be like, "Okay, we might need this one time, but once we see it one time, how do we automate it so we just hit refresh for the next time?"

Because we want to see the same views, and then we can update it over time. So I think a big piece of it is making sure that we're looking for scaled and automated things.

Lots of tools coming out as well on the market that make me extremely excited for helping to get better information into the teams. So like Pendo just acquired Zelta, and they hook into the sales products—sorry, support and sales products.

So they hook into your HubSpot or your Salesforce and then also your Gong and all these things, and then they digest it, and then they put it into—with their AI models or Genie models—they start to surface up like what are the trending themes from your customers.

Then they put a revenue number to it. Amazing! Now I have a place to start, right? As a product manager, I have a hypothesis on where to go.

Now, the product ops person, though, would be responsible for figuring out what types of tools like that we should get in. So I would say instead of creating it yourself—because we did create stuff like Dovetail, recreated that from scratch at Athena Health.

Jen Cardello pretty much did it herself. Fidelity, like we made research repositories from scratch. Now we've got all these tools; it would be a disservice to not think about what could we plug in and start getting data and information back to the teams as fast as possible.

So I think there's that. I see a lot of teams at scale as well with product ops focus a ton on process and governance. Marty Kagan loves to yell about this.

What I do see is not a bad place to start, and I don't blame the people who start with roadmaps because if you can't tell what people are working on, how can you make a trade-off decision as a leader? That's okay, but I wouldn't over-rotate on all the process unless it serves strategic decision-making, right?

You don't want to go down the agile coach route. We're not trying to control every little minute of ceremonies that product managers do; that's not the point of product ops.

The point of product ops is to enable the engine of product management to fly, right? Like you want to start that flywheel so that we can make strategic decisions at scale, bring transparency to the company, and people can do their jobs better.

People are happier, and it usually takes a lot of work off product manager plates too, so everybody's going to be happy when we actually do that.

So I would say don't think of this as like trying to over-define the process or specify every little detail. It's about what's going to make us better at product management.

All right, so now I want to shift to the third topic that, at least in my mind, you're kind of the face of it. I know this one was actually invented by Toyota, but I feel like you brought it into the product world, which is product kata. Can you talk about that?

Yeah, um, so I learned product kata because when I actually first started consulting, I worked with some people that I knew doing Kanban. So I worked in the agile and the Kanban world. This was back when a lot of people just thought they didn't need product managers.

So I was always like, "I'll teach you how to do product management." They're like, "Oh, we don't need that." I was like, "Okay." So I'm freelancing for these guys, teaching them a little bit more about just like flow and flow-based things and how to use Kanban.

It was like an hour a day that I spent with this team. This is where I learned how to do kata.

So Hoke and Force actually created something called the Kanban kata off of Toyota kata, and it would teach people how to optimize their boards and their flow that way. And I looked at it, and I went, "I've been running experiments for a long time."

And I learned experimentation through Lean Startup Machine, and they had a very described method of doing experimentation that didn't quite fit with me, where it was like, "First, we do a concierge experiment; then we're going to do like a Wizard of Oz; then we're going to do this."

And inside a company, because I wasn't doing my own startup, I was applying this to Open Sky. I looked at it, and I was like, "This is not how I kind of approach experimentation. It doesn't really work."

And I always had a hard time reconciling it back to those models. And I learned kata, and I was like, "This is actually how I think, right? Like, this is how I set up what we should be doing next or how I think through how to do an experiment or what's the next step to take when it comes to product management."

That's why I use it as a tool because I think it's a good mental model, and it's a good way to teach people how to break down the problems they're trying to solve and what's the next step to take.

So the way that kata works is that you look at your big goal, and for a product manager on a team, for instance, that's a product initiative. So what's the problem we're trying to solve with that? Where are we trying to get to with that?

Then you say, "What's standing in the way of us reaching that goal?" So these are the challenges at the beginning of product development. A lot of this is discovery-based, so it's like, "I don't know X, Y, and Z about my customers. I don't know what the problems are that they actually have. I don't know blah, blah, blah."

So it could be a gap in knowledge; it could be the challenge. Then you say, "What's the next step I'm going to take to help face that challenge?"

So first, you want to prioritize all your challenges. Then you go back and you say, "What can I do to learn?" Right? Like, what can I—what step can I do to learn?

So that might be talking to your customers; it might be doing some research yourself. Then you want to go back to the loop and say, "How much closer are we to our goal?" Right? What we're trying to get to.

So you're going to go through that. Now, in tangible product management form, what that might look like is you do some discovery to figure out what direction you want to go in.

So I've got this big product initiative; I want to break it down into what I'm going to solve first. So I'm going to do some discovery around problems; I'm going to get that information; I'm going to define what are the problems that I want to actually tackle, and I'm going to pick the first one, and then I'm going to decide to tackle it.

So I usually am breaking that thing into a product option. That's where we get there, right? I'm setting a goal for that product option, and then I'm cycling through experimentation and releases to help hit that goal.

So what product kata does is it's a way to systematically walk through that. So as a leader, what you could be doing with your team who's trying to break up the product options and work through these product initiatives is by saying, "Hey, here's our product initiative goal. What's standing in the way of us reaching that goal?"

The team goes out, does a bunch of work on their products, they come back, and they surface it up and they say, again, like, "Our challenge for our customers is that they want to market better in e-commerce to the people who are buying stuff. They need help with marketing."

Okay, I don't understand that. Product managers go, "Go do some landscape of it; go figure out what the discovery is."

Product manager comes back, and they say, "Hey, found some specific problems around the marketing issue here. One, they do actually have good knowledge about how to do marketing; we just don't integrate with their tools well, so they have to do a lot of manual work to get all the stuff in our system out into their systems to do this, and it's not combined.

So there's just a lot of friction here in what we do versus what they want to do and what their workflows are. Two, they want to be able to offer, you know, different discounts and bundles to people. The marketing here is not just about marketing; it's also about getting people to come back and to get into that.

So they're thinking about what can they do for loyalty programs. So maybe that's an offshoot of a bigger problem, but maybe that's a product initiative, right? I mean a product option. But we've got these two problems now; which one do we want to tackle?

Okay, let's learn more about how we do integrations into other systems. As a product manager, I'm going to ask myself, "Okay, what is the goal that we're trying to hit with these integrations, right? Like, what would success look like?"

That's going to become my goal in kata. Then I'm going to say, "How far away am I from that goal?" So what's the current state?

So for example, if it's to increase sales for those customers through that marketing or increase outreach, something like that, that's my goal. What is it today?

And then I'm going to say, "What's standing in my way of reaching that goal?" So is it that I don't know something? Is it that I don't—our users aren't doing something? Is it that something's broken?

I'm going to break that down; I'm going to look through all the questions I have to answer, and then I'm saying, "What can I do to learn more about that obstacle in my way?"

So for example, if it's customer—they're not able to do X, Y, and Z because these pieces are broken, maybe my next step is to fix this in a lightweight way and see if sales increase there.

Or if I don't have a way to do campaigns, maybe I take that on manually, run an experiment, run the campaigns for my people, and see if it gets us closer to the goal in that scope.

And then I iterate through that to do a full solution to come out. So you're basically stepping through the kata and just breaking down what problem are you solving into smaller pieces so that you can start to prioritize and figure out how do you learn about that, and then how do you go back and keep seeing if you hit that goal.

The other piece I love about this is it's iterative. So we always talk about how we launch a V1, and we never go back to it. When you follow the kata, you're always going back and saying, "Did we hit our goal?"

And if you didn't, then you say, "What's our next step, right? What should we be doing next to actually hit that? What do we expect? Why didn't we do that? What do we learn from it?"

And the questions in the middle there are always about learning, right? What do we learn? What do we think would happen? What didn't happen? Why? Right? And we're questioning that.

Yeah, kata itself, just saying it, is kind of rhythmic, and I feel like it's kind of like it's developing that rhythm for your product team to break down small problems, iteratively experiment, test, learn, whatever it is, and kind of move forward.

Yeah, and if people want to learn more about kata, Mike Rother is a person who wrote the book Toyota Kata, and he explains it. He comes from a manufacturing perspective, obviously, with Toyota Kata, but his book Coaching Kata is very much about how you deploy this down in organizations, right?

Like, what do we do when you are a leader and you're trying to coach your teams through this pattern and bubble up the strategy and think through it? So all of this actually goes back to a product strategy deployment way, right?

It's a way of getting people to think through strategy, come back to it. And when I see it work really well in organizations, we're asking this why; we're letting people go out and understand it, and we're coming back and saying, "This is what we're going to do to hit it, right? This is what we're going to do next."

So we talked a little bit about product ops and where it is growing and not growing. When we look at the field of product management as a whole, it was on this upward ascent from 2000—actually 1999—to 2021.

So 22 years of basically nonstop growth. It might not have been as fast as people think; it was like roughly like a consistent 3 to 4%, but it compounded into a lot. And then at 2021, we hit a peak product manager in the zero era, you know, crazy SPACs and crazy fundings.

We saw peak product manager, then we saw this decline in 2021 and 2022. 2023 and 2024 have kind of seen that flat since the decline. You have kind of this unique vantage point of working with so many different product managers, big companies, small companies.

So I feel like you can help tell the story for us. What exactly happened there? What caused the inexorable rise? Why did it peak? Why did it decline? And why have we just seen it flat? Why haven't we seen it pick back up like engineering?

We look at it; it did have the same time decline, but it picked back up faster.

Yeah, there's a lot of reasons. So we go back to like the earlier days that you were talking about, right? I remember like working in New York City in the 2010s and people arguing with me that they didn't need product managers.

So what happened? Where what I observed happened is that there's two big shifts in the 2010s that made product management pick up. One, a lot of Silicon Valley companies or founders started to move to other cities and start companies there, and they brought the product management role with them.

They started hiring into it. We got a big explosion of startups in New York City. I worked on Silicon Alley. Silicon Alley was in Flatiron, but like we had everybody like next door, right? Like was up and down the street.

So like product managers everywhere. When I first moved to New York City, nobody knew what the hell I did, and I always was like, "I'm going to go to San Francisco because nobody knows what I do here."

So they started moving around, started making new companies; they started exploding, right? So now we got more product managers there. At the same time, agile hits the scene. All these companies started doing agile transformations. They all pick up this product owner role.

Now, all of a sudden, we've got like in the blink of one year—like imagine a company with 45,000 people, right? In one year, they could have created something like 5,000 product management roles, and I say that happened.

So it's like boom, product management!

So throughout the 2010s, you got everybody all in these large organizations doing massive agile transformations, instantaneously creating product-type roles—not necessarily product manager, but product.

And we get then to the zero era, and then all of a sudden we go, "Oh, we no longer have free cash monies." What do you do when you no longer have free cash monies? You go, "Oh, we have to prioritize when things are successful."

Like they were in the 2010s, people were scaling like crazy, and they weren't prioritizing. And it goes back to company strategy. A lot of people weren't even making strategic decisions because there was just free money, especially with low interest rates, right?

And same in the zero era. So I think everybody expected like zero to tank a bunch of companies, but in tech, we kept growing because money was free.

And then all of a sudden, when money gets tight, what it does is it forces prioritization. And when you force prioritization, you realize, "Hey, I don't actually need a ton of teams."

And then you start laying them off. So I saw a couple things happen in the post-zero era. It forced people to ruthlessly prioritize. They should have done it earlier; they just didn't. They just thought, "If I throw money at the problem, I'll solve it."

And I think that was a big strategic mistake on a lot of companies—just a lot of people not willing to prioritize.

Two, a lot of these companies that started their early agile transformations became more mature. They trained their product people, and then they actually reconciled a bunch of their products and came up with a strategy for it, and they realized they didn't need quite as many people as they had.

So when they reorg, a lot of companies that I saw, and especially in like the Fortune 500 space, they reworked from like a component standpoint.

So every product and every feature had a product manager over it, and you ended up with these people who had this much scope, right? And not much to do because it wasn't prioritizing strategy or it wasn't broken.

So they were just like creating work, and once they got to a certain point in a certain maturity at these larger companies, I think they realized like, "Oh, I don't need to do all of this," or "I can actually level up my product people over a larger feature."

I don't need everybody on every single little component, right? So a lot of reworks happened; a lot of people were let go because of that.

I've also been in a lot of companies too where during these agile transformations—and I've done a massive amount of them, training these product managers at large Fortune 50 companies with Product Institute—like we go in, we train all the people, we help them with their transformations.

What happens is after some of this training, when people are new to product management, they go, "Oh, I don't want to do that. That's not what I thought that was."

I see it happen all the time. Like, I think we take it for granted how we always hear about people who always want to be a product manager because they want to be the mini CEO.

Once they get into the role, I see a lot of people say, "I don't want to do that, actually. That's not what I thought it was. I thought I just got to make all the decisions. I did not realize I had to deal with all these people and get them aligned, right? I did not want this kind of responsibility."

So I also see people backing down from it, backing away from it because it is a hard job. It is a massive amount of work; it's a massive amount of people skills.

You know, like you said, you're working 50 to 80 hours a week. Like, you just—you don't turn it off. So I do think a lot of people too are choosing to get out of product who might have thought it was very flashy and very cool.

Now that they spent a couple years in it, they were like, "This is not really what I thought it was going to be."

Yeah, it seemed like it almost was going to take over like consulting and banking, and it just became like that career that everybody wanted.

I think where the numbers were at Wharton, where I went, was like it went from something like 2% of grads to like 16 to 17, and like IB and consulting were each at 20. So like it almost hit that, and now it's kind of retreated back to like a more steady, like probably better for the field level.

Yeah, hers was the same way. Like, all my students wanted to—well, obviously, a top product management—so all my students wanted to be product managers.

But at the end of my class, same thing happened. A lot of them were like, "Eh, no, I think I'm going to like stick with consulting or sales. Like, this was not really what I thought it was going to be."

And I think that's fair. It's not for everybody.

But I do think it's not like we don't have a one-to-one ratio of product managers to engineers, so it's going to keep growing. I think product management will keep growing as a discipline, probably a little slower now.

But there are still companies that are very early on in their digital transformations. There are still companies who are just starting to get into software, and it's hard to believe sometimes because we work in software all day, but there are still companies just starting out.

So they're going to need product managers. They're going to need, hopefully, experienced product managers as well, but they're going to be creating the role, hopefully training their people, and then hopefully bringing in some more product managers, and then it's going to scale.

And that's how it works. So I don't know if it's explosive growth that we're going to see like we did with the agile boom, but I do think we're going to see a desire for more competent product managers.

I already hear that out there in the world, right? Like, I need people who know what they're doing here, who can really dive in and understand that their job is to figure out what the customer value is that's going to drive this business value, right?

And put that together and turn it into a solution, get it out the door, right? We're going to need more of those people. We're going to need more competent product leaders as well.

So the consequence of this peak in PM that we had in 2021 is that about 5% of the field was left without a job. As we've described, you know, one or two of those percentage points—so 20 to 40% of that 5% have left the field.

But that still means like 3% of the field—and this is my experience—is without a job. Like, there's just an enormous base of experienced PMs who are job searching. You must see this in your inbox as much as I do.

What are like the tried and true advice that you're giving to these people who do have PM experience but they're struggling to find a PM job?

Yeah, it's hard. It's hard because a lot of people aren't hiring right now, and I have a lot—I have like a lot of empathy for this. I wish some people need to hire. I see so many organizations out there where I'm like, "Please just hire an experienced person. Like, it's going to go much further."

Right? And I think if you are an organization in that perspective, like now's a great time to hire in some experienced people, right? They're out there looking.

And people were fighting for product managers a couple years ago. I also think I've heard this from some of the product people too, especially ones that got laid off from really large companies.

I think like Google, Facebook, and Amazon ruined the product management market a little bit, and they did a bunch of the layoffs too. They inflated the salaries so high for product managers that I had people like graduating from Harvard MBA and didn't have any experience in product management whatsoever, got a job at one of these big companies, and they're making almost like $300,000 a year.

$300,000 a year in a growth-stage company is like the base salary of a CPO. Who can afford that, right? There's only a couple Amazon and Facebooks in the world. There are a lot more growth-stage companies.

And I feel bad saying this to these poor people who got laid off from those roles making a bunch of that money because they probably bought houses on that, you know, with that and the mortgage and stuff.

But what I think we're seeing right now is a correction of the market into value realization for this role because $300K is not the salary of an individual contributor PM. It shouldn't be.

And growth-stage companies and smaller companies and even like just normal-sized enterprise companies, they're not going to pay that for an individual contributor PM.

So I'd say like for the people who are looking, this might be hard, but you might need to take a step back to step forward in some of these companies, and you might need to take a pay cut to do it.

At the beginning, I talked to a ton of people who were not willing to do that, and I do realize that everybody's got different financial circumstances.

But if you really want to be realistic and you want to get a job now, it's the smaller companies that need help that are going to be hiring. I'm not telling you to go down $60,000 a year, but like you have to kind of reevaluate what you had versus what you're going to be able to do over time, and you'll probably get back up there.

But I think I'm kind of like mad, honestly, about how bad I think these large, you know, FAANG companies set up product managers by overinflating that, trying to take all the talent, and then being like, "Oh, actually, we had nothing for them to work on. Let's just lay them off."

Right? And it was probably cushy while people were there, and it was nice, but like that wasn't the reality, and now it just left all these poor people in like a really hard spot.

And I think it's going to take a while to come back from that. So I think that's a situation. If you're on the fence and it's like you've been like, "Oh, it's not really my salary," I've had some conversations with people about it, and I say this because I have had conversations where people are like, "I'm targeting this," and I'm like, "That's just really not realistic for the type of role you're looking for."

So there's that aspect of it. Now, there are other people who have very realistic expectations, and they just want a job, right? Like they just want to get into it, start doing it.

For them, I'd say target smaller companies. A lot of people, when they're looking to go somewhere, they almost always reach out to me, and they say, "I want to get a job at a FAANG company." I'm like, "Why?"

Right? If you have experience, you can actually probably go into a higher-level role at a smaller company and take a step up, right? Or just be like a senior IC that gets stuff done and probably be well paid for it.

So like look for the smaller companies because those make sure it's stable. Make sure there's cash flow and stuff, right? But those are the ones you're going to be hiring because they need it.

They need help. They're the ones hiring right now. The really large companies can get by for quite a while, and they're probably going to freeze hiring quite a bit because they don't need it.

They have so many people already, right? And they could just reprioritize down and cut initiatives, and they'll be fine, right? Like they might not make their goals; they'll make their goals, but like they might not grow exponentially over the next couple years, but they can wait it out.

They have enough cash; they will wait it out. The smaller companies, if they don't grow, they die, so they will need to hire people. They'll be looking for it.

I do hear of a lot of smaller companies hiring, so like that's where I would look at how do you find those jobs because it's hard to target small companies.

Go to venture capital websites; they list all their companies that they invest in. You can find a whole portfolio of them. Sometimes they even list what jobs are open in those companies.

But go to all the websites, look at all the companies they invest in; they'll give you ideas of what's out there. You may never have heard of them, but they're out there.

I think that's a great way to start looking for smaller tech companies, right? They're in that stage. Again, ask them the questions when you get in there: is it stable?

Is it okay? If you go too small, sometimes they're not stable; sometimes they don't have enough runway to scale. But if you look at some of those mid-stage scale-up companies that are well-invested, also look at the timeline on when the investors invested.

If it was recent, they've got enough runway for a while.

Yeah, I really have been giving the exact same advice, and I love those mid-stage companies. Like, those are career-launching companies. It was for me. That's how I made the shift from IC all the way up to director at what is now a public company.

But when I was there, ThreadUp was just a Series C company. We took it through Series D, Series E, and I was able to grow with the company.

I've also had to talk a lot of people down from the level, which is like, you know, if you manage two or three PMs, I think that rule has kind of been eliminated of the manager of two to three PMs these days.

It's like managing like 10 PMs, so if you manage less than 10 PMs, it's like you might have to take an IC role.

But what I really want to talk about is this aha moment I had when you were talking because I've always struggled with, like, that—as I mentioned, the growth of PM was like 2 to 3% per year, but the market cap of tech companies was like 10 to 11% per year.

So I've always wondered, like, if there was this huge delta. And then even now, in the last two to three years, again, they've returned back to that 10 to 11% growth.

Why couldn't they sustain the PM growth? And I think I realized it is because of the market size of PM salary.

So the number of PMs was going up by 2 to 3%, but PM pay, like you mentioned, was going up like 8 to 9%. 2:3 + 8 to 9 equals PM market size was growing faster than tech market cap.

And now we've had that correction where it was like ever so slightly growing faster than market caps, and so we've had to see the tamp down in pay where especially these growth PMs are shifting from public companies to growth stage where they're getting paid less, and we've also seen slightly fewer PMs.

I feel like that's actually the story of what's happened in the industry.

It's a great point; I think so too.

So that's what's happened for folks. And what's also happened then is because those FAANG companies were paying so well, we got all the consulting IB people who want to like increase their salary super fast.

Like they want to like get to that 10 years; you become a consulting partner, you make a million a year. Like, I think that's what most people kind of aspire to.

And so we also got these like money-hungry people into the role who might not have been the best fit. So we've kind of had this like natural exodus of people who might not have been like builders at heart but were like a little bit more compensation motivated joining the role.

Yeah, I definitely saw that too. Or not even compensation motivated, sometimes like ego motivated, where they thought they were like the mini CEOs, right? We attracted a ton of those.

But I did see a huge shift in people coming out of like banking, IB, sales type things into products, and they thought that that was going to be their cash cow.

So I think a lot of those people were wildly surprised once they got into the meat of it. But now that the ceiling is not astronomical for them, unless, like, let's say you become either a founder or a CPO and you hit it big, right?

Like that's where you're going to get super rich off of these things, and I think that's realistic. But I mean, I think that's realistic for some people but not for many.

When you come back to reality, you can be paid well as a product manager, and I don't think it's anything to sniff at, like what our salaries are, but it's definitely not the spend two years and make a million dollar type role unless you like just happen to hit—unless you were at Nvidia for a while, but you happened to get lucky and work at those 1% of companies.

But you can't really bet on that; that's kind of the problem.

No, too many people make the bet on that, and they end up working at—was it Bolt? That company that like hit 15 billion in valuation and now it's down to like 500 million?

And so you end up working at some of those too there.

And you know what? It's funny because I see people not understand too that just because you're in a venture-backed business doesn't mean that they're going to exit for millions of dollars.

And every time there's an exit, everybody's like, "Oh, congratulations! Like, oh, you must be filthy rich now!" And people just fundamentally do not understand what stock typically translates into in one of those—when in the majority of exits, let's put it that way.

Like you get your Facebook every once in a while; you get your Salesforce every once in a while, but 99% of companies don't do that. You might make a little bit of a bump, but it's usually not like life-changing or retire money, right?

It's like, "Oh, this was a nice little down payment on a house," right? But not like, "Okay, going to go buy an island in the Caribbean."

Yeah, exactly. It's not like island money; it's just down payment on a house money.

But hey, like most of us, we would have been happy with that when we were growing up or when we were thinking about what job we wanted.

So the other thing that's happened with this 5%, which is a lot of people, it turns out, because there's millions of product managers, so this is like tens of thousands of people, is a lot of them want to become like us.

Whether it's writing a newsletter or doing a podcast, which we both do, or coaching, which you also do, or training, which you've talked about, or interim CPO, which you've talked about, or consulting, which you've talked about.

So I was wondering if you could kind of open up the books on Melissa the business a little bit and maybe just from a percentage point of view, help people understand how do you make money today, and what are the main sources and buckets?

Yeah, um, I'd say like the majority of my money comes from my online school, Product Institute. So I started building this back in 2016. I was teaching in-person workshops.

I was one of the first people to do the product management online, and while we do sell to individuals, I mostly help large organizations with their product management training.

So I've gone through iterations with this too. I talk about because I've done so many things in the past. So let's talk about like kind of historically where did I come from and like where is it now?

I started consulting. First, I started freelancing, and then I started consulting like 10 years ago. And when I first started doing that, I was going into companies and like being an intern PM, right? Or an intern product leader too.

So I would go into companies; I'd spend like three days a week there and do that. I was speaking at a lot of conferences at the time too, so I was like flying around doing that. They did not pay me; I just thought of it as a way to like get—I got paid for my like plane tickets, and I was like, "Cool, I'm going to go see these places."

So that was fun. But then my name started getting out there, and I started getting asked to come into other companies, right? So I'd come into a company; I'd talk about product management, but then I'd usually do a lot of work with their teams.

So I'd go in, and I'd be a product manager, and I would help train the people around me, but I would also be like a player-coach, right? I was doing the work, and I was helping level up the team around me. I was setting up processes.

I was basically like an interim VP of product to a lot of places. I was doing this for a while, speaking more, and some of the large companies were going through agile transformations.

They hit this point where they were like, "What do I do with all these product owners?" They called me and they asked if I could come in and train their product owners.

That was the first signal that people actually cared about product management. I spent all this time trying to get tech companies that never had product managers to adopt product management back in the day, and nobody wanted it.

So that's why I would go in and do these interim roles, but nobody was—so many companies were just not interested in it. They were like, "You come in, you do the work, or we don't have product managers at all," right?

It just wasn't a big thing. So now I'm like, "Oh, there's signal coming from these enterprise companies," and I started to get in there, and I was training their product managers and working with them.

And I realized how broken it was in these large companies. So I did a lot of working with teams, doing transformations with teams.

Eventually, I was flying around doing these workshops everywhere. Like, I trained at Lloyd's Bank; I trained Capital One at one point.

And I said, "I got really tired of doing that. What if I put it online and recorded videos?" And I went back; I started a—I made a little studio in my basement in New York City, recorded a bunch of videos, and I started shopping around to the companies that were coming to me.

And I said, "Hey, what if you watch these videos first, and then I come for two days instead of a week to do training?" And they were like, "Oh, that's awesome! That's fantastic!"

And I'm like, "Great!" So I started selling the videos. I only made like a couple of them at first. I'd go in, I'd do the training, I'd do the rest of it in person, and then I kept building it and building it.

And I found that more people wanted it, and eventually, I got to this point where I get my biggest consulting gig at the time was going into Athena Health, and I was a full-time consultant there for a year and a half, helping lead a product transformation.

So at first, I came in, and I trained all the product managers. We had 365. We used Product Institute. I set up a community practice; we rolled out training across the organization.

And then we got done with training, and we were like, "Okay, what's next?" So then we went and we started to optimize how the product teams work.

Then I started implementing product operations there. So this was one of the times where we looked around, and I'm working with their C-suite, and I'm working with their CEO, and he's like, "Hey, I can't get the information I need to like present to the board about what we're doing."

I'm going, "Oh, we need—like JIRA is not working. Like we need something more than JIRA."

So we're going around; we're trying to—we hacked together JIRA into this like product roadmap. Mess—it was not good, but like we—it was the beginnings of like starting to put all this blocking and tackling together to scale this right across this gigantic org that was worth, you know, $8 billion at the time.

So we're doing that. Then I'm working with the leaders to create the strategy and deploy the strategy. And throughout that whole thing, I learned so much about like what this was to do at massive scale.

And this is where like a lot of the product ops stuff started, where a lot of these things started. At the same time, I'm working with a couple other enterprise organizations and flying around.

I was on the road pretty much every single day, and I got done with that, and I was like, "I hit this wall, and I just said I can't travel like that anymore. I need to go home," right?

So the end of a year and a half, I said, "So long, I need to go back home." This was in Boston. I was like, "I got to be in New York City a little bit more."

And that's when Insight Partners made and said, "Do you want to start our product center of excellence? We don't want to hire somebody full-time, but we'll, you know, we'll do a partnership with you if you hire the people and train them as consultants to go do what you do."

So then I started working with them. We also had outside consulting clients, but I ended up growing this team. So I had a team of, oh man, we probably got—we got to like five full-time people and a bunch of consult contractors where we go into the growth-stage companies, and we play interim CPOs.

We'd help them with—I help them with hiring chief product officers. We help them with setting strategy, setting up product ops, BS blocking and tackling for insights teams.

At the same time, we're doing that with other companies.

This episode is brought to you by Dovetail, the AI-first customer insights hub for all teams. Dovetail has always been the go-to tool for teams that want to find insights in customer calls, user interviews, or documents.

Now they've stepped it up with the release of Dovetail 3.0. It's three new products and a ton of AI features that make it faster and easier than ever before to truly get to the heart of what your customers want.

You can get a real-time pulse on what your customers are thinking with Dovetail's automated feedback analysis platform, Channels, or pull summaries and insights from every customer interaction your team has ever had using their conversational AI, Ask Dovetail.

You can even recruit from over 3 million participants directly in Dovetail. All of this is just the tip of the iceberg. Dovetail wants to give everyone in the organization instant access to their customers at any time.

From roadmaps, discovery, to strategy sessions and more, it's never been easier to make customer-centric decisions. The good news? Listeners of this podcast can try Dovetail's Pro Plan along with their newest products and features free for 30 days.

Just go to dovetail.com/aash.

And this is—I had been doing so much speaking and writing, and Escaping the Build Trap had come out right then. At this time when I was working with Insight, things started to speed up, and people started reaching out for more and more help.

So I still had Product Institute going, but we just had one course. Then I had all the consulting work going, and I was trying to like manage both of these things.

And on the Product Institute side, I tried to—I hired some people, and we started to create more courses. And then at this time, we're scaling, we're scaling, we're scaling, and like COVID hits, and things are going totally fine for the business.

It actually was phenomenal year just like revenue-wise, but I realized I was doing too much, and I like completely burnt out. And I was like, "This is so unsustainable."

And I looked at what I was doing, if you want to say like Melissa as a product, and realized that it wasn't scalable. And here I am teaching everybody to scale things, and I'm not scaling myself; I'm not scaling what we do.

And I realized consulting was not really what I wanted to do because running a consulting agency, especially like it's not a scalable model. You have to go out—I was doing sales 24/7.

I was good at it; like it wasn't like I was bad at it. I was really good at it, but it was not what I wanted to do. It's not where I get my energy.

And all of my team was doing all the fun work at a certain point, right? When we trained them, we got them all up and running; they're doing all the cool strategy stuff that I was doing before when I was like more hands-on.

And I'm looking at this, and I'm like, "I have to hire more people if we want to take on more clients. If we don't take more clients on, then we don't have enough runway, right? Like you have to say yes to a bunch of things when you're scaling."

And then we got more people on here, more salaries, more running, and I was like, "This is just untenable."

Like at a certain point where I said, "Am I getting joy out of doing this?" And I realized, "No."

So at the end of 2020, I shut down the consulting agency. I still work with a bunch of them. Denise and Tammy were my VPs of product, and everybody else went inside one of the companies that we worked with, either through Insight or somewhere else.

And I kind of like took a step back and tried to figure out what I wanted to do. And I went through this whole thing of like I had tons of inbound coming in.

I sent a lot of it to the people I used to work with consulting-wise, and I looked at it and I said, "What I really want to focus on, though, is teaching. That's what I love doing."

And Harvard had approached me right before this, so I went to Harvard and I taught there for a couple years. But Product Institute kept growing.

Yeah, and it kept growing and growing until this point where I couldn't ignore it anymore. And I had always said, "I'm going to go focus more on Product Institute," and I just was never disciplined about it because I like learning.

And anytime there was like a shiny new opportunity to do something I hadn't done before, I'm like, "Yay! I want to learn that!" And I go do it.

And then just over the past two years is when I got a lot more disciplined when it came to Product Institute, and I said, "That's my thing that scales, and that's how I can help serve thousands of people rather than just one customer if I do the consulting."

So now what that work all looks like is I still occasionally say yes to like certain things, but I do most of my training for teams or individual product managers, and now getting into a little more with leadership is through Product Institute.

It's all pre-recorded videos. We're about to launch a product strategy course just about everything that we just talked about aimed at that mid-level of product leader—not CPOs, but you know, right below it, looking at a product strategy.

So stay tuned to that for that if anybody's interested. Then I do CPO Accelerator, which is a—I run it twice a year right now just from a time perspective, but we do small cohorts of 20 to 25 people who are either VPs or first-time CPOs.

And it's really to help level up people who are great product people into strategic product leaders and executives.

So when I was working with Insight, there was this big gap where we were trying to hire CPOs, and there was just not enough strategic product leaders on the market to meet the demand of what we were trying to hire for.

And it took forever. Like sometimes I'd run these searches for like six months. I wasn't the recruiter, but I interviewed everybody, and I looked at it, and we were like, "We need a way to level up this talent."

And it's been awesome because we've had over 250 people go through it, and a ton of people have become CPOs or kept their CPO job. That's how I mark it. I'm like, "You kept your job! That's awesome!"

Like, you know, if you're a great product leader, I don't want to see them get replaced. Some of them too have gotten into CPO roles and again said, "Like, I want to take a step back. I don't know if I really want to be the executive."

And that's okay, right? Because it's a lot. It's a lot of work, and it's a hard job to be a CPO.

But that's the class that I teach. I do bi-weekly like 90-minute sessions for six classes, and then we have a community around it.

That is going to be our executive offering for Product Institute. And then I'd say the other thing that I've been doing is I go into executive teams at larger companies, and I help them with this workshop.

I do set up, evaluate their product management operating model, and then try to create a roadmap for change.

So whereas at Athena Health, I went and I led the change myself, what I realized is that if you want companies to effectively change over time, you need the product leader and the executive team to really own that change.

So now I try to take an enablement approach to it. We'll do this workshop, help them set up a roadmap, and then I check in with them periodically and make sure they're going in the right direction.

And that's usually working with like CIOs of larger organizations, CTOs of some of the largest banks, and CPOs too if they have a CPO. They're all different phases.

Some are like, "We have product managers; I'm the product leader; I'm just trying to do this well, and I want best practice advice." Some of them are, "We don't even have the product management role defined, but we would like to do that."

So it's at all different phases, but it's helping them understand the entire landscape of what we're trying to do here and then helping them show the path forward and then giving them the tools to go out and implement things and then being that voice to come back and check with them.

So I do that with a couple companies a year, and then a lot of stuff feeds into marketing those services. So I do a lot of speaking, which I now get paid for, which I'm very happy about.

Yeah, but I just can't—it's a good filter to say no to things. I don't love saying no, but it is; it's a time thing.

I do the book writing, and again, that's a scale thing. So with product ops and escaping the build trap, it's very like how do I not repeat myself 80 times?

Like how do I give somebody a guide to go read something, and then we can dive into it, right? And then I do the podcast, and the podcast came out of the same reason of everything else.

I got a lot of people asking me one-off questions in my email saying like, "Hey, can you tell me about this?" And there were so many similarities.

I said, "I'm so tired of writing. I was so burnt out at this point. What if I just answer them? I could talk about anything forever. Like, what if I just answer them and put it on a podcast?"

And somebody was like, "You can't just answer questions on a podcast." And I was like, "All right."

I also am curious just what other people are doing, so like I'll interview people as well. So that's how the Dear Melissa segment on the Product Thinking podcast started, and then I interview the guests.

And it's been really cool because I get to go inside a lot of companies, but I don't get to see them all. But now, like you probably see talking to people on the podcast, I get to learn about all these other ways people are doing this, and I get to see the similarities; I get to see the differences.

I got to ask people questions, and that's been really exciting. But what's also exciting for me is that when I have people come in and say to me, "Hey, like I'm in a large bank, and I—you know, large banks don't do this, or I'm not sure how other people do it," I'm like, "I had the CPO of JP Morgan on my podcast. Like, listen to Anish; he's done it already. Like, let him tell you about it."

Or Shai from US Bank; she's also run it. Like, I love being able to get people information so that they can do their jobs better and so that they can make product management better at their organizations.

So I try to commit myself to things like that that will help people scale the power of product management.

So that's a long-winded way of saying that most of my work goes into developing content for Product Institute. So that's been like a big push this year.

Podcast recording, as you probably know, takes a long time. I'm actually pretty shocked on it, like just how long it takes.

So that's a big time sink there. And then I work with executives.

Amazing! You've tried it all. It's interesting your journey about figuring out what you like versus necessarily what the market is paying you a lot of money for and kind of finding that sweet spot over time.

So there's a lot of lessons for people in there

Get Our Mobile App

Mastering Product Strategy with Melissa Perri, Author of Escaping the Build Trap

Transcription