The MVP Myth: Why Most Founders Get It Wrong

The following post is based on a talk I gave at the 24 Hour AI Bootcamp in Tel Aviv.

The dangerous "ship fast" advice founders keep repeating

There are a bunch of really smart people throwing around really smart-sounding things that could be quite dangerous.

Reid Hoffman, co-founder of LinkedIn, likes to say: "If you're not embarrassed by your first product, you've launched too late."

Mark Zuckerberg says: "Move fast and break things."

Great soundbites. Easy to remember. But they can be detrimental if you misunderstand them.

The problem: "If you're not embarrassed by what you launched, you've launched too late" can easily be misconstrued as "I'm gonna launch a crappy product."

That's not what it means.

What a minimum viable product actually means

In really simple words, an MVP is the simplest version of your product that answers one question:

Do people want this?

Note the emphasis on simplest. Not half-baked. Not broken. Not 30 features that barely work.

An MVP does not mean launching something crappy. It means launching something simple that actually works.

Three features that delight your customers is better than thirty features that frustrate them.

MVP example: The car that doesn't move

Let me give you an example.

Say you're trying to answer the question: "Do people want to go from point A to point B?" You're testing whether transportation is a thing.

Approach #1: You build, build, build... and you ship a car. But it's an MVP, so you cut corners. It has a steering wheel. It has the body. But no wheels. No engine. And unfortunately, as a consequence, it does not move at all.

Is this a good MVP?

Of course not.

All you learn is that people don't like half-built, broken things. You never answered your actual question: Do they want to go from A to B?

Approach #2: A skateboard.

It's simple. It works. And it gets you there.

For the question "Do people want transportation?" this is a decent MVP. You learn that yes, people do want to get from A to B. Then you can iterate: skateboard to scooter, to bicycle, to motorcycle, and finally to a car.

Why the skateboard-to-car MVP example is misleading

The skateboard example is everywhere online when people talk about MVPs. It's a great visual. But it's also problematic.

Because whether an MVP is good or bad depends entirely on the question you're asking.

Let's change the question.

What if you want to build an MVP for a car specifically? You're asking: "Do people want a motorized, multi-passenger way of getting from A to B?"

Now look at that skateboard again.

It's muscle-powered. It fits one person. It goes very short distances.

For this question, the skateboard is a terrible MVP. It doesn't test any of the things you actually want to validate.

A better MVP here might be a very basic flatbed truck. Motor-powered. Carries two people. No AC, no fancy features, you're sweating in the summer. But it gets multiple people from A to B with an engine.

Simple. Works. Answers the question.

How to build an MVP that actually validates your idea

An MVP is only as good as the question you're asking.

If your MVP helps you validate that question in the simplest possible way, you're doing it right. If it doesn't, you've just built something that teaches you nothing.

The right MVP is:

• Simple: Minimal features, not maximum features that are half-done
• Focused: Tests whether there's demand for what you're specifically building
• Functional: It actually works. Don't ship things that fail.

My MVP mistakes with Glitter AI

I'm standing here lecturing you about MVPs, but I've gotten this wrong many times. Most recently at the beginning of this year.

I spent months building a feature that should have been built in a week. Personal perfectionism is a hell of a thing.

But it was worse earlier in the company's life - when I launched Glitter AI.

I built for eight months before launching. Eight months before I ever saw a customer.

The product had dozens of features. It really only needed one.

And when I "officially" launched, I found out that the login page didn't work 🤦

I went live on Product Hunt, got a bunch of traffic, and then support tickets started flooding in: "Hey, I'm trying to log in, the email isn't sending." "Hey, this is erroring out."

That's what happens when you get ahead of yourself. You build a bunch of features but don't dedicate time to perfecting the ones that matter.

Oops.

3 MVP rules every founder should follow

If you take anything from this:

1. Ship early. Don't wait one second more than necessary. Get something out there.

2. Ship simple. Three features, not thirty. Make sure those features actually answer the question: Do customers want this thing I'm building?

3. Ship something that works. An MVP does not stand for "crappy product." Test it with customers. Make it delightful. Just don't overload it with features.

---

Lectures are nice and all, but startups are messy. You're gonna go build stuff and do it wrong sometimes. That's okay.

Power through it. Learn from the process.

I'm still learning.

Frequently Asked Questions

What does MVP actually stand for?

MVP stands for Minimum Viable Product. It's the simplest version of your product that can answer the question: Do people want this? The key word is 'simplest' - not half-baked or broken, but genuinely minimal while still being functional and valuable to users.

What's wrong with the advice 'if you're not embarrassed by your MVP, you launched too late'?

The advice itself isn't wrong, but it's easy to misinterpret. People often hear this and think it means 'launch something crappy.' That's not the point. The point is to launch something simple and minimal, not something broken or half-built. Your MVP should work well - it just shouldn't have 30 features when 3 will do.

How do I know if my MVP is testing the right thing?

Before building, clearly define the question you're trying to answer. 'Do people want transportation?' requires a different MVP than 'Do people want motorized multi-passenger transportation?' Your MVP should directly test your specific hypothesis. If it doesn't address the core question you need answered, you'll learn nothing useful.

How many features should an MVP have?

There's no magic number, but think in terms of 3 features rather than 30. The features you include should be the minimum necessary to test your core hypothesis. Each feature should be polished and delightful - not half-done. It's better to have fewer features that work really well than many features that barely work.

Wait, didn't you fail to build an MVP for Glitter?

Yes. Despite giving a talk called 'How to get MVPs right,' I got it quite wrong with my own company. I spent eight months building before a single customer ever saw the product. It should have taken a week. I built dozens of features when the product really only needed one. Why? Personal perfectionism. I'm an engineer who loves building, and I got ahead of myself instead of validating the market first.

What happened when Glitter launched?

Core features of it broke. After eight months of development, on the day I launched on Product Hunt, the login page didn't work. Emails weren't sending. I started getting support tickets immediately: 'Hey, I'm trying to log in and nothing's happening.' That's what happens when you build a bunch of features but don't dedicate time to perfecting the ones that actually matter.

How do you balance coding and marketing as a solo founder?

Honestly, I don't do it well. I've been coding since I was eight years old, so I naturally get pulled into building features because I love it. Context switching is really hard for me. I avoid engaging with the market because coding is just easier. Glitter would probably be much more successful if I dedicated more time to marketing. I try to lean into my strengths by building 'marketing as code' - semi-automating marketing efforts - but it's still a struggle.

Should I be a solo founder?

My honest advice: don't. Working in a team is so much better. You have someone to bounce ideas off, someone to share the emotional weight with, someone who can cover your weaknesses. When you're stuck on a problem at 2am, having a co-founder means you're not alone. You can divide and conquer - one person focuses on product while the other handles sales. You celebrate wins together and process losses together. I ended up solo due to a past co-founder mismatch, but if I had to do it all over again, I'd find the right partner.

Why is the company called Glitter?

Because it's fun. That's it. There was no strategic reason. I just liked the name.