4 lessons learned from my failed startup

Truthfully, this was kind of painful to write. I've published this on my blog first, but thought it could be helpful for some of you here as well!

--
I’ve read my fair share of books about building a startup. All written by successful founders or VCs, containing loads of useful advice based on actual experience. But, everytime I came across advice that contradicted my modus operandi, I disregarded it. Thinking: “I’m different than the others. This advice is not meant for me.” Fast forward almost two years and I can finally say: it was not different, and I absolutely needed to listen all that advice.

None of the mistakes I made were made for the first time. None of the lessons I learned because of them are new, or ground-breaking. But I guess I first needed to make the mistakes to learn and understand. I’m writing this hoping it will prevent someone else for having to do the same.

About the startup
I tried to solve the problem of agile teams not knowing their capacity and productivity. The idea was to build an advanced analytics platform on top of a kanban or scrum tool, where teams could easily monitor and track these metrics over time. It originated from my own frustration at work, where I wasn’t able to quickly look up these key performance indicators during a planning or retro session.

So what went wrong?
In retrospect, the biggest mistake was the order in which I did things. Only after building the MVP I saw the lack of validation for the problem I was trying to solve. I spoke with potential customers and nobody was interested in the advanced metrics I offered. The main responses were: “We’re already happy with the built-in analytics solution”, and “we don’t see how we would use this information.” That was the harsh reality after building something in the dark for over 14 months. I should have spoken with potential users about the problems they experience.

Lesson: Identify a problem, validate your assumptions, then build an MVP. Don’t get it backwards.

If you’ve read the same books as I, or follow the same people on Twitter, there is something else you would be triggered by in the previous paragraph. That also happens to be the second mistake. It took me a whopping 14 months to build the MVP*.* That’s way too long. A popular piece of startup advice is that your first working product shouldn’t take you more than three months to build. For me, this turned out to be the piece of advice I disregarded effortlessly: “I’m not a 10x engineer, you can’t expect me to build something that fast,” and the classic “but my app is far too complicated to build it in such short time.” And that last statement was kind of true. In the end I build; multiple email flows for new and leaving customers, a portal for subscription management, a design that I redesigned twice, different ways of signing up and logging in, and a lot more I thought I needed based on all the apps I was using. All without a single paying customer.

Lesson: Keep it stupidly simple. Build one feature - build it really well - and ship it.

Another factor that didn’t help to reduce the time building the MVP, was that I wanted everything to be next-gen. Only the latest and greatest. For only the best tech, builds the best products, right? No, not really. Instead of choosing the technologies I was most familiar with, I went with newer - fancier - ones without a clear need for them. MongoDB instead of MySQL, and GraphQL instead of REST. I had to learn them and struggled to get it to work. All the while thinking I would win all of this invested time back in the long run. But then I failed and I never even got the chance to win it back.

Don’t get me wrong, I’m definitely not against new technologies - in fact, I love them! But I would advice against using them while building an MVP, unless that technology itself is critical to the MVP.

Lesson: Stick with what you know. Only deviate from this when you can’t build it without that new technology.

When I was eventually finished to build the MVP, I had no clue where my customers were. I struggled with finding the people that would actually want to use it. Given I’m more a developer than a marketeer, I should have invested way more time thinking about the customer and where to find them. This made me realise I got a lot of things wrong, making it the last thing I learned before shutting down the project.

Lesson: Think about the distribution first. You shouldn’t build something you don’t know how to sell.

So, what’s next? I’m definitely trying it again. Although I failed miserably the first time, I really enjoyed the journey, met interesting people, and learned a lot from it. But next time, I will do some things differently.

If you're interested in following this, or want to leave a comment, you can find me on Twitter or here on IndieHackers!