Product to Product: Melissa Perri on how to think like a product manager

Product to Product - Melissa Perri

It’s episode two of Product to Product‘s second season, a podcast for / by product people!

Listen to the episode below:

This season we continue to explore the human side of product. Up next to share her real-world, practical stories of navigating the human-related aspects of the product space is Melissa Perri, CEO and founder of Product Institute and Produx Labs.

As a product consultant and founder of a product school, Melissa has trained over 2,000 PMs across her career. And her mission has always been clear-cut: teach people how to effectively think like a product manager.

Seeing as product thinking is a unique skill in itself, our CEO, Latif Nanji, sits down with Melissa to investigate what it means to think (and not think) like a PM, what fuels product thinking and how aspiring / existing PMs can learn this abstract skillset.

The episode can be listened to above, and we’ve also included a transcript below. You can subscribe to Product to Product on iTunes (here) and Google Play (here), or get the latest episodes delivered to your inbox by subscribing here.

Latif: Thank you, Melissa, for joining us on our Product to Product podcast.

Melissa: Of course! Thanks for having me.

Latif: I wanted to start by asking you about Product Institute. Can you talk a little bit about what it is, and why you started this education initiative?

Melissa: So, Product Institute is an online school for product managers to level up their skills. Right now, we have launched our first course, last year, which is a 10-week program in the fundamentals of product management. We call it our foundations class. It really goes over everything a product manager should know, from how to identify and set good goals, to discovering problems, talking to your users. That’s our first stab at the first course. We’re going to be launching more courses this year, a little bit smaller, and we’re going to do some fun stuff with it.

I think the overall goal that I really see for this school is to make it that, a school, where people can come and learn. It’s not just a course. It’s not just one and done in 10 weeks. We really want to build it into something where you can come, learn new skills, new techniques and things about product management that you don’t find in many other places. And feel like, even if you’re an experienced product manager or somebody who’s just starting out, there is just a wealth of information there for you to learn from.

Latif: One of the things I really love is the positioning of this course, which is, how to think like a product manager. From your perspective, what does it mean to think like a product manager?

Melissa: This is something that I noticed as I was training product managers over the year. I’ve trained a couple thousand people at different companies, and I think what sets a decent product manager apart from a really great product manager, is really the way they think and approach problems. To me, thinking like a product manager is about problem solving. It’s about synthesizing a lot of information, understanding the system, trying to piece together what is the problem, breaking it down into small manageable chunks so you can analyze it, and then figuring out what is the right solution from there.

That’s what we try to teach throughout this course. We teach practical tools throughout the whole thing, but what I want people to do is really walk away being better decision makers; being able to take the information we give them and apply it in real life, to think through why are they doing things. To me, that’s the most important part. I think with some of the other courses that I’ve seen or have been a part of, they teach people the tools. But in practice, what happens is—as a coach, I go to these companies and I coach people—they grab the tools and they’ll start putting them into practice, but some people will peak at that point. They know how to use a tool, but they don’t know how to use it within the system. To me, making that transition is really important for a product manager.

Thinking like a product manager involves making the right decisions about what tools, what processes we use, where we are in the life cycle of the product, and really understanding the problem, breaking down a large system and figuring out how it all relates to each other.

Latif: That’s definitely a challenge that I’ve experienced with some of the PM’s I’ve worked with as well.  What does it mean to not think like a product manager, and how do you undo previous bad habits in terms of thinking?

Melissa: I see a lot of people treat it like a linear process. That’s something where I’m trying to really break down in the product managers I teach. They were taught that you identify the problem, figure out what the solution is for the problem, spec it out, figure out what’s going on, hand it off to the developers, develop it, put it out, get feedback, and go back to the beginning. That’s really just one piece of it. There are lot of tools that come out in the market today that promote that type of linear thinking. I think people see that it’s just do step one, step two, step three, for every single use case.

What I want product managers to understand is it’s not a linear process. You may never start in the same place, depending on where you are. One of the things that I try to get all my product managers to do when I coach them is for them to stop and think about what they know and what they don’t know. We always go back to these, known knowns and known unknowns.

"To me, thinking like a product manager is about problem solving."

