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.

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!

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

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.

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.