Often when we are building a new product we usually dream with all the features that it would have, the set of things that can be done with it and tend to imagine a lot of users using it completely in a daily basis. Unfortunately, dreams and reality are not the same and we have to be very careful with the scope of our new product unless we want to start an endless trip of development without publishing.
Over the time we have been pushed to think on MVPs and prototypes. That’s perfect and I totally agree with that vision. The problem is that some of us end confused about what should be included in that prototype.
Personally, I’ve been several times on that situation and really want to take you away from it. So take some notes of this article and let’s ship it!
Mockup your idea. Completely
As software developers, we always want to start coding as soon as possible. That’s great if it’s a test project that will never see the light, but if we want to publish our project, then we have to focus on other things first.
- Let you check and fix some user workflows before you build them.
- You can share with the team and get feedback instantly.
- As it’s just a prototype you can change as much as you want without the need to re-write the code.
- You’ll realize the real size of your product.
Ask yourself if your users will need all of that
Once your prototype is complete, it’s time to ask yourself a big question.
Do my users really need all of this?
Be honest with you and your team and think if your final users will need all those features. Most of the cases your app will be usable with half the features than you think. Of course, we are not talking about just destroying your product, we are talking about being selective and focus on those features really important for your users. Always keep in mind:
Build half a product, not a half-assed product
Some techniques used to choose between features are interviews or some basic research on the internet and other similar products. Something important to notice here is that even when other services similar to yours offer more things, you don’t necessarily need to build all that stuff, it’s better to identify and focus on the core.
Another great idea is to imagine yourself using your product and thinking in those main actions that you’ll follow to accomplish the final goal. If you don’t use some features in a basic flow, maybe those are future iterations of your app instead of initial features to be included.
Pretend that you have half the time to build it
If it’s the first time you do something like this (no one was born being an expert) you’ll probably still preserve some features just because “you like them” and don’t want to launch the product without them. Some of those features we love are nice-to-have.
Spend just a bit more time and ask you:
If I had half the time, should I include those features?
If the answer is no, please stop including them just because you love them. You’ll have time later to work and include them in your product. But concentrate on getting real instead of building a giant that will never see the light.
We hope this article is helpful for your next project. In case you want to share some experiences or techniques used in your team to select those core features, please write them in the comment box. We will be happy to hear them.
Regos Dev Studio is a product development company that builds add-ons for Jira, Confluence, and LiveChat, combined with the development of custom solutions in a variety of languages.