Defining service boundaries: how small should a microservice be?

we're in the process of breaking apart a substantial monolith, and the team is constantly debating how small a microservice should actually be. some advocate for very fine-grained services, like a 'userservice' that just handles user profiles, 'authentication service' for login, etc. others push for broader business-capability-oriented services, like a 'commerce service' that might encapsulate products, orders, and payments. the argument for tiny services is clear separation of concerns and independent deployment, but it often leads to incredibly chatty architectures, complex distributed transactions, and a lot of boilerplate. too large, and you just have a 'distributed monolith' with all the downsides of a monolith plus network latency. we're trying to find that sweet spot. how do you define service boundaries effectively without over-engineering or under-engineering? are there any heuristics or red flags you use? we're really struggling to get a consensus on this, and it feels like every approach has significant drawbacks.