The entrepreneurs’ creativity is a great asset and probably one of the reasons behind their success, along with hard work, a good network and a bit of luck amongst other things. But sometimes creativity and crazy ideas need to be controlled and focused. And when you want to build a web application, that’s when your technical partner comes in and helps. They are the voice of reason that will help you make reasonable and economically viable decisions.
What is feature selection?
It is simply the process of selecting a few core features for your project. You can choose 3, 4 or 5 features, there is no right or wrong number. The objective is simply to drill down to the basic functionalities and implement these first to give you a solid base called an MVP, Minimum Viable Product.
Once you have a solid base, you can build on it, improve it, embellish it. The beauty of the web is that you can easily and quickly release new features or adjust existing ones.
Why do you need it?
I can think of many reasons why you would want to launch an MVP instead of a complex full-featured application, but all come back to the same point: you want to be able to launch your product quickly to see if it has legs and start making money with it (with sales or fund raising). Once both conditions are fulfilled (i.e. the project is showing signs of success and you have more money), you can think about implementing some of your ‘nice-to-have’ features. It’s as simple as that.
We ran into the perfect example recently with someone who came to see us to talk about his new venture. He is an entrepreneur, a true one, with a million ideas a minute and a life dedicated to creating, launching and running his own businesses. He came to us with a new idea, a concept that he is trying to turn into reality. He has lots of ideas, great ones at that, but he is very conscious that he won’t be able to implement everything immediately. He is not even trying to. Instead, he is doing his market research, talking to potential customers and looking for a technical partner to help him understand the implications in terms of technology, time and money behind all his ideas. Now, that’s the perfect approach and that’s where we come in…
Why is your technical partner qualified for the task?
Your technical partner’s role is not to tell you how to run or grow your business. Their role is to give you technical advice and accompany you on your journey to create and launch a great product. The first obvious thing they will bring to the table is the ability to tell you how long it will take to build all these features and how much it is going to cost you. A key element when it comes to deciding which features should be included in the MVP.
Another less obvious reason is that it is often useful to bounce ideas with someone who has a knowledge of the industry but a more objective view on your project. Someone who isn’t as involved as you are and can give you a more objective opinion. So you need a technical partner who won’t be afraid of giving you an honest opinion and will do what’s best for the project, not for their own bottom line.
Let me give you another example: a client of ours, who launched their startup last year, came to us recently with a list of new features or amendments to make to their web application but a limited budget. In the list was the ability for customers to swap products. In itself, the requirement seems straightforward enough and you can easily see the added value for the customers. But it turns out that it is not that simple to implement and it would have taken at least 10 days to build, design and integrate in the current app. Besides, while talking to our client, we realised that they weren’t even sure that their customers really wanted this feature. So instead we suggested adding a simple button: ‘want to swap your products? contact us and we will arrange it for you’. That is all they need for now, for proof of concept. And if it appears that a decent amount of people get in touch, then we will add it. But for now, it’s not necessary. So their budget will be spent on more important features.
How to proceed?
In order to find what is necessary and optional for Phase 1 of your project, you can try to categorise each feature as ‘must-have’, ‘nice-to-have’ or ‘future development’.
In order to do so, here some examples of questions you should ask yourself:
– what added value does feature A bring to the application?
– if you remove feature B, will the application still make sense?
– what are you trying to achieve?
– if you could choose only 3 actions that your users can perform, what would they be?
– would users pay or pay more if you added feature C?
Once you have got a shortlist of essential features, you need to evaluate their value, i.e. what it adds to the app vs what it is going to cost to build it, because at the end of the day, every additional feature will cost you money and your budget probably isn’t unlimited (if it is, then lucky you!), so you need to keep an eye on the economic viability of your product.
Let’s look at a well-known application, Twitter, and drill down to the core features. So at the beginning there was:
– users can create an account
– users can send a tweet (text, links, pics)
– users can follow other users and view their tweets in their timeline
This would be a very basic version of the service.
Now you can add ‘nice-to-have’ and ‘future development’ features:
– users can send direct messages
– users can search tweets using tags and usernames
– users get suggestions on who to follow
– users can view and browse trending topics
– users can add a background image to their page
– users can categorise people they follow into groups
And many more because the service has massively evolved since it launched.
How do you get there? Well, by researching who your users, what their expectations and requirements are, and also by discussing with your technical partner. We, for example, offer our clients a feature selection workshop, during which we discuss the features one after the other, help to categorise them and draw a list of ‘must-have’ features. It only takes a day, sometimes two if the project is quite complex, and the client gets a curated list of requirements.
Well, next is the development phase. Build it, ship it!