How to create a successful side-project: Build as a developer, Manage as a business person

  
0:00
-10:26

The road to creating the first successful startup / side-project is spiky. The reasons for you to fail are endless and the reasons to win are complex. How can you get your next big thing? And what is stopping you from achieving it as a software developer?

As a senior undergrad and aspiring entrepreneur, I created over 7 projects over the past 3 years. All of them miserably failed and lessons were learned the hard way. You don’t have to go through the same experience to learn the same lessons, here is the final summary of my 3 years journey

1 - Build and launch

This might sound trivial, but you actually need to launch. No, you don’t need the best looking product out there to be able to compete, and yes you can find people interested in your product specifically. The internet is an endless source of attention, wherever you go, there is at least 1 person that wished for a solution to a problem you are solving. If the problem you are solving isn’t a priority for the end consumer, you will know. Your project can only grow as much as you believe it can. You are the ship captain and you are the god of that little project, make it or kill it.

In my countless attempts to build a unicorn (jargon for a startup valued at at least $1B) I often never understood why my project was going to work or fail so I quit. Fun fact, soon after, people made it with the same exact idea. I often acted out of ambition, and needless to say, resilience is what gets you to success. The more you endure, the closer you get to where you want.

Before even launching your solution to a problem, think of what approach you are adopting:

Product focused approach: Your sole purpose is the product, you forget about the market because you are sure the product solves the problem for some people out there. So you strive to make the best UI/UX product out there. The initial time investment makes the approach high-risk high-reward. Personally, I’m not a big fan, if you don’t know someone who can build an optimized and off the charts UI/UX product design, maybe you want to let this one approach down. You’d be better off with having an MVP (minimal viable product) a product with core features only.

Market focused approach: This approach is the low-risk high-reward investment. You iterate crazy fast over multiple ideas and see what sticks. You can literally skip building a product, set up a landing page, and start talking to people. This approach is not easy either because it will require building your communication skills and learning how to ask questions. I recommend reading ‘The Mom Test’ for this purpose.

This approach is more secure since there is no upfront investment, and if you are building something not wanted, you’ll know it. You will for sure. On the other side, you are building a product with the community, so even though you are working on the project solo or duo, in practice you aren’t, since you get help as much as you talk to users.

2 - Build but listen

If you are building a high-end or low-end product, you want to keep talking to people. Think of it this way: You are sailing a ship at 1 in the morning, darkness is your refuge, and there is a storm. Your only way out is to look at the stars. But there are no stars! In this context, your users are your stars, no matter how much you shy away you’ll end up hurting yourself. No matter how confident you are building the right thing, you are putting your confidence into a reality check.

Some developers aren’t comfortable talking to people while others can: Fun fact, you still need to do it. And it’s only a matter of time until you realize that your end users are people like you because you are solving the problem for yourself, to begin with.

Main take away: build a rocket ship or a cookie, you still need to talk to users. Crazy how many people don’t do it and end up wasting 5 - 7 months of development (yup that’s me)

3 - Manage but learn

One of your duties as a software developer is switching hats - You didn’t sign up for this did you- One time you’ll act as the technical guru of the project and another you’ll need to make business decisions. Your project is a bottle in a sea, who will even notice it? Forget money, for the time being, no ads, no paid marketing. First, you need to build your ‘business’ skills: promote your product, look at analytics, draw correlations between features and retention, bootstrapping, etc.. You don’t need me to mention all of the problems because they are countless, and this is what’s exciting! You’ll find yourself forgetting your code and reading a huge stack of articles on how to promote your product.

Playing the business person is overwhelming, that’s why it is advised to have a cofounder. Finding one isn’t easy but doable. Sharing the tasks never exempts you from learning the business side of things but at least will lift off some pressure.

As a business person, you don’t want to be stiff, stubborn, or sensitive! If your decision is bad and someone told you, then guess what: you found a valuable member for the project. Not anyone dares to criticize a friend’s product, and the faster you acknowledge your mistakes, the faster you learn, the higher you climb toward your long-waited goal. Obviously, I’m not implying that you should always say you are wrong even if you don’t believe so.

Finally, read! Okay this is probably the best piece of information there is on this article. As cheesy as it might sound, reaaaaaaad!!!! It opens doors you never knew existed. In fact, you can play a game - what I did and had instantaneous results - curate 5 to 6 high detail articles about 1 niche topic. Read all of them and highlight what you find important. Guess what, you are now in the top 1% of your competitors in that specific niche.

If you found this article helpful share it with 1 person that you believe will learn from it, keep the flow of positivity and information going. Thank you sooooo much for reading this. Until the next time, bye :)