I'm working on an web platform (SAAS) that's about six years old. Like a lot of new web services, it's evolving rapidly in response to client and user requests.

In the short time that I've been here, I've noticed that many more features are added to the platform than are removed.

Anytime I've presented a choice of two features to the marketing and product teams, their typical response has been, "We'll have both, and could you add that third feature thingy we talked about last week?"

I'm a firm believer that good design is about hard choices, yet those choices are not being made.

Does anyone have a good technique for strangling feature creep, and/or forcing the difficult choices in a corporate environment?

The only answer to feature creep is to respond "It will cost more/It will delay the delivery". One of these should make them decide. If not, you have a gravy train that you never need to finish.....
–
Schroedingers CatMar 7 '12 at 19:05

To build on what @SchroedingersCat said, more features = more complexity = harder maintenance and harder to add more critical features later. In essence, more features = less ability to "pivot"
–
cdeszaqMar 7 '12 at 19:18

1

37signals just launched a completely new version of Basecamp after running into this problem. They decided that taking another step with the product was impossible due to the original being 7 years old, so they built a new one where they were free to reevaluate each feature. So there's a market/thought leader you can refer to. More on their blog
–
Rahul♦Mar 8 '12 at 0:16

4 Answers
4

I prefaced my pitch with some strong relevant examples of successful products that really illustrate the 'less is more' principle and some of the obvious usability issues that come with clutter - Steve Krug 101 stuff would help.

I presented factual data that showed that certain features weren't even being used. This is very powerful if you can pull it off, and you should, otherwise how can you justify removal of one feature over another?

I mocked up an alternative that visually illustrated the benefits of removing the chaff and how it allows the core moneymaking features to to shine through.

I think the key here is that I made sure not to come across like a business advisor so as not to 'step on any toes', but instead tie everything to user psychology and behaviour.

I was quite successful with this approach and after a few rounds of working this into the meetings, it really started to stick and the role of UX in the company shifted from "Here, take these features we've come up with and squeeze into the design." to actually being a part of the product definition process.

@David Sinclair Would you call your company a engineer- or a sales-driven company? Do you think the data you show depends on audience?
–
FrankLMar 8 '12 at 9:39

1

@FrankL That particular company was unusual in that it was a traditional publishing company attempting to move into the digital arena. They are marketing and sales driven but I also had to handle the expectations of content creators and editors. Another big issue with this company was introducing the concept of a release plan/MVP to a culture that is accustomed to not launching until its 'perfect' and making sweeping changes last minute.
–
user2694665Mar 8 '12 at 13:15

Thanks to all who took the time to answer this question. David, especially, has some good concrete advice here. I will also try to gather statistically significant data on which features are being used and which are not. Likely that will entail a combination of Google Analytics, Morae (or some similar tool), User Voice, user testing and server logs. It will be a bit of a research project, but I think it will pay dividends in the long run. Thanks again for all your thoughtful answers.
–
RobCMar 14 '12 at 14:53

Unfortunately in cases like this, its going to be a case of "When in Rome, do as the Romans do"

While talking to marketing teams,I have found the best way to address the focus is to focus on maximum business return and how limiting the number of features and clearly driving the focus of the page can maximize results as opposed to overloading the page with multiple features and confusing the user about the end goal. It also helps if you have some hard numbers of what led you to come up with the feature and what was the potential market for it but as long as you can keep the focus in terms of conversions and dollars in the target market,you will have an captive audience.

With regards to product teams,I generally focus on the implementation constraints that would arise with potentially incorporating that additional feature with regards to the timeline,the business value proposition, the budget and the challenges in ensuring that there is no slippage due to the additional requirement. I have found that presenting the information in terms of a visual timeline highlighting the impacted areas has generally helped.

However there are times when there is a strong push back from the senior management who want multiple features,in that case you could make a pitch for a version 2.0 or an update to the proposed design once the intial design has been implemented

Add logging into your application so you know which features are being used and which aren't. You don't need to record user data, just that option A was used.

Then, when you've got enough (a few weeks or months depending on how many users you have) you can see which features are being used and which aren't. Any that are totally unused are candidates for immediate removal. Any that are used a little should be put on "watch".

The argument is that it costs developer and tester time to maintain these features and if no one (or only 1% of your user base) is making use of them then this is a waste of resources that can be spent on maintaining useful features and developing new features.

I agree with all the points David and Chris made. In addition try to dig deeper into the reasons behind features - ask lots of why's.

Constant adding of features often means that the team is trying to put on band aids on a problem that refuses to go away. If you can understand what this problem is, very often it's possible to find one good solution instead of multiple band aid type features.

On the other hand, this happens when there are way too many stakeholders who have a saying but dont have a unified goal, naturally product team tries to accommodate all of them by adding whatever was requested by different parties. Instead, they should strive to unify the feature plan under one umbrella goal and consistent UX.