How We Created a Successful MVP Without a Single Line of Code

Every product manager dreams of crafting an MVP without writing a single line of code. Our journey with ExperiRace turned that dream into reality - but success brought unexpected challenges.

Our Vision at ExperiRace

Our vision at ExperiRace was to provide live and personal video broadcasts for every athlete wherever they compete. We intended to do that by enabling people from the crowd to take videos using our mobile app, applying AI to recognize the participants in the videos, and our server would broadcast to the participants' friends and fans in a dedicated web-based personal experience. Before building anything, we wanted to discover and prove that this vision created value for people. Here's how we did it without writing a single line of code:

Our MVP Creation

1. We asked a runner we knew to be our MVP hero and booked him for a race. He was one runner out of 1000 runners in that race. 2. We asked him to create a WhatsApp group and invite 20 of his friends, family, and fans to it. He wrote to them that in a few days he would be taking part in the race, and in this chat group, they could see live updates about his run. 3. We then recruited 7 people, our MVP "crowd" videographers (the typical things startup founders' friends and family get to do), and added them to the same WhatsApp group. 4. On race day, we scattered our videographers along the race course and made sure they all knew what our runner looked like and when he was likely to pass by them. 5. When they saw our runner friend approaching, they took a video shot of him and sent it to the WhatsApp group together with the time and a "map screenshot" of where they were. 6. Fans on WhatsApp saw the updates close to real-time, and we measured how they reacted. Spoiler: it was a very lively chat group full of excitement.

We could do that for one race and one runner. Identification was easy as the videographers knew the runner, and WhatsApp did the heavy lifting of distributing the content, sending push notifications, and getting reactions from the fans.

The Enthusiastic Reception

We measured the engagement and interviewed the participants to validate our value assumption. The most important question was whether they would take part in something like this again. The runner and the fans loved it - 70% of them followed the messages live, and 35% of them reacted actively, some posting their own reactions or comments in return. They were thrilled to receive real-time updates and videos, creating a unique and engaging experience. NPS was very high, almost perfect, and although we got many comments and suggestions for improvements, everyone said they would do it again, and some, especially the runner, said they would even pay.

Falling in Love with Our MVP

Since the value signals were high, and we got such amazing reactions, we said: "That's it, all we have to do now is to make this MVP real". We believed our next step was to prove viability by making race broadcasts profitable. We focused on scaling from broadcasting 1 runner in a race, to 100 runners in a race, slicing and removing parts of the MVP one by one and automating with software in order to achieve that. However, we underestimated the importance of finding someone to own the race broadcasts. We should have paused and tested this assumption with a new MVP, but our eagerness to develop led us to prioritize feasibility and usability over business viability. Our love for the initial MVP result guided our development but also blinded us to the need for further validation.

The Mistakes We Made

1. MVP (Minimum Viable Product) is not MVB (Minimum Viable Business)

Investors care more about MVB because it shows you can create a repeatable business even with just one customer. Validate this before improving your MVP or building a product out of it. I found this MVB article from Forbes that talks about it nicely.

2. Identify the Biggest Problem to Solve

As you move forward and solve problems, you should carefully agree, what is the next biggest problem to solve. Next you should develop your MVP to figure out how to solve that problem, or create a new MVP for that purpose. You can and should have many MVPs; don't stop at the first successful one, and don't be drawn in to develop upon its success if it's not covering the end-to-end assumption tree you rely on.

3. Risky Assumptions About Customers

We took a bet and believed that if a race was profitable, someone else would want to own it and make money from it. Money is only one thing; in general, the value needs to outweigh the pain. I also discussed it here in my previous article about Navigating Product Market Fit. This bet led to a "short cut" that put us on the path to develop a profitable broadcast, before figuring out the ownership question.

4. Test Creative Business Models and GTMs

In the meantime we assumed some different business models to solve the race ownership problem: B2B, B2B2C, and even C2C. It's okay to use creative business models and GTMs, but you need to test these ideas, not just outline them on slides.

5. Resist the Urge to Over-Develop

When you love your MVP, you'll be tempted to develop a product that recreates that experience in production quality and scale. Before you do that, make sure you have MVP'ed everything that needs to be tested.

6. Self-Sufficiency is Key

Even if you've developed a lot of the product, it's still an MVP, or it still has some MVP parts if it's not fully self-served and requires behind-the-scenes magic to deliver value.

7. Focus on Business Viability Over Features

Don't get distracted by making your product "feature complete" or providing the "best experience" if you haven't yet proven it can make money.

8. Avoid "If You Build It, They Will Come" Fallacy

Make sure you can tell and test a story to see "if they come" first, and "build it" only once you validated interest and purchase intent from your customers.

Summary

Our journey recreating our MVP success at scale taught us that while it's easy to fall in love with initial success, it's crucial to stay objective and continuously validate all aspects of the business. An MVP is not just a prototype; it's a method you need to continuously use to test assumptions. Introduce and kill more MVP parts as needed to test things efficiently, and hope for failure just as much as you hope for success. In both cases, you achieve learning. This approach allows you to more quickly and efficiently test your assumptions, especially the toughest ones. By doing so, you can avoid the trap of bringing an MVP concept to life in a way that struggles to mature into a truly viable product and viable business.