Features: from core to bullshit

When looking at what features to build, we divide them into roughly 5 categories: core features, long tail features, BS features, checkbox features and anti-features.

Core features

These features form the heart and soul of the product. They make it clear what our vision is. All users of the product will use these all the time. Even if they’re not used by everyone, then all true fans will use them all the time (in the case of power features). If the product doesn’t have these features, it won’t shine, it won’t convey its value proposition clearly. If people aren’t convinced by the product with these features, then the vision behind our offering isn’t compelling enough and we should rethink the idea before building on.

Long tail features

Nobody will buy your product because it has these, but people might eventually leave because it doesn’t.

It does nothing to help you stand out, but people who need (or often, think they do) these features might leave or switch as competitors catch up with your main vision.

There is a very long tail list of these features, and it’s something you can add over time to improve both retention and conversions. They won’t completely make or break the product, and won’t be useful for validating your idea, so there is no need to rush these.

For example, think of how the original iPhone was revolutionary yet didn’t have copy&paste; that simply wasn’t part of what made it so special.

BS Features

As it says on the tin, these features are complete bullshit, laughable even. The product could technically do without these, but adding them helps the business in a different way, by giving it a twist or viral component which helps getting the word out.

Just like anything you write, it’s important to think of who the audience is. And the real audience of a BS feature isn’t the user; it’s an editor at CNN or a friend of the user who will tweet about it.

Spending a day on a BS feature which uses {machine learning, blockchain, chatbots, hype du jour} for no other reason so the press/investors will cover your product has a clear benefit. The product with or without the feature would otherwise be exactly as functional, but instead of being unnoticed, this version of your app does get covered or is fun enough to tell your friends about it.

The number of sales generated for Tesla because of its whoopee cushion “feature” making fart noises is >> 0.

Even better when there’s a viral component to it. We once added a “feature” to a CRUD app where you could add items by tweeting them to us, which other people then noticed. Delightfully silly and completely useless. So obviously people used it and the press wrote about it ;).

Checkbox Features

This one sits somehwere in-between “Long tail” and “BS”. The audience isn’t exactly the end-user, but you do need it to close more sales and expand your audience. It’s a category of features that is relevant for products which have decision makers who aren’t necessarily the user.

This happens often in B2B, and especially B2E (Enterprise) settings. Here, different people typically need to sign off on the approval of a product, all of them with their own ideas of what is important. The more layers are involved, the longer the Excel with “requirements” will become.

Especially if the layers involved won’t actually use the product, the feature requirements might feel strange because you know they won’t actually be used that way. They can be a hard requirement however because of the purchasing process, so your product will simply not be considered unless you can check all the boxes.

If it’s relevant for the market you are pursuing, you can decide to build these in, but in an incredibly minimalistic fashion. That way you can check the box, but nobody is going to care about it anyway. You can even make it a completely manual process. If an “Audit Log Report” is required every quarter to win a $$$ sale, you can manually query it from the DB and send it in a PDF. Boom, feature checked.


Other than the four categories above, these we need to avoid at all cost! In other words, we need to keep a not-to-do list and avoid falling in the trap of building anti-features.

An anti-feature is something we add to our product which would take it in the wrong direction. Not only does this take precious time away from building stuff that matters, but it can trade good customers and leads for an audience which is not relevant to the product.

It harms both the product and the marketing. It dilutes the vision of the product and makes it look like something it’s not. It also makes the product harder to use for your real audience.

Most often, the anti-features end up being built because a really persistent customer really “needs” it. Most likely they’re not even a customer yet, and just as likely they only think they need it.

Especially when starting out, with very little to no revenue, it can be hard to say no and tempting to build it in. Resist this, because it might turn you on a path of becoming a de-facto freelancer for individual clients and endanger your entire product.

Of course you won’t always know when something is an anti-feature. It’s tricky because some of them are easy to mistake for ‘Long tail’ features (but hardly ever for core features!). A good rule of thumb is that if you have doubts, they’re probably justified. If you keep hearing the same feature requests or complaints about the product over and over again, then you’ll learn automatically that it’s valuable enough to move to the nice-to-have Long tail list.

You can follow us on Twitter @jdvhouten and @wcools and look for #80daystartup

Read more

Work/new-life balance
Durable tech
Early user feedback
Spending time to save time
Products want to be platforms
Always be launching
Enjoying the journey
Work-life balance
Recap @ Day 59
Perils of caching
Making sense of contradictions
Trust signals
DIY javascript error logging
Taxes: an automation story
Magical thinking
Start small
High conviction, low conviction
Most deals fail

Post archive