F|R: How to Avoid Feature Creep with Your Software Apps


In my favorite movie, Wonder Boys, Prof. Grady Tripp is a writer who hasn’t had a best seller in years. His work in progress is a 1,500 page behemoth. Upon sneaking a peek at the magnum opus, one of Tripp’s most devoted students takes it upon herself to point out to the professor that some of his scenes suffer from overkill — being brought to life in such excruciating detail that they actually diminish the experience for the reader. The student accuses the professor of literary indecision.

We have a name for this in the software business, too. It’s called feature creep.

When your well-intentioned haiku of a software app turns into the Encyclopedia Britannica, you’ve lost your core focus, probably because you’ve given in to the temptation to answer this question in the affirmative, far too many times: “Wouldn’t it be great if our product did this?” Of course you want your product to be as good as it possibly can be, but the most successful applications (or literary masterpieces) actually require that you answer “No” more often than “Yes.”

Knowing what to include, and what to leave out, requires much more discipline. But in coding, as in writing, addition by subtraction is the Golden Rule. Product design is about choices, careful ones. It is extremely important to know your customer and listen, but there’s a difference between that and design by committee.

Recent history is loaded with examples of successful products that do one thing and do it well, from the iPod to Twitter. In fact, I have seen several product betas that have fewer features than the prototypes. At Mint.com, where I work, we’ve made such choices many times. Below I’ve put together a few tests to help you avoid feature creep, too:

1. The Vision/Mission Statement Test:
Does adding (insert feature X here) to your product fit with the overall mission statement of your company or service? At Mint, our mission is to help people understand and do more with their money. The vision is to improve the national savings rate. How well a feature does this either directly or by making some other part of the process easier is a major test. Users and engineers alike often get excited about metoo features like Facebook integration, and this is where they often die.

2. The Audience Test:
What market segment are you trying to reach? Who are your current users? Would a majority of those groups benefit from the feature? Adding a feature for 5 percent of your users that clutters and confuses the experience for the other 95 percent is not generally something you want to be doing. Be wary of vocal minorities.

3. The Scope Test:
Engineering and design resources are a scarcity at every company. Respect them. Understand the scope of what you’re doing, and if a single feature is going to hijack your team for months, be wary.

4. The Best Solution Test :
Customers are typically not designers. Neither for that matter are CEOs. Often they will find issues and suggest the most obvious ways to solve it, bypassing the problem description entirely. Don’t be afraid to ignore their solution. Understand the problem first and the users’ reasons for requesting it. Is there a better way? Perhaps something you can leverage in the product already?

5. The Revenue Test :
You need to make money somehow. Google Search has its monetization model aligned perfectly with its primary purpose: You visit Google.com to find something. Getting to that something may be sponsored, it may not be. Your click on a sponsored link is perfectly aligned with what you set out to do. Compare this to MySpace where you go to interact with friends but are assaulted by ad banners trying to divert you. As a user I prefer the former, meaning your revenue features should be aligned with the purpose of your product.

6. The Attraction/Retention Test:
Will the feature help you attract new customers? Are current customers going to bail out without it? If so, can you approximate how many? Don’t guess. Again, respect your engineering resources.

Above all, avoiding feature creep requires having a vision and sticking to it. Today’s innovators are not hamstrung by the revenue models of the past that required yearly upgrades with useless new features or else risked extinction. Solve the problem in your business plan, find the shortest path from A to B, and you will delight your users.

Jason M. Putorti is currently the lead designer of Mountain View-based Mint.com, which makes software for online consumer money management. Prior to Mint, Jason founded an advertising agency and publishing company in Pittsburgh, Pennsylvania.


Shankar Saikia

Microsoft Excel = UI For the (Business) Masses

As much as Microsoft-haters may disagree, Microsoft-Excel is the user interface that a lot of business users like in their applications. The reason: most business users start with an Excel spreadsheet for almost any requirement (e.g., expense report, sales forecast, invoice, project plan …. you name it). Once they get used to it, they want all “real” (i.e., ones actually built for the specific function) apps to have at least some MS-Excel-like features.

Jason M. Putorti

Thanks all for the comments. There’s so much more to this, but hopefully this will help people to take a step back and ask, “Why?” Just like when you start a business, you want to be solving a problem or filling a need. Be sure you know whether the feature is for your users, or for you, and treat accordingly.

Jason M. Putorti
Lead Designer, mint.com

Rob Sandie

Incredible post. I really like how you made the first thing the goal then let everything else dictate this. Great job and I love Mint!

Comments are closed.