We had a team of ~8, well over a dozen products, and 6 different product owners. I won't claim this is the best way, the best way is to staff enough people to properly support all your products, but I've had experience similar to yours and we worked out a system that worked really well for us.
We kept two Kanban boards:
- Epics (1-3 month projects)
- Currently played stories/backlog
We normally kept our Epic WIP limit to 2, but would raise it to 3 as an Epic was nearing completion. This allowed a graceful transition between epics by giving us time to groom & plan the next project as the last one was being polished off.
Weekly, we'd meet with any product owners of active epics to have them prioritize their stories in the backlog. Monthly, we would meet with all the product owners so they could collectively prioritize the Epics.
This may sound like a bad idea, but we found that people generally would do what was right for the company. I heard very often, "Oh. Yeah... no. My thing isn't as important as Bill's thing. Do his first." I think the huge benefit was giving everyone visibility into all of the requested work. Our product owners could easily see how their pet projects may not be the most valuable thing for the team to work on and gave them an appreciation for just how much we were being asked to do. In the long run, they became some of our greatest advocates. We didn't have to go begging for more staff, because our product owners were doing it on our behalf. They wanted teams dedicated to their products so there would no longer be so much contention over our time. When I started at that company, there were two of us, soon after I left, there were 3 teams of 4.
Anyway, having a team of 8 soon gave way to having 2 teams of 4 working mostly under the same model, but having 2 teams (each with fewer products to support and prioritize between) resulted in a much reduced overhead. It allowed us to specialize more. Once we had split into 2 teams, we reduced each team's Epic WIP to one.
I feel like this is a good approach because it dramatically reduces the context switching for everyone. Yes, some people will get anxious waiting for their project to be next, but if they want it done sooner, they need to convince their peers and the CEO that it should be next. In the meantime, we were able to give a single problem our full attention, which seriously reduced our cycle times.
Again, the best way is to have enough staff to support all your products, but I understand how hard it can be to convince a non-software company that they require that staff to support all the things they build. Just recently I had a hard conversation with a client about some scope creep. It basically amounted to "To meet system parity, you need to build this tool that doesn't exist in the old system." ... uhhhh huh... Anyway, we asked them if they were prepared to spin up an entire team, Product Owner, Scrum Master, Dev team, to build and support this product indefinitely. The answer was obviously no, but they had not considered the true cost of this new product until we mentioned it. Just some food for thought. I've always found that people want want want until they see the price tag. Show them the price tag.