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:
Build a spec for yourself and decide want is needed to solve the problem (core features).
Keep a note of the other stuff and let you users tell you what they want (always look for consensus / majority).
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!
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!
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.
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
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
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
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
