Saying No to 1,000 Good Ideas

When Jobs said he was as proud of the things Apple didn't do as the things it did, and that focus means saying no to 1,000 things, people heard a productivity tip. It's not a productivity tip. It's the most expensive discipline in product work, because the thousand things you say no to are good ideas.

This is the final part of a four-part series on my product design philosophy. The rest: Part 1 — If Your Product Needs a Manual, the Design Already Failed, Part 2 — Start With the Experience, and Part 3 — Nobody Asks for the Future.

Bad ideas reject themselves

Nobody needs a philosophy to say no to bad ideas. Bad ideas die in the meeting where they're proposed. The dangerous ideas are the good ones: the feature a real customer genuinely wants, the adjacent market that genuinely exists, the integration a real partner is genuinely offering. Each one passes every test except the only test that matters, whether it serves the one thing you're trying to be exceptional at.

Do a few things exceptionally well rather than many things adequately. The math behind that sentence is brutal and simple: exceptional is a threshold, not a gradient. A product that's adequate at six things loses to a product that's exceptional at one, in every market I've ever operated in, because users don't buy averages. They buy the one thing you're for. I've argued before that prioritization is the job; this series is why. Every yes is funded by quality withdrawn from everything you already said yes to.

Kill what misses the bar

Saying no at the idea stage is the cheap version. The expensive version is killing a project that's already alive: months invested, a team attached, a roadmap commitment made, and the honest assessment is that it will ship as adequate, not exceptional. Most organizations ship it anyway, because the sunk cost has a constituency and the standard doesn't.

Jobs killed products days before launch. I'm not romantic about the brutality, I've been in those rooms and they're miserable, but I am certain about the economics. The cost of shipping adequate isn't the one mediocre feature; it's the permanent tax of maintaining it, the support load, the surface area in every future redesign, and, worst, the message to the team that the bar is negotiable under deadline. Killing it says the opposite, and the team you keep hears it loudest. A high standard you enforce once buys you a hundred arguments you never have to have.

Prototype with real working models

Make real working models, not just drawings. Of all the principles in this series, this is the one where the ground has shifted most since Jobs said it, and it's shifted in his direction.

A mockup is a drawing of an opinion. It cannot be slow, it cannot have an awkward empty state, it cannot reveal that step three is infuriating, because it cannot be used. Decisions made from mockups are decisions made from the most flattering possible version of the idea. Working software is the only honest critic on the team: it pushes back, it embarrasses the idea early, it tells you things nobody in the design review knew to look for.

In 1997, demanding working models was an expensive eccentricity only Apple could afford. In 2026 it's nearly free. When building gets cheap, a working prototype costs an afternoon with a coding agent. Which means deciding from static mockups is no longer a budget constraint, it's a choice, and it's the wrong one. The new rule on my teams: if we're debating it in a document for the second meeting, someone builds it instead. The prototype ends arguments that decks can only prolong.

Refine until it feels right, restart when it doesn't

Keep refining until it feels absolutely right, and don't be afraid to restart if it isn't. "Feels right" sounds unrigorous next to metrics and acceptance criteria, but it's the most demanding bar on the list, because feel is the sum of every detail from Part 2 and you can't unit-test the sum.

The restart is the part teams fear, and the fear is outdated. A restart was a catastrophe when the build took a year. When the build takes days, a restart is just iteration with honesty about how far back the problem goes. The second build is always faster and always better, because the first build was the real spec, the working model that taught you what the thing actually needed to be. Version one of anything important I've shipped was thrown away at least once. That's not waste. That's the method.

The whole philosophy on one page

Four essays, one position. Simplicity is the ultimate sophistication, and a product that needs a manual has failed. Start with the experience and work backwards to the technology, with quality going all the way through, including the parts nobody sees. Build what customers can't ask for, and own the layers that carry the vision. Then protect all of it with ferocious focus: say no to the good ideas, kill what misses the bar, prototype for real, and restart without fear.

None of it is new. That's rather the point. The philosophy has been sitting in plain sight for decades while building was too expensive for most teams to live by it. Cheap building just removed the last excuse.

If your roadmap has a thousand yeses on it and you know which essay you skipped to get here, let's talk →