Episode 88: Dear Melissa- Answering Questions About PMs as Scapegoats, Breaking Hard News to Developers, and Sunsetting Products
In this Dear Melissa segment, Melissa answers subscribers’ questions about how to handle the unfortunate reality that oftentimes product managers are blamed for things out of their control, how to communicate to engineers when it’s time to pivot off of a project they’ve devoted a lot of time and effort towards, and how to build a shiny new product without completely disregarding all of the learnings from the original one.
Have a product question for Melissa? Submit one here and Melissa may answer it in a future episode.
Subscribe via your favorite platform:
Q: What should your course of action be if you perceive yourself a scapegoat position in product management? [2:54]
A: I think a lot of people think product management is this glorified position where, if [you] get into it, [you’re] going to be like Steve Jobs. More often than not, we're put in really bad situations like this as product managers. Here are some things to consider if you believe you’re in a scapegoat position. [3:23]
Q: Have you ever had to pause a tool or product? Do you have any frameworks when making such decisions? To what degree is it my responsibility to communicate this as opposed to senior management? [9:11]
A: If you get into an organization that celebrates killing products, that's fantastic. However, it may cause friction with the developers who have spent a lot of time and effort in building the product. Here are the best ways to communicate a product kill to the engineering team. [10:13]
Q: How can we use our current product to help us build a better replacement? [15:40]
A: There are certain times when you can't leverage old things. Ask yourself this: is this design the best design? Why does it win in some places, and then where can you actually improve it? Tune in to learn how I would tackle this issue. Hint: it involves user research. [16:06]
Resources
Melissa Perri on LinkedIn | Twitter
Transcript:
Melissa:
Hello and welcome to another episode of Dear Melissa. Happy q4 everyone, as you're going into annual planning season, I hope you are really taking a step back, uh, thinking about your strategic intents, your goals, your outcomes that you wanna hit, uh, and making sure that you're focusing on those. And I also wanna let you know too, if you are having trouble setting up a good way to understand the outcomes of your strategy, assess your strategy, uh, get the data to make strategic intents, all that wonderful stuff, we are having a product operations workshop coming up through produx labs. And in that workshop we do teach you all about how to set up a good product operations framework, uh, and organization so that you can get all that information and you can make updates to your strategy a little bit faster and, uh, more repeatedly, more iteratively throughout the year so that when we go into November, it isn't like we throw everybody in a room and say, Hey, guess, right?
Like, let's try to pull all the data in one week and see what happens, because that's gonna take away a lot of time and a lot of development power from your teams. So October 27th, we've got a remote masterclass happening. If you go to produxlabs.com, look at our training there, you will see it, you'll be able to sign up. Denise Tilles is our, uh, instructor for that. She is my co-author on the product operations book. And uh, this is a great way to get up and running and understand more about what product operations can do. So definitely go check that out. In the meantime though, on this week's dear Melissa, we are gonna answer three questions for you about product management. The first one is about being a scapegoat in product management bet. A lot of people can empathize with that <laugh>. The second one is gonna be how to communicate hard product decisions to the engineering team. And the last one is gonna be about sun setting products. So I wanna remind you before I dive in that if you have any questions for me, please head to dear melissa.com. Uh, we love it when you leave voicemails, you'll hear one of our voicemails in this episode, but call in, let me know what you're thinking. It's great to hear your voices and be able to connect with you from all over the world. Without further ado, here's our first question.
This question is the, Dear Melissa, what would be your course of action if you're perceived as a scapegoat? So, ooh, this is a toughie. You know, I think a lot of people think product management is this glorified position, right? Where if I get into it, I'm gonna be like Steve Jobs, I come up with all the ideas, I'll be the hero of the SaaS company, whatever it is that you may think this job is. More often than not, a lot of the times we're put in really bad situations like this, SaaS product manager, and I do hear a lot from people that, you know, the product manager in their workplace is a single threat to choke, or it's the scapegoat, like you said, or the people that get blamed for everything and they don't feel empowered to make these decisions that they're supposed to be making and doesn't seem fair.
And it's not fair, honestly, that you get held accountable for all of these things. So I'm gonna unpack a couple different sides to this question. It's a great question, but I need you to think very carefully about the situation that you are in and figure out which parts of this apply because I only know so much. So I'm gonna tell you what I've seen and what I've observed, but uh, here it goes. So first off, are you able to push back? In a lot of situations, we end up in this waterfall environment where we've got executives dictating down what we should be building. Uh, they tell us what to do, they're communicating in solutions. And what I see happen is that a lot of product managers don't know how to navigate that. So they end up taking those things, becoming a waiter and you know, just implementing them.
And then when they don't work out, the executives go, Oh, what'd you do? Like, you built that solution and it didn't work, blah, blah, blah, blah, blah. You're sitting there going, Well, you told me what to build, like I just built what you told me to. And it becomes this vicious cycle where you're held accountable for the decisions that you did not make. Now that's not what good product management should be like. So in those situations, the ideal way to approach this is to not build everything that's dictated down to you, right? You need to be questioning all of those solutions that come your way. You need to be asking, why are we doing this? What outcomes do we wanna achieve? Um, why are we building this? What's the data that you have on this? What's the, you know, what's the goals that we're trying to reach as a business?
And the idea here is that if your executives are dictating down solutions, you wanna lift them back up by getting to the why, trying to focus them on other things. And sometimes that's really, really hard to do. I'm not saying this is easy, <laugh>, anything i I tell you to do usually is not very easy, but it's worth it, right? And that's what we should be doing. So can you push back instead of just building everything, like can you go back and say, Hey, um, that's a fantastic idea. I also tell people like, don't jump the gun. Don't be like, Oh, that's awful. Like I should be coming up with the ideas. You just need to give me goals, right? Play into it. That's a great idea. I just need some more context. In order to build this correctly, I need to understand what the outcomes are that you're trying to achieve.
So let's sit down and talk about this. If I build this thing, what does success look like in six months? What numbers do you wanna see change? How do you know that those numbers are going to change if we build this? Like really pick apart what you're being given, right? Make sure that you understand it before you decide to commit to it or not. And then at the end of the day, it is your decision or it should be on whether or not you build that. Now you might not be set up in an organization that you, this all works really well together. You might need to bring up like, hey, I need to be really understanding what the goals are and we need to be focusing on outcomes here. You may need to like try to see if you can shift people into that mindset.
And then sometimes, you know what? That just doesn't work because the organization that you're at may be toxic or not set up correctly. Um, it may be really hard to hear these things coming from somebody internally as well, which happens a lot. So I'm telling you all the things that should work, but you need to understand or kind of assess your situation to see if it will work. And that's hard. Is this a safe place? Doesn't sound like it to me, but is this a safe place where you can bring up these things where you can say, Hey, I don't think we're doing this correctly. This is not how the best organizations work. What we should be doing is X, Y, and z. I should be doing X, you know, these these things. You should be giving me this stuff. This is how we should be going.
It sounds like you're being pushed out of these key positions that you want. It sounds like you're being blocked from decision making and it also sounds like you brought up some of these concerns that I'm actually talking about. And if that's the situation and people are not embracing how good product management should be, well, you need to look at two things. One, can you change the approach of how you did this? Did you come in like super fiery and tell everybody they were doing it wrong? <laugh>? In which case people don't love that. People are gonna be like, Hmm, I don't wanna listen to the person who's screaming at me. Um, I've been in that situation before where I have done that. Trust me, I've told everybody that they were wrong <laugh>.
And that's not the best way to approach these situations. Instead of really trying to figure out where the organizational goals and showing people how product management can help get them there. But let's say for the sake of argument that you did it all right, you approached it really well at that point. I don't know if this is the right environment for you. That's a really tough thing to say. It's a really tough piece of advice to give people because I don't take for granted that switching jobs is easy. Um, I don't take for granted that, you know, finding another job is easy, but if you feel like you can't thrive in this place because it's toxic, um, and people don't wanna do good product management, then you deserve to go to a place that does wanna do good product management. And there's a certain point where you just have to say, it's time for me to go. And that might be where you're at. If you're not getting the opportunities that you need to grow and you are not able to make the decisions that you need to do as a product manager, it may be time to go, but I don't take that for granted. So I would try all the things that I just said. If you've already tried them though, that's when it's time to take a hard look at where you're at and say, If I can't change the people in my situation, it's time for me to change my situation.
All right, second question. Dear Melissa, my question is about pausing development and deprecating products. I recently had a pause, a development of an internal tool that had been struggling to drive adoption with internal users even after two years of being launched. I inherited this tool after I joined the team and I was a third pm looking after it. I recommended pausing its development to my leadership because of one wrong product market fit and two lack of alignment across organizations. Soon afterwards, the decision was made in my engineering team of six people, many of whom I've worked with, who've worked on the tool for a long time, moved out of the organization, the engineering manager had left the company months before I made the recommendation. While I still think pausing the, the development was the right choice, I wonder if there was a better way to communicate it to my engineering team.
Have you been in similar situations where you had a pause or deprecate a tool or product? Do you have any frameworks when making such decisions? Lastly, to what degree was it my responsibility to communicate this as opposed to senior management of product or the executive layer? Thanks in advance and congratulations on the continuous good work you do with your podcast. Well, thank you very much.
Yes, I have been in this situation before where you know that this product is not worth looking at and you're gonna have to kill it. A lot of teams like to kill products <laugh>, and they celebrate it. And if you get an organization that celebrates these types of things, that's fantastic, right? You want to get into the habit of being like, Yay, that wasn't a great product to maintain or to build and we killed it. Let's focus on the things that really matter. But if you've had an organization that's been working on these products for a very long time and then you kill it, a lot of people who built it could feel that sunk cost fallacy of, Hey, you know, we just went through all of this trouble of building this thing over a lot of years and then you went and killed it and all of it was for nothing.
And that feeling does seep into our work and it seeps into the people's mindset who have been working on this thing for a very long time. So when we decide to kill something, we need to really communicate it well. How do we communicate this with the engineering team? I know you guys put a lot of time and effort into building this product, but it's not meeting the needs of our business anymore. Here's where the vision of our company is going, Here's what the goals are doing. You know, this is where where our company's trending, here's what our business goals are. Our product is not living up to those things. Now we could spend all this time refabricating it, but if we did that, here's the projected outcome of where it would be and it still wouldn't be enough to justify the cost of building this thing.
So what we wanna do is make sure that we're working on the most important things we could be to further the business. And we wanna make sure that we're rolling this down so that you can all focus on the new cool stuff that's gonna hit our goals and be critical to the success of our business. Now you're putting your engineers in a hero position, right? Where they get to be freed up from this product to work on some cool stuff. That's, that's a Boone usually. two. You wanna also communicate to people that you know, it costs money to keep products going, it's maintenance, it's oversight, it's data hosting. You know, it's not free to just have data on the cloud. Um, and a lot of people don't understand that. So you wanna show people that it costs money to keep these things going and that instead we could be spending that money on things that are gonna make the business better.
You also wanna put these engineers too into a position where they feel like I'm gonna be working on stuff that's gonna further our business and be, you know, out there as critical products. You know, not something that's old and stodgy, but something that's gonna be a critical product that's gonna help our customers. So that's really what you wanna do. And you have to take into account that these people poured their heart and soul into this product for a very long time. So if they've been working on this for a long time and you're the third PM looking after it, they've probably seen a lot of change. They're like, Oh, somebody's coming in here just to tell me what to do again, You know, changing their mind, putting us through all this stuff and then they just killed all the things I was working at. That is what their mentality is going to be.
So how do you reposition it? How do you reframe the opportunity for them in this moment when you kill this product and get to work on other things? That is the way that you really communicate these decisions and you show data, you show that it's not just like, hey, this was a management decision. And that's another thing too. When you decide to kill it, it shouldn't be a shock to the engineers. You should be communicating this stuff to them throughout these conversations. Otherwise they're gonna be like, Wow, they just had a leadership discussion and decide to roll back all the things we've been working on for years and nobody consulted us. That's not how it should be. You should be having conversations with your engineers about how much this product could produce. What could you do to actually change it? Um, what effort would it take to make it better?
And that should help them see that if we just keep spending all our money and our time on trying to improve this, we're not gonna reach what we need to as a business. And then you paint the picture of the opportunities they could have if they worked on something else, if we rolled it back. But you wanna bring people along for this journey. You wanna feel like it's partly their choice as well of whether or not to stop building it. And if you just surprise them and say, Hey, all the things you've been working on are gonna go away tomorrow, that's when people are gonna get upset. So that's how I would communicate these choices and that's why I've seen be successful. When you make these decisions, it comes down to, you know, we, we are talking about frameworks, how to make these decisions. It comes down to what's it gonna cost, what's the opportunity if we do fix these things and uh, should we be working on something more important?
What's it gonna cost to just keep it going? How many people are using it, right? Like I look at all of those things before I decide to kill things, but just having like a product around is not free. So I applaud you for killing this. Let's put it that way. Like, I applaud you for killing this and that's good. You wanna make sure that your products are simpler so that you can develop on top of them better. Lastly, you asked, what's your responsibility to communicate this first senior management or the executive layer? It is your responsibility to communicate it if it was your decision. And if you bring your engineers along for that ride, they should be behind you. They should be like, I get it. And you should also approach them with, look at all this other stuff we're gonna be working on too, so that they get excited about what's to come. Otherwise they're gonna be perceived as replaceable. You don't want that. So really think about how you're gonna approach your team. Get your team behind you. Make sure your decision making is transparent and do not surprise them. That is the biggest part of really deprecating a product. And remember, like humans work on this. People get attached to the stuff they work on. You don't wanna surprise them. You wanna make sure that they're brought along for these decisions as well.
All right, last question. Dear Melissa, My company is in the process of completely rebuilding one of our SaaS products to sunset an old design that can't be simply updated for multiple reasons. Old code can integrate with the rest of our suite, need to build something more user friendly that can scale for support. Although I agree with the decision to sunset the old product, I feel like we've so far ignored most of its design to try and build a shiny new thing as it's replacement. How can we use our current product to help us build a better replacement? I love leveraging old things. Um, but there are certain times when we can't leverage old things. So let's go through two scenarios. We really need to evaluate is this design the best design? Why does it win in some places? And then where can we actually improve it?
Now when you're making a big switch, um, there's a couple different ways that you can update code or back ends. You could just change your back end and keep your front end all the same. Uh, you may need to rebuild the front end then because it doesn't work what the code base out you're using, like if you're going to change code bases, any of that stuff, it sounds like it can't integrate. You're probably gonna have to change what the front end looks like too, depending on how it was built. That can give you an opportunity to update to the the design. And it sounds like a lot of people are excited about that. So they're like, Oh, cool, let's just redesign everything. It's great to look at these opportunities with a fresh eye and figure out what could be a better workflow, but you still have to learn from the past.
So what would I do? I would do a lot of user research with people using the old design and understand what works, what doesn't work, um, where could we improve, where should we keep it the same? And do like a really deep dive there and then take all that feedback and incorporate it into the new design. There are certain things that you probably shouldn't change. And if you do keep this in mind, if you do change everything and there's a lot of people using this old design and they like it, they may be extremely mad when you update it, if it's not better, if it's not more intuitive. And sometimes we think that it is more intuitive, sometimes we just get wrapped up in our own heads and say like, Cool, we could do all this great stuff with the design and we don't figure out how that design works with their current workflows and what might break.
So best way to do this, do that user research spike, get in there, figure out what people are doing, do usability testing, and then purposefully take that information and update the new design with it. Try to figure out how you can make a seamless transition for them into using this new thing and make sure that it's done intentionally so that people are getting better outcomes when they use this product with the redesign. That's how I would think about this. So you're not wrong. You can use your current product to help you build a better replacement. You just gotta study what's working about that current product and then incorporate that into your new design. This is a great opportunity to update things and you never wanna shy away from updating things, but you also don't want to fix something that's not broken. So definitely look at that. Definitely look how people are using it and understand deeply why they're using it in certain ways and how you can make that better for them. All right, thank you so much for listening to dear Melissa this week. And again, I wanna remind you, go to dear melissa.com, submit me your questions. I would love to hear what's on your mind, and I will see you next week.