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.

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:

Melissa Perri on LinkedIn | Twitter

MelissaPerri.com | CPO Accelerator