What I try to ask them is: Where are you? Do you know what your goal is? No? Okay, we have to go figure out what your goal is before we can do anything else. Do you know what problem you’re solving? No? Okay, we have to go figure that out. Yes! Okay, you might know it. Maybe let’s just confirm and skip it. We don’t have to spend four weeks, five weeks, six weeks in problem exploration mode if you know what the problem is. Yet, I see some new product managers get stuck there. They think they have to spend a lot of time in that phase. They think they have to go through it. But to me, if you’re 100% certain about what the problem is, it’s readily apparent. You just confirm and move on.

The same thing goes for solution exploration or really iterating on a concept. Having a first version of a product out there and sitting on it. So what I see is people fall back to that linear approach, where they must go through problem exploration. You do want to acknowledge each one of those pieces, but if you’re 100% sure about those areas, you need to move on. Know that you may discover that one of your assumptions about the solution that you thought was right, was wrong, and then might have to go back to the beginning. It’s not a root path. Doing product management is not just one simple process that you follow. It’s about analyzing where you are, and depending on where you are, choosing the right path and the right tools to go forward.

Latif: I really like the concept of making sure it’s not just a linear path and really mapping out your goals to see your known knowns and your known unknowns. How do you tie that concept, to the idea that I was reading on your blog, called the Build Trap?

Melissa: The Build Trap is really where we get stuck in this mode, as a company, releasing feature after feature without really stopping to think about: Is this the right feature? Is it hitting our goals? Are we aligned to the company vision? Are we actually going after the right thing? Instead, we really focus on the output of how many number of features we released. We think value is tied in the quantity, rather than the quality and problems we solve for our customers. 

I see so many companies really suffer from it. They look at productivity as the amount of things you release to customers, rather than the amount of value you provide. I think quantity and value get really mis-concepted and they get tied together, when sometimes, that’s not really the case. When companies are stuck in the Build Trap, they don’t really have a firm or set product management domain in their company. They’re not really setting great goals from the CEO level, down. They’re not focusing around what’s really going to propel the company forward. They usually lack a product vision. They are being measured for success based on output, rather than outcomes which tie right back to those goals. That never helps break the cycle. You can always increase an output, but it never really tells you if you’re providing value.

They also get stuck in this because they don’t really have a fully-functioning product management and strategy cadence to figure out what the right thing to build is, and then feed that into their agile development processes. Agile development processes are more about how you work together. Not about trying to figure out what to build, and is it the right thing to build. We need to marry those two sides together so that we have a fully functioning system throughout the company, where we’re building the right things and we’re building them really, really well, and getting them out there to our customers very efficiently.

Latif: One of the concepts around product strategy that I’ve always struggled with is, when can a PM really start to take ownership of it? How have you found that some of the work you’ve done at the Product Institute ties to that? Do you find that you have to take students through a lot of how to think like a product manager first, before they can get through product strategy?

Melissa: Yeah, I think it starts with, how you define strategy, too. What is a product strategy? How do you come up with it? How do you define it for the rest of the company? Where I see people get stuck, especially executives, is they think that product strategy is like a plan. I’m gonna build these features at this time, and it’s all going to ship on these dates. Strategy is not supposed to be that. It’s supposed to be a framework that helps you make decisions. Good strategy is about giving a people a framework in which they can look at the decisions they’re about to make, and then be able to decide whether or not it fits with the product they’re going to build.

When we teach our product managers about strategy, we set it up a little bit differently. We say, there’s a few components of your strategy you should know and that you want to refine, but you don’t need to know the answers to all the strategy right off the bat. You have to do some research. You have to do some experimentation to really build a great strategy. For strategy, when you look at the vision of a product, you want to ask: what value will this deliver for our customer, and through what means? What are the principles that we build this product based off? You want to create a cohesive vision that people understand.

"Doing product management is not just one simple process that you follow."

Now, sometimes you can’t do that right off the bat. If I’m faced with a new problem, and I have no idea what that problem is, I have no idea how to solve it; I can’t just pick a vision out of thin air. I have to explore the problem more. Maybe some experimentation to figure out what’s the right product to build, right? The vision for some of these larger things, they might evolve over time. I have to look at the market. I have to look at how we have more advantages based on how we build it and what channels we use.

