Features vs Ideology
If you're in the market for a powerful and user friendly Help Desk solution, please take a look at my company's flagship product HelpSpot.
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.
Discussion
Great post Ian. I do think it's hard to balance customer feature requests against your vision for a product.
It touches on something I've been pondering about recently: what parallels are there between building an online community (blog, forums, etc.) and software? With both there's this pull between what you want to create and what your users/readers want to consume. The most successful online communities are those that are free to evolve at the direction of it's members. Maybe there's a way that software can fit that same model. Not by introducing every (or even most) feature that customers request, but by shaping the vision for software based on how customers actually use it.
I for one, was overjoyed when you added the Trash feature. It's helpful for day-to-day non-ticket messages that come into HelpSpot, but it also saved my sanity when I accidentally setup some horrible forwarding/auto-responder loop with my email that created hundreds of HelpSpot tickets.
Created by Ade on 04.09.2007 7:03 pm
Thanks for the insight Ian. Great post.
Created by Michael Sica on 04.09.2007 10:47 pm
Great post.
I think another criteria would be: does the feature will make a lot of my customers happy. This may sound obvious at first but it actually doesn't. In many cases even you may not like the requested feature - however, if it will make a lot of your customers happy - do it! It will pay. Do it your way, but do it.
Created by Maayan Porat on 04.10.2007 3:12 pm
Good point Maayan. I generally agree, but I think it can be tricky to know that for sure. Customers may say they want feature X, but once it's there it may turn out they really need Y and were just explaining it as X. Not an issue on straightforward features, but it can be on more complex ones.
Created by Ian on 04.10.2007 3:18 pm
I agree. Always use your common sense, read behind the customer words and when implementing - do it your way.
Created by Maayan Porat on 04.10.2007 3:25 pm