Theoretical vs. Practical Product Management

Speaker A: Welcome to the Practical Product Management Podcast, episode one. This is the pilot episode of this amazing new podcast that Marilyn and I have decided to have. Um, so today what we thought we would talk about was how we know each other and why we're doing this podcast. So we're going to product manage this podcast for the next few minutes. All right, So I thought we should start by, um, just explaining how we know each other. Um, some people will know that know us both, but, um, we can talk about a little bit how we know each other and then why we had this idea. So, um, do you want to tell people how we know each other?

Speaker B: Oh, my gosh. Uh, I'll start, but you're, you're, you're going to chime in. Um, so Leah and I have had a career that has intersected, um, many times since about 2010, 2011, somewhere in there. Um, we met first at Amazon, um, where we were both product managers, by the way, and what is seemingly an amazing friendship where we're super supportive of each other and always looking out for each other. Did not start off that way. Uh, I think we're both very sort of strong. Um, we're strong minded people and we had a vision of what we wanted to create. And when you're early on in your product management journey, um, you tend to be very sort of fixed, um, in your way of thinking. Uh, and I think that we crossed in a moment where we were both fixed, um, and there was a period of time where we pretended like the other person didn't exist probably for about a month, month and a half. I think even though we worked on the same product.

Speaker A: Maybe we should invite Gino to the podcast to talk about the month where we didn't talk. Absolutely. He has wounds and scars of that time. So he can, he can see, he can exercise his wounds for six weeks that we didn't talk.

Speaker B: I love it. We should, we should, we might try. There might be tears. Not. But yeah, I think that, um, I think you and I have both worked in different industries in, in different areas on different products and really have a very similar approach, a very similar thought pattern. Um, we've led teams through similar evolutions and, uh, I mean, I just think the world of you. So thank you for allowing me to be part of your journey. Yeah, it's been a privilege. Same.

Speaker A: Um, I think, I think the best decision I ever made when it came to our relationship was to decide for the two of us to decide we were gonna, like, go back in and try again, like, all right. Let's, we, we should, let's give this a real shot again. And can we trust each other? And what would it look like? Right. And because I think it has, for me, changed my whole career and changed my life because I've had you as a partner, a thought partner in everything I've done since. Right. So whether that's been at work or in my life, and I think that that has, um, has really been life changing. Right. I mean, this is, I, I, I say to lots of people, like, find yourself a person who you can hand your financial contracts to and say, am I making a good deal? Right. Um, and the person, oh, you need to do this, this, and this, or you're not making a it' decision. Right. And, oh, okay, you know, and you scurry off and do what's right for yourself. Um, and I think women in general don't have that. Right. Ah. As much as men do. Um, and just finding your person that you can be like, here's my business, and know that come back, there won't be a return, won't be judgment. Right.

Speaker B: Yeah. Only support 100%.

Speaker A: Uh, I also wonder how much of our current way of being and working we learn by working together. Like, there are some things that I know I picked up because I worked with you and was like, I know how to do this because Marilyn taught me how to do. And, and kind of along the way, things we also acquired from one another. I think that's also true.

Speaker B: I mean, a thousand percent, because I did not know about, nor did I care about platforms before I met you.

Speaker A: Yeah. Uh, I remember one time being like, hey, wait a minute, are you running a platform and I'm running the front end? And you were like, yeah, that's weird. What, did we just change identities? And I was like, yes.

Speaker B: Uh, it's like the Freaky Friday movie. Exactly.

Speaker A: It's a good thing we both knew something more about that because of each other, because neither of us knew what we're doing. Totally. So Marilyn was at my house this last winter. Nope. In the. Yeah, winter. It was winter. It was February. Um, and we were talking about all of the theory of product management out there, all the book books, so many books, and how important the books are. And I get really snarky about the books often because I'm like, wow, those people don't even launch products anymore. I always sound so mean when I talk about the books. And Marilyn was like, well, but we need the books. Right? And so we started talking, having this exchange about theory versus kind of practical product management, which is how this podcast was born. Um, so do you want to say more about, like, that. My. My snarkiness. Do you want to say?

Speaker B: Uh, no, I mean, I think that's exactly right. Um, I think. I think there is a need for some structure. People need to understand what. What. What does it mean to be a product manager. But I think the thing that was, um. I think the. The key moment for us is when we were sitting down and we said, yes, but it depends.

Speaker A: Yeah.

Speaker B: And so there's always this moment where, like, the, The. The theory is great, but when you take it and apply it very rigidly, um, or you take it without understanding the. The purpose behind it, you actually don't get what you're seeking. And so it really. When you, you know, when you walk into a new company, and I think you and I have done this each many times, you walk into a new company and they're like, take this group of people and turn them into product managers. And it's not actually how it works. You don't just apply, uh, a book to one small subset of people and get magic. Because.

