Skip to main content

Why Product Managers Shouldn’t Spoon Feed Developers Priorities

April 28, 2022

6 minute read

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.

Try not to spoon feed developer priorities

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.

For example:

  • Product enhancements 10%
  • Bug enhancements 30%
  • DevOps tasks 60%

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!

Sign up to our monthly newsletter, The Outcome.

You’ll get all our exclusive tips, tricks and handy resources sent straight to your inbox.

How we use your information

5 thoughts on "Why Product Managers Shouldn’t Spoon Feed Developers Priorities"

  1. Hello Janna,

    great article! I mostly agree with all of your points.

    I still believe it’s a product manager (even if acting as PO in your example) task to define what the sprint priorities and expected outcome should be.
    In that regards, my experience has taught me that often quality issues and ‘bugs’ can be the main hurdle for customers getting the true value of your product.

    Since I am a strong believer that PM are the gatekeeper of delivering customer value, I would say that a product manager should be involved in monitoring the impact of a particular bug or quality issues impacting the expected results, and help the team to prioritize accordingly.
    I do agree that a very granular prioritization of every single bug is not a PM/PO main job, and that ideally the team should be able to find the right priority.

    I have however experienced that often bugs / quality concerns get postponed until it negatively impact retention/churn and get escalated, as most engineers tend to hate ‘fixing bugs’, for some odd reason.

    1. Thanks Oliver! Yeah, I agree – the product person should still definitely be guiding on what’s important. I think we’re both saying the same thing from different angles, showing there’s got to be a balance of giving the developers clarity on what the business needs, and giving them enough room to find the best way to deliver on those needs.

  2. The example dev pipeline breakdown made my heart hurt …
    10% enhancements!?
    60% devops!?

    I hope that was just meant to get a reaction from product people like me. That looks like a path to the sunset.

    1. Oh absolutely—Not the ‘ideal’ pipeline at all, but honestly, too many blogs write about greenfield projects or magical products that don’t seem to need any maintenance at all, and we refuse to live in la-la land.

      The entire point is that each team will have their own breakdown, however it’s weighted, and can communicate better and make better decisions if it’s laid out for them. Better to know you’re on the path to sunset (as an agreed strategy across the business) than have your product suffocated out with a similar but unspoken breakdown of work going into the dev pipeline.

      Here’s hoping your own breakdown is richer than that! ✨ (care to share what your ideal mix is?)

      Thanks for your comment, David!

      1. Your commitment to stay out of fictional product worlds is much appreciated 😁 A product team that honestly knows where they are is too rare.

        For my part, I would say a development pipeline that plans only 10% enhancements is a worst case scenario. It’s usually points down a 0% enhancement sunset path. In that scenario, I try to keep the team engaged by reducing their involvement with that product to a minimum and progressively move them over to whatever is next. I guess the real worst case scenario would be when there is no next.

        Depending on where the product is in it’s life, I’d say a reasonable pipeline could be anywhere from 40% to 80% innovation-centered. IMHO, once I fall below the 40% mark, it’s either time for a hefty refactor of the code base or the end of the product is in sight.

Leave a Reply

Your email address will not be published. Required fields are marked *