Do Not Ask What We Can Add
A mature product does not prove itself by how much it contains. It proves itself by how little the human has to carry.
Start With the Human — Do not begin with the product. Begin with the person.
Product teams are easily rewarded for shipping more
Roadmaps make new features more visible than removals. Demo days celebrate what appeared, not what disappeared. Release notes tell addition stories more easily than simplification stories.
This creates a bias: if you want to prove progress, add.
More shipped does not automatically mean more value.
Every new feature creates new cost
A feature is not only code. It creates state, options, edge cases, permissions, support questions, documentation, learning and maintenance.
Addition creates footprint. If value does not exceed cost, the product is accumulating complexity.
Every feature creates a permanent tax unless proven otherwise.
Complexity compounds over time
Ten features can each make sense in isolation. Their interactions do not stay linear.
Users must understand more. Teams must test more. Systems gain more paths to fail.
Complexity compounds faster than feature count.
Choice overload is a form of product debt
More options do not always create more freedom. Sometimes they simply move decision burden from system to human.
If the product can infer, remember or choose a good default, users should not have to decide merely because the system refused to.
Every unnecessary choice is work handed back to the user.
Removal can create more value than addition
Delete an unnecessary field. Merge two flows. Remove a step. Eliminate a setting few people understand. Let the system remember what users always re-enter.
These changes may look less dramatic, but human burden actually falls.
Removal is a product decision, not the absence of one.
The system should remember so the human does not have to
If users already provided information, the system should remember when appropriate. If a preference is clear, defaults should reflect it. If context can persist, do not make people recreate it.
Machine memory should reduce human memory burden.
What the system can remember, the human should not have to.
Before adding, ask whether it can become unnecessary
Can we remove? Can we combine? Can we remember? Can we infer? Can we automate? Can we make the decision disappear?
These questions are not anti-feature. They protect the product from turning every problem into another control.
The best feature may be the one you make unnecessary.
To me before I add another button
If my first solution is another button, tab, setting or dashboard, I want to ask once more.
Does the person truly need this control, or is the system handing them a decision it should carry itself?
If a product can become simpler while doing more of the right things, that is not doing less. That is maturity.
Build less where understanding allows it.