Speaker A: Because if you could, we would do it really, really fast and repeatedly, like, oh, oh, here's the book. Read the book, and then we'll be done. Everyone, we're good. Yeah, I actually. I'm coaching a product leader right now who has a guy on his team. The person will not be able to figure out who they are, but has a guy on his team who read a book. The book. He read the book by Marty Kagan and believes that they're. That that's how they should be doing it in their company. And so he's stubbornly in every meeting is like, uh, yeah, but this is not how product management is done. And my client is like, okay, listen, I need you. I understand. I get what you're saying. Marty's not wrong, and that's not how we do it.

Speaker B: Yeah. In this moment, Marty's also not right.

Speaker A: Exactly. Yeah.

Speaker B: I. I mean, I. I love, uh, I've been fortunate enough to. To have gotten to talk to a lot of the current authors and work with them in different, like, you know, you know, Melissa Perry and Jeff Goth elf and Marty Kagan, and. And I do believe in bringing in the larger mindsets, but when you get to application, there's a practicality about the company you work in, um, the culture.

Speaker A: Yeah.

Speaker B: Right. Will this. Will this sort of activity be sustained? Or you don't want to create an antibody reaction where the. Where the company Just rejects all your product managers. Um, and to be super honest, if you just, like, again, take. Take a small percentage of the company and say you act differently. Yeah, it's not going to work because no one's going to treat them differently. No one understands their new job. No one gets why they're asking the questions. And so you're just going to everybody else.

Speaker A: Everyone's like, the product management team is annoying. It's like they're jerks. They keep talking about stuff that we don't talk about here, right? It's like, uh, yeah, they all read a book, right? Yeah. And. And I agree with you. Like, I think the books are necessary and that we need some structure to what is a bit of madness. Product management has an element of madness because it's not something, you know, I always joke and say, no kid is sitting in, you know, kindergarten. Like, I want to be a product manager when I grow up, right? No, nobody. Maybe the kids that know me, right? Because I'm like, you should be a product manager. But most. Most little kids, that's not what they're dreaming of. They might want to be the boss, right? They might want to build things. They might want to be responsible. They might want. They might see that and be like, oh, I want to have a company or, I want to own a thing, or, you know, but they don't know. Like, nobody's like, I want to be a product manager. Most of the product managers I know didn't set out to be product managers. They started out, right? I mean, I was an accountant, for God's sake.

Speaker B: Right?

Speaker A: So. But, you know, and I think that's. I think where it gets tricky because the theory is helpful because this is a bit of a. Like, hey, what is this thing we're all trying to do? Um, but it gets really dangerous when it's like, now you must apply this thing with this rigor, and it is the only way. Yeah, yeah, yeah.

Speaker B: And I think that's where these schools get involved. This is where product management gets commercial.

Speaker A: Yeah.

Speaker B: Because these schools get involved and they go to a big company and they're like, not only can I make product managers, but I'm going to teach you Scrum. And it's going to be safe, and it's. It's all going to be like magic. Um, and then they bring in a bunch of expensive consultants and people they call Scrum Masters, and they spend a lot of company money, and nothing changes between the customer and the company, right? Nothing changes. You get a whole bunch of process. You Get a whole bunch of expensive process. And that fundamental relationship, that pane of glass between your customer and your company does not change. It doesn't get faster. It doesn't get more intuitive. Because that's not what you're measuring or looking at.

Speaker A: Right? Right.

Speaker B: Like you're like your deifying process.

Speaker A: Yeah, exactly. Like this is how we do it. It makes me, it gives me the eye twitch as you're talking because I mean, I literally left a company and the person who took my job, who had never done product management, came in and took my job and hired Scrum masters for every team and then started, started, um, teaching the team Scrum. And I'm like, it's a team full of engineers who have only ever done Scrum. You don't need to teach them the thing they know how to do. Yeah, right. So here I have this whole team of people that are like, Leah, uh, it's madness in here. I'm like, sorry as I back away slowly trying to get away. Right. But it just, it's, I mean I

Speaker B: just think it's, it goes back to that thing that you measure is the thing that you, that you optimize for. And you're measuring process instead of value delivery at the interface between the company and the customer so you can realize business value sooner, so that you can move faster, so that you can learn. Like you're not so rigid in your mindset that you, you truly believe you already know what the solution is. Right?

Speaker A: Right.

Speaker B: You and I both know.

