> There are 2 backlogs, one run by product and one run by dev/ops/arch/sec. Over the course of a PI (about 1 quarter), capacity planning usually allocated 70/30

> There are 2 backlogs, one run by product and one run by dev/ops/arch/sec. Over the course of a PI (about 1 quarter), capacity planning usually allocated 70/30 between the two backlogs. Does "run by" mean that dev has to justify their projects to product and vice versa? Or is this a "this is our area, we'll take care of it thank you" kind of thing? In my team at AWS we have ~5 backlogs each planning cycle, which includes areas like 'operational risk reduction,' 'operational burden reduction,' and 'adoption'. What makes it work in our case is that both dev and product jointly own all the backlogs, and have to come to a single recommendation on allocation they put forward to the service GM. Dev has to defend projects they want to do in the more engineering focused backlogs, while product has to do the same for the feature oriented backlog. Over time, allocations have shifted significantly depending on where the service is and what customers are asking for. What I like about this is that it forces everybody to get along and to keep their eye on what's actually important (the customer). This does require that both product and dev are experienced enough to see the other perspective. Product will have to understand that it's not in the customer's interest if dev has a super high burden, while dev will have to accept that a perfect solution is usually worse than a good enough one.