Do We Really Need To Build That?
Feature bloat is a real problem for all startups big and small. Staying focused requires the discipline to know when to say “no” even when feature creep feels absolutely necessary. That being said, there are circumstances when it is OK to diverge from your roadmap, and here’s how we think about it.
Focus is key for all startups. The success of our product comes down to a fulfillment of our core value proposition. At Simon, our guiding light for what to build (and what not to build) comes from our roadmap. Every two months we do a thorough review of our existing customers, what’s worked and what hasn’t, and prioritize development for the next iteration.
Items on this list have been thoughtfully considered, prioritized, and well specified. We try to structure our plan to be focused and comprised of a set of goals that’s attainable within the upcoming iteration.
In our experience, the single biggest threat to the integrity of this roadmap is feature bloat. The allure of “just a few pixels” or “a few lines of code” has long-term side effects and costs that span beyond a few hours of development time. The cost of adding these extraneous features is realized in the form of maintenance that comes months and years down the road.
The True Cost of Feature Bloat
Before Simon, several of us were at Etsy, which suffered tremendous feature and technical bloat in its early days. The problem became dire: there were dozens of disparate shopping experiences (built mostly with Flash), middleware layers that did nothing except add complexity, queueing services with minimal requirements that could have been built with existing databases. This functionality made the product harder to use (and degraded overall experience) at a high cost of maintenance.
My team killed features. We had a laundry list that we thought provided little value. Once per month we’d identify the next on our target list. It involved careful research and testing — who used it, why, and what alternatives may exist if it were deprecated. Then, we’d go through the engineering effort required in removing the feature — making sure any side effects and shared library code were well understood and tested. Finally, we announced the removal to the community, existing customers, and requisite support.
While I wasn’t at Etsy when most of these features were built, I know that the time required for killing them typically exceeded initial development time.
When Exceptions are Needed
The continual flow of new and unexpected feature requests is a strong tension that we live through every day. We can’t say “yes” to all of them, yet we can’t say “no” to all of them either. When prioritizing off roadmap functionality, we try to back things into the following three principles that are inherently coupled with the success of the business.
Keeping existing customers happy. Often, customers ask for a particular solution, but they’re trying to solve a problem with a different solution than we currently support. Occasionally, edge cases arise that we need to build against, and we prioritize these depending on urgency. Good account management goes a long way.
Acquiring new customers who will be successful. Zealous customers ask if we can do A or B, or W or Q, some of which may be more or less related to our product and roadmap. We work with larger customers, so the pressure to close deals can be high. Occasionally, we agree to build something for new clients — but only after thorough review by engineering and sales.
Staying innovative. One reason we love working at a startup is our hatred of corporate process. Innovation comes from random ideas and lunchtime inspirations that start with modest proof of concepts. We love small experiments — spend a few hours on an idea, push it to our production system, and turn it on admin-only so that we can play internally and see how we like it. Most won’t make it to a customer-facing feature, but all provide some insight into our product.
When new feature requests arrive, we try to match them against the above criteria. In some cases, we’ll realize that we just need to hunker down and build the unexpected. However, if the request doesn’t fall under any of these three buckets, we ask ourselves the question, “Do we really need to build that?” After which we punt until later, drop it in the icebox, wait until we can more thoroughly evaluate, and then get back to work.