Speaker A: But I was gonna say, I think the one thing that we would say, I think that we agree on for sure is Amazon's got other things that are wrong with it. But what they do know how to do is focus on the customer and that laser focus and the constant rigor to say, anyone can say, what's, why would we do this? Is there anything in it for the customer? And you're like, no, I want us to do this thing. No. Right. And I think it does. Uh, that mindset. I always joke that I can walk into any networking meeting and figure out who worked at Amazon based on how they talk like that. Right. Because I'm like, ah. They instantly talk about the customer or say vocally self critical or, you know, they use the lingo. Right? Yeah. I'm like, oh, yeah, okay. I know you. Right. Uh, this is familiar.

Speaker B: Exactly.

Speaker A: You don't have to focus on that. Like you, you can become a customer focused person without having to work there.

Speaker B: 100. I also think the challenge. And uh, we'll get into the differences of product managers from different big tech companies in another episode. I promise you this. I think challenge with, with Amazon is because they're so good at it, there's an arrogance that every company has to operate like Amazon. Right. And I also don't think that's true.

Speaker A: Right, right. It's not practical. Like it is.

Speaker B: Exactly. Right.

Speaker A: That is practical at Amazon. But if you try to make work somewhere else, you can bring some of best practices, you can see what might work. Right. But it is, it's not practical to try to be someone else. Like, it doesn't make any sense. Right. So. And I think, I mean, going all the way, full circle. I think part of the problem at the beginning of our friendship, our relationship, working as colleagues, forget friendship as colleagues, was we were all in a kind of a tight little spot, being we were all competing against each other and all trying to be the best, whatever. And really we each needed to be who we were and be the best. Like, the most practical thing to do is for me to be me and you to be you. Right. Instead of like, which of us is the best Amazon product manager. Right. In theory that sounds nice for us to march towards that. But practically speaking, we needed to each be ourselves. Right. And that made magic. Right?

Speaker B: Yeah, exactly. Right.

Speaker A: Yeah, for sure.

Speaker B: Exactly right. I think, I, uh, think helping people understand practically, uh, how things should work and how things could work for their product, for the company and for themselves, um, actually allows you the flexibility to become more well rounded as a product manager because you enter this, you enter this space of you don't know. I think that's the part I love about product management the most, is your job is to try to understand the things that are not known.

Speaker A: Yeah, yeah, no, totally. It's so much fun. I remember, um, I remember years ago, someone we know, Brad, saying, um, Leah doesn't really like ambiguity. And I was all, what's the whole job, Brad? I. My job is to disambiguate things. So I, I make things narrower. I take all the noise and I make it. He was like, yeah, okay, that's fair. I was like, thanks. I'm not comfortable with this. That's why I have this job. I take us here. He's like, okay, fair enough. Right? And he was right. Filled with ambiguity. He's. Which.

Speaker B: I think I love ambiguity. Um, but I also. My bias is to simplify.

Speaker A: Yeah, totally.

Speaker B: So I do the same thing. Like, I love walking into an area where I know nothing. It's a total disaster.

Speaker A: Yeah.

Speaker B: Um, but then my Instinct is to sort of separate, disambiguate, narrow focus, prioritize,

Speaker A: and go, yeah, how do we, how do we go faster from here? Right. It's like, it's. So, um, so what would you say? Let's go, let's be practical. So this is practical product management. What would you say are the, like always must haves, like, things that doesn't really matter what the framework is? I told you this morning when we started talking that I looked something up and it was like 21 product management frameworks. And I was like, we don't need 21. Why are there 21? Nobody needs 21 of anything. Right. Maybe drinks, I don't know. But, but even then it gets a little bit tiresome. Right. Even that's a tipping point. Right. But, but I was, I was looking at that and I was like, oh, I mean, there's some good stuff on the list. But no, but no wonder people are confused. Right. So I think in general, even within those 21 product, those product management frameworks, there must be some always true things.

Speaker B: Commonality.

Speaker A: Yeah.

Speaker B: I, I mean, I think it comes down to, uh, what, what problem are you trying to solve? And, and why should whatever business you're part of solve that problem? And why should they solve it now? What's in it for the business? Um, what's in it for the customer? Why is this a problem that someone has? And why do they need you to solve it? And why do they need you to solve it right now? And then you have to be able to work well with engineering teams. Like, at the end of the day, if you're hoping to stand on a golden pedestal and be nominated product manager of the year, you're in the wrong job. Because really it's a servant leadership sort of role.

Speaker A: Yeah.

Speaker B: And your job is to disambiguate and understand so that everybody else can be successful.

