The Lean MVP Flowchart: How to Follow the Value

Most founders think that building an MVP (Minimum Viable Product) is a time-saving strategy for getting to market. I’m here to tell you it’s more like a time-wasting strategy.

I blame the misleading word “Product”.

Question:
What’s the minimum viable thing around which you can build a company?

Hint: It’s not a “product”…

…

…

…

Answer: It’s giving a person value.

I’ve previously explained in When *Not* to Be A Lean Startup that most pre-traction startups should be laser-focused on validating desirability.

In other words: If you currently have zero users, your most likely failure mode involves having zero users forever. You should use all your strength to bust through that obstacle and proceed to the next one.

In this post, I’ll explain how to build your early-stage startup around the core of giving a person value, rather than “building a product” per se. First I’ll show you the flowcharts that startups have followed in the past and present, then I’ll propose a better flowchart that I call the “lean MVP flowchart”.

The Pre-MVP Era: ’90s and Early 2000s

In the ‘90s and early 2000s, the conventional wisdom for tech startups was that it was a step-by-step process: Raise a $5M Series A, hire a team, build a product, launch, then hopefully the market loves you and you can IPO.

You would typically have 5+ people working for 2+ years (that’s 10+ person-years) to build Version 1.0 of your software using a waterfall process:

Finally, you’d try to get users to buy it. At that point, you’d either have a hot product and be on your way to IPO, or you’d go bankrupt.

Notice that in the above two flowcharts, the arrows only flow downward. They are missing a feedback loop. That’s because if you didn’t get lots of users on the first try, you probably didn’t get to iterate much or pivot, because you’d already burned through your Series A funding.

If you wanted to iterate or pivot, you were probably better off trying to start a new company and raise money again.

So a single company would be flying blind and either take off or crash, but at least a serial entrepreneur could experience a long-term feedback loop by starting multiple companies in a row until one of them took off.

The Bloated MVP Era: 2010s to Today

Paul Graham may have invented the idea that startups should build something quick & dirty:

“Ignore issues like scalability, internationalization, and heavy-duty security … The primary function of software in a startup [is] to be a vehicle for experimenting with its own design”
— Paul Graham’s essay on lessons learned in the first Y Combinator batch, a.k.a. “Summer Founders Program”. Summer 2005.

This idea gradually spread outside of YC, and the term “Minimum Viable Product” was popularized in 2011 by Eric Ries’s seminal book, The Lean Startup.

I believe we are now in the “Bloated MVP era” because while it’s become conventional wisdom that founders should build an MVP, most founders haven’t gotten the message about how lean the MVP can really be.

Here in 2019, the typical startup’s flowchart looks something like this, based on my own experience talking to dozens of startups:

The good news about this flowchart is that there’s an actual feedback loop! Like if 3 people spend 1 year working up to the MVP launch (that’s 3 person-years), maybe they still have some runway left post-launch. So they can iterate based on user feedback, instead of just going bankrupt.

My beef with this flowchart is that when people think they’re building their “MVP”, it’s really a bloated MVP. It’s way too labor-intensive, and the set of features it has is never “minimal” with respect to a specific value prop story.

See that diamond that says “Anyone getting value out of it?” I literally mean, is anyone getting value out of it, or do you have zero users?

Get One User

In my experience, over 80% of startups that “launch” something get zero users. So it shouldn’t take 3 person-years to answer the question of whether you’ll ever get one user. That question is too critical. You need to answer it earlier.

Quick, what’s the first thing any startup should do? “Build an MVP” is the mental image that comes to mind, but “Get One User” is a better answer. Here’s an example of how this advice affects your decisionmaking:

Let’s say you’re picking the logo and color scheme for your MVP. By now, everyone knows you shouldn’t go too crazy on it — it is an MVP after all. But I don’t think the conventional wisdom goes far enough. I would say don’t even have a logo until you first get one user.

You could argue that having a nice logo, or a nice UX, can get you 10% more users sticking around. But is having a logo going to make a difference as to whether you get one user? No. If you have zero users, then getting 10% more users is still zero users.

The Lean MVP Era: Starts now!

If you’re truly obsessed with getting one user — and you should be — then your flowchart will look like this. I call this the lean MVP flowchart:

I define a lean MVP as “that which gives value to one person”, or equivalently, “that which validates a value prop story”. A lean MVP typically shouldn’t be a product per se. It should be a demonstration of creating value.

(It would be confusing for “lean MVP” to stand for “lean minimum viable product” because it often shouldn’t be a product. So I’ll say that it stands for “lean minimum viable process”, where the process may be any kind of product, service, or manual founder effort.)

I honestly believe that most pre-traction startups would do better if the founders hung this flowchart up on their wall and followed it.

The motto for this flowchart is: Follow the value. It means you should pick what to work on using a greedy algorithm that always seeks to increase the amount of value you give people at the fastest possible rate.

How to follow the value

Case Study: A Marketplace for Going On Outdoor Adventures

I advised a company that was building a marketplace for going on outdoor adventures. The founders showed me the mockups for their (bloated) MVP and said it was almost code-complete, and they’d already cut tons of features so as to only launch something “simple”.

The mockup showed a user browsing through various types of possible adventures: hiking, skiing, skydiving, hot air ballooning, etc.

Their plan was to finish up and launch in another couple months.

I asked if they have one user yet? They didn’t — after all, their “product” wasn’t even “launched”, so of course not.

