Thread by @jensenharris

The “Minimum Viable Product” (MVP) is the most well-known, admired concept in early startup product development.

Unfortunately, MVP is often misused in a way that actually harms early-stage startups, leading them to create needlessly bad products.

4 thoughts about better MVPs:

1) MVP doesn’t automatically mean “ship a bad UI.”

The word MVP can end up being used as a battering ram against people who argue to flesh out the product design more, to make the user experience more complete.

Instead, the barebones-ness itself becomes a badge of honor.

The key misunderstood word in MVP is “viable.”

@ericries writes about this pretty clearly. Simplifying, you want to, in the quickest possible way, get to a product you can learn from and then measure if users are finding value in it. Only then should you invest more in the idea.

Here’s the thing, though: sometimes, the viability of an idea depends on it being delightful.

The actual inherent elegance of a product—and the visceral, emotional feeling people get when they use it—has a huge impact on how successful that product will be.

For some products, it’s absolutely true that good UI isn’t an important aspect of assessing product/market fit and, in those cases, definitely just do whatever’s fastest.

But in more cases than we care to admit, the choice we make to keep using a product relates to how it feels.

The difference between a delightful to-do list app that climbs the App Store charts and one that fails to attract users is not mostly defined by feature set; it’s defined by how it feels to use.

Measuring the core viability of an idea like this requires a small, polished UI.

2) What MVP actually should mean is: ship bad code.

OK, bad code is never an admirable goal in itself, but especially if you don’t know whether your idea is going to work, every moment you spend creating the perfect architecture using the most elegant tech is likely wasted work.

For most startups, focus only on what matters for MVP:

a) A user experience that gives people a sense of the true soul of your product (what it does and how it feels)

AND

b) The telemetry code needed to measure what people are doing and how they feel using your product.

Unless you are building a dev-focused product, those are the two key aspects of an MVP… not the code quality.

The actual underlying code you can always fix later. Lots of time to do that once you have customers and funding and a bigger team. 💪🏼

(And yes, do fix it then 😁)

So many early-stage startups have failed with beautiful code.

A fault-tolerant, elegantly-architected and factored repo full of wonderfully-documented code just as easily ends up deleted as the quick thing you put together that also didn't work.

MVP isn’t: bad UI, good code. 😇

3) Make sure you’re clear about what you’re validating.

As an example, consider the various “virtual assistant” scheduler bots that are all the rage right now. Several of them validated their market via contracting out assistant duties to real humans that pretended to be bots.

What did they discover? That people really like having professional assistants to schedule meetings! Market validated!

But, of course, we knew that already—there’s a reason human assistants exist in the world.

The hard part of the problem is replacing them with a computer.

When you create an MVP, be really clear about what you intend to measure/learn, and what actions you would take based on that.

If you can’t clearly state those things, then you probably aren’t ready to build an MVP at all.

Which leads me to my final thought:

4) Sometimes an MVP just isn't the right way to build.

While the MVP concept has been incredibly successful for many teams, it isn’t the only way to build software.

Not all products can be assembled from a set of small, discrete, measurable, and independent features.

Sometimes, a big step forwards requires the artistry and vision of a number of deep and interconnected features.

And many times you don’t know how the pieces come together until you’ve built some of it. The experimentation, the playing as you go, is the creative process itself.

This is a risky way to build, for sure.

If you are wrong and there’s nothing there, you could waste months (even years) of time. So, in place of MVP, figure out what are the go/no go points along the way that determine whether you should continue building in a certain direction.

It might be an intuitive sense of how all the pieces are coming together—using it with your own hands, or within the team, and realizing that you’re on to something special.

It also needs to include bringing in outside customers or advisors to use and experience as you build.

I learned from @stevesi the value of early outside feedback.

We had an opportunity many times to show early work to brilliant people like @waltmossberg and get thoughts. So often, people’s first impressions even at a very early stage matched customers’ eventual feedback.

MVP has been an incredibly influential concept for startups; it’s hard to argue with its success.

So use it for good: Build a product with soul quickly, and then validate it. But never compromise the product's soul.

And remember: MVP is not the only way to build software. 👍🏼