Your app idea is now cemented in your mind and that of your team. Now begins the cold war of deciding what features to include and which ones to throw in the bin. This development phase is dominated by the phrases “wouldn’t it be great if…” and “our market research suggests…”. Ideas are thrown around boardrooms like hand grenades. What starts as a discussion turns into a civil war. Tempers are frayed, egos shattered, and only a few features decided upon. This meeting was a success. That doesn’t sound, right? The more features the better right? Wrong.
Popular Opinion
You would think that having an extensive feature list would be the hallmark of a great app. This would be the popular opinion, and users do always want more. This leads to developers believing that if they want more features should be given. Such a mindset will only lead to a list of failures as long as the feature list itself.
What should be strived for is an app with only a handful of features. Each feature is carefully thought out, perfectly coded, and easily figured out by the user. Even if the app has only one feature but comes out as the perfect example of what was envisioned, then that should be regarded as a mission accomplished. There are several reasons why this ideal should be strived for. Starting with are you ready for the responsibility.
Features need to be Nurtured
Think of adopting new features like adopting a living breathing thing. The living breathing thing needs to be cared for throughout its young life. Every feature you include is no different. Throughout the development to launch you and your team responsible for those features. Would you rather be responsible for a handful of features or an entire zoo?
For every feature, it needs to be sketched out, UI developed, then coded. That is only the beginning, then comes several rounds of testing, changes to existing features. This is followed by seeing if changes need to be made to existing documentation and policies. Only now can you begin to think about the launch. This must be done for every feature. This level of engagement over a period can be draining, even for a small number of features. Long feature lists should look even more intimidating with this process in mind.
Can you manage?
Given that adding a feature is comparable to adopting a child, it must be asked if you can manage? Honesty is certainly the best policy with regards to answering this question. Apple and Google can develop feature-rich products, with some features that will rarely be used, if ever. Do you have their resources? The answer is likely no. The best course of action then would be to focus solely on doing a few things well.
When presented with the choice between 15 or three features, see if you can get away with two. This will often lead to what customers demand. While customers can provide valuable insight into what works and what doesn’t; their demands never end. Besides, they will constantly remind you of the features they want to see, and you can always think about them later.
Saying “No!” saves the Day
Even suggesting a successful meeting could be had when feelings are hurt will seem blasphemous. Some will recall in horror as ideas are shot down before they even have a chance to fly. When it comes to deciding what features are to be included that is exactly what must happen. Your team will thank you later when the app is released, and they have no additional grey hairs.
That is why saying no is so important to say to almost every feature, if not every feature, right from the beginning. In a sense, you are making the proposed feature work for inclusion into your app. Even if the proposed feature has tons of market research to back up its inclusion, treat it like the rest. By saying no, a filter is placed on the idea and only the best ideas should hope to get through.