The Say No By Default Framework
Protect your product's soul by making no the default answer to every request
It is effortless to say yes. Yes to another feature, yes to an aggressive deadline, yes to a mediocre design. Before long, the stack of commitments towers so high that you cannot see the things you should actually be doing. This framework makes no the default response to every request, including your own best ideas, as a way to maintain focus and product integrity.
The principle cuts against the deeply held belief that the customer is always right. If enough customers say your food is too salty, you adjust. But when a few vocal customers demand bananas in the lasagna, you refuse. Making a few loud customers happy is not worth ruining the product for everyone else. ING Direct built the fastest-growing bank in America by saying no when customers asked for credit cards, online brokerage accounts, and large deposits. They kept things simple.
Critically, you must also let your customers outgrow you rather than warping your product to serve their increasingly complex needs. If you tailor your product to power users, you make it intimidating for new users. There is an endless supply of customers who need something simple and basic. Scaring away potential new customers is worse than losing existing ones who have grown beyond your scope.
The framework also applies to ideas. New ideas generate a rush of enthusiasm that feels like certainty but is actually just novelty. Rather than dropping everything to chase the latest brainstorm, write the idea down, let it cool for a few days, and then evaluate it with a calm mind. If you keep forgetting about a particular idea or customer request, that is a signal that it was never truly important. The requests that really matter are the ones you hear over and over until you cannot ignore them.
- You rarely regret saying no, but you often regret saying yes
- The customer is not always right; do not add bananas to the lasagna
- Let customers outgrow you rather than making your product too complex for newcomers
- Do not confuse the enthusiasm of a new idea with its actual priority
- The requests that truly matter are the ones you hear so often you cannot forget them
- Do not write feature requests down; if they matter, customers will keep reminding you
- Make no your automatic first responseWhen any request comes in, whether from a customer, a teammate, or your own brainstorm, default to no. This is not about being dismissive; it is about requiring every yes to clear a high bar. The burden of proof should be on the request, not on you to justify the rejection.
- Apply the cool-down period to new ideasWhen you or your team get excited about a new feature or direction, write it down and wait at least a few days before acting. Evaluate it with a calm mind. Most ideas that seemed like sure-fire hits will downgrade to merely nice-to-have within forty-eight hours.
- Use memory as a filter for customer requestsStop tracking feature requests in spreadsheets or databases. Instead, listen and then let go. The requests that genuinely matter will come up again and again until they are impossible to ignore. If you forget a request, it was not important enough to build.
- Be honest and kind when decliningSaying no does not mean being a jerk. Explain your reasoning politely. People are surprisingly understanding when you take the time to share your perspective. If your product is not right for someone, recommend a competitor. A happy customer using someone else's product is better than a resentful customer using yours.
ING Direct built the fastest-growing bank in America by systematically refusing customer requests. When customers asked for credit cards, the answer was no. Online brokerage? No. Deposits over a certain maximum? No. The bank offered only savings accounts, certificates of deposit, and mutual funds.
Long-time customers told 37signals they were outgrowing the product and wanted advanced features for their increasingly complex workflows. The team refused, prioritizing simplicity for new users over retention of power users.
37signals repeatedly faced pressure from long-time customers to add complexity to their products. Some customers said they were outgrowing the software. The team said no, reasoning that they would rather customers eventually outgrow the product than never be able to grow into it in the first place. This decision to protect simplicity over retaining individual accounts became a defining strategic principle.