How to get your software-development priorities right

I've been spending some time reading the 37Signals book Getting Real. It has a lot of common-sense advice for keeping development projects on track. Here's a sampling of some bullet-points that I found particularly worthwhile:

• Explicitly define the one-point vision for your app. What does your app stand for? What's it really all about? Before you start designing or coding anything you need to know the purpose of your product — the vision. Think big. Why does it exist? What makes it different than other similar products?
• Work from large to small. Don't worry about the size of your headline font in week one. You don't need to nail that perfect shade of green in week two. You don't need to move that "submit" button three pixels to the right in week three. Just get the stuff on the page for now. Then use it. Make sure it works. Later on you can adjust and perfect it.
• Find the core market for your application and focus solely on that. (37Signals calls this "Hiring the Right Customer.") The customer is not always right. The truth is you have to sort out who's right and who's wrong for your app. The good news is that the internet makes finding the right people easier than ever. If you try to please everyone, you won't please anyone.
• Scale later. You don't have a scaling problem yet. If you've got a huge number of people overloading your system, then great — that's a nice problem to have. The truth is the overwhelming majority of web apps are never going to reach that stage. And even if you do start to get overloaded it's usually not an all-or-nothing issue. You'll have time to adjust and respond to the problem. Plus, you'll have more real-world data and benchmarks after you launch which you can use to figure out the areas that need to be addressed.
• Build half a product, not a half-ass product. Beware of the "everything but the kitchen sink" approach to web app development. Throw in every decent idea that comes along and you'll just wind up with a half-assed version of your product. What you really want to do is build half a product that kicks ass. Stick to what's truly essential. Good ideas can be tabled. Take whatever you think your product should be and cut it in half.Pare features down until you're left with only the most essential ones. Then do it again.
• Essentials only. Our favorite answer to the "why didn't you do this or why didn't you do that?" question is always: "Because it just doesn't matter." That statement embodies what makes a product great. Figuring out what matters and leaving out the rest.
• Start with no. Each time you say yes to a feature, you're adopting a child. You have to take your baby through a whole chain of events (e.g. design, implementation, testing, etc.). And once that feature's out there, you're stuck with it... Make each feature work hard to be implemented. Make each feature prove itself and show that it's a survivor. It's like "Fight Club." You should only consider features if they're willing to stand on the porch for three days waiting to be let in. That's why you start with no. Every new feature request that comes to us — or from us — meets a no. We listen but don't act. The initial response is "not now." If a request for a feature keeps coming back, that's when we know it's time to take a deeper look. Then, and only then, do we start considering the feature for real.
• Expose the price of new features. For example, be on the lookout for feature loops (i.e. features that lead to more features).
• Avoid preferences. Preferences are a way to avoid making tough decisions. Instead of using your expertise to choose the best path, you're leaving it in the hands of customers. It may seem like you're doing them a favor but you're just making busy work for them (and it's likely they're busy enough). For customers, preference screens with an endless amount of options are a headache, not a blessing. Customers shouldn't have to think about every nitty gritty detail — don't put that burden on them when it should be your responsibility.
• Ask people what they don't want. Most software surveys and research questions are centered around what people want in a product. "What feature do you think is missing?" "If you could add just one thing, what would it be?" "What would make this product more useful for you?" What about the other side of the coin? Why not ask people what they don't want? "If you could remove one feature, what would it be?" "What don't you use?" "What gets in your way the most?" More isn't the answer. Sometimes the biggest favor you can do for customers is to leave something out.

For more of the book, see the free online edition here.