Wondering how to handle bugs for your development team? Well, you don’t.

Managing the flow of bugs, DevOps tickets, and other fine-grained development work is not the PM’s job.

There’s a common misunderstanding here. A lot of PMs think that their job is to manage everything that developers do. That’s not true. Product managers are responsible for filling a portion of the development pipeline, while other teams – such as Quality Assurance (QA) and Development Operations (DevOps) – are responsible for other portions.

In this post, I’ll go through what kind of tasks fill the development pipeline, who’s in charge of them, and how the dev pipeline should be allocated. I’ll finish with some tips about how PMs can help define these workflows and focus on their own objectives.

The development pipeline is not the product pipeline

That’s right. This is the top and bottom line of the issue: the development pipeline is not the product pipeline.

Developers have a set of things that they do, and PMs can inform one part of it. This includes creating user stories and product specs.

But these comprise only the Product slice of the whole Development pie. The pie has at least two other parts: bug fixes and operational tasks, or DevOps.

What are the different development tasks?

Bugs are minor (sometimes major!) malfunctions within the app itself that need fixing or enhancing. These tasks typically come from the QA team and customer support. Bugs are also (relatively) straightforward. Fix the bug, close the task. You have a list of 100, and you get to them as you can. For a bug to be logged, it should be replicable and reproducible. Anybody should be able to log it and confirm that it does, in fact, exist. So bug fixes can happen at any point in time. 

DevOps includes tasks that the development team has created for itself, related to upgrades and ongoing maintenance of the larger tech infrastructure. This could be upgrading servers or libraries and maintenance of their Dev stack.

Product tasks, on the other hand, are less concrete. These tasks represent options that need to be specced, prioritized, and re-prioritized based on the current needs of the business. They can be ordered or grouped together based on how they’ll impact user metrics, how many accounts they’ll reach, or the value of the customers that would benefit. They can also be scrapped at any time. In other words, product tasks are perpetually in a state of, “Should we even do this?”

PMs manage this fuzzy product strategy side of things, and when options are confirmed, PMs add them to a product pipeline for dev.

Of course, all of these tasks need to be in balance, or some kind of ratio, in the development pipeline. But this part of the process is where a lot of confusion lies.

Where does this confusion come from?

The “Product Manager” title actually involves different roles
The role of a particular PM can have loose definition and scope creep into areas beyond the product roadmap and backlog. Sometimes the product manager is also the QA person, so they’re wearing different hats. Similarly, on some teams the PM can also function as a project manager or Scrum Master for dev.

The workflows for different tasks overlap
Sometimes the same tools and workflows are used to process different requests and task logs. Bugs don’t go to your roadmap, they go to your QA tool, which is often JIRA, but JIRA is also the DevOps tool. So there’s no technical separation between these things, but they’re different workflows that have differing priority. 

Who should manage the development pipeline?

Development work is a blended pipeline, with different proportions for each element of the work. The dev team should be able to set these percentages, based on the maturity of the product and how old the tech stack is.

Sometimes PMs manage the ratio and make those decisions. In these cases, PMs are the product owner and the de facto Scrum Master, as I mentioned above. But ideally the development team has autonomy and a dedicated person who manages the ratio and blended pipeline exclusively.

That’s because this is a tech strategy decision, not a product strategy decision. How development and engineering time is allocated is (usually) the CTO’s decision. For instance, some teams set aside the last week of the month to crush bugs, and focus on R&D during the rest.

What do product managers control?

So, Product’s job is to answer for themselves: “If we have 10% of the sprint, or X amount of the engineering pipeline, how are we going to make the most of it?”

Your team has to be as smart as possible in figuring out how to get as much learning from the pipeline slice you have. As long as you constantly fill the product pipeline with what’s most important, the dev team will always grab the most valuable stuff.

Tip: Don’t get too granular with prioritization, i.e. don’t try to parse out tasks per sprint. Instead, show development the next 50 things you want done. With their technical expertise, they’ll identify which items go together and maximize efficiency over the next couple sprints. A developer could look at the list and say, “While we’re doing #3 in that part of the app, we might as well knock out #27.” Perfect!

You’re not going to project manage a kitchen renovation, telling your contractor to do appliances first, tiles second, and windows third. You trust them to know the right order and combinations to get everything done on time. This analogy is closely linked with Jeff Patton’s ideas in this ProdPad webinar about embracing lean development. Check it out!

Last word

Separate the workflows of bugs, DevOps, and product tasks so there’s clarity around who owns what. Distinguish between the product roadmap and the development pipeline!

If you’re able, as a PM, focus only on the product slice of the development pipeline. This will preserve product resources (and sanity), and let engineering steer their end of the work. They shouldn’t need to be micromanaged anyway!

The post Why Product Managers Shouldn’t Spoon Feed Developers Priorities appeared first on Product Management Software | ProdPad.