We receive several Intervals feature requests each day. Some of these requests are easy to say ‘no’ to, as they don’t align well with our trajectory. Other requests are fun to say ‘yes’ to, because they are a vote of confidence for features we’ve already considered, or they are an opportunity to give a sneak peak into a feature in development. And then there are the feature requests that fall in between, the ideas we review and think “I can see it both ways.”
Many of our feature requests fall into this camp. They are really good requests — ideas we didn’t think of ourselves — that we really like. Our project manager will see how it fits his needs, but our developers will argue it as unnecessary. And sometimes it’s the developers who support it, while marketing doesn’t want it.
The point is, it’s not always easy to say ‘no’ or ‘yes’ to each feature request. There exists an ambiguous gray area in between the two. Navigating this gray area, and extracting the ideas that will enhance your offering without stagnating or bloating it, is what makes a web-based service successful. Say ‘no’ to too many features and customers will start branding you as pompous and irrelevant. Say ‘yes’ to too many features and you’ll end up with bloatware and frustrated customers.
There is no easy answer on how to do this. If you are just setting out to build a web-based service, my advice would be to build on what you know. The more intimate your understanding of your product, the better you will understand how each feature will impact your long term goals. If your web-based app is already out there, analyze your customers; talk to them, distribute surveys, find out what they want. Knowing and understanding your customers will help you keep their needs inline with yours. The rest is up to you.
