Is your MVP too big?

The MVP has long been heralded as the launch of your startup journey.

You had your great idea, you scraped together resources to build it, and now you’re releasing it into the world to start getting customers and feedback.

But what actually is an MVP?

And has our definition outgrown the original intentions of the idea?

As a design and development agency, we build a lot of MVPs. And one thing always happens.

Founders want to overbuild.

And we could comply. Companies do it all the time. But what you risk by overbuilding is your cash. And startups don’t have a lot of runway, so we should save the cash (and time and customers and headache and board room kerfuffles).

One of the most popular ways to explain the process of building your MVP come byway of the illustration below by Henrik Kniberg (He’s also written a great deep dive, “Making sense of MVP (Minimum Viable Product) – and why I prefer Earliest Testable/Usable/Lovable,” here).

We live in a time when founders have access to and use amazing technology daily. And you’d want anything you build to be on par with what’s in the market. While there is a demand for quality, this can lead to building too many features that 1) you haven’t validated your customers want and 2) drain your runway on the wrong things.

If you build it, they won’t necessarily come. So how can you make sure you’re building something people actually want?

In lieu of the typical MVP, there are two things founders can pursue with laser focus before spending a dime on custom technology:

• A small idea to test

• A group of friendly users

A Small Idea to Test

And yes, we mean “a small idea to test.” Not a 5 feature product. Not a 3-year rollout plan. Just one simple thing to solve that you can put before real potential customers and get feedback on.

Kniberg named this phase your “earliest testable product.” It’s the first (and smallest) thing you can put before users to solve their problems. It’s often seen as the “skateboard” in the image above.

As you see, the earliest testable product doesn’t assume it’s a usable product (yet) - the point is to see if the core of your idea can even work and gather feedback from friendly users (more on that below) as early as possible.

Henrik discusses how Spotify did this in its early product development:

As a startup in 2006, Spotify was founded on some key assumptions – that people are happy to stream (rather than own) music, that labels and artists are willing to let people do so legally, and that fast and stable streaming is technically feasible. Remember, this was 2006 when music streaming (like Real Player) was a pretty horrible experience, and pirate-copied music was pretty much the norm. The technical part of the challenge was: “Is it even possible to make a client that streams music instantly when you hit the Play button? Is it possible to get rid of that pesky ‘Buffering’ progress bar?”

But instead of spending years building the whole product, and then finding out if the assumptions hold, the developers basically sat down and hacked up a technical prototype, put in whatever ripped music they had on their laptops, and started experimenting wildly to find ways to make playback fast and stable. The driving metric was “how many milliseconds does it take from when I press Play to when I hear the music?”. It should play pretty much instantly, and continue playing smoothly without any stuttering!

We spent an insane amount of time focusing on latency, when no one cared, because we were hell bent on making it feel like you had all the world’s music on your hard drive. Obsessing over small details can sometimes make all the difference. That’s what I believe is the biggest misunderstanding about the minimum viable product concept. That is the V in the MVP.

-Daniel Ek, co-founder and CEO

Another concept that has emerged within this phase is the “Riskiest Assumption Test.” This encourages you to solve your riskiest assumption as early as possible to validate if you’re on the right track. Martin Christensen put together a database of example tests you could pick and choose from to begin testing your assumptions.

A Group of Friendly Users

Perhaps the earliest way you can determine if you can sell to real users is to find a group of early adopters who can provide early feedback and help shape the direction of your product development.

Find those people who are experiencing the issue you’re solving, who are excited that you’re solving that problem for them, and invite them into your process. These people can direct product growth and keep you from spending time developing features they don’t need or want.

If you can sell to 20 people, you can sell to 2000 people. So find those 20 people first.

Back to Spotify,

Once they had something decent, they started testing on themselves, their family, and friends.

The initial version couldn’t be released to a wider audience, it was totally unpolished and had basically no features except the ability to find and play a few hard-coded songs, and there was no legal agreement or economic model. It was their skateboard.

But they shamelessly put the skateboard in the hands of real users – friends and family – and they quickly got the answers they needed. Yes, it was technically possible. And yes, people absolutely loved the product (or more like, what the product can become)! The hypotheses were validated! This running prototype helped convince music labels and investors and, well, the rest is history.

A Right-Sized MVP

So let’s bring all this back to the MVP… Founders can tend to focus on product perfection over testing solutions, which can lead to an overbuilt MVP.

For founders with limited budgets (We’ve never met a founder with an unlimited budget. If you know one, send them our way!), your downfall could be overbuilding what you want and not what your customers want.

If you deplete your runway building the wrong thing, where does that leave you?

Identify the smallest possible thing you can test and get that in front of friendly users who are eager for the solution you’re building.

Tweak, iterate, and continue to grow with their feedback leading the way.

Not sure if you’ve overshot your MVP design? Concerned you might waste money building the wrong thing? Schedule a call with our team and we can dive into your current needs as a business and how your tech can help you get there.