Build half a product, not a half-assed product

Build half a product, not a half-assed product

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.

A strategy that we follow in Regos is to make a prototype in InVision or Sketch so that we can visualize the complete idea of what we want to build. It’s great for several purposes:

  • 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.

Don’t forget to check out our website, visit our Atlassian marketplace listing and our apps for LiveChat. You can also follow us on Twitter and stay tuned for updates!

Leave a Reply

Your email address will not be published. Required fields are marked *