How to Kill a Bad Idea
Are you in the software business? I bet most of you would answer no. So let me put it another way: Do you have a website? If the answer is yes, you're in the software business. A website is software. It has utility, and that utility is accessed via an interface on a computer or mobile device. That's software.
Given that today most businesses -- and plenty of individuals -- have websites, far more of you are in the software business than you probably realize. You may make widgets or furniture or run a restaurant or provide a service, but you're also responsible for software. Even if you outsource the development of your website, you're ultimately responsible for its presentation. In that way, you're little different from a restaurateur -- you probably don't grow or raise your own ingredients, but you serve them to your customers. The buck stops with you.
Being in the software business is a wonderful thing. It means you can create just about anything. A basic set of raw materials -- a server, some code, some graphics, some words -- can be configured into a billion billion combinations with relative ease. That is unique and wonderful and should be celebrated.
However, it's also a curse. Understanding why is the key to building great software -- or a great website.
Let's start by looking at a physical object -- say, a standard 16-ounce water bottle. Think Evian, Poland Spring, Fiji, or something like that. You don't have to be an expert in anything to know that those bottles are well designed. They are made of clear plastic, which means you can see the contents from far away; if they were opaque, you wouldn't be able to tell what was inside. The water inside the bottle is heavier than the packaging; if the bottle was heavier, you wouldn't be able to feel if it was empty or full without picking it up or pouring out its contents. The bottles are grippable, portable, and easy to use; if they were too tall or too fat or too slippery or too thin, you wouldn't be able to just grab and go.
You don't have to analyze the bottle like I just did to understand that it is well designed. You know it, because you can see the bottle, feel it, and use all of its features immediately. You can see where it starts and ends. It is not complicated. It is in balance with its purpose. Imagine a bottle without a spout or a bottle that was burning hot or a bottle that was as slippery as ice. Every reasonable person would know that wouldn't work.
Contrast that with software. What are the criteria for evaluating software? Software doesn't have mass. It doesn't have shape. It doesn't cast shadows. It has no edges. It has no size. You can't pick it up. You can't feel it. It doesn't obey the laws of physics. It's not really even there. Nothing is pushing back, saying, "That's a bad idea; that won't work; that's going to burn someone or hurt someone or make someone drop it or..." Almost none of the tools we've developed to evaluate physical objects apply to software.
This is why most software goes bad over time.
Software -- websites included -- usually starts out pretty good. The first version is pretty focused. Yes, there are horror stories of overstuffed websites or unwieldy software products being launched. But for the most part, the first version of something has the fewest features it ever will have.
As time goes on, customers send feedback, and the business evolves. Things get more complicated. More people, more opinions, more pressure to add stuff.
The software grows. Version 2.0 comes along. It does more than Version 1.0. More features, more options, more screens, more stuff. Or the website is redesigned with more pages, more words, more images, more departments, more tools. Nothing has gone wrong yet. In fact, Version Two is pretty good, too.
But over time, yet more stuff is added. Remember our water bottle? Imagine what would happen if more stuff was added to it. Pretty soon it wouldn't be functional. The physics would push back. Not so with software. You can just add more pages! Or you can just add more features or more settings or more preferences and hide them behind yet another button or menu. It's just one more button, right?
This is where it all begins to fall apart. Future versions are loaded with more and more stuff. Nothing pushes back; nothing says no. And eventually, the product or the site becomes unmanageable. It's too big, too slow, too confusing, but it's still all subjective. Unlike the water bottle, the software can just keep growing. Software can't overflow. It has no edges, so it can never be too big.
Guess what? It can.
The only way to stop this perpetual growth of an object without physical borders is for you to create your own borders. Those borders are discipline, self-control, an editor's eye for "enough." The ultimate border is one simple word: no. Someone in charge has to say no more than yes.
If the laws of physics govern the physical world, the word no governs the virtual world. "No, that's one feature too many." "No, that's just not worth it." "No, no, no."
I remember when our software company, 37signals, didn't know how to say no. We were building the first version of Highrise, our Web-based contact management tool. And we kept saying yes. "Wouldn't it be cool if..." Yes! "Oh, man, it should totally do this..." Yes! "How about we add the ability to..." Yes! It was always yes, yes, and more yes. Which meant that when it was finally complete, Highrise ended up sucking.
It wasn't easy, but eventually we looked back at what we had created and admitted, "This is just way too much. It doesn't make sense. It's not simple. It's not clear." So we scrapped it and started over. The new version was built with a heavy dose of no. It turned out wonderfully. Today, Highrise is our fastest-growing product.
It's still hard to say no when we're building a new product. I think it's because yes just sounds so much better. Yes is the thing of dreams. Yes, we can do this. Yes, we can do that. Yes feels really good.
The problem is that yes often results in massive costs that we don't consider when we're dreaming up all the things we want to do. Yes doesn't push back until it's too late. If you've already agreed to do all these things, then it's that much more difficult to say no later on.
And that's the key to it all. No is easy if you say it early. It's a lot harder to say it later, because it's usually in response to something you already said yes to. This is where things get hairy.
No means you have to make tough choices that aren't always obvious at the time. No can be hard, even painful; it can lead to imagining what could have been. But when you make software, it's almost always a good idea to say no more than you say yes. Over time, you'll regret saying yes more than saying no. No?
Jason Fried is co-founder of 37signals, a Chicago-based software firm, and co-author of the book Rework, which was published in March.