It doesn't have to be perfect

“Just ship it!”

I used to hear these words a lot from the business folks trying to convince devs (including me) that the product is good to go. “Crazy! What are they talking about!? Development takes time! It needs testing! It needs to be thorough! It can’t be just shipped unfinished!” I would think.

I was wrong. The product definitely can be shipped unfinished. That’s because it rarely ever gets finished in the first place. There will always be bugs to fix and more features to add. Even when you tick off every single task from the backlog, your users will always come back with more suggestions. You don’t ever finish, you just decide when to step away.

Most websites and apps we interact with keep getting updates and new features. It's normal that you release a product when it’s “good enough” and then you just keep working on it. We all know it, and yet when working on your own product, it’s so hard to let go of perfectionism.

MVP hype

When developing a new product, MVP (Minimum Viable Product) is something you’ll be thinking about a lot. It is the minimum set of features required for the successful launch of your product. Thinking of Airbnb it would be everything that lets people browse, and book short-term accommodation. Nothing more. Nowadays, they offer much more, including experiences and online classes. But all of that came after they established their product.

MVP might be one of those overhyped words in the software/business conversations, but there is a reason for it. MVP lets you focus. After the initial planning phase, it should be unchangeable. If you have an idea for a great new feature, you can add it to the backlog. Don’t change the scope or you’re risking postponing the launch. I’ve personally experienced what can happen without a concrete plan and trust me, it is not something I ever want to repeat.

Hand holding a pen and drawing user journey diagrams

Sinking dreams

I used to work at a startup where we were developing a new, ambitious platform. It was one of those ”solve all your problems” cases, where we could see so much potential, we couldn't stop thinking of new ways to use it and new features to add. There was no MVP. Back then, I didn’t even know that word. We just wanted to build this app and we kept changing the plan as we went on.

As you can imagine, it didn't go well. We would often run out of money and annoy the investors with more delays. We kept thinking “this one more feature will get things going” or "this functionality will get that company interested" and so we kept adding more to it. Even after the launch, the lack of focus and constant change of direction made it extremely difficult to stay afloat. After all, even having developed an awesome product, we had no money to market it properly and gain the traction we needed to keep going.

Lesson learned. Don't spend months working on all the fancy features which will be rarely even used. Don't waste your time figuring out creative solutions for content filtering, when the initial amount of content will not even need to be filtered. Focus on what matters. Focus on what your product needs to be successful. After all, nobody will see those beautiful animations if you don’t have any users in the first place.

Love the feedback

When working on a personal side project, we don’t need to be all that concerned with how long it’s going to take. We're doing it (most of the time) for fun so obviously, we want it to be exactly how we imagined. However, if you do eventually want to publish it, it’s for the best to avoid the scope creep hellhole.

Last year I released my first indie game. It wasn’t too big, but it still took me about 2 years from the first concept to the release (and I was not working alone). Looking back, one of the biggest mistakes I made while working on this project was refusing to show it to anyone until I deemed it "good enough". Now, I’m a clinical perfectionist so "good enough" meant the game was pretty much finished when I gathered all my 2 grams of courage and shared the demo with the few people I knew would be kind to me even if the game sucked.

Three people working on a laptop together

The feedback was great, so I shared it with more people. Everyone agreed the game was good. It wasn’t perfect, of course, and there was some criticism which I had to address. The problem was that the game’s code was so convoluted at that stage, that making any bigger changes proved to be very difficult. If a small change was going to take a week of work, I had to let it go. Otherwise, I would have never released the game.

Had I asked for feedback from the very beginning, it could have been so much better! My fear of sharing unfinished work managed to sabotage the project. Also, a lot of time within those 2 years was spent on doubt, hesitation and trying to regain lost motivation. I’m pretty sure that if I had heard that positive feedback earlier on, I would have finished it much sooner.