Then the other part is really about aligning your goals. Strategy’s all about reaching the vision. How do we build to reach our business goals, while also looking at the vision for the product and building in line for that? To me, it’s a system of having great vision, goals that you want to hit, that help you align and prioritize what I should do in order to get to that vision. Also, some constraints. What do we not want to do? I think that’s not something that we talk a lot about in product management, but it’s really important. It’s important to prioritize, in light of things we don’t want to do, so we’re not distracted.

Latif: What are some of the hardest lessons, product managers who go through the Product Institute, need to learn in order to think like a PM?

Melissa: I really think it’s about analyzing where you are, and stopping to think that way. One of the tools that I try to teach everybody is called the Product Kata. It’s a framework based off of Toyota Kata, which was basically a framework that Toyota used to help all their employees improve. They would analyze where they are, where they wanted to go, and come up with ways to improve the way they worked together.

I took some of the foundations of that and created the Product Kata in product management for that. What the Product Kata does, is it asks you a series of questions, and you do this repeatedly. It trains you to think like a product manager. So, the first thing is set the goal. Then it asks, “In relation to that goal, where are you now?” We talk through that. Then you ask, “What are the biggest obstacles standing in the way of me reaching that goal?” So, what questions do we have to answer before we feel confident making another move. We look at those and choose the biggest question we have to answer, out of those obstacles, and then we ask, “What can we do to learn it?” So, maybe it’s user research. Maybe it’s an experimentation. Maybe it’s gather data. We design a way to learn and answer that question, and then we ask, “What do we expect to happen after we run this experiment?” Do we expect to have data back? Do we think we know what the answer is? Then, we run it and at the end, we ask, “What did you learn?” Then, we do this again starting with, “Where are we now?” Did we move closer to our goal? Did we go further away? Are we still at the same spot? And, we keep repeating it.

So, the Product Kata is something that you practice habitually. It’s something that you should do every couple of days, every week, depending on how long it takes to answer that question. You meet afterwards and step through it. As a coach, what I do with my product managers, is ask them all those questions to help them think through and formulate their thought process. To me, that’s really thinking like a product manager. It’s breaking down, what I have to learn. Where am I right now in comparison to my goal? What is something I can do to get more information?

Latif: Can you give us a couple examples or exercises that people can do to think like a PM that can make the learning curve less steep? 

Melissa: With product managers, what I would say is, start by really looking at what you’re currently working on. How do you know it’s the right thing to build? Do you have goals? Do you know what the problem is? Do you understand it? The first thing you could possibly do is really diagnose where you are. To me, there’s a couple stages of product management that we all have to go through, and then apply the right tools to it.

The first one is goal setting. Do we know what the goal is, or what the business outcomes are for this product? If we don’t, we have to do figure out what those are. The next one is really, problem exploration. Do we know what problem we’re solving to help reach those goals? If not, that’s where we do user research. That’s where we get in touch with our customers. That’s where we pull data. That helps us break down and narrow our scope. Once we know that, we define the problem and we move into solution exploration mode. This is really asking, “Do I know what the right solution is to build?” If I don’t, I have to experiment around it.

"We think value is tied in the quantity, rather than the quality & problems we solve."

For example, I like to use a checkout page. Checkout pages have been explored. People have experimented with them. There are pretty well-known best practices in the industry of how to create checkout pages. Maybe I take some of those best practices. I implement a checkout page, launch it, and start measuring to see my results. Maybe I don’t have to spend more time doing smaller experiments where I’m really crafting a unique user experience, right? I can just implement something.

Being in solution exploration mode, that’s where you make those decisions. Can I just choose the best practices if it’s a very well-known problem? Or, do I have to spend more time really exploring what the best solution is? Once you know what the best solution is, you define it. What is the vision of this solution? Then you break it down and start going through your processes to really build and launch it in incremental value, so that you can iterate on it and get feedback.

So, any product manager who’s starting out and really trying to figure out how to think like a product manager, I would tell them to really go back through those phases and figure out what phase they should be in, and if you’re using the right tools. You shouldn’t be building features in production code yet, if you’re really not sure what the solution is. You have to spend some time discovering that, mapping it out, maybe doing some prototypes or doing some other types of experiments. So, that’s my advice for anybody who is trying to figure out who to think like a product manager. It’s about really diagnosing where you are, and applying the right tools, depending on that phase. If you’re in problem exploration mode, you should not be making prototypes.

