Build your MVP asap | #3

Friends,

Make sure you don’t miss this week’s recommended content pieces –also summarised at the end of this post: In my humble opinion, these are some of the most high-quality readings you can find as a founder on the path to product-market fit.

You’ve heard it before: Building a Minimum Viable Product (MVP) is the fastest way to start learning.

Launch quickly and iterate. Don’t create 100 surveys, interview 600 users, contact 10 competitors or work on your 13-worksheets market sizing spreadsheets.

The term MVP was coined and defined in 2001 by Frank Robinson, popularized by Eric Ries and disseminated as best practice by Y-Combinator. Nowadays, the MVP approach is accepted as the path to follow as a founder if you want to find product-market fit.

One of the core ideas of the MVP approach is to launch fast. No doubt, that’s helpful advice as many founders delay the moment of putting a first product in front of customers. There are mainly two reasons for that – summarised by Michael Seibel in this video: Being unreasonably worried about putting your embarrassingly limited product in front of users (“it’s not bad to feel the fear but it’s bad to act on it”). Being overconfident by thinking that you know what the perfect product looks like, thereby falling into the trap of developing it without early exposure to customers – “the fake Steve Jobs”.

Having worked with hundreds of founders during my time at Entrepreneur First over the last years I realised that there is another fallacy of equal importance:

Building your MVP too early.

Why is that?

Building an MVP means following an extremely limited and lean approach. It’s about weeks and not months, rigorously cutting your specs and not falling in love with what you build. The first AirBnB product was without a map view, no payments and airbeds only. Despite the focus on what’s “minimum-viable”, it’s about building the first product. The consequences of building are easily underestimated. When you start building a product, you start from a blank command screen. Once you start writing code, you start to add technical and product debt. Moreover, as soon as there is a first product, your thinking can be constrained by optimising what’s in front of you, instead of optimising towards a solution based on first principles.

Instead of building your MVP as fast as possible, you should do two things as fast as possible: Understanding your customers’ problems in-depth and executing Minimum-Viable-Tests (MVT) – only then consider building.

Understanding your customers’ problems in-depth

Your job as a startup founder is to become an expert in understanding the problem(s) you want to solve. How do you do that? By talking with potential customers in the most effective way. Succeeding with that is much easier said than done. Mainly due to three challenges:

1. Bad data: You have to cut through a lot of noise such as compliments (“I love it!”), fluff (“I usually”, “I would”, “I could”) and ideas (“I bet if you did it this way…”)

2. Incomplete picture: It’s easy to fall into the trap of thinking you’ve understood the problem but in reality, you haven’t. Prepare your interviews, conduct them exceptionally well and repeat them until you stop learning new things.

3. Confirmation bias: The questions you ask should terrify you. They could disprove what you’re researching.

How often does the problem occur? Could you walk me through all the things you’ve done before and after x? What else have you tried? Who else should I talk to? What additional motivations are there?…

Asking potential customers the right questions in the right way is not only a gold mine but probably the most important task as a pre-PMF founder. I’m not going into more details, instead recommending the best book you can find on this topic: The Mom Test by Rob Fitzpatrick.

Lenny Rachitsky, one of my favourite newsletter authors, calls this phase of your ideation journey the listening path:

He asked some of the most successful entrepreneurs from the US to share their experiences on this topic:

• Spenser Skates, founder of Amplitude (IPO’ed): “We did not talk to nearly enough. We talked to 30 different companies within a month. I should have aimed higher, like 50 companies in a month. But we talked to 30 in a month before building anything”

• Eric Glyman, founder of Ramp (unicorn): “Before we shipped a single card, we talked to over 100 finance and founder teams. We’d reach out to old YC batch-mates, or old friends who left companies and went to other companies; also the founders in the New York tech ecosystem”

