Too many times I have found myself at a point of developing a side project, where I had lost all the joy I initially felt while coming up with ideas, drafts, designs and potentially even prototypes — just because too much time had passed since the first steps. And that's not even taking into account the weeks of procrastination after buying a fancy domain and before starting actual work. If this resonates with you, maybe I can share some knowledge on how I'm trying to avoid this habit by changing my mindset about how I work on projects and products without ending up switching to some other activity that's more fun. Ideally, everybody should see their level of enjoyment and progress going from 📉 to 📈 by adopting the following ideas.
If you analyze my previous blog posts you can very easily observe the aforementioned problem: It's not purely coincidental that most of my published (and finished) projects include small tools that I was able to finish in just a few hours or days. While this could look like I just didn't try working on bigger projects, it's actually part of a bigger story, a story where I'm eager on starting a big new side project, envision using fancy tools and technologies, and end up with building the same stuff over and over again, just to lose interest and discard a project without even having gotten to the idea's core.
This is the fundamental point I'll focus on in this post: The early stages of side projects. While you might start off creating a new side project with as much vigor as you possibly can, chances are that this motivation will decrease over time. This could be due to lacking results or incentives you failed to generate over the course of building the foundation of what you want to achieve, or just a natural cause of keeping up a creative process over a long period of time. Out of this experience, I have changed a few things, many of which can be found in the principles of Lean startups. Actually, the development of a side project is very similar to building a startup, both endeavors include having limited resources like time and money, often accompanied by the uncertainty of success.
This is actually the most important step of product development, since every following decision will be based on it: Before you start any further work like setting up development environments or meeting other prerequisites, you have to be fairly certain about what your final product should look like, which basic features it should contain, and so on. This doesn't mean that you should know the outcome of every technical or business decision in advance, but should rather guide as a baseline for building your initial prototype or Minimum Viable Product (MVP).
This mostly applies to projects where you are able to spend limited resources on building a limited version of your product that only contains the fundamental functionality. The result doesn't have to be perfect at all, it merely acts as the first milestone towards your vision of the final product. While developing the prototype, you're often able to gain useful insights to confirm or discard assumptions you've made in first drafts. This task was the primary point of failure for me all along: Because I focused on building everything but the actual functionality and spent my time on setting up account systems and routing, fancy signup confirmations and infrastructure-related tooling, I completely missed the point of starting off my development with a simple prototype to check if my vision was technically possible and what it needed to become reality. I think of this flawed workflow as the irrelevant-bottom-up approach, whereas the preferred solution should be to start with nothing except your MVP and iterate over important features at first, followed by chores.
Once you have built your MVP, you find yourself in a situation where some of your targeted features are already built (possibly in a very hacky way). Although this might discourage you because you still have a long way to go before being able to ship a result, you've done the most important step. Building new features will be easier from now on, you will notice that you're moving faster every iteration until you've completed every task. As magical as this sounds, this is completely predictable and depends on your ability to create actionable tasks. Without planning and organizing product development, you will find yourself having a hard time. Especially in the context of side projects, when your availability and resources are somewhat limited, you will benefit from a structured approach, for larger projects this is required to keep up the pace. Not only are clearly defined task scopes helpful for general-purpose organization, but they also help you enjoy the moment once you finish a task and get to see real results.
This marks the end for the series' first post and although it was almost 0% technical, I really enjoyed writing about a different topic I had on my mind for the last weeks. Hopefully, you were able to pull out some information for yourself, if you've got questions or suggestions let me know by sending a mail 👍