Yes, it does cause confusion and can cause people to create an architecture that is too fragmented, resulting in a higher than necessary overhead in support for all those tiny services. I suspect a lot of people who don't like microservices are suffering from this problem.
Some people's definitions of microservices are that they are separated business domain, with each development team focusing on their business processes. Therefore they can reflect reflect Conway's law. Those teams develop autonomous services which communicate with the services of other teams (e.g. the invoicing team build services to interact with the sales team).
In smaller companies a single team, or indeed each team in a larger company, can have multiple microservices, but there are some qualities that would be needed to truly fit the microservice definitions.
Some people's definitions of microservices are that they are separated business domain, with each development team focusing on their business processes. Therefore they can reflect reflect Conway's law. Those teams develop autonomous services which communicate with the services of other teams (e.g. the invoicing team build services to interact with the sales team).
In smaller companies a single team, or indeed each team in a larger company, can have multiple microservices, but there are some qualities that would be needed to truly fit the microservice definitions.
If you haven't read Martin Fowler's article on Microservices then it's a good start: https://martinfowler.com/articles/microservices.html There's a side bar on that which asks "How big is a microservice?"
Of course Sam Newman is also a great resource for microservice principles: https://vimeo.com/131632250