Latif: Absolutely. I’m curious to know how you think about what you just said in the context of B2B versus B t2C? 

Melissa: I always get this question about if my advice is applicable for B2B versus B2C. I don’t think there’s really a big difference between how you approach these phases I’m talking about. These phases still exist between B2B, and B2C. How you approach them might be a little bit different between B2C, and B2B. I don’t think you go any faster through them. I don’t think you go any slower, depending on your context. It’s really about the problem you’re solving.

One of the clients I’m working with, they’re building software for healthcare. It’s a really complicated, big software, and it’s a massive team building it, but they still approach all of the same patterns that we talked through. You have to because in B2B, there’s more pressure because you have clients banging on your door to sign contracts, but requesting features. What we try to get all of our product managers to do, is take a step back and say, “You know they might be asking for this feature, but it might not solve their problem.” It’s never the customer’s job to solve their own problems. It’s their job to provide you information about the problem. It’s our job, as product managers, to interpret that and figure out, what the best solution is for them and for our company. How do we get business and customer value?

Even though you do have customers who are banging on your door and complaining, they’re there. They’re human beings. They’re not anonymous, like some of the people in B2C environments. You have to, as a product manager, learn to synthesize that information and really get to the root of the problem.

"It’s important to prioritize, in light of things we don’t want to do, so we’re not distracted."

One of my colleagues told me the other day, there was somebody from marketing. They said, “I worked with an amazing product manager on one of your teams the other day, and I was telling him the feedback we were getting from the clients.” He was able to sit there and say, “Okay, I know he’s asking for these tools and these features, but what I think he’s really saying is that he needs to be able to accomplish it. Am I right?” And he was right. So, he kept seeing into the problem to really figure out what was the root cause there, instead of just saying, “Yeah, yeah, we can build a solution.”

Where I see some new product managers get into the trap is when they dismiss the feedback coming from customers because they say, “Oh, he’s giving me a solution. He should be giving me problems.” So, with my new product managers, I have to tell them, even if somebody comes to you with a solution, that’s not their fault. Don’t blame them for coming to you with a solution. That’s how people think. What your job is, is to sit there with that person, really understand why he picked that solution. Why they have that problem? How do I understand better? What’s causing him to ask for this?

That’s really the most important part of getting into B2B versus B2C. You just might get more feedback that’s more pressing, but you really shouldn’t change your approach. You would change your approach, probably in testing phases. You might change the tools you use. You might change the way that you release things. You might change the way that you get feedback, or synthesize that information. That might be different than B2C, but the approach and the phases are all still the same.

Latif: You talked a lot about goal setting and I was wondering, is there a framework that you use around goal setting that can help product managers, get out of the Build Trap? Is there anything that you’ve seen work effectively for that?

Melissa: Getting out of the Build Trap, that’s a long systemic process. The first thing is to start with the goal. That’s why I harp on it so much. A lot of people can find that they make a lot of progress getting out of the build trap, just setting a goal. In my school, I teach people about the HEART and AARRR metrics, just as two examples of how to break down product metrics. Where I think new product managers struggle with that is, they look at too many metrics. If you give them frameworks, they’ll want to measure everything, but what I think you want to do with any framework, or with any of those goal-setting metrics, like HEART or AARRR, is to really break them down and figure out what’s relevant for me and my context.

Sometimes, as a new product manager working on a small little sliver of a feature, some of those frameworks might actually not apply to your small little area. It might apply to a much broader area of your product, and you have to zoom out first, look at the holistic level, and then figure out what do you control in that system. It’s really breaking down those types of metrics into a way that makes sense for your context.

Latif: What are HEART and AARRR metrics, just for the audience?

Melissa: AARRR metrics is something that Dave McClure started. It’s called, Pirate metrics. I think of it as funnel analysis. It goes over acquisition, activation, retention, revenue and referral. These can change order, depending on what type of product you have. Acquisition could be adoption of a feature or product. Retention is how many times people come back and keep using it. With AARRR metrics, you’re looking at the funnel. I try to get people to break down the funnels and user flow through the system.

