Simplicity is not a starting point
A simple product is never one that did little. It's one that removed a great deal.
Simplicity is one of our five values, and probably the most misunderstood — including by the people who claim it.
It's almost always taken as an opening constraint: do little, stay minimal, don't overload. But a product that does little isn't simple. It's incomplete. The difference shows up immediately in use: an incomplete product forces the user to do the work somewhere else.
Real simplicity is an outcome. It arrives at the end, after the work of removal.
Where the complexity goes
Every real problem has irreducible complexity. Tax compliance is complex. Document management in a two-hundred-person organisation is complex. No product makes that complexity disappear.
The only question is: who carries it?
A badly designed product hands it back to the user — as configuration, as choices they have no basis to make, as steps they have to sequence themselves, as rules they must know in order not to get it wrong.
A well-designed product absorbs it. It makes the default decisions that are right in 90% of cases, keeps the remaining 10% reachable without imposing them, and never asks the user for information it could infer.
That absorption is work. A lot of it. It's precisely the work a "simple" product has done and a minimal one hasn't.
Why it's hard
Removing is harder than adding, for three reasons.
Adding is measurable; removing isn't. A shipped feature can be demonstrated. A feature avoided leaves no trace, and nobody thanks you for what doesn't exist.
Every addition has an advocate. A feature always corresponds to someone's real request. Removing it means disappointing an identifiable person in favour of anonymous users.
Complexity arrives in small doses. No single decision is unreasonable on its own. It's the accumulation that makes a product illegible — and by then no particular decision can be named as the culprit.
What we actually do
We define scope by what it excludes. A framing document contains an explicit list of what the product will not do. That list matters as much as the other one, and is harder to write.
We ask what use disappears. Before every addition: which existing behaviour changes, and for how many users? An addition that complicates the main screen to serve an edge case is almost always refused.
We go back over it. Once a product works, we revisit the decisions made along the way. Some options exist only because we didn't decide at the right moment. Those can go.
We accept no as the default. The cost of a feature isn't building it. It's maintaining it, documenting it, its interaction with everything else, and the space it occupies in the user's head.
The test
There's a simple test for whether a product is genuinely simple: watch someone use it for the first time, and say nothing.
If they hesitate, they aren't undertrained. The product has handed them a decision it should have made on their behalf.
Category BUILD · Reading time 7 minutes