Practical Product Management · 2024-06-26 · 28 min
Key moments - from our scoring
Substance score
35 / 100
Five dimensions, 20 points each
Leah Farmer and Marilyn McDonald debunk seven pervasive misconceptions about product management that drive poor behavior and misaligned expectations. The core myth - that PMs are "CEOs of the product" - sets an unrealistic power dynamic; instead, PMs must influence without formal authority, act as team members rather than order-givers, and shield teams from organizational noise while taking responsibility for decisions. Other damaging beliefs include treating PMs as order-takers from business owners (the "Flo at Mel's Diner" problem), conflating product management with project management or product ownership, and reducing the role to pure feature delivery. Farmer and McDonald also challenge the notion that PMs must be deeply technical or code, arguing this gatekeeping excludes strong candidates, and warn against viewing the job as purely innovative or glamorous - most product work is incremental improvement across repeatable patterns, and the reality involves grinding through data, documentation, and cross-functional alignment. The episode is essential for founders, business leaders, and aspiring PMs who need to understand what product management actually demands: team orchestration, strategic problem-solving, and relentless execution without public credit.
It creates poor team behavior because PMs lack actual hiring/firing authority. The real skill is influencing without control - building belief and alignment through trust and team membership, not command. When PMs behave like executives issuing orders, teams return negativity and disengage.
Product managers answer 'why are we doing this and what are we doing,' while project managers answer 'when will it ship.' PMs who spend time on Gantt charts and milestone tracking lose time with customers and stakeholders; technical program managers handle dependencies and execution timelines, freeing PMs for strategy.
No - technical knowledge is valuable but not required. Requiring coding ability or deep engineering backgrounds gates out strong non-technical candidates. Former engineers often struggle as PMs because they jump to solutions instead of staying problem-focused, a harder habit to break than learning technical concepts.
Most product challenges (roughly 80%) solve already-solved problems like onboarding, two-sided marketplaces, or algorithms. True innovation in new markets or new products should be a small portion of time. Treating everything as innovation is expensive and prevents learning and repeatable patterns.
No - when done well, PMs take almost no credit, elevating others instead. The daily reality includes rewriting documents, investigating bugs, checking data, organizing user stories, and orchestrating alignment across engineering, design, finance, and business stakeholders while balancing strategy with execution.
Our reviewer’s read on each dimension, with quotes from the episode.
The episode recycles well-worn PM truisms (PM isn't the CEO of the product, isn't project management, doesn't have to be technical) with lots of banter and jokes but few non-obvious claims a smart operator hasn't heard.
product managers are the CEO of the product
product managers don't do project management
These are the most-circulated PM myths in the field; the only fresher note is the Ansoff-matrix framing on innovation allocation, but overall the takes are conventional and agreed upon by both hosts.
You must influence without control
It's in service of an outcome
The two hosts appear to be experienced product leaders (references to leading teams, Klarna, Amazon), but there is no external guest and the transcript does little to establish scale or specific accomplishments.
when I was at Klarna, we had this, this pipeline of people who wanted to leave other competences and become product managers
I think that might have been weak2@Amazon for me
A few named references (Klarna, Amazon, Ansoff matrix, RACI) but almost no data, metrics, timelines, or concrete case detail; the discussion stays at the level of analogies (diners, cats, buttons).
I actually love this notion of the ansoft, uh, matrix
it's like taking someone from the kitchen who's responsible for doing all of the prep for a chef
This is two friends enthusiastically agreeing with each other; there are no probing questions, no pushback, and no productive disagreement - mostly mutual affirmation and jokes.
Uh, that's the worst. That's the worst.
Yeah, totally, totally agree.
Computed from the transcript - who did the talking, and the words that came up most.
In this episode, Leah and Marilyn discuss some of the biggest misconceptions about the role of a product manager. They start with the idea that product managers are the CEOs of the product, emphasizing that product managers must influence without control and work as part of a team. They also address a few other often discussed myths and misconceptions. Takeaways Product managers are not the CEOs of the product, but rather influencers who work as part of a team. Product managers should focus on understanding the strategy and problem-solving, rather than simply taking orders. Product management and project management are distinct roles with different focuses. Technical skills are not a requirement for product managers, as their role is more about problem-solving and understanding the market. Product management is a challenging and multifaceted role that requires balancing various responsibilities. Leave comments here or ask questions over at PracticalPMPodcast.com
Transcribed and scored by The B2B Podcast Index.
Speaker A: Welcome back to Practical Product Management Podcast with me, Leah Farmer and my friend, Marilyn McDonald.
Speaker B: Hello.
Speaker A: Today we want to talk about some of the biggest misconceptions in the role of a pm. Some of the cringe worthy misconceptions about being a pm. Doesn't that sound fun, Marilyn?
Speaker B: It sounds way super fun. Let's do it.
Speaker A: Okay, I'll start. I'll go first. One of my favorites that will make my eye do that is product managers are the CEO of the product.
Speaker B: Uh, that's the worst. That's the worst.
Speaker A: It is the worst. Why is it the worst?
Speaker B: I think it's probably one of the single biggest drivers of poor behavior I've seen in the team. Um, people misinterpret what it means to be a CEO.
Speaker A: Oh my gosh. Yes. I think exactly that. I, and you know, I think when the idea behind it, like, oh, you're the CEO of the product, is, uh, is giving someone a sense of ownership. Yep. Because we view the CEO as like being locked and loaded. She knows what she's doing, she knows what she's in charge of, she knows what she's driving towards. Right. And yet that ownership that we want product managers take is not the same as being a CEO. This is not the same job.
Speaker B: It's not, it's not. I think this, uh, uh, this lack of actual authority to like, yes, hire and fire people to dictate, uh, in a product manager, you must influence without control. People must be able to follow you, actually. So I don't want to say it's harder than being a CEO, uh, because I've never been a CEO, but it is like, you know, you do have to drum up belief and you have to get people aligned. Um, and it's a much more influential
Speaker A: role.
Speaker B: Uh, without authority.
Speaker A: Yeah, yeah, totally. There are lots of types of CEOs, and the, the ones that I have always really most loved working for have been the kind of people that understand that they do have a lot of impact and authority and that their words matter and that what they say will make people scurry off and do things right, but that they find a way to surround themselves with really bright people that are exceptionally good at what they do and they just leave them to it. Right. They just don't. They're not like, I'm gonna now be in the weeds. I think as a product manager, I always believed my role and what I believed when I was leading product managers, you were part of the team.
Speaker B: Yeah.
Speaker A: You, you are not there to hand out orders and send Everyone scurrying, right. Like you. And if you behave in that way, um, the team will, they will return the favor.
Speaker B: I want to work with you if you're a jerk. Like, if you hog the glory and pass down the poop, no one's going to want to work with you. Your job is to bring. Collect people collectively together to solve a problem, um, in the best way possible. And that's going to take the wisdom of the crowd to shield the team from the poop. I would expect you to take all the poop and none of the glory. Like, that's actually.
Speaker A: Yeah, totally, totally agree. I, uh, think. Yeah, I think it's fundamentally like you said at the beginning, it can create such poor behavior if you really believe you are the CEO of whatever that product is. Right.
Speaker B: So I never want to be a CEO.
Speaker A: Let's skip it. All right. What's one of yours?
Speaker B: Uh, I think mine is more of a business misconception than a product management misconception. Um, I think there are a lot of businesses, particularly those ones that, that did not grow up digitally native m. That believe the job of the product manager is to take exact orders from someone that we call a business owner or, or, um, you know, someone in the business and their job is to, uh, transcribe what they say exactly. And build exactly that without any sort of thought.
Speaker A: Right.
Speaker B: Um, with no consideration, with no understanding, um, and just go and, and make those engineer people do the thing I said.
Speaker A: Right, right. I always, every time we've talked about this, I get this image of, you know, Flo at Mel's Diner walking up with her pad and her pencil and being like, what do you want, honey? Right? Like, so, Like, I'm sorry, you. What do you want? And taking orders is not the job. If you, if you hire a product manager and give them that to do, they won't be respected in the team. They won't build the right things. They will be distant from the business in a way that starts to really creep into what your goals are and what gets built.
Speaker B: Yeah, yeah, yeah. And I've actually, so. I've actually seen some places where, uh, where this, where this layer will no longer allow the product manager or the team to talk to the customers. Right? Oh, yeah.
Speaker A: How am I supposed to know what to do if I don't get to talk to. You know, I've had, you know, um, I've had that happen for me, I was, you know, leading teams in the merchant space. Somebody saying, like, we don't want you to talk to the Merchants, it'll confuse them. And I'm like, well then I'm not doing my job very well. If I can, if I can roll into a merchant and confuse them.
Speaker B: You are so confusing.
Speaker A: Right, then I am a problem that we should talk about that problem
Speaker B: or
Speaker A: is this a problem or a me thing? Like I'm m. Let's talk about how, how confusing I am.
Speaker B: But yeah, I also think it's like funny that people think they can dictate a feature to uh, to, to what I would call like a cross functional development team. So product TPM engineering use. I have seen, I have seen people try to do that. Like here's the feature, go do it. Um, but in reality that, that delivery team can come up with multiple ways to solve a problem and they're going to have different costs, different time to return value. Um, and you're really hamstringing yourself and the company and the person you're trying to solve or solve for the customer. You're going to build really shitty things because usually the person dictating the feature actually doesn't understand.
Speaker A: Right.
Speaker B: All the ways you can deliver a thing. So you're, you're really just torpedoing your team.
Speaker A: Yeah. And it's funny as you said that I was thinking about like all the times that someone has said like just go build this thing I want. And um, I've been like, the thing you want isn't actually what the customer wants. And the, the tech doesn't do that. And, and, and the layers of uh, answers to that, to that comment are like, okay. And also then you don't need me.
Speaker B: Yeah.
Speaker A: So why are you paying product managers?
Speaker B: Like, because the people that say stuff like that don't understand how tech works. They just want you to do the thing. I mean like, uh, I find it flummoxing. Like I like it blows my mind when someone's like, this is what I want. And I'm like, you know, that's actually not how things work.
Speaker A: Right, right. And I think it goes back to the whole premise of what we've been talking about. Like there is a theory that some people have about what they're going to get from product management. And the practicality is you actually get something different if you don't understand it. Right. And so it's not, it's not as simple as, well, I read a book and I know what product managers do and it's like, I mean the number of times that I've heard founders say, well I've been doing product management, I'm
Speaker B: like, maybe some aspects of the role, but you have not been doing the role.
Speaker A: Right. Right. You understand, you have a vision, you have an I, you know, a thing you want to solve for and a customer problem. Check, check, check.
Speaker B: Yep.
Speaker A: The role has 8,000 more things to be done.
Speaker B: Agreed. So, okay, what's your next biggest misconception?
Speaker A: I don't like. And we'll get twitchy if someone believes that product management and project management are interchangeable terms.
Speaker B: Yeah. Just because they start with pm.
Speaker A: Right.
Speaker B: Same thing.
Speaker A: I mean, God help us if you throw program management in there. Right? That's all. We need new words. We need some more words.
Speaker B: We do need more words. Let's make it way more confusing. No, like. Like, I am. I, uh, do not do project management. I do not. I do not. That's not who I am. I hire people that are geniuses at it.
Speaker A: Yes.
Speaker B: I love my, like, you know, my. My favorite people can run a project. My favorite people can, like, decompose a program. Um, technical program managers are my favorite because they understand the tech and, uh, the architecture implicitly and manage the dependencies between teams and also do the project management that gets you something out the door at the right time.
Speaker A: Right.
Speaker B: Um, but product managers don't do project management.
Speaker A: No. Because that is not the why am I. Why are we doing this and what are we doing?
Speaker B: Exactly Right.
Speaker A: That is the. That is the when is it going to show up? Exactly.
Speaker B: Right.
Speaker A: And if you ask the why, what people to do the win all the time. Like, sometimes on small teams, you need to be responsible for milestones and whatever. But if you want them to build you a Gantt chart, they won't be spending their time with customers, talking to stakeholders, understanding the strategy, driving the product in the right direction. They'll be like, uh, have to see what's happening on Tuesday. Yeah.
Speaker B: I mean, it's like. It's like taking someone from the kitchen who's responsible for doing all of the prep for a chef and putting them out front and asking them to serve drinks. It's probably not the best use of their time.
Speaker A: Probably not.
Speaker B: I should have someone who's an awesome person to, like, run around and manage multiple tables and.
Speaker A: Right. Totally. Marilyn, what's another one of yours?
Speaker B: Yeah. Um, I think another one that makes me a little crazy, um, is when a product manager is just expected to be a feature delivery mechanism, like, build me another button, build me another webpage. Um, without. Without sort of understanding, um, the strategy, the return on investment. Are you seeing the metrics and the things You've already launched. Is this still the right decision? Yes or no, but you better get me the next thing.
Speaker A: Yeah. And I mean it makes me, makes my face one chi when you talk about it, because I think if that was the job, there's no way I could have done it this long. No, no, it's no fun. Like that would be the fun in like, let me go build a button. Let me go. And like, to be clear, of course, if there's a button needed or a. Whatever needed, it's the job, it's part of the job, but it is not the sum total of the job.
Speaker B: Yeah. It's in service of an outcome.
Speaker A: Yes.
Speaker B: It's like, I will build, I will build buttons like you wouldn't believe. I got the best buttons. Uh, but it has to be in service of, uh, of a problem, of solving a problem for either the human. On the other side of the glass, if you're building a digital product or the business, and in some cases both, in most cases it should be both. It should, that button should do something that's meaningful.
Speaker A: Right.
Speaker B: Um, and I think sometimes, uh, we, we like, we will launch features and celebrate the feature and then we don't talk about what happens next. Right. Is it used, is it producing the right outcome? Do we understand what it's doing? Did it actually survive first contact with the customer?
Speaker A: Right.
Speaker B: Because a lot of things don't.
Speaker A: Yeah, totally. I mean we talked a lot about this in the last episode, you know, this. What is the marriage between building for customers and building for business outcomes? And I think when we think about only feature development, we take um, the role of the product manager and squeeze it down to that product owner job. Like the role of a product owner in an agile team. Like write the stories, make sure the team understands, look at the acceptance criteria and out you go. Right. For me, that role is what is the market? What are we trying to achieve? What is the strategy? What is our vision? How do we assure that all stakeholders are aligned around the things we're building, not just the button.
Speaker B: Yeah, you just made my face squinchy because I think there's a, there's a, there's a false equivalency of a scrum actor, role of product owner, and the job of product management. Product managers can actually work in any sort of develop development mechanism. It can be waterfall, it can be safe even though it shouldn't be. That's a personal opinion, should be combat. It could be, it can be Scrum. Product owner is a set of actions that are Taken in the mechanism of delivering software, that is the Scrum methodology. And that can be played by anybody. It's usually played by a product manager, but it's not the sum total of their job. Um, and that, that equivalency makes my, like, it's like if I was a cat and you grabbed me by the tail and rubbed all of my fur backwards. That's the feeling I have. I'm. I'm experiencing right now.
Speaker A: Yeah. It's like, ah, no, I don't want to. Don't make me.
Speaker B: I gotta run away and I might bite you while I'm at it.
Speaker A: Exactly. So I'll say one that I think might even surprise you.
Speaker B: Okay.
Speaker A: Product managers must be technical. You know, uh, you know, I love a technical product manager.
Speaker B: I know I was gonna say, like, I can't believe that's your misconception.
Speaker A: It bothers me when there is this idea that product managers have to be able to code. They have to be super technical. And I think it can be an intimidation factor for people who could be great product managers. That keeps them out. Yeah. And that's. I think that. So I, of course, I'm a technical product manager. I love building platforms, I love architecture. I, I mean, that is my jam. Right. And I've never written a line of code. My teams are always like, what? You haven't.
Speaker B: Right.
Speaker A: But that, that limitation of, um, you must be really, really technical or deeply. You know, you have to be a cs, you know, major. You have to have all this background. I just think it boxes out people who can come in and be great product managers.
Speaker B: I agree with you. I also think there's this notion that, like, if you're an engineer and you just don't want to do it anymore, you can go be a product manager. And I think they're fundamentally different skill sets. I think that engineers typically are solutions oriented. They will, they will jump to solutioning really quickly. Where product managers must be in love with the problem. Yeah, they must be. That's where they, that's where they live and breathe. And you cannot just be jumping to solutions because you're actually missing some of the. The opportunity.
Speaker A: Yeah, I mean, I think, I don't know about you, but I think some of the toughest product managers I've had to coach and make into great product managers have been former engineers. Yeah. They come with all this knowledge that you're like, oh, thank God they already know all of that. And then you're like, oh, now I have to get all of these bad habits out of them.
Speaker B: Oh, you already know the solution. Like, that's not your job to know the solution at all.
Speaker A: Right? Stop talking about the how already. Come over with me to the why of the what.
Speaker B: Right.
Speaker A: And so I do think that there's a, you know, it can be great for, uh, an engineer to become a product manager, and it can also be real hard.
Speaker B: Yeah. So a hundred percent. Yeah, let's, let's go to the other side of that one, my friend, which is like, um, you know, it's only about the ux, it's only about creativity, it's only about innovation at the edge. Um, oh, boy. I mean, we're not just designers of screens.
Speaker A: No, no. Um, we can really create some man, some tough environments when we expect people to just be all about creation and innovation and shiny and experience and all of that. When there is so much of product management that is happening, that is about execution, that is about prioritization, that is about how do I get this aligned with the rest of the rest of the product or the technology or the business or whatever. And you, uh, know. Yeah, that's fun. Innovation and creativity. And shiny is fun, but the other stuff can be fun too.
Speaker B: Yeah. I actually love this notion of the ansoft, uh, matrix, where, like, where like, you, like your, your core product for your core customer must be foundationally solid. It must solve a problem in a really economically viable way for the company. And then you can look at new markets for that product, um, and you could look at new products for that market. Innovation in that top quadrant should be a small portion of your time. And it really is about understanding things that are not new products for an existing market and not new markets for your existing product. It really is more of that sort of like new products for new markets. Um, and in order to responsibly think about your portfolio and how you're allocating your team's time. Right. This is a sort of, like, what, really big balancing act. Um, I would love to spend all of my time in innovation and only thinking about magical things, but that is going to kill a company.
Speaker A: Right, Right. And I think it's interesting what you say. Uh, like, I think we can get really hung up on the language of it must be innovative, it must be new, it must solve a new problem. Most of what people bring to me as a coach, even when they're like, we're trying to solve this problem, I'm like, All right, so 80% of that's already solved problem. So what are you doing about the 20?
Speaker B: Yeah.
Speaker A: And they're often like, no, it's not. And I'm all, listen, we've built onboarding before, we've built this before, we've built two sided marketplaces before. We built, you know, we've used algorithms and AI. We've like, yes, it feels that the pace of change is fast in what we do. Right. But it's incrementally. Like there's these little nits that are happening deep in the tech that make it feel even faster. But most of what you're looking at at any given time is about 80 soft.
Speaker B: Yeah.
Speaker A: Somewhere. And so you can use repeatable patterns, you can use repeatable tech, you can use repeatable, you know, ideas and concepts. You don't need to innovate every time. Calm down, it's expensive.
Speaker B: Innovation is expensive. Like you're actually investing in the unknown. And, and most companies that try to build in the unknown are doing innovation the most expensive way possible instead of learning as quickly as you can, like testing the psychology of an idea before you actually test the idea anyways. Madness, madness, madness.
Speaker A: Yes.
Speaker B: That's a huge misconception of the role of product management.
Speaker A: Yeah. All right, so the last one I have, and then maybe you have another, but the last one I have is that product management is glamorous. I mean, weird glamorous. But I, you know, I think I may have mentioned this in one of the episodes, like when I was at Klarna, we had this, this pipeline of people who wanted to leave other competences and become product managers. And the first question I would always ask them is like, why? Yeah, why do you want to be a product manager? Because you better understand how hard this job is before you say, I want to be a product manager. This is not like, you know, Rudolph the red nosed reindeer and the little kid that's like, I want to be a dentist. That's not the same thing. Right. It's like, this is, this is work and it's not all shiny and glamorous.
Speaker B: I think that, uh, some of the best product managers I know make it look easy. Um, and I do think it can look fun.
Speaker A: Yeah.
Speaker B: Mhm. But when it's done right, uh, when it's done right, um, I think that you, again, like, take almost no glory.
Speaker A: Right.
Speaker B: Like, how are you elevating your team? I, um, mean, I like you and I have both worked, you know, long nights, long hours and past credit, because that's what the job is.
Speaker A: Yeah.
Speaker B: You know, your finance guy's the one that developed the mod, the financial model, your engineers are the ones that built the product that scales. Your UX person made it delightful. Like, yeah. You just brought it all together in a way that made a little bit of economic sense and, like, kept the team together and, you know.
Speaker A: Yeah. I'm holding poster board and a glue stick. Like, that's my job.
Speaker B: Right.
Speaker A: And I'm like, I'm gonna put this all on the same board. Right. Uh, but it. I didn't do most of the deep pieces. Right. I. To your point, you brought it together. And I think, you know, I. A while ago, I wrote this sort of open love letter to product managers that was basically like, I see you, I see you grinding.
Speaker B: Yep. Right.
Speaker A: It is a. I see you grinding and everybody saying like, oh, it must be so nice to be the CEO of your product. Back to, um, full circle.
Speaker B: Yeah.
Speaker A: See you grinding.
Speaker B: Yeah.
Speaker A: Right. Because sometimes it is rewriting the document, checking the data. Let me go. I gotta go figure out why we don't have these user stories. Why is the testing not working? Why is, you know, like, where. Why is this bug keep happening? What is. You're in the weeds.
Speaker B: And oh, by the way, am I still on track for product market fit? Is my strategy still.
Speaker A: Right, right, right.
Speaker B: I think that people that work for me are sometimes like, I can't do it all. Uh, and I think if you're. If you're a strong product manager, that's often the feeling.
Speaker A: Yeah.
Speaker B: Because you understand the breadth of what you have to do and it's a balancing act.
Speaker A: Yeah, yeah.
Speaker B: Uh, you know, you're going to sort of like, often put in, like, effort somewhere and then realize something's suffering and then come back and totally. It's, uh, exhausting.
Speaker A: And despite all of that, we love it.
Speaker B: I sign up for it every single day.
Speaker A: Exactly. And I love coaching product managers and being like, keep going, keep going. You can go. You can do this. Right?
Speaker B: Yeah.
Speaker A: I loved it. I mean, I. So it. It is. There is something so beautiful and challenging and exciting about the grind and the glamour. Yeah. I don't actually.
Speaker B: Like, did I miss the whole glamour part? Because, I don't know, like, I never really got the whole glamour part.
Speaker A: No, no.
Speaker B: I love the, um. I think that the nice thing about what you just said and the way that this sort of like, comes together is, is you're really a team builder. You're not going to build the strategy yourself. You're not gonna understand the business and the economics all by yourself. You're sure as hell not gonna figure out how you're gonna deliver It. And when it's gonna happen by yourself. Right. Um, you're not going to make any decision by yourself because someone's always going to challenge you. Your job is to harmonize all of that and get everybody in alignment that this is the right thing to do right now. It's not always going to be easy. It's not always going to get everybody to alignment, but there has to be someone that brings this brilliant group of people with this larger problem set together to make something happen.
Speaker A: Yeah.
Speaker B: And that's the job.
Speaker A: And there's. So there can. There is exactly right. What you just described that, like, that is where the joy is.
Speaker B: Yeah.
Speaker A: Right. Like, yeah, it's hard and there's a lot to it. And you have to. You m. Have to rally all your best communication skills and all of your patience and all of your, you know, brain power and. And all of your listening and all of those things. And the joy is in that space.
Speaker B: Yeah. If you love.
Speaker A: And the thing is, if you love being a product manager, like, you love it. Yeah. Right.
Speaker B: And so, because the magic is right there in the middle. And I'll tell you, I have no patience, I have no communication skills. All of the things you just listed, I was like, ooh, um.
Speaker A: Oh, right. You do, too. That's not true.
Speaker B: I do. I. You know, I think there's a lot of misconceptions and. And, um, I'm happy that we're bringing them to light. And I think they're difficult and they're. They're endemic in every company. Um, and the only way to overcome them is not by whipping out a document and being like, let's do a huge, racy. I hate races. Races make me very sad.
Speaker A: Um, it makes you. It makes you throw pins.
Speaker B: Yes, it does. I have. I have thrown a pen in fury.
Speaker A: That's the only time I was in, ever, in a racing meeting with you. I was afraid to do it ever again.
Speaker B: Then I met my goal.
Speaker A: I mean, the good news is it hit the board and bounced in the trash. So it worked out great. Exactly.
Speaker B: Shot into the garbage bin. I hate races. I feel like they're just, uh, they are frameworks to set people up to battle.
Speaker A: Yeah.
Speaker B: And really, the best teams need to seek to bring themselves closer together. Don't draw lines. Figure out how to optimize everybody's superpowers in order to get the right thing done. How do you work together? Not how do you draw battle lines. Yeah.
Speaker A: Uh, I love, uh, that maybe we can do an episode in the future on, like, How. What do you do in conflict as a product manager? How do you hold that space? What are some tools?
Speaker B: I throw pens.
Speaker A: Throwing pens. I mean, it worked out. I laughed.
Speaker B: Right. I was so mad.
Speaker A: I'm not sure everybody else did, but I laughed. I think that might have been weak2@Amazon for me. That's good.
Speaker B: I like races. Make me sad.
Speaker A: Yeah, I'm with you. I'm with you.
Speaker B: I do think that conflict is a really good. Like that. That is. That is a great topic because, uh, there is no. Especially when teams are early in forming, before the trust, before you get the wins, before you understand each other's superpowers. Conflict is high.
Speaker A: Yeah.
Speaker B: And even after you're, uh, uh, a really super tight team, there will be. There will be moments where you disagree.
Speaker A: Yeah. And I think going back to sort of the idea like, like, theoretically you should manage conflict by doing these things. Also, my feelings are hurt. Yeah. Right. Or it feels personal. Like, oh, it's not personal. Well, feels personal.
Speaker B: I'm a person.
Speaker A: I'm a person and I feel it personally. And so really, what are the.
Speaker B: What are.
Speaker A: You know, I think, like I said, I think this is a great topic for the future. Like, what are the ways that we can really, like, dig into that space and say, okay, we're going to work this out. It's not going to be easy.
Speaker B: Yeah, I think we have good, good stories around that. Yeah.
Speaker A: Yep, we do. Maybe we could talk about ourselves. Right? Yeah. Okay.
Speaker B: So for everybody that listens to us, um, what are your common misconceptions? What, you know, what do you see out in your industry? What do you see in your companies? What do you think that, you know, that, that really is, like, people think product management is blah.
Speaker A: Yeah, tell us, Tell us. You can leave a comment on anywhere that you're watching it. We'll. We'll respond to that. You can go to our website, um, which is practical product management, podcast.com. it's a lot of. Lot of words. Um, you can go there and check it out. And if you have been a person who feels like, uh, you know, the misconceptions made me not want to do it anymore or, um, actually made me want to dig in and do more. Like, tell us. We would love to talk to you. Come talk to us.
Speaker B: Also, don't leave product management because you've been in a company that has misconceptions. Like, uh, we need. We need more product managers in the world that are helping us build the right thing. So don't let one weird environment take you down, right?
Speaker A: Totally agree. Totally agree. Awesome. Thanks, Marilyn. This was fun as always, Sam.
Other episodes covering the same guests and topics, from across The B2B Podcast Index.