• Rujul Zaparde, founder of Zip (unicorn): “We did a lot of interviews with CFOs, heads of procurement, heads of finance (I think the exact number is around 75), and over the span of two to three weeks. It really helped refine that idea. We had like 110 pages of notes or something in those two or three-ish weeks. Turns out the response rate is pretty good on LinkedIn when you just want advice. We would be like, ‘All right, we had these three ideas. These two suck, but maybe we should tweak this idea because of what these two or three people said.’ And so we’d keep honing it down, honing it down, honing it down, iterating every day.”

Executing Minimum-Viable-Tests (MVTs)

Let’s say that you’ve gained a very deep understanding of your customers’ problems. You’ve reached the limits of testing your hypotheses through interviews.

Instead of jumping into building your MVP now, I would consider following the Minimum Viable Testing approach.

An MVT does not attempt to look like the eventual product. It’s rather a specific test of an assumption that must be true for the business to succeed.

Gagan Biyani, CEO & Co-Founder of Maven and Founder of Udemy coined this concept.

Instead of trying to test everything with an MVP, you focus on one risk at a time. Think holistically – startups are a collection of risks.

1. Find your value proposition: Determine the promise of your idea. Why would users want it? What are you promising them?

2. List your risky assumptions: List the primary risks: why might this not work? What breaks your system?

3. Test the atomic unit with a focus on the primary risk: Determine whether your idea actually works. Focus only on the “atomic unit” of what you plan to sell.

For each MVT you run, you should ask yourself again: Now that I’ve proven or disproven that risk, what are other risks I should be considering and testing against? Here’s the link to the full article from Gagan.

Closing thoughts

After having interviewed two dozen of today’s most successful companies Lenny Rachitsky breaks down the journey of how successful founders came up with their ideas. There are three paths: “Past pain” (solving a large pain seen at a previous gig), “ponder & probe” (whiteboard, tinker, interview, iterate) and “Present pull” (seeing signs of pull and pivoting fully to that).

I would argue that it’s especially important to become obsessed with understanding your customers’ problems in-depth and executing MVTs when you find yourself in the second category – like the founders of Figma, Notion, Airtable, gusto or Databricks. Ponder and probe relentlessly resourceful with system and focus to create the foundation of your – hopefully at some point large & meaningful – company.

Eric Ries states that for a pre-PMF founder “everything that doesn’t lead to validated learning is waste.” I couldn’t agree more. Avoiding waste implies being deliberate when you start building your MVP.

Founder’s view: Rob from Feather

How did you come up with your startup idea?

We spent a lot of time with customers. We wanted to build in the insurance space, so we just gave people free insurance advice. We ran a few events, and even before covid to make life easy let people schedule calls with us online. We also hung around a few co-working spaces and used the communities there for feedback.

The specific idea grew over time, and it’s hard to pinpoint the exact moment, as even a year into the company we sharpened on what exactly we were doing.

How did you test your startup idea?

Once we had given maybe 50-100 in-person recommendations, we thought it was time to automate a bit. Then we went fast. We went live in literally a day with the first version of our product. It was a quick insurance recommendation for expats in Germany. Obviously, that was quite hacked together. It had tons of broken links and involved Vincent (my co-founder) sending an email (that we later automated) of a recommendation result to a user.

Fun fact: That product was around for about 2 years before we upgraded it. The hacked-together tool (about a week's work in total) was one of the longest-lasting original pieces.

What’s one piece of advice you wish you had known earlier?

You learn by doing things. If you’re unsure just do stuff. You can listen to all the podcasts you like, read all the books or blog posts, and worst of all attend generic startup events (a huge waste of time) when you should literally just be doing stuff.

They’re not all bad of course, and there can be real value there if you know exactly what you want (e.g. B2B sales, and you get to be on stage), but make sure you’re heavily biased towards action. Nothing beats action.

Three recommended content pieces

• The Mom Test by Rob Fitzpatrick

• Seven-part series of kickstarting & scaling a b2b company by Lenny Rachitsky

• The Minimum Viable Testing Process for Evaluating Startup Ideas by Gagan Biyani

Worried about missing out on the coolest events in Berlin & Munich? You should check out the FOMO newsletter of my good friend Cephas.