Speaker A: Yeah, one, uh, hundred percent. 100%. When I worked at Klarna, we had a program where people could move out of their other competence into product management. And I was often the person who would talk to them first to determine if they even could get into the program.

Speaker B: Right.

Speaker A: So the cpa, like, talk to Leah and I was like, okay, so I would talk to somebody from, you know, merchant support or from customer service or from, you know, marketing who wanted to be a product manager. And if I always started with, why do you want to be a product manager? If they said, because I think that's where all of the, you know, like, that's where the money is and where the glory is in some form or fashion. I was like, okay, well, yeah, we get paid well, but it's because the job is kind of a shit job sometimes, so.

Speaker B: Exactly.

Speaker A: Right, let's try again. Why do you want this job? Right? And so if they could say, because I really love solving problems, or I'm super curious, or I want to. I want to have some ownership over something that makes a difference or, you know, whatever, I was like, okay, you're in. You can come into the process and we'll interview you and see if you fit. Right? But the people who were just like, this is the only way I can improve my career, I was all, oh, honey, money, that's be a problem. You're not going to like this job because it's gonna. Yeah, yeah. So I think I agree with you. I think there is. There are some basics, right? To your point. What are we trying to solve for? Why are we the ones to solve it? And who's going to get the benefit? Like, what is the benefit to the customer? What is the benefit to the business otherwise? Don't do it. Stop doing it. Don't write the code if. If, uh, you don't know the answer to those things. Don't write the code.

Speaker B: Yeah. Like, I actually think that the, the product manager's superpower is disambiguation. It's. No. Yeah, it's prioritization.

Speaker A: Yes.

Speaker B: You cannot do everything. So with your. With your precious time and your precious resources, what are you going to do?

Speaker A: Yeah. And how do. And I think so many. I mean, when I'm coaching people, I coach quite a few product managers, and one of the things that they regularly ask me is like, how do I say no to this? And I'm like, okay, yeah, it's easy. You say it. No,

Speaker B: I mean, I think I started my career with. Or.

Speaker A: That's interesting. But right now I get to say hard pass. I'm going to give away one of my, My massively important coaching, uh, examples. I tell them, like, literally put your hands in front of you in front of whoever is asking and say, my hands are full. If I pick up the thing you want me to pick up, what would you like me to put down?

Speaker B: I, uh, love it.

Speaker A: And they're always like, oh. And I said, because when you do this, the other person has to visually imagine that you're holding a pile of stuff and that you're like, I don't. I can't reach for it. What. What do you want to put down? Right? You're going, I Can't pick up the thing. And sometimes I've said sometimes. The answer is if I put some of these things down and pick that up, we won't be able to do that. Because I need to do these things first. Yeah. So I do want to do the thing you want me to do. I want to say yes. That's what I mean. I've. The number of times in my career I've said, oh, I really want to say yes to you, but the answer's no. You know, like, it's no for now because I need to do this.

Speaker B: I love no for now. Uh, because I think one of the bad habits. And we'll get. We'll get to bad habits in another podcast, I'm sure. Um, one of the bad habits I've seen with product managers is they just put it on the backlog instead of saying no. Yes. You know, you're not going to do that if you. If you know you're not going to do it in the next quarter or two quarters, don't, because the problem's going to change. And if you have a backlog of 900 things, you're never going to continue to think, yeah, you're just going to march down a stupid backlog of stuff that people thought about a year, a year and a half ago, like, delete

Speaker A: it, don't do it. And people, uh, over time, you lose trust because you just throw stuff on the backlog that might be a great idea that you need to actually listen to. Right. And you're like, yeah, good, huh? Uh-huh. And you just throw backlog because you can't. Your mind is so narrowly focused on whatever that you need to be like, wait a minute, I'm going to actually listen to ideas for a minute. That's not bad. Maybe I need to pivot some things down here. Maybe I can't do it right here, but I might change it here. But if I just run the backlog, then I've got to do these things. 12 things that came in before that. Really good idea.

Speaker B: Yeah. Terrible thing, glorifying the process thing. Right. Like, here's the process. You give it to me, I put it on a backlog. Yep.

Speaker A: Yep. So let's share before we close. Let's share. You have. You've created a little stakeholder interview, um, many. So I'm going to share this, my screen, and you can walk us through, like, what this is and how it. How you have found it helpful. And let's, let's, uh. And then we'll share it As a resource on our website for people that want to, um, want to take a look at it. So love it. Here it is.

Speaker B: So I created this, uh, I created this for, for people that were trying to evolve into product managers and, and the situation that they often find themselves in is someone hands them a piece of work m that's fully baked or fully considered. Not really, it's not really tech ready. Um, and then they just say, just do this, just do this. Don't, don't think critically. Just do this thing. Um, so this is a tool that I've offered up a number of times to, to just ask enough questions to give you enough space. Think critically about what you're being asked to do. So who's it for? Describe the customer. What's driving the deadline. This is important because sometimes it's nothing.