I said, “Let’s step back and follow the value. You want to give people value by making it easy for them to go on fun outdoor adventures, right? Do you know a specific person who might want to go on an outdoor adventure next week, maybe a friend of a friend?”

The founders sent out a bunch of Facebook messages and came back to me with a list of five specific people who said they were interested.

I said “great, don’t write any more code or even bother putting up a website until you’ve given value to these five people”.

They looked at me a little skeptical.

“Also, don’t bother connecting them to any third-party adventure guides. Just lead their adventures yourself.”

The founders had been envisioning a marketplace where people could connect with thousands of different “adventure guides”. But instead of trying to “be faithful to their vision”, I felt strongly that the best order of operations would emerge by following the value.

Their number of people who had value was zero, and it could be five. That’s a big win. Take that win and go from there.

So they did. They went on a backpacking trip and even an African safari. They learned a lot about what their users wanted, much more than by sitting in a room coding a UI mockup.

Based on their learnings, they decided to stop working on the idea. They never finished coding up their previous concept of what their “MVP” would be. That means I saved them each two months of their life. I did a good deed.

So should we do everything manually, like make ourselves consultants?

Yes, a manual consulting-type process is probably the quickest way to give value to one person, which is your #1 goal. It’s probably also the quickest way to give value to five people.

So when you only have a few users, my advice to follow the value turns into Paul Graham’s advice to do things that don’t scale.

When you start getting lots of users, you won’t have time to help them all manually yourself. But you should try, and see exactly where your breaking point is. If you’re efficient enough, you might be able to juggle 10 or even 50 clients at a time by a purely manual process.

You might think “surely by the time I have 50 clients I need to get this thing automated”. But don’t sell yourself short. There’s not a discrete jump from “manual work” to “automation”, as most people seem to think. You can gradually augment or streamline your manual process to make yourself 10%, then 50%, then 90%, then 99% more efficient. Eventually, it’ll be like you’re a cyborg who is “manually” servicing thousands of users.

When should we raise money?

Most founders mistakenly think of fundraising, like building a product, as something that needs to be done at the beginning of the startup flowchart.

Let’s follow the value. Do you need to fundraise to be able to give one person value? Probably not.

As a rule of thumb, it’s usually best to focus on showing that you’re giving real people value, even just 1–10 of them, before seeking to fundraise. Until that point, you yourself shouldn’t be convinced yet that your idea is any good.

From my perspective, it’s usually a red flag if a founder is thinking about raising money when there’s still doubt that they’ll ever create value for even one user.

Yes, This Applies To Your Startup

If you’re a startup founder working on a bloated MVP, you’ll probably read this article and think: “This is pretty insightful stuff, it just doesn’t apply to my startup.”

There are many reasons why your brain will tempt you down the Bloated MVP path:

• Value Prop Blindness: You don’t really understand what problem you’re solving, and you don’t realize how important it is to pass this sanity check before building anything
• Cargo Culting: You want to build up your self-image as a “founder”, and you have a mental image of founders building products, so you set out to build a product
• Social Permissivity: The startup community hasn’t yet picked up on the idea that a Minimum Viable Product typically shouldn’t be an actual product, so you get to plow ahead in the wrong direction without feeling socially pressured by your startup-peers to course correct until it’s too late
• Sense of Control: Working on product design and engineering makes you feel (wrongly) like you know what you’re doing and you’re making tangible progress
• Fun: Product design is fun. Engineering is also fun.

Imagine you were back in 2004, the pre-MVP era. You’d probably envision a startup as a big project that requires 10 person-years. If someone explained “Lean Startup” methodology to you, it would be tempting to blow them off and go back to your 10-person-year project.

In that scenario, would you be enough of an independent thinker to be like, “ok you’re right, we should make sure to get some Validated Learning this month so we’re not flying blind”?

That’s basically your scenario now — I’m asking you to shift your perspective to better understand what Paul Graham, Eric Ries, and others have been preaching all along.

Successful MVPs Were Leaner Than You Think

Magic

Magic (YC W15) began as an exercise in taking YC’s motto, “Make Something People Want”, literally. Their MVP was a phone number that you could text any request to, from burgers to flight bookings, and they’d make it happen.

How did they avoid the temptation of a bloated MVP to become supremely lean?

It’s actually because they applied to YC with a different idea, and they gave up on it a couple weeks before Demo Day, and needed to rush something else out the door. Luckily, rushing your lean MVP is generally what you should do!

Stripe

Okay, that’s one whimsical example, but how about a real heavyweight company like Stripe (YC S10)? Surely Stripe’s lean MVP should get to be a product?

Nope. In the early days, if you registered for a Stripe account, Stripe’s founders would work behind the scenes to manually fill out and mail the required paperwork to register you as a payment processor. Manually filling out paperwork was more than good enough for Stripe to Give Value to Ten People. It would have been overkill for Stripe to do it any other way until at least the Give Value to 100 People step.

Conclusion

The “Lean Startup” movement has been a hugely successful paradigm shift, but the old paradigm got stuck halfway shifted.

The term “Minimum Viable Product” has misled thousands of entrepreneurs into thinking that the first thing they should do is build a product. They painstakingly go to work on a bloated MVP, during which time it’s uncertain if they’ll ever get even one user. Their feedback loop is sluggish; they’re flying blind until they launch.

The lean MVP flowchart presented here, and the “follow the value” algorithm, will save you from building a bloated MVP, and efficiently guide you toward product-market fit.