We have one Dev Team (Approx 20 Team members) currently working on 5 products with 5 product owners (one for each product). We are struggling with story prioritization between different products and lots of meetings for the same.
Below are the two options we are looking at:
1. Merging product backlogs to a single product backlog
So that team can pull stories from one product backlog to sprint backlog. (And does not have to bother about priorities anymore). But a single product backlog maybe too huge and unmanageable.
2. Separating the team into 5 teams for each product
But this is not currently possible as we have resources specialized it a particular skillet and needs to be shared across the products.
Any suggestions?
I would suggest a third option.
Form teams around the products that generate the most work. Then have the remaining developers work on teams that cover the remaining products.
Something like:
Team 1 - Product 1
Team 2 - Product 2
Team 3 - Product 3, 4, 5
Hopefully this will reduce the struggle with story prioritisation (although not completely eliminate it).
The most important thing is to identify what you want to gain by the new organisational structure and how you intend to measure success.
Get some suitable metrics in place, try the new structure and see if the metrics get better or worse. Then inspect and adapt your approach.