The true cost of adding features (and why it's my job to say no)

Over the past twenty years as a developer, barely a day has passed when I have not had a request for a new feature.

Our software is already feature-rich, but we have a regular stream of "Can you just add..." and "Why haven't you done this..." questions which we welcome with open arms. We even have a dedicated area for it on our community.

We love that our customers take the time to put their ideas to us. But almost always, my initial thought is "no".

I realise this sounds sacrilegious in today's customer-first mindset, but as development director, it really is my job to say no.

And here's why.

"Each time you say yes to a feature, you're adopting a child." - 37Signals

Raising kids is expensive, and software is no different.

Technical Debt

When you add a feature, you also have to support and maintain it throughout the lifecycle of the product. You need to factor in the cost of adding the code, internal QA testing, public testing, knowledge base updates, bug fixes, support, and so on.

In addition to that technical debt, every new feature creates a feature-loop where customers will ask for more features on top of the new feature, which demands more attention from customer service and developers.

This cycle repeats itself for every major version release. You can quite quickly end up supporting a feature that doesn't fit with the vision for your application because no one likes it when you take features away.

As a homeowner, I'm always tempted by simple tasks I can do to improve my home.

"Let's just add an extra electrical outlet to that wall," I think. It's a simple suggestion, and the benefits are apparent. It's rare to find a modern home that couldn't do with a few more electrical outlets for our growing collection of chargers.

You might already be mentally getting into the car to visit your local home improvement store.

Before you turn the ignition key, let's think it through. To install a new outlet, you'll need to consider the current load on your existing circuits. Do you need to add a new circuit breaker? You might find yourself reworking a lot of existing cabling.

To do a neat job, you'll need to make holes in plasterboard or channel out plaster to hide the cables before redecorating. You will want to consider the placement to make sure the outlet is in a useful position. Will it still be useful if you move furniture around?

One the outlet is in place; you'll need to test it regularly and replace it if it gets broken.

If your home improvement skills are like mine, you'd have lost interest in this idea by now.

Weighing up the feature against the cost almost always makes you reconsider.

We've certainly taken a few missteps along the way.

I was recently reminded that for a short while we added a "threaded" mode to our community platform. A long while ago, we had a lot of requests for this when a competitor folded. A less disciplined version of ourselves shrugged and set about implementing it. After all, it was a popular request, and we were keen to please.

The feature itself was rudimentary. It never wholly aligned with the principles of our application and felt slightly out of place. We expected a standing ovation, but it was largely ignored.

The technical debt was enormous. It was a complicated portion of code that confused almost all our of development team. It was riddled with bugs and caused a significant increase in support requests. We kept it alive for a few more iterations by adjusting the UI to make it less obvious the threaded mode existed before eventually killing it.

We should never have added that feature because it didn't fit the vision for our application and the technical debt for reward ratio was severely skewed.

We also greatly inconvenienced the handful of customers and ultimately their members by removing it.

Eventually, we learned that while our customers were asking for a threaded mode, they didn't really WANT a threaded mode. They were telling us their users were struggling after they migrated. They naturally felt that if they emulated their previous software that their members would be happy again. This wasn't the case. We looked at how new members were onboarded and made adjustments there, which had a more significant impact.

Our biggest misstep was spending 18 months creating a new application that would take us into a brand new market. We eventually pulled it completely, but that's another story.

We only implement half of the feature

We never half-ass something, but we frequently half-implement it. As I write this, I'm procrastinating from finishing a major new feature. I have hundreds of ideas for this feature, but I've only implemented the essential functionality to add more in future releases.

"Steve Jobs gave a small private presentation about the iTunes Music Store. People kept raising their hand saying, "Does it do [x]?", "Do you plan to add [y]?". Finally, Jobs said, "Wait wait – put your hands down. Listen: I know you have a thousand ideas for all the cool features iTunes could have. So do we. But we don't want a thousand features. That would be ugly. Innovation is not about saying yes to everything. It's about saying NO to all but the most crucial features." -Derek Sivers

Working iteratively allows us to bring a feature to market quickly and gather feedback and make informed decisions about adding more functionality.

Some features that we have ideas for die on the vine, and sometimes they get taken into brand new directions we couldn't have thought of when our customers make use of them.

When we say yes

Of course, just because the first reaction is 'no', it doesn't mean that we ignore all customer requests.

Occasionally we have a lightning strike moment where we take a customers idea and implement it almost exactly. More often than not a single theme bubbles up regularly in our feedback forum.

A common issue for communities is converting casual readers into contributing members.

We recently had a lot of suggestions in this area. We had ideas posted for boxes with "Sign Up" messages, or a short registration form embedded where the reply box would go and so on.

We said no to each of those, but kept the core issue in our minds.

Our solution was "post before registering" which allows visitors to post a reply to an existing topic. Once they submit their post, they are taken through an onboarding process to sign them up. The idea is that they have a stake in signing up as they have already invested time writing the post.

By saying no to the individual suggestions, but being receptive to the repeated requests for "something" to improve conversion, we came up with a new novel feature.

Getting the feature through the kill-zone

Every single feature that we've shipped has been through a rigorous process to ensure that it is viable and that the technical debt to benefit ratio is positive.

From the original idea to execution is the kill-zone. Most feature ideas don't make it.

Everyone in the company is receptive to new ideas. We read everything in our feedback channels. If we find a recurring theme we want to develop further, it gets posted on our Slack channel for peer-review.

This is the kill-zone. Our developers, sales teams and support teams question the feature and probe angles to ensure it is robust and fits well within our current vision.

Key areas we look at are:

• The ratio of technical debt to reward

• Time to develop the essential features

• Impact on existing code and frameworks

• Impact to support teams

• Maintenance requirements

• Feature-loop potential

• Potential customer overwhelm

• Does it drive the product forward?

If it survives (and they mostly do not; the ones that do are often transformed into new ideas) then it makes it to a pending list.

And then we do nothing for a while.

That burning desire for a feature almost always cools after a few days allowing us to review it without bias.

When it's time to start planning a new release, we pull these feature ideas from the list and begin to craft various themes (notification improvements, UI updates, engagement improvements).

This allows bad ideas to be exposed quickly. Internally, we have a phrase for this: "Mexican lunch".

Mexican Lunch

A few years ago, Charles was over in the UK, and we had an in-person team meeting. Even though most of our team are based remotely, we do meet up regularly.

Charles and I left the team for some business planning, and we chose a Mexican restaurant to lunch at. During this meeting (and it's possible we had a drink or two) we came up with a fantastic idea to improve search.

Our excitement built as we discussed the idea, and we were very impressed with ourselves.

We returned to our team and told them we had this great idea. They glanced up from their MacBooks for a second and our eyes locked.

This great idea evaporated as we tried to explain it. The more we walked our team through it, the worse it sounded.

The idea died in record time.

Now we refer to some ideas as a "Mexican lunch"; they sound great until you probe them even gently.

"Ideas are cheap; execution is everything." Chris Sacca

We love listening to our customers and receiving their feedback and feature ideas. We greatly appreciate the time taken to visit our community and write up their ideas.

Speaking with our customers daily is a highlight, and we never forget the privilege we have in reaching so many people.

All our stakeholders want the very best from our product, and sometimes that means saying no.