Episode 96: Dear Melissa- Answering Questions About Advocating for Resources, Bottom-Up Transformation, and Setting Expectations
In this Dear Melissa segment, Melissa answers subscribers’ questions about advocating for resources in a non-leadership role, whether or not a bottoms-up transformation can really work if leadership isn’t immediately on board, and how to effectively communicate with teams outside of product in order to set realistic expectations and get them on your side.
Have a product question for Melissa? Submit one here and Melissa may answer it in a future episode.
Subscribe via your favorite platform:
Q: As a product manager that is not in a leadership role, how do you recommend advocating for additional resources on your development?
A: The big thing [you should do] when you're not in a leadership role is show the leaders your ability to do things efficiently and reach their goals with your current team, or what would happen with your expanded team. Here are some things you’ll want to communicate to them.
Q: Have you ever seen a product transformation work from bottoms-up, work at the team level first, and then improve at the executive level? If so, what do you think were the deciding factors?
A: In my experience, I've never seen a great transformation that was wildly successful that was only bottoms up. You can work at the team level first and then improve the executive team, of course. Honestly, most transformations I've seen have started somewhat that way. There needs to be a point where the leaders go, “Okay, this is the way we're going,” and they drive it. Listen to hear how I approachl transformations.
Q: How do I work with non-product teams who have no regard for prioritization or respect for the actual product team’s process?
A: Here's where your situation is: you need to completely reset expectations with the rest of the company about how you work and why it's beneficial for them. As the head of product, the biggest thing for you to do is work with the leaders across the company and explain to them how product works, and hear their side of it. Find out how and why by tuning in.
Resources
Melissa Perri on LinkedIn | Twitter
Transcript:
Melissa:
Hello and welcome to another Dear Melissa. Today I've got three great questions for you. One about advocating for additional resources on your team when you're not a leader. Two, about really working with teams outside of product management and communicating to them about how you work and what deadlines mean. And three, about really looking at digital transformation from a bottoms up versus a top down perspective and what works well. So without further ado, we're going to the phones and here is our first question. All right?
As a PM that is not in a leadership role, how do you recommend advocating for additional resources on your development team. I'm watching my engineers become overwhelmed, and I see that the expecations from leadership dont align with our bandwidth. Would love your insight. Thank you.
All right, so the big thing when you're not in a leadership role is you wanna show the leaders the potential for you to be able to do things quickly and efficiently and to reach their goals with your current team or what would happen with your expanded team. So you are gonna wanna communicate a couple things to them. One, you wanna show them that if you had additional resources on your team, you would be able to get to market faster, which does unlock, um, you know, monetary value for the company. So can you show that by putting, you know, a couple more engineers on your team, you would be able to do it x amount of times faster. That would pay off into, um, you know, why amount of money, which kind of justifies you bringing on the extra resources. You wanna do that math for them?
You wanna show them that and you wanna give 'em options, right? You wanna show like if we had one res uh, one additional developer, you know, we could do this. If we had two, we'd be able to do this. Like show them what you would be capable of if you had more resources on your team. Additionally, you might wanna talk about churn. Uh, leaders are always worried about good people le leaving their company. So if you can show them that the team is overwhelmed in danger of churning, in danger of leaving the company, they're gonna get nervous and they're gonna be like, wow, we have to look at that team and try to figure out how to keep them from burning out and how to keep them employed. So you wanna really advocate for those types of things. But the idea here is not just to go to your leaders and say, Hey, I need more people if you want me to do that.
You wanna show them why, right? So what I would say is this is a great time for, not that everybody loves this, but the velocity talk, it is a good time for the velocity talk. Hi. We have been measuring the capabilities of our team, and based on that, we believe that we can get X, y, and Z done within the next quarter or year or whatever timeframe you wanna do based on our current team. But that is also working at a breakneck speed. And we predict that we might have something like 20 to 30% churn in our engineers within a year. If we do that, that's not great, then we'll have to hire and replace them. It takes about three months for an engineer. I don't know how long it takes at your company, but let's say three months for an engineer to get up to speed and be super productive.
Uh, that will kill our velocity, which means we will only be able to do, you know, why next year we won't be able to do any of these things. If people leave, that's a problem. So what we're proposing is that we wanna hire or bring onto our team from somewhere else in the company, maybe that's not as prioritized and add, you know, two to three additional people to our team that would allow us to do blah, blah, blah. And that results in this amount of money for us to make on a recurring basis once we release those features, uh, which will help us justify the costs, right? Something like that. That's really the way that you present and I believe that they listen to it. It's about optionality. We do this a lot in org design, even at the highest levels where we say, all right, what do we wanna do as a strategy for our company in this year or next?
Uh, can we do that with the current team or does it make sense to actually expand our budget, hire more people so that we can get things done and bring it to market faster? So you wanna have the same type of conversation, um, and you wanna reset expectations, right? You need to go up and say, Hey, this is, this is what's happening right now. Here's some numbers, here's what we're looking at. This is what we're capable of. I think to what happens on a bandwidth conversation with leaders that I've seen in teams is that they come and they give you a lot of stuff and you're going, no, we can't do that. But you're not going back and explaining why you can't do that. It's just more like, that's a lot for our team, but you're not showing them, Hey, with the current team makeup you get, blah, blah, blah, blah, with the new team makeup, you get this and this and this.
Like, you need to have that conversation where you show them the options and stick firm to that and explain why things are the way that it is and why you're building that way. So that's the type of conversation that you need to have. It's really about resetting expectations, being transparent and showing them the numbers. And that typically will buy you, um, more things and it becomes a conversation about we can either do this much stuff if we have the current team, or we can do all of this stuff if we have a different team. Um, and we might be losing people if we continue to work at the pace that we're working at. Like, those are the conversations and the things you wanna hit on. So try that and I hope that helps.
All right, next question. We are going to the phones again. All right, here we go. Product Coach from Hamburg Germany. I usually advise my clients to always, always, always start with the company's vision and strategy before they even think about changing job descriptions and empowering teams. I have simply never seen it work the other way. Without understanding the need for an ambition vision and insightful strategy, all efforts at the team level are wasted. Now my question- have you ever seen a product transformation work from bottom to top? Work at the team level first, and then improve at the executive level? If so, what do you think were the deciding factors?
All right, so in my experience, I've never seen a great transformation that was wildly successful, that was only bottoms up. Uh, you can work at the team level first and then improve the executive team of course. And honestly, most transformations I've seen have started somewhat that way. But there needs to be a point where the leaders go, okay, this is the way we're going and they drive it. It can't last or linger at the bottom too long where, you know, the team level people in the organization are driving everything that doesn't work.
So it's kind of gotta be a little top down, bottom up, top down, bottom up and it's gotta go back and forth. So here, here's what needs to happen. Um, I've worked on a lot of digital transformations and the way that I'm usually brought into organizations where that I used to be brought into organizations because I've stopped working this way now, is that they have always said, great, we're gonna do a digital transformation and I want you to train all my product managers. So what did I do? Came in, trained all the product managers, and I would do this at very large companies, very big banks, very big insurance agencies, like you name it, huge places. And I know a lot of them. Um, I know a lot of places are still stuck in this mode as well, where it's like train all the people on the team level.
But the problem is once you train all those people on the team level, if the leadership team is not caught up to what those teams have just learned about, for example, um, how they should be getting outcomes and goals and iterating towards a solution for them, what happens is now the team knows how they should be working and they see the organization does not work that way. So what happens? Oh, a lot of them leave, a lot of them get frustrated, um, or people go back to working the way that they used to work. So the transformation fails. Now, the ideal way to work is having a desire at the leadership level to move towards this transformation. You can start training the teams while the leaders are being trained as well and getting their things in order.
That's totally fine to do at the same time, but the leaders need to know what to expect. So whenever I would go in to do transformations, what it turned into in the future, because I realize like this whole train the people and the team level and then not the leaders doesn't work, is I would usually, I'll start with leadership, explain what they're gonna get with a transformation. So a lot of them, like, I wanna be digital, but they don't know what that means. And I think that's a problem, right? They don't understand how it changes the entire way that the company operates and thinks it changes the way that they do their roles. It changes the way that they interact with their peers. It changes everything in a company. When you do a digital transformation, it is not just about creating software, it's about creating an entirely different culture in your company.
And if the leaders don't understand that, if they don't understand that that's what they're signing up for and that's what they're getting and they're willing to do whatever it takes to get there, that's when transformations fail. And I have seen many transformations fail because of that. Um, they also have to understand that this takes a long time. There are a lot of companies still transforming. They're still at the train, the product team level, and they're also at train the leader level and they're gonna be there for a while cuz it takes a lot to move these really large companies in this direction. So expectation setting at the beginning of a digital transformation is so important. It's so important to understand as a leader, like how does all of this work? What do I need to be doing? How do I need to change the way that I work so that I can enable my teams to be more effective?
And if you're leaders are not bought into that, once they understand what's, you know, what it takes to actually do this digital transformation, that's where it fails. That's where I always see it fails. So let's say we're getting the buy in there, we're setting those expectations. Now you can do a little bit bottoms up a little bit top down. Um, you can train the teams, you can get them going on what is already there while you train the leaders in the new ways of working and how they have to communicate. Um, typically you wanna make sure that they're communicating down strategy really well. As a leader, you wanna make sure that the direction is good, that you're worried about OKRs, that you're bubbling up what everybody's working on, and you're ruthlessly prioritizing. You don't have to get it all right at the leadership level to be able to enable a good digital transformation.
You can work your way through that. But I think the biggest thing is the buy-in. You wanna make sure that they're working at the same speed that the teams are learning so that they can enable the teams to be effective and those teams can do their job in a good way. So you wanna make sure that it's, it's staggered correctly and it does take a while to get teams up to speed on these news ways of working. So you do have some time as a leader to get your stuff in order. That's all right, but it should be happening together.
Now I have seen it where the teams start the digital transformation. Um, but again, like I said at the beginning, the leaders have to buy into it eventually and quickly before those team members leave. Uh, if there is no buy-in at all ever, this will never work. This will never, never work. Um, but the leaders I think can catch up and if they're smart, they will catch up. So I have seen many successful teams start with, uh, you know, we're gonna start doing some research practices, we're gonna surface these things up. The key here, I think that wins the leaders over is talking to them in ways that they understand. So instead of being like, Hey, we're doing a digital transformation, which means we're using agile processes down here and scrum cadences, and this is velocity and story points, that's gonna tune the leaders out. Instead you wanna say, Hey, by enabling really good discovery practices, we learned X, y, and Z about the company and uncovered these opportunities that are gonna make us money. Then the leaders ears are gonna perk up and say, wow, how'd you do that? Like, why isn't everybody doing that? That's amazing. So you wanna really strip down the jargon when you're doing a digital transformation and focus on what the outcomes are that people care about, which is making money and furthering the business. And I think if the teams are starting the digital transformation and you
Don't, don't find that there's a ton of buy-in or there's maybe like half buy-in from the leadership team, changing your communication is really important there because they're gonna wanna see the outcomes of what the digital transformation is doing and then they're gonna be more bought in because they understand what they're getting for it. So I think that's totally fine. The, the thing is, it's gonna have to tip with the leaders like being extremely bought in and willing to change the way that they work for anything to be successful when it comes to a transformation.
All right, next question and last question Dear Melissa, I currently work on a small company with a lot of transparency across teams. My product team uses Scrum and releases every two weeks, but the non-technical teams are constantly complaining about our team's lack of urgency and have no regard for prioritization.
The rest of the company operates on deadlines that are dependent on developers time, but they plan their monthly deadlines at the top of each month. They even send us cards with requirements already written out and expect them to get scheduled right away, dictating to us what is needed. And when we've told them repeatedly that we don't work on deadlines, but in two week sprints and that they should plan six weeks in advance to account for specking engineering and qa, but they're not hearing it, I feel like the entire team has no respect for the actual product team's process. What do I do sincerely feeling micromanaged? Oh man, I would feel micromanaged to, but here's, here's where your situation's at. You need to completely reset expectations with the rest of the company about how you work and why you work and why it's beneficial for them.
So I've seen this happen a lot where people just come and yell and say, we need you to do this and you can't do this on our timelines, but we need it to be sold and you gotta do this, blah, blah, blah, blah, blah. You need to get ahead of everything. So, um, as I can see that you're the head of product as the head of product, the biggest thing for you to do is go work with the leaders across the company and explain to them how a product works and hear their side of it. You need to empathize with the rest of the organization and learn how they work and why they're asking for these things. So if somebody's coming over and giving you cards of requirements, what is that requirement? What, where did it come from? Why do they have cards? So I would go meet with the leaders of the rest of the organizations and talk to them about how they work, empathize with them.
Say, I really wanna learn more about your team. I wanna learn about, you know, what you're doing over here, what's riding on it, what's your goals, all of that stuff you need to get in sync with the rest of the um, leaders. So do that first, then reset expectation with those leaders and then their teams. now come back and start to tell them where do you go to submit ideas? Paint a product vision for them as well. So you are talking about how your product team uses Scrum and releases every two weeks. They don't care about that. What they care about is understanding more about the roadmaps and what they're going to get for different things. So you need to get ahead of that. You need to be presenting to them and saying, here's the vision for what our team team is doing. Here's the roadmaps that are aligned for it.
This is how it's gonna release value, this is what it needs, you know, this is what everybody needs. So get ahead of that and paint them a picture of how product works. Then you start to design the way that you work together. And this is a big thing that we talk about in product operations because we see this all the time. If you've got a sales team for instance, where they're just giving you requirements of what to build and they're not listening to you, you need to go back to that sales team and say, Hey, this is how you can advocate for things to get onto our backlog. Um, we're gonna meet every two weeks or so and we'll share with you what's coming up, what's on our roadmap, why we're building it, and what's gonna unlock at that time. Maybe you can suggest other things that are in line with our product vision.
If it's not in line with the product vision, it's gonna get tabled so that we can have a bigger conversation about whether or not we want to get into that or in the future if, because that affects our strategy, right? Like that's not just can you do this, that affects the entire strategy if it's not in line with the current product vision. Um, so that happens here on these cadences in these meetings with these people, right? Really paint them a picture of where they can go to submit these things and where you can have a conversation. Also set the expectation that if you give us a card with requirements, we're gonna come back to you and just ask you a bunch of questions about that card anyway. Why do you need it? Who needs it? Where it goes? Because say that's our process and you have no, you have no bearing on what our process is.
So, and that's another thing you gotta stick to your guns with. Like they might be coming over here and doing all these things. The first thing is to ask why. The second thing is to have your own process that you can explain to them and say, this is not how we work. And it sounds like you've tried to explain that to them, but they're not hearing it, which tells me there is a tension of them not perceiving you, delivering on things that will help them. So if that's the case, if that's the case, right, you need to figure out what they need and why. And we can't also just be up in our head as product leaders and product people saying we know all the answers, right? We know all the answers to all of these things and I'm not gonna listen to anybody else in the company because we have a backlog and we're gonna stick to that.
That's not how we work and that's not how we should be working because there are probably people in your organization that have a wealth of information that's useful to you. Now your job as a product person is to get all of that information. It's not to react or act on that information immediately, but it is to learn what that information is and then judge with all the information that you have because you went around getting it all and you can see everything. You can see the technology side, you can see the business side, you can see the customer side, you can see the market side, you can see the competitor's side. You have all the information. Now you use that information to figure out which way you should go and then repeat back to them if you did use some of those requirements or if you did deliver on it, make sure you go back and tell them that you did.
And if you don't tell them why, tell them what the other information is that affects it. So that's a big part of this. It's about getting in front of a lot of things and making sure that you have a solid explanation for people about why you're doing the things you do, how you work, how much you can actually take on. But also listening to them and empathizing with what they need and really figuring out are these things that we can deliver? I'll give you a great example. Um, I once worked with a company where they had an old head of product who was extremely, extremely process oriented. Um, you know, stuck to their guns about the way that Scrum was, the way that Agile was, uh, you know, the product team shall not be dictated to. And that was their mentality. That person was the enemy of all the other leaders.
The other leaders were like, I can't work with product, they're impossible. And when you talk to the other leaders, they had very valid points. They said, I have no idea what we're building. So I said, let me go find out what we're building. And I went to that leader and I said, can you share a roadmap? Can you share these things? They did not have it. They did not have it and they were not sharing it because it did not exist. So that's telling me that this leader is not doing what they should be doing, which is getting ahead of the stuff that they're building and building a compelling vision for the rest of the company. A compelling roadmap, all of those things to communicate back to the leaders. And what happened was, because they were just very, I don't like anybody dictating me, blah, blah, blah, blah, product's gonna do this.
They turned everybody else in the company off and they were replaced. New head of product comes in, right? Instead, works on a collaborative way with the rest of the people. The first thing they do is they go to sales and they say, what have you been asking for forever that we haven't delivered that you know, is gonna get us immediate sales in this quarter? And they said, oh my God, it's this thing. I have been asking for it for two years. I know that I can close about, you know, x hundred thousand dollars of revenue just this quarter if we had this thing. It's one thing that people have been begging us for. It's the one thing that I can't compete on with the major competitor that they all leave and go to. And the product person said, okay, how a product goes, okay, lemme go talk to this team about it and see if we're able to get that for you.
Goes back to the team, discusses it, they look at it, they say, yeah, we've just been punting that down the road. Um, you know, the other head of product really didn't want to do this thing, blah, blah, blah blah. Product leader looks at it, says, okay, actually we can get this done and it's pretty straightforward and easy. Goes back to sales and says, we're gonna do this for you, um, and let's see how it works. They were able to deliver on that thing within, you know, just a month sales was able to sell hundreds of thousands of dollars worth of new revenue into the market to get into the sales numbers. And now everybody's happy and working together and now sales doesn't come back and complain all the time about them not delivering, not prioritizing, not having a lack of urgency. It was because they made one small concession there.
And what did the head of product do? They looked at it and they said, is this like the most strategic thing we could, could be working on? No, but is it going to get me buy in with the rest of the company? Yes, it's gonna make me the head of sales best friend. And it is something that's useful because it will make us money. He didn't ask for something that was unreasonable. He asked for a very reasonable thing and he is been asking for it for so long. And it did get the company a good amount of money and it did not like completely, uh, steer the train off the tracks by not being strategic or anything like that. Was it the most important thing they could be building? No, but it was it important? Yes. And it actually had a really good reason for people asking for it.
So that's what I would say is like, try to evaluate where are these people coming from? And you need to be pragmatic when you are a product leader too. I know you feel micromanaged and it sucks feeling micromanaged. Um, but usually people are micromanaging you because they don't understand what the long term vision is and they don't understand why you're doing the things you're doing. So get out of like everyday mode and just meet with people. Have deep conversations about these things. Explain to them why things are working. Don't, don't feel like you're getting your, you know, feathers in a rough ruffle with all of this stuff. Make sure that you're just saying, let me put myself in their shoes and empathize like a good product person does. Let me empathize with them and try to understand this from their perspective. What are they feeling?
Why are they feeling pressured? Maybe they have ridiculous expectations set on them and you could be their best friend because you go to the CEO and say, you know what? We can't all work this way. You might find that you all, you know, band together and approach all these issues in a really collaborative way. And that's what I hope for you. So really take a couple steps back and just empathize. I cannot say this enough. Empathize, empathize, empathize. Get ahead of the story, get ahead of the narrative and co-create things together. All right, that's it for dear Melissa this week. Thank you so much for listening in and if you have a question for me, please go to dear melissa.com and leave me a voicemail. I wanna hear all your lovely voices and I love hearing the context in which you say these things. Um, so please go leave me a voicemail@dearmelissa.com. Tell me what you're thinking. And we will be back next week with another episode of the Product Thinking Podcast. So make sure that you hit that subscribe button so you never miss an episode. We'll see you next time.