By Rachel Andrew CHAPTER 11In the case outlined above, there are ways people can declare regions in
code and add additional options to regions — using alternative tags — so
you can often use these requests to prompt thinking around a solution. If
we can provide a frequently requested feature in a way that doesn’t dam-
age our basic use case, then, assuming we don’t burn up a lot of develop-
ment time for a very rare use case, we generally will.
However, you need to make that call on a feature-by-feature basis. If
your product has an API, as Perch does, you can add extra features by way
of plugins for the core product, and make the API available so people with
specific needs can develop their own functionality.
I see this need to protect the core use case as a potential problem when
using a public system that enables upvoting. There might be a popular
feature request that just doesn’t sit well with the core use case you want
to protect. Not addressing it may cause people to believe that you are not
listening.
I spoke to Ian Landsman of UserScape^6 , which develops helpdesk appli-
cation HelpSpot^7 , the system we use for our customer support. I asked him
if certain features weren’t included because they were outside the scope of
support, or issues that software shouldn’t attempt to solve. He said:
Absolutely. In fact HelpSpot takes this more seriously than most. Many of
our competitors have lots and lots of other features that, to me, fall outside of
customer service, like network monitoring, asset tracking, CR M functions,
network password resets and so on. Obviously, some people like the all-in-one
solution, but we’d much rather build something that’s very focused on one
specific problem and solves it well rather than be all things to all people.When you do have to push back on a feature, perhaps because it doesn’t
fit the product or is useful only to a small minority, you do risk upsetting a