Less Is More in Product Engineering
Why Great Engineers Simplify, Consolidate, and Delete for Maximum Impact
Most engineers add.
Great product engineers subtract.
They reduce friction for the user.
Simplify tangled systems.
Collapse microservice chaos into cohesive domains.
Remove unnecessary state, tools, and ceremonies.
And by doing so—they amplify product impact.
The Science Behind It: Subtraction Neglect
A few years ago, I came across a video summary of a Nature article that keeps resurfacing in my work.
Research from Leidy Klotz shows that when faced with a problem, people systematically overlook subtractive solutions, even when they are more effective. This bias—called subtraction neglect—is not just cognitive. It’s cultural.
We’ve been conditioned to show value by adding:
New features
New services
New processes
New layers of abstraction
But in product engineering, what you subtract can matter far more than what you build.
The Subtraction Playbook
Let’s explore how subtractive thinking can reshape your approach across architecture, user experience, and delivery processes.
1. Simplify the User Experience
Tessler’s Law: Every system has a certain amount of complexity that cannot be reduced. You can push it onto the system—or the user.
Most teams unintentionally choose the latter.
Subtractive product engineers:
Remove unnecessary steps in user flows
Kill underused settings and toggles
Use progressive disclosure instead of cluttered UIs
Automate input (defaults, autofill) where possible
Ask: “Can this feature be absorbed into another?”
It might seem like a Product Manager or UI Designer's job, right?
But engineers are often the ones most up-to-date with emerging standards, browser behaviors, and system-level defaults.
Engineers aren’t just here to deliver features—they’re product partners in offloading complexity from the user to the system.
P.S. Do you want to be impactful Product Engineer? Check the Product Engineering Manifesto.
2. Reduce Microservice Sprawl
Microservice sprawl often starts from good intentions: separation of concerns, independent deployments, and fault isolation.
But over time, teams fall into the trap of splitting by role or team instead of domain behavior. The result?
Dozens of tiny services with unclear ownership
Complex traceability across calls
Coordinated deployments across multiple teams
More time spent wiring infrastructure than delivering value
This is when you get nanoservices: services so small and isolated that they offer negative ROI.
Before adding a microservice, ask:
Do we need independent deployments more than simplicity?
Will the distributed complexity be worth the scaling benefits?
Can we achieve our goals with a better modular organization instead?
Industry stories worth exploring:
Segment's move from 100+ microservices back to a monolith, reducing deployment time from hours to minutes.
Amazon Prime slashing 90% of infrastructure costs by moving away from microservices.
Shopify's embrace of the modular monolith.
The best engineering leaders know when to consolidate, not just when to distribute.
3. Domain-Driven Design as Complexity Reduction
The most successful product engineering leaders use Domain-Driven Design (DDD) not to add sophistication, but to subtract unnecessary complexity through better organization.
The rest of the examples + The Subtraction Cheatsheet are available for paid readers.