Defining service boundaries: how small should a microservice be?

we're in the process of splitting a pretty large monolith, and the biggest point of contention is defining service boundaries. everyone has an opinion on how small a microservice should be. some argue for single-entity services like a `userservice` or `productservice`, while others advocate for business-capability services like `commerce_service` that encapsulate multiple entities. the problem with too-small services is chattiness and increased network calls, making transactions harder. too large, and we're back to a distributed monolith. what principles or heuristics do people use to draw these lines? is there a sweet spot, or does it always depend on the domain and team structure?