Philosophical Alignment
The single most important factor for us is whether the feature matches our vision of where we want Sifter to go. We don’t simply think about whether people want it, we think about whether we want it. We use Sifter ourselves, and that means that most of our decisions are based on our experience. Long-term, we want Sifter to play a significant role in supporting our business. As a result, we’re more likely to add features that support web app development because that’s what we know.
While this can be a contentious area, I believe it’s one of the most important aspects of software and product development. It’s obvious when a product has crammed in every single feature request that comes along. It’s more obvious when they did it as quickly as possible without giving much thought to the value or alternatives. Trying to please everyone is a fool’s game. You might widen your audience, but in doing so, you’re alienating what would otherwise be your most passionate supporters.
Thanks to the breadth of the internet, even the smallest niches can comfortably support a software business. We’d like to make money off of Sifter, but we’re in it first and foremost for the love of what we’re doing. Oddly enough, when you do that, the money usually shows up at some point.
Business Value
The second factor is simply business value. That is, will this new feature improve the experiences of a significant number of customers or potential customers? Then, the number of customers helps determine the priority. Also, if there is a reasonable workaround without writing any additional code, there’s less business value to a new feature.
For instance, Searching and uploading files are foundational features that most everyone will use at some point. They are features that will help everyone with very little drawback beyond the fact that they add complexity. They were important features with very little subjectivity.
However, adding Textile or Markdown would only help the portion of our audience that is formatting-saavy. Even among those customers, many people copy and paste error reports or portions of log files into Sifter, and Textile and Markdown would butcher those. Then, there are people who aren’t familiar with text formatting options. They end up being surprised and confused when the formatting language changes their text in unintended ways. So, text formatting, implemented in a basic way, is a draw. It helps some and hurts some. So, we haven’t done it. (That doesn’t even go into the problem that everyone has a different preference.)
Level of Effort and Impact
The other significant facets when choosing a feature are the level of effort to implement it and the scope of the impact to the system. (There’s usually a close correlation to the two but not always.) If something passes the business value test, takes only a couple of minutes to implement and only affects one page of the interface, chances are that it will make it in quickly even if there are other big features in front of it.
However, if it touches multiple pages and components and take a couple of weeks to implement, then we’re going to sit on it for a while and think about it. We’ll design and explore a few different options so we can understand the tradeoffs. Sometimes, we’ll even create a dummy app in a sandbox just to play with our ideas.
For us, the key thing with this process is that we’re not afraid to pull the plug or delay a feature at any point. Unfortunately, sometimes, even after you decide a feature is a great idea and a good fit, digging into the implementation might prove otherwise. If we think something is going to take one week, and we discover it’s going to take four weeks, we reevaluate whether it’s still worth it or if other features are now more valuable.
Degree of Implementation
Working hand-in-hand with level of effort is the “Degree of Implementation”. That is, with most features, you can create a very simple watered-down version or you can create a really complex and fancy version. We want to aim for the sweet spot, but we also don’t want to underdo it. If we have to choose between a half-ass quick and dirty implementation or delaying a feature for a month or two, we’re going to delay it. We believe that if there isn’t time to do it right, there won’t be time to fix it.
So, while we’d love to get new features in your hands as soon as possible, we only want do push them when they’re worthy of being in Sifter. We can build them quickly to make people happy with our delivery timeline, or we can take our time and make sure people are happy with the actual feature. The latter is a more sustainable model, so that’s what we do.
Summary
It’s a constant balancing act to please people and build a sustainable business. Time, revenue, operations, customers, and personal goals all compete for attention. If we neglect any of those, Sifter wouldn’t survive for long. We can’t work on features all of the time, so we strive to be very careful about where that times goes when we have it.