If Your Product Needs a Manual, the Design Already Failed

I didn't invent my product design philosophy. The bones of it are Steve Jobs', and before him Leonardo's: simplicity is the ultimate sophistication. What I can claim is twenty-five years of testing it against real products, real teams, and real budgets, and watching it hold up every single time. This series is that philosophy, written down the way I actually use it.

This is Part 1 of a four-part series. The rest: Part 2 — Start With the Experience, Part 3 — Nobody Asks for the Future, and Part 4 — Saying No to 1,000 Good Ideas.

Simplicity is a destination, not a starting point

People hear "keep it simple" and think it means doing less work. It's the opposite. Anyone can ship complicated; complicated is what naturally happens when a team builds under deadline. Every first draft of every product I've ever seen was complicated, including mine. Simplicity is what's left after you've understood the problem deeply enough to throw most of your solution away.

That's why I treat simplicity as an engineering outcome, not an aesthetic preference. A simple product means somebody did the hard thinking so the user doesn't have to. A complicated product means the team shipped its org chart, its indecision, and its meeting notes straight into the interface.

The manual test

Here's the cleanest quality bar I know: if users need a manual, the design has failed. Not "the documentation team has work to do." Failed. A manual is a confession that the product couldn't explain itself.

And the test applies everywhere, not just to consumer apps. Your internal admin panel needs a manual? Failed. Your API needs a two-hour onboarding call? Failed. New engineers need a wiki page to run the build? Failed. I push this hard because I've watched companies bleed margin through tools their own operators can't use while everyone shrugged and said "it's just internal."

When someone asks how to do something in your product, the instinct is to answer the question. The discipline is to also log it, because the question itself is the defect. Products should be intuitive and obvious. "Intuitive" isn't a compliment users give you; it's the absence of all the questions they never had to ask.

Eliminate, don't organize

When a product gets confusing, the common response is to organize the complexity: better navigation, better grouping, a settings page with tabs. That's tidying the clutter instead of removing it. The Jobs move, and the right one, is elimination. Unnecessary buttons, features, and options don't get filed, they get deleted.

My least favorite artifact in software is the settings page that grew for five years. Most settings exist because two people on the team disagreed and nobody had the authority to decide, so the user got handed the argument. Every toggle is a decision you outsourced to someone who paid you specifically so they wouldn't have to make it.

Elimination hurts because everything you'd cut is there for a reason. Some customer asked for it. Some deal closed on it. That's exactly why subtraction is a leadership job, not a design task: the designer can see what should go, but only leadership can absorb the cost of removing it. I'll go deeper on saying no in Part 4, because it deserves its own essay.

Question every "should"

The second half of this philosophy is the part people skip: challenge every assumption about how things "should" work. Every product category carries inherited conventions, and most of them are fossils, somebody else's old constraint that outlived the constraint.

Invoices look like invoices because paper was 8.5 by 11. Dashboards open with charts because executives once got printed reports. Signup asks for a company name on step one because a salesperson needed it for routing in 2009. None of these are laws. When I review a product, the question I ask most isn't "does this work?" It's "why is this here at all?" The answer "that's how it's done" is not an answer; it's an invitation.

Break from conventional wisdom when necessary, and necessary means whenever the convention serves the category's history instead of your user's next thirty seconds.

Why this matters more now, not less

Here's the twist that makes a decades-old philosophy urgent in 2026: building got cheap. When building gets cheap, adding a feature costs almost nothing, which means bloat is now the default failure mode. The marginal feature used to be filtered out by engineering cost. That filter is gone. The only filter left is taste, and taste means restraint.

Teams that don't internalize this will ship more than ever and mean less than ever. The ones that win will use cheap building the other way: to afford the three rewrites it takes to make something genuinely simple.

Next in the series: start with the experience and work backwards to the technology, including why the parts of your product nobody sees still have to be beautiful. And if your product is failing the manual test right now, let's talk →