Beware The Checkbox Feature

A component that doesn't have direct customer value — that's how I define a checkbox feature. You see, there is some list, put together by someone involved with the organization doing the software development, filled with vague, must-have features. The urgency with which these features actually need to be developed is non-existent, outside of this arbitrary list. The acceptance criteria, for having completed any of these features? You get to check the little box beside the list item. While not exactly useful, to anyone really, this checklist of capabilities looks darn impressive when used in a sales or marketing context. The inherent problem is that these features don't really solve a specific customer-facing problem. A given checkbox feature may be enough to get your foot in the door, but you also need to be aware of side-effects.

Any software feature can range in size and scope from something huge, to something trivial and minor. Depending on the nature of the feature in question, the impact on the system it might have varies too. For example, a feature could be deemed large simply due to the number of UI screens involved, the number of new backend validation facilities required, and the number of corresponding unit tests needed to validate that everything works. This is a large feature simply due to the programming effort involved. There's not a ton of risk. But, something seemingly small, as in there isn't much effort in terms of programming, could be catastrophic if wrong. For example, swapping out a different piece of technology that has a similar interface. This latter checkbox is a scary one, because it seems it happens all too often, and for all the wrong reasons. We want to advertise that our system is implemented using technology A for reasons B, C, and D. There's no real harm in making this change if the reasons for checking the item off the list are compelling enough. Checkbox features usually aren't compelling enough, especially when it comes to making changes to implementation technology.

There is a tight correlation between getting the development team to work on these types of technology-based checkbox features, and trendiness. You obviously want modern technology, something that's being used, successfully, by other firms today. This is perfectly valid as far as I'm concerned. You need to attract developers who have relevant skills, you want to utilize other components that are actively developed, open source or otherwise. You simply have a hard time doing that when you're using ancient software. Ancient is a relative term, and things become ancient really quickly in software. But, there is an obvious difference between something that accumulates dust, and something that poses a real threat to the success of the organization.

Users breed checkbox features, just as much as development firms do. Generally for the same reasons, too. We might even call checkbox features, me-too features. This other guy is using software that has feature X, and so I want it. I need it. This might even make sense, to a degree. If your competition is offering up the ability to upload unlimited image data, you had better find a way to do it. The trouble comes when the users blindly seek out these me-too features for the sake of copying the competition. You've now met the minimum requirement, but, the other guys were there first. What makes your feature stand out? A checklist of features that a given system doesn't yet have is a good starting point in figuring out the future direction of the software. The checkbox feature is a good input into the brainstorming sessions that ultimately take these rudimentary ideas about what the software has to do, and turns them into the next killer feature. Checkbox features are the exact opposite of killer features — they kill the software if they're not expanded into something valuable. Something the user craves.

If you look at a particular product domain, they do share the same set of primitive checkbox features. Mind you, these are loosely considered features, and more like essential traits that qualify the type of software. This is just the starting point. Because, you have to start somewhere. Killer features don't just pop into existence, but rather, morph from a me-too feature taken from a checklist into something that thrills users to no end. This is a long process, and I managed to condense it into just so many words. Probably these do not even fit into the release scale, but more like the many-year scale. It takes time for software to develop character, something the users are familiar with, and can call home. Usually because they played a role in defining what the software is today, as an active participant in the evolution of one or more features.

Can a killer feature grow out of something mundane, found on the checklists of every competitor out there? Absolutely. Just being first doesn't grant you exclusive rights to be the best thing in the world forever. Other development shops will catch up. They will exceed what was your bread and butter, and you only need to sit back and watch it happen if you don't believe me. The alternative is to do something about it, but what?

The short answer, don't maintain checkbox features, go out of your way to identify, and change them. You'll have to first identify that you're either writing a me-too feature straight from the get-go, or that something you've had around for a long while has grown stale. It was once glorious, you users praised its awesomeness, but now it's just OK. Furthermore, the other firm has this product that does this thing, and that other new thing, so, see ya. And so the cycle begins for you all over again. You have to take a look at what the competition is doing, and copy it. At least as a starting input to the product roadmap going forward. If you're to have any hope of retaining our users and acquire new ones, you'll need to figure out where all the checkbox features are, and what you can do to exceed them in some small way.

Checkbox features are a tool, not an end result you want to sell to customers. Let all the other vendors compete and establish a checklist for you. They're competing, successfully, as they have customers. And with that, you have a baseline. You can then go on from here to create a better checklist, one specific to your own unique brand of software. This checklist isn't something you just put together with some marketing people because it's what you need to compete. You make a list of killer features, the result of hard work and deliberation. The checkbox feature can churn out mediocre software, or, it can be used as a tool, to consistently produce software that goes above and beyond.