Product Thinking
Episode 121: Answering Questions About How to Deal with Development Teams and Leaders and Balance Product Strategy, Bug Fixes, and Minor Improvements
May 31, 2023
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.
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. 


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?

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.

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?

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.

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.


Melissa Perri on LinkedIn | Twitter | CPO Accelerator

If you enjoyed this episode, please visit:

Product Thinking is handcrafted by our friends over at: