This was really spurred on by a recent post by Michael Sica. Michael has a problem with his new designer collaboration software. There's a very logical feature which he knows users want, however, he's trying to resist adding it because the feature goes against his vision of the software. It enables users to do something which is "bad". Not really bad like hacking, just not what "should" be done, at least in Michael's view.
This is a quandary every software developer faces. It's especially difficult to determine the right course when you're first creating a product. Often with a version 1.0 product you're trying to make a statement, be different than the competition.
There's a very fine balance though between being different and confusing or frustrating your users. If you don't offer a unique perspective in your feature set there won't be a version 2, on the other hand if you're too far outside the norm you'll likely have the same result.
I have hit many of these decisions in the evolution of HelpSpot. One I recall is the deletion of requests. HelpSpot is a help desk application and from the beginning I was opposed to having the ability to delete requests. I felt that any data which entered the system (other than email spam) should always be preserved. There's a chance that information might be needed down the road, even if that doesn't appear to be the case now.
Well it turns out that help desk managers are very picky about their reporting. It also turns out that a help desk application gets lots of things which are not at all relevant to the help desk, but which are also not spam. For instance, when training a new user they may enter test requests. They may receive email bounce notifications from automated processes beyond their control. You get the idea.
All these things being sent into the system throw off the reporting capabilities. The reports are essentially wrong because they contain things which are not requests and are not related to the help desk. They also interfere with searching and filtering.
Customers being rather inventive sorts find ways to work around these problems. Customers started deleting these requests as spam since that completely removed them from the system. That though had the undesirable consequence of training the spam filter that these items were spam when they were not. Since these requests often contained "good" words it would throw off the filter and real requests would start being filtered as spam.
In the last release I gave in on this point and added a trash feature. Now there's a proper way to remove unneeded requests from the system rather than routing around or having inaccurate reporting. My delay in adding such a feature has certainly cost me sales. That's not always a bad thing if it was for the greater good of the application, but in this case it wasn't. It was just me being stubborn about a feature. As it turns out I really like this feature myself and find it very useful.
So how can you decide if a feature should be included in spite of your ideological opposition to it?
As the story above points out I'm no expert in this field, but I have a few guidelines which I'm trying to follow going forward. None of these are hard rules, rather if a feature meets one of them all it means is that a little extra thought is required to confirm that the ideological stance against the feature is valid.
Is a feature universally available?:
If you don't have a feature only because everyone else does have it you may want to revisit it. Sure less can be more, but if all your potential customers expect it to be there it's only going to cause them to not understand your interface.
Is the missing feature easily routed around?:
Like my example above, is it easy for customers to route around the lack of a feature. If so does the routing around result in a worse overall experience for the customer? In my case it did because the result was an increased percentage of valid requests being filtered as spam.
Is not having the feature a positive differentiator?:
Does not including this feature differentiate your product in a good way? For example, HelpSpot doesn't allow you to create a title for a request. There's no concept of that in HelpSpot because we found that titles inevitably turned useless. Titles end up being "printer", "problem", "issue" and so on. Instead the interface takes the first line of each request and turns that into what other applications would show as the title. This turns out to be very useful.
Not having a title is a differentiator that increases productivity by removing the need for customer service reps to take time making up meaningless titles. Not all customers like this, but most do.
If the feature isn't a positive differentiator, a noticeable improvement over the competition, then you may want to include the feature. Not having it could keep customers from buying and not having it doesn't add anything to the experience.
Is the ideological stance on this feature still relevant?:
As applications evolve it's not unusual for circumstances to change. What made sense in version 1 doesn't always make sense in version 3. Perhaps your user base has shifted or the other application features have evolved in unexpected ways. It's possible the stance is no longer appropriate given the changing circumstances.
These are the type of questions I've been asking myself as I continue development on HelpSpot v2. I'm hoping they'll keep me from getting locked in to one view and missing out on opportunities going forward.