With HEART metrics, that’s what Google created that’s a little bit more UX-centered. That’s about looking at happiness, engagement, adoption, retention and past success. That, I think of too, as health metrics for your product. How do you know if your product’s up and running? Are people actually adopting your product? Are they happy with it? Are they accomplishing the task that they set out to do? Is the job getting done that they set out to do?

"It’s not about you. It’s not about your ideas. It’s about the team’s ideas."

What I try to tell my product managers to do is rip them apart and figure out which pieces you implement. For example, when I was working with a company, my goal was only around acquisition. I know that everything that I have to do is trying to get more people to sign up for a site. Then, I was able to take that and say, “Okay, for my scope of the area, which is just after people land on our website, until the moment they sign up, how can I influence acquisition within that scope?” Then, I’m trying to figure out what problems exist with people coming to our website and signing up. Why aren’t they signing up? What are the metrics I can influence in that? What I did was I looked at that and found out that conversion rate was pretty low. So my metrics were influencing conversion rate to go up. I took these high level metrics that I’m talking about, with AARRR, and then I broke that down into something smaller, that was more measurable for me, and I concentrated on that and set it as my goal.

Latif: Just to tie things up here, what was one thing that you wished you had learned at the beginning of your PM career, that now is a fundamental part of PI?

Melissa: I think it’s really about how you come up with solutions. Throughout Product Institute, we really stress, especially when you’re getting into solution exploration and trying to figure out what to build with your team. I find a lot of people who are new to product management, or a lot of companies who are new to product management, treat product managers sometimes as not part of the team, which to me, is a crazy thing. When I was first getting into product management, I was told it was my job to come up with the solutions and hand it off to the development team. What I learned throughout my career was, that wasn’t my job at all. My job was more to point my team in the right direction and then we, together, figured out the best solutions. Four or five brains is way better than just one.

That’s something that I stress throughout all of Product Institute. It’s not the product manager’s job, alone, to come up with all these ideas. It’s your job to provide the structure in which people should think. For example, if I know that I’m in solution exploration mode and I know what I have to learn next, let me bring that for my team, and then see what ideas they have for how we can quickly learn it.

"It’s not you versus the team. You are part of the team, and you have to work as a team."

When I was working at one company, my tech lead came up with a way that we were able to learn on that conversion example. Why people weren’t signing up. It was nothing that I would’ve ever thought of implementing in my life, and it wasn’t really a huge tech problem. It was a user research problem. We had no idea how to get in touch with our customers. He researched it like crazy and was like, “Hey, I found this thing that we could put on our site with a few lines of JavaScript and we could probably get the answers you’re looking for.”

If I never let my developers or my team into that process, I would never have got the answers I needed. That’s something that I really try to stress for all product managers. It’s not about you. It’s not about your ideas. It’s about the team’s ideas. You help everybody make decisions. You provide the framework in which you make decisions. You narrow people’s focus, and you keep them on track. But you don’t have to come up with all the solution ideas yourself, first. You have to open it up to your team, and have a collaborative approach to it. As we get through Product Institute, I really stress, every step of the way, that if you’re doing user research, bring your developers to it. Have planning meetings where you frame it with the problem and you frame it with what we know, and then open it up to ideas. You’re going to make the final call, but you don’t have to come in there with all the answers. It’s not you versus the team. You are part of the team, and you have to work as a team.

Latif: That’s awesome. I think that also sort of sounds like the definition of a leader. Those are sometimes interchangeable with being a product manager.

Just to close out, Melissa, where can our Product to Product audience find you online?

Melissa: Yeah. If you want to follow me on Twitter, it’s @lissijean. (It’s my nickname from my mother.) I blog at melissaperri.com. If you want to come join us at Product Institute: productinstitute.com. We have open enrollment and a great community of over 500 people talking to each other on Slack, exchanging knowledge. We’d love to have everybody.

Latif: Thank you so much, and we will definitely direct people your way. Really appreciate your time, and thank you so much for coming on the podcast.

Melissa: Thank you. Yeah, it was great talking to you!


Subscribe to Product to Product on iTunes (here) and Google Play (here), or get the latest episodes delivered to your inbox by subscribing here.

Author
tarif

Tarif Rahman

Tarif is the Digital Content Specialist at Roadmunk. He's got a penchant for storytelling, enjoys bringing creativity to the tech world, and has an aversion to Netflix (don't judge).