The dark side of microservices PMs don't talk about
I lead the strategy and delivery of products and systems that solve real problems, support commercial goals and scale across teams and markets. My work spans platform foundations, user-facing experiences, commercial tools and developer products, and I adapt my approach to the needs of each domain. I focus on maturing complex systems, improving the experience for both users and developers and strengthening the foundations that make products reliable, scalable and easy to build on. I care about clarity, good judgement and creating the processes and environments that help teams deliver consistent, long-term impact. My experience covers early-stage, scale-up and enterprise product environments, combining hands-on delivery with team leadership and award-winning work recognised across several innovation competitions.
Microservices are often sold as an obvious upgrade.
Autonomy. Scalability. Faster delivery.
For many organisations, they deliver exactly that, at least initially.
What's discussed less is the cost side of that trade-off.
Microservices shift complexity; they don't remove it.
The complexity just moves from inside your codebase to between your teams.
From a product perspective, the dark side shows up gradually:
Coordination replaces simplicity; what used to be a function call is now a cross-team negotiation
Integration replaces implementation; you spend more time connecting things than building things
Failure modes multiply quietly; every network call is a potential failure point
None of this is immediately visible on a roadmap.
I worked on a product where adding a new field to the user profile used to take one PR.
After microservices: the field needed to live in the user service, be exposed via the API gateway, consumed by the mobile app, synced to the analytics pipeline, and validated against the permissions service.
Same feature. Five teams. Three sprint cycles. Endless Slack threads about data contracts.
We'd gained team autonomy. We'd lost feature velocity. Both were true.
As services proliferate, product decisions become harder to reason about.
A small change; adding a filter, changing validation logic, updating a workflow, can span multiple teams, each with its own priorities, roadmap, and release cycle.
The PM work shifts from problem-solving to dependency management. You spend less time on "what should we build" and more time on "how do we coordinate building it."
Another issue is cognitive load.
Understanding the system becomes harder as boundaries increase. Context is fragmented across repositories, teams, and documentation.
New PMs take months to understand data flows. Debugging requires tribal knowledge. Simple questions, "why does checkout behave this way?", require archaeology across five services. The system becomes illegible to the people who need to change it.
This isn't an argument against microservices.
It's an argument against adopting them without recognising the product cost.
Microservices demand stronger discipline:
Clear ownership: every service needs an accountable owner, not just a maintaining team
Stable contracts: APIs can't change casually when dozens of services depend on them
Intentional governance: someone needs to prevent the same logic from being reimplemented in fifteen places
Without those, autonomy turns into fragmentation. You get the coordination cost without the architectural benefit.
For PMs, the challenge is knowing when the benefits outweigh the coordination overhead and being honest when they no longer do.
Ask: Are teams actually moving faster? Or are we just coordinating more?
If most of your time is spent aligning services rather than delivering value, the architecture might be working against you.
The dark side isn't that microservices fail.
It's that they succeed in ways that make systems harder to change over time.