Your new business is small and limited in its resources. Your vision is probably ten times more ambitious than what you’re currently capable of delivering. (Just to let you in on a little secret, that ratio never changes.) it’s tempting to bite off more than you can chew. This early on, however, you’re better off focusing on shipping fewer features but making sure they work really well.

New features aren’t always a good thing. Every feature you add may have as many drawbacks as benefits. Unfortunately, we all tend to focus on the potential upsides rather than acknowledging the downsides. A new feature may increase sign-ups, but if it doesn’t deliver, they won’t stick around–and your reputation will suffer.

I never regretted leaving a feature out of Sifter, but I have had regrets about multiple features it does have. In one case, repeated requests from numerous customers led to implementing a feature that is only used 1.3% of the time, but which constituted a much larger percentage of support requests and code complexity.

I added quite a few features to Sifter, but no single feature ever significantly affected growth. That’s just not how it works. When we launched, we didn’t even offer seemingly critical features like searching or file uploading, and everything worked out fine. Slow and steady improvement works, but there’s rarely a silver bullet feature that changes the trajectory of a business.

it’s easy to view quantity of features as a growth strategy, but in our experience the quality of the feature matters far more than the sheer number of them. Features add complexity, mass, and even technical debt that you’ll need to circle back and clean up at some point. Features require support and bug fixes. And that distracts you from creating the level of quality that sets one product apart from the next.

Think Hard about Whether to Add Features

There will come a time when you’ll want to remove a feature. You may find out that few people use a particular feature, or you may need to remove one to make room for a better solution. Either way, you’ll quickly discover that removing features is like pulling teeth–it can be done, but it won’t be painless. Removing features will invariably upset some customers, and when that happens–even if it’s a minority–you’ll spend some time helping them adjust.

Every time you add a feature, think long and hard about what it would take if you had to remove that feature later. The difficulty of removing a feature shouldn’t influence whether you build it, but the process of thinking about removal is a healthy one that can influence how best to build it.

Build the Right Features

There’s no way to get real feedback from customers before you launch–your chances of building the wrong functionality go up dramatically if you try to cram them in before the site goes live. Before launch, don’t think of each new feature as worth X new customers; instead, think of it only in terms of its downsides: development effort, maintenance, support, and bugs–that is, “This feature will force us to launch two weeks later, and we’ll lose two weeks’ revenue.”

After launch, you’ll have more feedback than you know what to do with. From that point forward, you’ll know what you should or shouldn’t be working on. Any decisions before then are merely speculation. You have to start somewhere, but it’s best to start with a core you can extend, rather than trying to build everything in one fell swoop.

Before we launched Sifter, I fully expected that we’d eventually have to provide some level of control over Sifter’s design and branding so people could customize the appearance of their accounts. In eight years, we only received a few requests for this feature, and no one ever told us it was a deal breaker. Had we decided to launch with this feature based on my confidence that people would demand it, we would have made a huge mistake and wasted countless hours. There were at least half a dozen features like this that we ultimately put off and Sifter still doesn’t offer today.

Concentrate on Quality

In a new business with limited resources it’s dangerous to try to compete on the number of features you have. In most cases, if there’s a competitor in your space with a massive feature set, you’re probably creating your product precisely because their application has become large and bloated. If you try to squeeze in features to compete with them, you’ll be striving to become exactly what you set out to avoid. You can almost bet that the number of frustrated users of that other product has increased with the number of features. If you provide quality instead of quantity, your product could be the breath of fresh air they have been waiting for.

it’s best to build a limited but reliable and pleasant experience–at least for your first version. Fewer bugs. Better design. More delight. If you pile on too many features, you’ll end up with a lower-quality product that you’ll have to go back and improve. Then you’d be busy cleaning up mistakes rather than focusing on customer requests. In the end, though, you won’t be able to ship a perfect product. The point of shipping fewer features is to ship sooner. If you burn through too much time perfecting things, you erase the benefit of launching fewer features. Keep it simple, but also be judicious with perfection.

Focus

Nothing is more important than applying your limited resources wisely. If you try to build ten features at once, you won’t be able to focus on any of them. You’ll no longer have a vision–you’ll have a mess. You’ll execute more efficiently if you force yourself to narrow your attention.

Similarly, if you try to build those ten features, you’ll have a much harder time deciding what to build first. Narrowing your application to a handful of flagship features helps you spend your limited time wisely and frees you from having to constantly juggle tasks and switch contexts.

Embrace Simplicity

Complexity will weigh you down. As a startup, your ability to quickly move and adapt is one of your biggest assets. Every extra bit of code weighs you down–it’s like running a marathon with weights strapped to your ankles. Features are good–and important–but if you try to add them before receiving real feedback from paying customers, the potential downsides are greater than the potential upsides. No matter how confident you may be about a feature, you don’t really know if your customers will want it until they tell you.

Releasing a Feature Isn’t the End

You might think that releasing a high-quality feature is the end of the work for that feature. However, a quality feature without a quality plan for education and promotion isn’t a quality feature. The caliber of the supporting documentation, marketing, and announcements of new features are just as central to quality as the actual code. A high-quality new feature that no one understands isn’t a high-quality new feature. Take the time to generate awareness and teach customers how to exploit the value of that feature. Finish strong. Don’t just release and forget.

Marketing is Easier

You may not fully appreciate the challenge of marketing just yet, but you will. The simpler a product is, the easier it is to explain to people, and that’s marketing. To the average consumer, Google is search. They’ve expanded far beyond that, but that’s the core. In Sifter’s case, it has always been about simplicity in place of overwhelming configuration options. If you pick one thing to hang your hat on, you’ll have a much easier time explaining what it is and what it isn’t. In turn, you’ll have an easier time marketing and selling it.

Software Quality Academy I meticulously researched and documented the practices that help teams ship the highest quality software possible. If you’re ever unsure that quality is worth the investment, this should help.

No more yes. It’s either HELL YEAH! or no. Derek Sivers provides a great framework within which to decide what to do and not to do. It’s just as relevant when deciding what to work on within your application.

Bootstrapped Startup Saves Over $100K By Dropping IE Tyler Rooney of Format discusses how dropping support for Internet Explorer enabled his team to focus on delivering a superior experience.