In this Dear Melissa segment, Melissa answers subscribers’ questions about learning how to compromise and collaborate with fellow product managers and new team members.
Show Notes
Q: How do I work with other PMs in a productive manner and avoid an unhealthy competitive atmosphere?
Q: How can I improve a relationship with a new PM and our ability to collaborate?
Q: How do you determine how much you need to reduce the scope of a feature when defining an MVP? Do you have any ideas for how my PM and I can come to an agreement?
Resources Melissa Perri on LinkedIn | Twitter MelissaPerri.com
Episode Transcript
In practice, it always ends up being a hybrid between what this person is doing and what you're doing. And as long as it gets done, and as long as you create products that people use and they produce outcomes, that's the right way. So you might wanna also ask yourself if you're being a little dogmatic.
And then are they being a little dogmatic? You're probably both being a little dogmatic, honestly. How can you compromise, right? Like how can you come to an understanding that we're both in it towards these goals, working towards these goals, creating things that are going to actually achieve our goals and we're on the same team.
We're all on the same team. We're all in this boat together. I think that's the only thing that's gonna bring you back and improve your relationship. You gotta give a little, you gotta take a little, and you gotta share some learning. And hopefully you align, but you can't give feedback to somebody who's not receptive to feedback.
Hello, and welcome to an episode of Dear Melissa from the Product Thinking Podcast.
The lines are now open and we're ready to answer your most pressing product questions. Which prioritization framework would you recommend and why? Hi, Melissa. Do you have any suggestions on developing a product strategy? What's the best way to invest in a smart product? Hi, Melissa. I have a question.
Which do you recommend and why? Whoa, whoa, whoa, whoa, whoa. That's a lot of questions. All right, let's dive in. Hello, and welcome to another episode of the Product Thinking Podcast. Today, we have a great episode for you all about compromise and collaboration, which is a key skill for product managers, right?
We can't do this on our own, so we've gotta work with other people and we have to figure out how to collaborate with them, how to compromise, and it's not easy. So we've got lots of good questions on this and we're gonna dive right in. So, first question. Dear Melissa, I'm a regular listener and I really appreciate your insights on all things product.
I recently landed a job at a high growth company as one of three new product managers under a new VP of product.
I'm really excited about this opportunity, but I just left a small startup after two years as their sole product manager. So I'm used to being the only PM and working with a small team. How do I work with other PMs in a productive manner and avoid an unhealthy competitive atmosphere? Any insight on this would be greatly appreciated. This is a fantastic question and also a tricky one because you want to really rule the world when you're the sole product manager, but we'll talk a little bit about how you can collaborate and how you think about your new team members after this quick message.
All right, we're back and we're talking about how do you go from being the only product manager to actually working with a product management team? The great thing about working with a product management team is like, congratulations, you don't have to do this by yourself. You have other people to brainstorm with, to jive with, to get other ideas thought of.
Come on, working with a team is fun. So you have to think about it that way. Don't approach it like I'm losing scope or I'm losing my importance. Approach it like, hey, I finally have people who understand what I'm going through and I can bounce my ideas off of them. I think as long as your product management paths, like your job scope is well-defined, you're gonna be okay.
Like you're not gonna be stepping on each other's toes. There's no competition there. It's about really working well together. So you should be meeting regularly to discuss what you're all working on, if there's any dependencies, and also get ideas for what you're doing. One of the best product management teams I worked on, we would do this all the time.
Like we'd get together, we would do little classes together to learn things. We all took an HTML class and presented what we were working on to each other because we just wanted to get better at it. We would talk about what we were trying to solve and the problems we were trying to solve. I'd get feedback on my experiments.
And it was really nice having other people to turn to when you need advice or needed to bounce something off of them, besides just your team members. Sometimes that good outside perspective is really important. So that's what I would really look at. You have to ask yourself why you would be competing with them.
And I'd also ask myself, is the culture setting me up that way? Is your VP a product? I'd ask this question if I were coming in and you told me this, is your VP a product pitting you against each other? I've seen that before. I've seen that in executive teams before too, and it's really, really unhealthy.
And if you do observe that or you think that might be happening, it might be important to bring that up. Hey, can we all work together as a team?
I feel like I'm kind of being put on trial here to be the best PM. I wanna be the best PM, but I think we can all collaborate together. I think these are good things to actually look at. If you feel like you're forcing the competition because you're just used to ruling the roost and being the only person there to do it all, take a couple steps back and think about what you get with the team.
Because in reality, you're never gonna be the only PM somewhere unless it's your own company. You're gonna be a team of one for a very long time. So you're gonna have to get used to working with a team and you need to look at them as colleagues and not competition. If you do your job well and they do your job well, this company, you just said it's in high growth.
It's gonna scale. Like you're gonna hire so many people. So many people actually, it's gonna make you like your head spin. When I was at OpenSky, I was employee like number 30. And by the time I left two and a half years later, I think we had 150 to 160 people. So expect that.
Expect that type of growth when you're in a high growth company. It's not gonna be just you and these people you're looking at. Your team is gonna grow pretty fast as well. And there's a spot for everybody in that, which is great about high growth companies. In a corporation or a larger company, you may need to wait for somebody to leave to move into their role.
In a high growth company, those roles, especially if you wanna move up the ladder, like they're just gonna open up because you're gonna scale and scale and scale and grow and grow and grow and have so many team members that there's gonna be a spot for all of you. So don't think about it that way. Think about doing your best.
Think about collaborating. Think about bringing your other team members along with you. And also think about what you can learn from them and what they can learn from you. How do we collaborate as a team? How do we think through our strategies together? How do I show that I'm a good team player as well and that I can work with these people and bring them in?
But again, like I said, if you do have a culture at this new company where it's very competitive, it might be something that you wanna all agree on to like kibosh, like, can we actually not do this? Can we all work together?
There might be larger conversations that you need to actually have there. So hopefully that advice helps. Look at them as peers and look at them as allies. Don't look at them as competition. All right, second question. Dear Melissa, we've recently hired a new PM from a company that competes in our space.
I quickly observed that they have different ideals and ways of operating than I do. Having come from a culture that was very top-down and efficient, we've already butted heads on product philosophy and execution. They feel that our teams are lacking structure and process, hindering our efficiency and ability to execute, while I worry that they are very quick to get to solutions which could result in us building the wrong thing.
I provided them with feedback, but it wasn't taken very well. This PM is technically senior to me and cited their experience as a PM with the former company as reasons that they're able to quickly land on what the right thing should be. And yes, I have even mentioned Escaping the Bill Trap as the book they might find helpful for this perspective.
Because our product group shares goals and outcomes across a number of collaborative projects, I'm worried that our product group could suffer from the thrash and distractions that can come from misalignment.
How can I improve this relationship and our ability to collaborate? I'm stuck right now between trying to balance our philosophies, attempting to lead by example, which is difficult due to seniority, or just continuing to bring this up to our mutual manager. What should I do, Melissa? So this is a really interesting question, and I think there's a lot to unpack here.
Differing product philosophies. Oh man, I've seen that a million times. It's something that you're gonna run into a lot. So I feel like this is good, just advice. This is not the first time this is gonna happen to you. So let's unpack this a little bit and see where we go. First of all, you said that you gave the product manager feedback and it wasn't taken well.
I think one thing to understand about giving feedback is you can give feedback, but if somebody is not in a place to receive feedback, it's not gonna be taken well, and it's not gonna be effective. So you may have tarnished a little bit of that relationship by giving feedback to somebody who wasn't willing to hear it. This is something that I had to learn with coaching.
A lot of people say they wanna be coached, but they don't.
Or you go into an organization and the executives are like, hey, coach my team, but leave me alone. And you coach them and they're not happy about it. So that's one thing about giving feedback. Somebody has to be in a position to actually be able to take that feedback. So in this situation, you might need to have let it go for a little while.
Let it go a little bit longer. See if that person is having trouble. And then when they come to you for advice, like create that relationship where they're actually gonna listen to it and receive it. So that's something to remember just about giving feedback in the future. But right now you already did it.
So it's out of the way. So what can we do? All right, so they are talking about having very top-down efficient process. There is a good thing about speed, right? Getting to a solution quick and trying to figure out how to get it out there. But yes, with speed does come a lot of problems that you're mentioning, should we be building the right thing?
I've also seen a lot of teams toil in the experimental world for a really long time, right?
Or take longer than they need to to get to a decision about that. So you can take a couple steps back here too and look at your process just from an objective standpoint and say, are we going as fast as we could possibly go to prove these things and actually get this out to market? And you know what?
The answer is probably somewhere between where they're going and where you are. Like maybe there's opportunities for you to improve your efficiency and actually get things out to market faster. But maybe there's a lot of opportunity for them as well to learn how you're working and to be more experimental and to not just jump to solutions too quickly.
And you're gonna have to find out where that balance is. So you need to look at their process and start to give them cred in some spots, credibility, right? You gotta look at this and say, what are they doing that's actually really good that I can pull out and praise? And you wanna give them credibility with the rest of the teams.
And you also wanna talk to them about that and see if you can learn from that.
What this does is establishes a relationship with them where they're gonna start to trust you. Now, I'm not saying that everything they're doing is great and you probably don't agree with that. And I don't know if I would agree with that because I don't know what this looks like, but find the thing that is good.
Find the things that they're doing that are good and amplify them. Bring them to the team, ask them if they can explain how they do that, make them a little bit of a hero. But then in the same way that you just did that with them, do that with your processes as well. Maybe you could start like a lunch and learn or something where you all talk about product management practice and what the objectives are and really break it down and figure out what pieces you can use from all the different processes to actually work well together.
I'd also try to figure out like from a philosophy of product management, it's not just about the processes you're using, right? Like this way that you execute and how do you jump into conclusions and solutions and experimentation and stuff like that. Like talk to them about what they feel like product management is just period, right?
Like talk to them about their domain knowledge coming from this other company. Talk to them about the competitive space. Talk to them about what they learn there. If you show an interest in what they know, you're gonna create much more of a rapport with this person and then they're gonna trust your opinions, especially when you go to them and say like, hey, your process sucks.
You should be moving over to our process because we're doing it the right way. A lot of times like, I know like I write in Escaping the Build Trap, how we should do this well. And I do think companies do find more success when they use the methods that I am talking about. But in practice, it always ends up being a hybrid between what this person is doing and what you're doing.
And as long as it gets done, and as long as you create products that people use and they produce outcomes, that's the right way. So you might wanna also ask yourself if you're being a little dogmatic and then are they being a little dogmatic? You're probably both being a little dogmatic, honestly. How can you compromise, right?
Like how can you come to an understanding that we're both in it towards these goals, working towards these goals, creating things that are going to actually achieve our goals and we're on the same team.
We're on the same team, we're all in this boat together. I think that's the only thing that's gonna bring you back and improve your relationship. You gotta give a little, you gotta take a little and you gotta share some learning. And hopefully you align, but you can't give feedback to somebody who's not receptive to feedback.
I've tried it, it sucks. Nobody listens to those things. So make the relationship strong first. Don't keep hounding them around the way that they're working. Learn what they know that's important for you to be successful. Leave what's not gonna make you successful, but show an open mind to learn some of their things, talk to them about what they're really strong at, try to figure out what that is, and then really focus on creating that rapport and that relationship.
Talk about shared learnings and things like that. And then once you have trust, that's when you can start to give feedback. But you can't give feedback without that type of trust. And that's the part that's gonna be really, really tricky about mending this relationship, but it's totally possible.
So take a couple steps back, don't jump to conclusions, don't like really dive in there. Really try to figure out who this person is, why they're here, why they're committed to product management, what they wanna achieve, what their goals are, and start speaking in that language and start figuring out what they're really strong at and make them a little bit of a hero for that. That's what's gonna make them trust you.
Then you can really get into your differences once you establish that trust. So that's my biggest piece of advice there. All right, last question. Dear Melissa, I want to know your thoughts on how to know how much to reduce the scope of a feature when defining an MVP. I'm a product designer, and this is something that my product manager and I always disagree on.
My product manager wants to make it as light as possible to start measuring it as soon as possible, but I always worry that we will reduce it so much that it will no longer give the intended value to the user. Do you have any ideas for how we can come to an agreement? This is a really good question.
I have seen MVPs that have been reduced to be too light and they don't actually test what you need it to test.
So the best way to really reconcile this is, you know, take your opinions out of it and then go back to your riskiest assumptions and then also what you need to define about those assumptions that you know will make this product a success. So let's go back to our known-knowns and our known-unknowns, right? What do we know as known-knowns and how do they relate to the solution of the product?
Those are the things that you need to include in your MVP. If you know that people are more comfortable operating on mobile than they are on desktop, like that should be included in your MVP. Then once you get through those known-knowns and you've looked at them, then go to the known-unknowns and figure out what your riskiest assumptions are and what you're trying to learn from this MVP.
And then once you design the solution to learn that thing, go back and ask yourselves again, is there any part about the solution where somebody is using it that can actually skew the results? We are not gonna learn what we wanted to learn. Give you an example that's like common, I see all the time.
Sometimes people don't pay attention to the design of the product when they launch it and the design looks like it's not even part of the software they're using. Like the feature is just completely left field, looks like junk and everybody looks at it and they're like, is this broken? Is this even part of this platform?
If a user is looking at your MVP and they can't even tell it's part of your product, you're not gonna learn what you wanna learn. You're not gonna learn if they're gonna use it because you already set up a criteria where it looks out of place and it looks like a test or it looks like something weird and that's gonna skew your results. So you need to really sit down and go through like the whole solution.
Just think through every angle. Could this affect our results? Could the way that it looks affect our results? Could the way that we've marketed or showed it or put the value proposition on it or the content, anything, right? Like how could this affect our results? And then go back and say, is that preventing us from learning what we actually want to learn?
Because that's the whole point of an MVP, right?
You need to really align on what is it that we're trying to learn and is this thing going to help me learn it? And if the solution or the thing that you're shipping is not gonna help you learn that thing, that's where you have to throw it out and come up with something else. But there's always facets of it or factors in the MVP that could skew your results and you really wanna think through them.
So I think through experience a lot of times. I think through the way I notify people about it, the messaging around the MVPs. I think about the data I'm collecting on the backend. I'm thinking about what I do next as well. Like, can I actually deliver on the value? Am I not delivering on the value?
And there will be a different threshold for how big it can be for each type of product. Like there is no hard and fast rule here. And if you're getting ready, let's say this is more of a first version, like it's gotta be good enough where it does deliver on that value. And if you can't complete the full transactional value of what this product is supposed to solve, then you're gonna have skewed results for sure.
So I think these are good conversations, but I would just really go back to the basics, lay out what the problem is that you're solving, what are assumptions around it, align on what you're trying to learn, and then really pick apart your solutions together, look at them and try to come to an agreement about what is going to skew the results of what you learn based on if you bring it in or leave it out. That's the only way to solve those problems. So thank you so much for listening to this week's Dear Melissa episode.
If you have any questions for us, please leave them at dearmelissa.com. I love answering these every other week. Next week, we'll have another guest on our podcast, so I hope you can tune in. And if you're loving dearmelissa.com, please subscribe. That's always really important for us. And then make sure to leave a review and let people know that this is a good podcast to listen to.
I appreciate it. We'll see you next time.
