It's not surprising that you're struggling. Organizing teams around services is a form of having component teams.
Just because your organization considers each "microservice" to be a product doesn't mean that your customers see them that way. Your customers see the thing that they pay for and use as the product, and discuss changes (feature requests, bugs) in that context. However, in order to support those changes, you need to align multiple teams and dependencies.
Dependency management between teams is hard, which is why the preference tends to be on teams that are aligned with customer-facing products. For large and complex products, aligning the teams with streams may also be a viable solution, where each stream cuts across the entire product but serves a particular user base or high-level use case. The idea is to reduce the number of teams necessary to go from the initial request to deploying the necessary changes.
The common assumption in many of the scaled frameworks is that teams are feature teams because this greatly reduces the complexity. If you combine it with a robust automated test framework to capture the system behavior as an executable specification, you can reduce the complexity even more by ensuring that changes one team makes to a service don't negatively impact another team's changes. You may still have to deal with conflicts when integrating but at a much lower rate.
I believe the best suggestion would be to make fundamental changes to your organization. There may be some organizations who can manage with component teams, it's generally seen as less effective, especially when attempting to support agility.