Just curious, how much of your time is spent building necessary - but seldom used - features?

Does anyone else find that a large percentage of your time is spent building functionality to support rare, yet seemingly necessary, situations?

Just as one example, you might quite quickly build a messaging system that works well and is simple and elegant, but then you may need to give users the ability to delete a conversation, delete a message, flag a message, add multiple users to a conversation, subscribe/unsubscribe to a conversation, etc., etc. 95% of users may only use the basic conversation functionality, but, for the sake of this example, perhaps all of those other features are needed.

That’s just the first example that came to mind, but I notice that a lot of the time, I can build a piece of functionality I need in X hours, but then I realize, “what if the users need to do this… or that… etc.” and then I spend 5X preparing for these rare cases. Obviously, it often makes sense to NOT build some of this extra functionality, but sometimes, it seems to be important.

Anyway, just wondering if others experience this. Perhaps there’s even a word for it. Cheers, Phil


Yep, its not uncommon and its called Scope Creep, and can literally kill an idea because you lose focus!

My tip would be at the very least list all these things down (should really create yourself a simple feature spec) then prioritise them from 1 to 100 (if you have that many), then decide what those core features should be that 80% of users would need to do the thing they need to do.

Then use your initial users to find out exactly what they do want, then introduce those other bits and pieces as you go on.

Look, it is not uncommon to build out a functionality in an app you think is awesome and everyone else thinks is awesome "I want one’, but in reality no one uses. This is called the ‘Apple Piano Effect’ - cool Apple virtual keyboard they used many aeons ago to make the devices look cool and do cool stuff, it grabbed the attention and people thought wow - amazing! But in reality not many people actually used it.

So the key thing is to:

  1. Build a spec for yourself and decide want is needed to solve the problem (core features).
  2. Keep a note of the other stuff and let you users tell you what they want (always look for consensus / majority).
  3. If its cool and others think its cool and it brings in users, think about building it if you have a plan to milk it!

Hope it helps.


Yes, I’ve definitely done this before; it’s really hard to know what to build and what to leave out in the beginning. I’m reading a book right now which discusses this called Nail It then Scale It by Nathan Furr and Paul Ahlstrom to learn more about creating what they call a “minimum feature set hypothesis” and then testing with potential customers before adding any more features. It’s really helpful!

Here is a book summary with more info as well:


Thanks to both of you. Great insights. I have definitely become very aware of scope creep and am glad it came up in this discussion, but what I’m talking about is just the fact that with many features I build, I’ve noticed is that, often, only a small number of the elements and workflows make up 90% of what I would consider core functionality, but the rest is still needed, just not very often. It’s needed in the rare case a user wants to delete something, edit something, share something, etc.

But the scope creep side of things is a closely related issue and a big one, too. I hadn’t heard of the apple piano effect - I’ll look into it.


@fayewatson excellent recommendation. Added it to my reading list.

@philnauta a good rule I try to apply is to not to responsively build features based on a single user’s request. Rather, take their initial idea and validate it other users (and to let the initiating user know that’s the case). Doing so helps validate if the feature is both valuable to a wider audience and that you are building it in a way that makes sense.

You can take a “just in time” approach to feature development. Within this approach, you sketch at a high level and embrace this mindset: "Here are some of the probable features that a user may ask for. We aren’t going to build these yet. But if user’s validate the need, then we’ll consult our sketches and incorporate the feature.

Finally, I like doing a bit of root-cause analysis with feature requests. Often, a user may suggest what they see as a solution, but it’s not solving the underlying problem. By taking a “5 Whys” approach, you can ensure you solve the right problem.

As for time balance, I find building largely follows an 80/20 rule. 80% of the product is built in half of the total time. The remaining 20% takes the other half.


I think we veered more into discussing scope creep which I like since I just listened to a Podcast about this (they have a couple of them on the topic)

More on track with what @philnauta brought up though - building a necessary feature that comes with a lot of other things you hadn’t originally thought of (how to edit, how and where to delete, if deleted how it changes other things, etc). I have definitely experienced this and have a couple of thoughts around it

  1. Great for us for thinking of User scenarios where a small added functionality is needed along with this. It will save us customer support time, bug fixing and development time in the future and usually leads to a well designed and thought out software
  2. Try to plan for these added functionalities along with the feature when scoping things out / deciding if the original new feature is worth developing in the first place
  3. As it is still a form of scope creep, it is critical to make the judgement call of what edge cases need to be fully developed for and what ones can be dealt with later. Whenever creating a feature be sure to focus on ‘What is the Goal’ of this feature - develop this first and see if people ask for the edge cases you predicted before implementing them