How do you choose what features to build?

Shavin Peiries May 18, 2021 1 min read

May 18, 2021

I soft-launched Idea Bakery with a login flow that included a username and password. The intention of the app was to be used by independent creators who use Twitter.

The starting point of this app was a little convoluted in hindsight. I had used the base of it from a tutorial on GoRails. Following that tutorial made it possible for me to implement the idea I had in mind. But using it as a base carried some baggage over to the next work cycle.

The tutorial had features like allowing for multiple Twitter accounts to be added & managed. But the questions on my mind was whether it was necessary for the people I am trying to serve? And was this complexity worth working on right now?

Presently, I can only assume that it would be helpful. So why not build it, right? It sounds useful. But would the added complexity be worth it?

Building an unvalidated feature on top of a partially validated concept leads to complexity. In addition, features carry baggage if it is dependent on other parts of the system.

Taking the time to work on it would also mean sacrificing time to work on something that does move the needle.

Customer centricity is challenging to practice. There are many moving parts, and when it comes to building, it gets even more difficult because you're in the trenches making micro-decisions that will impact the customer.

It's better to plan your work before you start building. Ideally, as a pitch, outlining the motivation to make it, when you will ship it by and what the solution is. It gives you the tent poles to make trade-offs such as the one above. And to focus on what's important.

However, in all cases, do what is in the planned work. Then, let the future version of yourself worry about whether multiple accounts are valuable if customers say so. Then, you'll have more data to make a better decision anyway!