Episode 121: Answering Questions About How to Deal with Development Teams and Leaders and Balance Product Strategy, Bug Fixes, and Minor Improvements
In this Dear Melissa segment, Melissa Perri answers subscribers’ questions about dealing with technology teams and leaders and how to balance the team's effort between the things that are the focus of your current product strategy, bug fixing, and minor improvements.
Have a product question for Melissa? Submit one here and Melissa may answer it in a future episode.
Q&A:
Q: I recently joined a startup company as the first and only product manager. The CTO and tech leads believe I'm responsible for feeding the developers with work items. They're often telling me things like looking at the backlog. I'm afraid that some of the developers won't have anything to do next sprint or the sprints ahead. I'm tasked with plenty of discovery work to do, which takes a lot of time. At the same time, given the early stage of the company, there is no large backlog of tech items to be used as fillers for sprints. Therefore, developers remain with no valuable items to take. And I am pointed to as the guy who doesn't do discovery fast enough, which results in not enough items in the backlog.
Therefore, I have two questions. What is the best way to communicate that my job is not to feed the developers but to work on the product strategy by defining the right problems to solve and their solutions so that we can achieve customer and business value? Have you seen such a situation in the companies you worked in? Have you seen such situations in the companies you worked at or consulted? How do they tackle the issues so that product managers can focus on thorough discovery rather than becoming user story factories for the sake of keeping developers busy?
A: This is a pretty common misconception in some companies, but there's a back-and-forth here. You have to supply the developers with work, but that doesn't mean that it all comes down to you. The developers need to be thinking through things as well. So I guess my first question for you is, since you are a startup and you do need to work on that product strategy, which I totally get, do you have a vision for the product yet? How far along are you? If it's super early days, I understand that there's not really going to be a concrete vision. But if you've got some momentum, some customers, usually you're getting enough feedback requests. You're doing that discovery work you talked about. You can start to put together a good product vision and product strategy that should keep the developers busy for quite some time.
So I would work with the head of technology in this case and start to talk to them about what you're doing and what you could prioritize for the developers and how you're working on that vision or that strategy so that you can start to break it down and have a lot more work for them to do in early days.
It could be that you have too many developers for the stage you're at because you're not ready to build something big yet. After all, you haven't done the product strategy work or figured out what needs to go on two. You may have just not done that product strategy or vision work. But you're big enough where it needs to be done, and it needs to be done quickly. So I would encourage you to do the discovery, do it well, but make sure that you're doing it promptly and scoping out and communicating with the developers as much as possible so that they know what's coming like involving your developers in the strategy work so that they can see what's coming up and they can start to make decisions about it.
Q: I'm a new product manager at a small company, and my main concern is the effectiveness of our head of technology and the development team. I work closely with them as a product manager and also product owner, and occasionally a Q&A tester. Our primary challenge is a significant amount of technical debt that needs to be addressed. This complexity requires the attention of more experienced developers, particularly when working on larger projects. The current development team was quickly brought in to handle bugs and urgent issues but I believe they are no longer capable of meeting project deadlines. We have been experiencing a high turnover rate, which disrupts the continuity of our work.
Developers start in stories or projects but are let go or resigned shortly after forcing them to pick up where they left off. We have been experiencing a high turnover rate, which disrupts the continuity of our work. Developers start in stories or projects that are let go or resign shortly after forcing others to pick up where they left off. Unfortunately, the expectations and deadlines remain unchanged. The team makes little effort to learn the systems and relies heavily on discussions with me before starting any user story. As a result, our last large projects exceeded deadlines by two to five months, and I had to postpone three projects to the next quarter. I find myself being blamed for these delays as if it's my sole responsibility to provide clear acceptance criteria and requirements in the user story.
The head of technology often compliments my user stories. But when something goes off track, the blame shifts to me to clarify. I put a lot of effort into creating detailed documentation, including links, screenshots, mockups, acceptance criteria, and even videos when necessary. Despite these efforts, I continue to be blamed and overruled by the head of technology. This toxic dynamic makes it challenging for me to navigate the situation effectively. What can I do?
A: So what I'd say is, how do you make the problems that you're experiencing more transparent using data. Can you start to show things like velocity from the development team flow? I would try to track flow and show where the pitfalls are. I had to do this at one company. Once we mapped it out, we could not figure out why things were not being shipped right. And we mapped out how long it took from an idea to get to release, and we broke it down into each step.
And we tracked the time on one of those projects to show people where the bottlenecks were. And we found that it went into a big black hole of design, and it came back six months later. And then we would continue working on it, and then the design would come and disrupt it and keep changing it.
When we showed the leaders got involved and they were like, Oh, well, we have to change this process. Let's figure out what's going on with design and dive in deeper. So maybe say, I know we've had some bad delays. I'm proposing that we try something new. Let's try maybe mapping and tracking our flow of work right from the time that I have the acceptance criteria mocked up to the time that it takes the developers to start working on it all the way through release and then try to figure out and identify where the bottlenecks are.
If you have that transparency that helps give you some ammo back to the head of technology, but also to the leaders that will help you manage up and start to point out that this is not really all your fault. This is the development team's fault now. Also, you don't want to approach this, though, as it's a me versus them thing, which is totally what the head of technology is doing to you, and that's not fair. But that's not gonna win you any battles to say no, it's not me and like start all these fights, so you have to go to them and figure out how to get them to agree. So you have to go and say, Hey, I think we can work way better as a team member, and I want to make sure that the things that happened with our projects in the past don't happen again.
Q: My question is how to balance the team's effort between the things that are the focus of your current product strategy, bug fixing, and small improvements that are either feedback from our customers or small things that teams want to improve. Ideally, I feel like if we are more focused on the first, we would make the most progress toward our product and business outcome. But doing small improvements might never get picked. Should we save those small improvements as things that teams can do after they just finished a bug initiative?
A: I think here we need to look at the definition of a small improvement because sometimes something fast can have a huge impact. So I think you're gonna need to quantify all these things back to the metrics that matter and the overarching goals. And that's why these things are important. And it's important to know what you're trying to do to move the needle. So look at the goal for your product launches. Look at what you want to measure from a metric and then go back and say, How much will these new product things versus these small improvements versus the bug fixes actually contribute back to those goals. You might have a couple, you might have a customer satisfaction type thing. You might have a retention-type thing.
And at the end of the day, all of what I just said retention adoption. All of these things relate back to business metrics. They relate back to business value like retention is a quantifiable thing. How much money can we save? Can you start to break these down into what's going to move the needle for your area of the product and the business? And then you're gonna look at those small improvements and go, Hey, you know what? That was fast. So I thought it was small just because of a time thing, but actually, it's gonna help.
So don't think about little as a time thing. Think about it as a margin for value improvement, and that's how you prioritize it. So I always advocate dedicating some time to bug fixes. You definitely need to do that instability of your platform. But again, that's like a retention metric. So you're gonna have to remember that now you want to figure out what that should be in your organization.
Resources:
Transcript:
Speaker A - 00:00:00:
Creating great products isn't just about product managers and their day-to-day interactions with developers. It's about how an organization supports products as a whole. The systems, the processes and cultures in place that help companies deliver value to their customers. With the help of some boundary pushing guests and inspiration from your most pressing product questions, we will dive into this system from every angle and help you think like a great product leader. This is the Product Thinking Podcast. Here's your host, Melissa Perri.
Melissa Perri - 00:00:36:
Hello, and welcome to another episode of Dear Melissa. Today I've got three questions for you. Most of them are about dealing with technology teams and also with technology leaders. And then we've got one about prioritizing portfolios of work and different types of works like bugs, small improvements, that type of thing. And I want to remind you before I jump into this that you can submit all your questions to me at dearmelissa.com and I answer them every other week. So let me know what's going on, tell me what you're thinking about, what your burning questions are about, and I'd be happy to answer them on the podcast. So, without further ado, let's jump into the first question.
First question. Dear Melissa, I recently joined a startup company as a first and only product manager. The CTO and Tech leads believe that I am responsible for feeding the developers with work items. They're often telling me things like looking at the backlog. I'm afraid that some of the developers won't have anything to do next sprint or the sprints ahead. I am tasked with plenty of discovery work to do, which takes a lot of time. At the same time, given the early stage of the company, there is no large backlog of tech debt items to be used as fillers for sprints. Therefore, developers remain with no valuable items to take. And I am pointed to as the guy who doesn't do discovery fast enough, which results in not enough items in the backlog. Therefore, I have two questions: what is the best way to communicate that my job is not to feed the developers, but to work on the product strategy by defining the right problems to solve and their solutions so that we can achieve customer and business value? Have you seen such situations in the companies you worked at or consulted? How do they tackle the issues so that product managers can focus on thorough discovery rather than becoming user story factories for the sake of keeping developers busy?
Okay, so this is a pretty common misconception in some companies, but there's a back and forth here, right? You do have to supply the developers with work, but that doesn't mean that that all comes down to you. The developers need to be thinking through things as well. So I guess my first question for you, since you are a startup and you do need to work on that product strategy, which I totally get. Do you have a vision for the product yet, like, how far along are you? If it's super early days, I understand that there's not really going to be a concrete vision, but if you've got some momentum, some customers, usually you're getting enough feedback requests. You're doing that discovery work you talked about. You can start to put together a good product vision and product strategy, and that should keep the developers busy for quite some time. So what are you doing to put together that vision or that strategy? I know there's not going to be. A huge amount of backlog, but there needs to be that. So I would work with the head of technology in this case and start to talk to them about what you're doing and what you could prioritize for the developers and how you're working on that vision or that strategy so that you can start to break it down and have a lot more work for them to do. In early days, it is hard. If there's not anything to work on, the developers will be kind of like twiddling their thumbs for a little bit because you kind of have to do that.
Scoping this also begs a question of do you have too many developers for the stage you're at? If you're trying to keep them busy and you haven't identified what it is that you should be working on, there might be just a lot of people, but if you don't have that vision and that strategy set, that's what you need to do first. From there as well, the developers should be able to work on a lot of infrastructure tasks and setting up your platform and your back end and all these different things without so much guidance, but in lieu of that, they're probably going to be like, what are we supposed to work on? What are we going to do? So I know you don't have a lot of tech debt to point them towards. If you are a larger company, I would totally say they could be doing tech debt refactoring. They got, usually a lot of work that they're fighting to get prioritized, so let them do that, but in smaller companies, this is telling me there's something else going on. So one, it could be that you just have too many developers for the stage you're at because you're not ready to build something big yet because you haven't done the product strategy work or figured out what needs to go on. Two, you maybe have just not done that product strategy or vision work, but you're big enough where it needs to be done and it needs to be done quickly.
So I would encourage you to do the discovery, do it well, but make sure that you're doing it in a timely manner and scoping out and communicating with the developers as much as possible so that they know what's coming. Like, involve your developers in the strategy work so that they can see what's coming up and they can start to make decisions about it. And maybe they'll identify places where they need to get a head start on things, So they could be like, hey, actually we're going to have to build all this back end stuff in order to do these things that she's actually scoping out and trying to identify right now. Maybe now is a good time to get started on that. So involve them in your discovery, make sure they know what's coming up. All of these things, I think, are going to really, really help. But you're right, it's not just about feeding the developers. But you do have to know that the business value and the customer value has to be prioritized by you to go to the developers. So they are respecting that. What are you doing to build that bigger vision? What are you doing to build the longer term thing? And it doesn't have to be super long term, it could be like a quarter, It could be for the next quarter. We're going to concentrate on this based on discovery work, right? But just bring that picture together and I think that will help a lot.
All right, next question. Dear Melissa, I'm a new Product Manager at a small company and my main concern is the effectiveness of our head of technology and the development team. I work closely with them as a product manager and also product owner, and occasionally a QA tester. Our primary challenge is the significant amount of technical debt that needs to be addressed. This complexity requires the attention of more experienced developers, particularly when working on larger projects. The current development team was quickly brought in to handle bugs and urgent issues, but I believe they are no longer capable of meeting project deadlines. We have been experiencing a high turnover rate which disrupts the continuity of our work. Developers start in stories or projects, but are let go or resign shortly after forcing them to pick up where they left off. We've been experiencing a high turnover rate which disrupts the continuity of our work. Developers start in stories or projects, but are let go or resign shortly after, forcing others to pick up where they left off. Unfortunately, the expectations and deadlines remain unchanged. The team makes little effort to learn the systems and relies heavily on discussions with me before starting any user story. As a result, our last large projects exceeded deadlines by two to five months, and I had to postpone three projects to the next quarter. I find myself being blamed for these delays, as if it's my sole responsibility to provide clear acceptance criteria and requirements in the user story. The head of technology often complements my user stories, but once something goes off track, the blame shifts to me. To clarify, I put a lot of effort into creating detailed documentation, including links, screenshots, mockups acceptance criteria, and even videos when necessary. Despite these efforts, I continue to be blamed and overruled by the head of technology. This toxic dynamic makes it challenging for me to navigate the situation effectively. What can I do?
This sounds bad. Frankly, this sounds not great, and it does sound like the head of technology is searching you out to blame. So what I'd say is, how do you make the problems that you're experiencing more transparent using data? Can you start to show things like velocity from the development team flow? That's a big one. I actually would track try to track flow and show where the pitfalls are. I had to do this at one company. Once we mapped out, we could not figure out why things were not being shipped right. And what we did is we mapped out how long it took from an idea to get to release, and we broke it down into each step of the way. And we tracked the time on one of those projects to show people where the bottlenecks were. And what happened is we found that it went into a big black hole of design and it came back like six months later. And then we would continue working on it and then design would come and disrupt it and keep changing it when we showed that the leaders got involved and they were like, oh, okay, well, we have to change this process. Let's figure out what's going on with design and let's dive in deeper. So maybe say, I know we've had some really bad delays, I'm proposing that we try something new.
Let's try maybe mapping and tracking our flow of work right from the time that I have the acceptance criteria is mocked up to the time that it takes the developers to start working on it all the way through release and then try to figure out and identify where the bottlenecks are. If you have that transparency, that helps give you some ammo back to the head of technology, but also to the leaders, that will help you manage up and start to point out that this is not really all your fault, this is a development team fault. Now also, you don't want to approach this, though, as like, it's a me versus them thing, which is totally what the head of technology is doing to you, and that's not fair, but that's not going to win you any battles to just say, no, it's not me, and start all these fights. So you'll have to go to them, and figure out how to get them to agree to this, right? So you have to go and say, hey, I think we can work way better as a team member, and I want to make sure that the things that happened with our projects in the past don't happen again. So why don't we do a retrospective as a team and do this flow modeling and start to track out what's going on and address it as a team right? Like, be a team player. Don't make this look like a us versus them thing. The problems will surface themselves. But if you get really reactive or mad or be like, this is not my fault, it's just them, the headache, technology controls those people. Those are his people. He's always going to side with them. So you need to be able to surface this up into higher levels and bring in those issues. So I really think something like a flow map could really work for you.
Try to identify where the bottlenecks are and record what's happening so that you can go back and actually present this and show people what's going on. Also make sure that your things that you're specking out, your vision, your product stuff, all of those things are very transparent and clear in the organization. Like, put together a nice beautiful slide deck and present it to the organization about what's coming up and what we're going to do and show them mockups and show them the stuff you're putting in the user stories. Not all of it not super, super highly detailed, but enough where they go, she knows what she's doing and the rest of the company can see it. And then that's going to take the friction away from you just being in with technology, right? Right now, it's just you versus technology. You need to bring the rest of the organization in so that they could see you as a leader and you can show other people that it's not just you, it's not your fault. Like you have your stuff together, it's people who are not qualified there. But if you try to shrink and remain behind the scenes or anything like that, it's not going to win you any credibility and it's not going to help people come to your cause. So definitely try to figure out how to be more present and more open in the organization and I think that's going to go a long way. And if it's still toxic, time to leave. Like, nobody's got time to waste at toxic companies with people who don't want to listen. But I try this diplomatically first and then make your choice.
All right, last question. Dear Melissa, my question is how to balance teams effort between the things that are the focus of your current product strategy, bug fixing, and small improvements that are either feedback from our customers or small things the teams want to improve. Ideally, I feel like if we are more focused on the first, we would make the most progress towards our product and business outcome, but doing so small improvements might never get picked. Should we save those small improvements as things the teams can do after they just finished a bug initiative?
I think here we need to really look at what the definition of a small improvement is because sometimes something that is really fast can have a huge impact. So I think you're going to need to quantify all these things back to the metrics that matter and the overarching goals. And that's why these things are really important and it's important to know what you're trying to do to move the needle. So look at the goal for your product launches. Look at what you want to measure from a metric and then go back and say, how much will these new product things versus these small improvements versus these bug fixes actually contribute back to those goals? And you might have a couple, you might have a customer satisfaction type thing, you might have a retention type thing, you might have an adoption, any of those, right? But draw back what those mean. And at the end of the day, all of those, what I just said retention, adoption, all of these things relate back to business metrics. They relate back to business value. Like retention is a quantifiable thing, how much money we can save. Can you start to break these down into what's going to move the needle for your area of the product and for the business? And then you're going to look at those small improvements and go, hey, you know what, that was fast. So I thought it was small just because of a time thing, but actually it's going to help people. Like, people have been complaining about this little thing forever and this is going to help our MPs score.
We had some issues in some companies, I've been in where it was literally like a drop down or filters or things that they were doing every single day. And the UX interaction was just slightly off. It did not feel like a big thing. But when you change that right, your customer satisfaction scores would jump. So don't think about little as like a time thing. Think about it as a margin for value improvement and that's how you prioritize it. So I always advocate for dedicating some time for bug fixes. You definitely need to do that instability of your platform, but again, that's like a retention metric. So you're going to have to remember that. Now you want to figure out what that should be in your organization. Some people do 10%, some people do 20%. It really matters when it's like, how much tech debt do we have? How much should we be stabilizing? So think about it that way and come up with a number for that so that you make sure you're investing in bug fixes. And then I would compare the small improvements, which should be going back to enhance existing features. So that's definitely part of your portfolio against net new features. And typically there will be a distribution where we do both of those in a portfolio, meaning we'll have people work on both of those. But you want to quantify it so that you can compare apples to apples. So definitely think about what's going to move the needle there, what's the most important metrics and bring it back so that you can make a comparison.
All right, that's it for Dear Melissa this week. If you enjoyed this, please subscribe to our podcast, so let me know what you think. Leave us a review. That would be absolutely amazing. And remember that I am taking your questions every two weeks, so go to dearmelissa.com and let me know what you think. I'll see you next Wednesday.