Speaker A: Right.

Speaker B: What problem are you trying to solve? Um, if you had this thing, then what would happen? And I think that's also a really interesting one because they don't know. Right. They just want this thing.

Speaker A: Like, I need this thing. But what are we going to do with it? I don't know. Our competition has it. Okay, awesome.

Speaker B: Um, customers use it. Right.

Speaker A: I don't know exactly.

Speaker B: Uh, is it temporary or permanent? And that actually tells you how much to invest in the thing.

Speaker A: Yeah.

Speaker B: What does success look like? Like, this actually gives you a way to start to measure whether this thing is useful and, or not. What does failure look like? Which is a little more interesting. And then the golden question, and we should probably make this a different color just because it is the golden question. Are you open to exploring other approaches?

Speaker A: Just. I love that.

Speaker B: Ah, because this gives you the space to say you understand a little bit more about what this thing is. Um, and you can explore other approaches to solve the problem. Right. The one thing that struck me, especially when we worked at Expedia, um, was that a product manager can tell, uh, especially a new one, can tell an engineering team exactly what to build.

Speaker A: Yeah.

Speaker B: But the engineering team, if given a problem, will find multiple ways to solve that same problem. And some of it's expensive, some of it will take a long time, some of it's fast, some of it will give you great business value, some of it will give you 80% of the business value really quickly. But if, uh, the product manager is not open to the conversation, not open to exploring other approaches, they're just going to get the really expensive thing. And most often you think of the, the most expensive thing, that's going to take the longest, that will never Work. So.

Speaker A: Right. Because I mean, given ultimate freedom, if you just say, here, build me this thing, I mean, a lot of engineers are going to do something that's really fancy and fun to build, right? And. And that may take a long time or it may take a short time, right? And to your point, like, that's where what is. What are. What do. What are they thinking? What are you thinking? What are the stakeholders thinking? Really being the person who brings all that thought together and says, okay, we need a. We need a path forward that is quick, that is this, that, you know, whatever that meets the answers to the questions. Right? Um, super, super important. And I mean, I said that about engineers, but I obviously love engineers. I. But I. But you know, they like to do fun things too, right? So I don't want to just keep building the same thing.

Speaker B: So, I mean, even I have over complicated things. You know, I will cite it. I will cite a time when I was at Amazon or not Amazon, I was at MasterCard. Um, um, and we had an. We had a problem that we were mulling over a huge group of people, and it should have been like, the brightest people in the room. Solve it. M. We were running down a path that was expensive, was going to take months, and one engineer over a weekend wrote a proof of concept that actually solved the problem in the most simplistic way, and it was brilliant.

Speaker A: I love that. I love when that happens. It's my favorite.

Speaker B: Me too.

Speaker A: Everyone who's an engineer, if you're listening to this, go write a proof of concept over the weekend and make your product manager go, what? You did what? How'd you do that?

Speaker B: You thought about. You thought about it differently from problem space out, not from solution out.

Speaker A: Uh, and I think it's that to me, it reminds me of the, you know, the, like, don't fall in love with your solution, right? Uh, it isn't your baby, right? What is the problem you're solving? But don't fall in love with what you're building, right? Because, man, tech comes and goes, right? Customers have problems, right? But how you build a solution, I mean, I think about one of the very first things I ever built was the ability to read a check. Like, take a picture of a check and deposit it. We don't need a lot of that anymore, right? Like, if I was in love with it. Well, I mean, whatever. Very cool. Um, I'm going to stop sharing. We will share this as a resource, so thanks for sharing that with us. We'll share it as a resource on our website. And people. If you want access to it, it's yours for free. That's the beauty of, of, uh, watching our podcast. We'll give you free stuff that we've done all the hard labor over, so. Awesome. Well, I think. Is there anything else you want to share today on this topic? No.

Speaker B: I think this is an awesome wrap on episode one. I hope people like the pilot. I hope we're. I hope we're renewed for our first season, or however you say that lingo.

Speaker A: Let's hope that whoever's paying us. No one, um, will continue to pay us. I mean, not yet. Anybody wants to pay us for this, we'll take your money.

Speaker B: I think it's fair to say that we'll get funded for the next show at the same level we were funded.

Speaker A: Exactly. And it'll probably be pretty much the same in terms of exactly how organized we are. So. Awesome. Well, Marilyn, thank you. And I will see you in the next episode. Bye, everyone.