Tough Lessons #3: Building Things That Are Useless

Just recently I was looking forward to announcing my side project to the world. I already spent a month building it and was about to show the MVP (minimum viable product) to the initial audience. I was excited to get something out!

Before long, I learnt that what I built is useless. All I did was reinvent the wheel of something that has been done already in a much better way. It sucks to find that out, it's discouraging, and you feel like a dumbass. What's worst, it's not the first time I have done it. I keep thinking of ideas, researching them slightly, and then dive in straight into development.

Clearly, the obtuse strategy outlined above does not work well as there are way too few things that I have built that are useful and I am proud of. There must be a better way to go about choosing side projects that are worth working on.

Full story

A couple months before Christmas an idea came to make some kind of gift for my entire family. Ideally, the gift would involve some data visualization to improve my skills in that area. After some pondering on what to build, I decided to make a family tree builder.

A quick Google search revealed that there are existing family tree builders already but the two most popular ones I looked up are either too expensive or sucky. The research stopped there and I dove in right into the development (loud alarm sirens should go off here!).

I was working an extra 1-2 hours every day after my day job to make the project a reality. There were a couple false starts where I had to change my approach on how to build the project but overall it was a steady daily progress. I also collected initial data about my family members to make the tree. The only people I told about the idea were my parents and a friend. Both of them thought it's an incredible idea and were very excited.

Finally, the Christmas day comes. I am very close to finishing the MVP and am already telling my grandparents about the family tree builder and that I will show it to them tomorrow. However, they, along a couple other people express their puzzlement by saying that there are such tools already. I proudly tell them that yes, I did my research but the existing options either suck or are too expensive. They objected this by saying that they actually made a family tree already using one of the tools which worked well and was free to use.

I checked out the tool and damn they were right. It was almost exactly what I was envisioning in my own mind except it was already built and free with some limitations which are pretty generous. For those that are interested, the tool is called My Heritage. For whatever reason, when I was searching for existing family tree builders, this one did not come up at the top results. I am sure it was somewhere down the line.

Key mistakes

To prevent building something useless again, let's consider what were the key mistakes made this time.

1. Not enough research on existing offerings

Any business book will tell you to research your idea thoroughly before making the first step. Evidently, same should apply to side projects. I should have checked literally all the builders, evaluated their strengths and weaknesses and only then decided whether there is a place for my implementation as well.

2. Lack of consultation with target audience

While this project was supposed to be a surprise for my family, I secretly hoped to expand it further so that other people can use it. I definitely failed for not communicating this idea earlier to get initial feedback on the idea itself.

What I should have done is propose the idea to more people than just my parents and one friend. I should have gotten feedback at least from 5 people. I could have even secretly asked my family members for whom this tool was being built for an opinion on existing family tree builders and whether they tried using one. There was absolutely no excuse not to ask straight away.

I would just note an important point here. While feedback from others is useful, one must always be careful when deciding on whether the feedback is valid or not. Many people will simply reject your idea because they are not your target audience or they are a downers in general. However, in this case, if I heard from at least one person saying, look, such tool exists already, I use it and it's pretty good, I sure would have taken that into consideration.

3. MVP too big

I think the MVP should have been even smaller and taken 2 weeks to implement instead of 2 months. In this way, if you see that project is going nowhere, you do it much faster and waste less time.

Below you can see part of the initial MVP. It already has zoom, drag & drop, snapping and lots of other nifty features impossible to see from the picture. The MVP is way too big.

Part of the initial MVP

I should have forgotten about things like zooming, fancy drag & drop and the rest later. Furthermore, I should have made not a tree builder that others can expand but rather started with hard-coded data for initial showcase. This would have saved at least a few weeks of work already. However, the MVP would still be big enough to show others so that they can evaluate it's usefulness for them.

Checklist of steps to prevent this BS

  1. Find all existing implementations of the idea. Not just one, two or three, but all of them;
  2. Try out all the existing implementations of the idea, or those similar to that of the idea;
  3. Perform SWOT analysis on each one of them;
  4. Having performed SWOT analysis, evaluate if my product idea is actually novel and has the potential of bringing any new value.
  5. If I think it does, try to find out if the world needs it at all. If I can find 10 people from the target audience who think it would be neat if such tool existed, surely at least one of them would actually use the product once it was built.
  6. If all previous steps were completed successfully, define a completely minimal MVP. Once MVP is done, cut it down even further. Defining the scope of MVP is difficult and the process of it is something that I shall continue to refine.
  7. Once the MVP is ready, show it to the same target audience and get feedback.

I shall note that the checklist applies only if one wants to make sure that the project being worked on has the potential of becoming useful to some people. If the aim is simply to learn new skills, have fun, satisfy personal curiosity or any other reason, then the checklist is not so relevant. Having said, it's always better to build something that is useful, right?

Let's hope that this tough lesson won't be repeated and the amount of useful projects I built will only grow from now on!