The app iterations that EventList went through before we shut it down.

How I forgot about Minimum Viable Product and paid the price for it.

Everyone loves talking about their successes but here’s a refreshing story of failure and learning.

Liam Bolling
StartupIU
Published in
4 min readDec 10, 2017

--

You have this amazing app idea or want to start a business that solve a problem that you think a few people have. The next step is usually to go ask people for advice; where do I get technical or business talent, do I need a lawyer, I might need a few thousand dollars, etc. Fairly quickly you’re going to run into someone who claims you should create a Minimal Viable Product, or a very rough cut attempt at validating that other people have the same problem that you have. You need to prove your market and it’s honestly the most important thing you can do.

This is a short story of how to not do that.

When my team and I were working on the first stages of EventList, it was just the beginning of a product; a barley working alpha to say the least. The algorithm for scraping events was broken and a heavy amount of time was going into technical development. It was just my friend Andrew Jones and I trying to solve a problem we experienced first hand in New York, and we didn’t even consider creating a validation test because all we wanted to do was try to build the best solution for us. We wanted to build our dream app.

We waited until we were 90% of the way to a soft launch of the product to start thinking about if other people would use it. The early stages of testing started with sending the app to a couple friends to monitor their usage and to our surprise, nobody used it.

Users glanced at the app once and a while, but according to analytics, our weekly actives were trash.

We didn’t follow the minimal viable product strategy at all and thought about market demand purely on the evidence that we felt it was needed. It’s a conflict though because sometimes the best ideas are ones where it solves a problem in the creator’s life, but we forgot that the situation that Andrew and I were in was quite unique.

One problem we ran into was wanting to see what events were happening around us in a city we knew nothing about, but using data from providers such as Facebook, Eventbrite and others who we later found out, also didn’t know much about the city. It was a massive flaw that could have avoided if we knew our customers didn’t use those services to find events in the first place.

A simple survey could have validated the concern.

Another issue might have been not understanding the market forces (competition and restricted data sources) that would eventually push us out. We didn’t own the Facebook event data, and therefore we ran into legal issues while storing them to reduce queries on Facebook’s API and merging the data with other sources while attempting to keep attribution to the main source. The event app category was also, and still is, insanely crowded with a bunch of companies who have a very small piece of the non-existent puzzle.

Why do I say a non-existent puzzle? Well an events app goal is to explore what’s happening around you and join a group of people to have some fun.

After further research, we found that the majority of people we knew didn’t do the first part of that sentence; explore what’s happening around them.

Maybe it was just our market in college, but most people seemed to stick in their routine of going to their favorite bar or theatre every weekend.

I’m getting pretty off topic but the lesson remains the same. I can’t stress enough how much MVP is true and a very high order bit in the beginning of your entrepreneurial story.

Don’t make the same mistake I did, make your customers opinions extremely important and always listen to the people around you. They might not communicate in a conventional way, so survey, ask unbiased questions and observe market movements.

Now stop reading this and get back to changing the world.

Too Long; Didn’t Read (TL;DR) Summary:

  • Our team (Martin, Cyrus, Andrew, Sam and I) built an app in a bit of a vacuum.
  • We relied too heavily on other company’s APIs.
  • Nobody used the app and we spent a lot of time on it.
  • Always check if your product is useful before putting time into it.

--

--

Liam Bolling
StartupIU

Liam Bolling is a Product Manager and startup founder with a background in tech companies such as Google and Microsoft. See more at https://www.liambolling.com