How to think about your MVP (and how not to)

By Vineet Thanedar

So you have an idea. A problem you think technology can solve. A software startup you think has potential to disrupt a market.

You understand the first step is building something called an MVP.

What is this MVP thing?

The Minimum Viable Product or MVP as it’s popularly known is the first step in bringing your idea and product to market.

For the scope of this essay, I’ll assume that your idea, the pain point you’ve identified, needs an MVP in the form of a software product - a web or a mobile app.

An MVP doesn’t need to be in the form of a new software app though. An MVP is first and foremost a proof of concept or prototype to test your hypothesis.

It could be a series of sketches and design mocks, a no/low-code janky prototype, or a solution that involves humans doing things manually at the other end – something that has the potential to validate your hypothesis and de-risk what you’ll do next.

Think of the MVP as the most effective early channel to put your solution (that solves a real problem) in the hands of early potential customers.

Let’s assume though that your MVP requires new software, built from the ground up.

This can be a powerful thing when done right. In my experience, sadly, it is also something that most inexperienced (or misguided) founders and startup teams miss the mark on.

What could go wrong?

Over the past fifteen years, I have built or led the development of the first version of at least a dozen products. Some were small in scope and took only a couple of weeks, others were on the larger side and took a few months. 

I saw that most MVPs go astray in one of two ways:

1) You build the wrong thing based on incorrect assumptions.

Though not obvious at first, this is actually good news. You'll discover what your customer actually wants. This will bring you one step closer to building what they want-- so long as you don't commit the second mistake.

2) You took too long, over-complicated, over-engineered, and over-thought the MVP.

This is often a serious error of judgment.

But why would we ever do that!

Of course. No one starts out by thinking that they will over-complicate their solution and spend far too long building it. Intentions, spirits, and thinking are often well placed in the beginning. 

But it is surprisingly more common than you could imagine. Of all the unforced errors teams make, this one likely ranks right at the top.

In my experience, there are two things that derail MVPs:

1) not thinking through what's truly important in the first version and 

2) having a team that doesn't understand trade-offs.

The first has to do with product discovery, the second with engineering.

Scope and Simplicity do not go hand in hand.

The first version of your product needs to answer one, and only one question -- are we solving the right problem? I don't need to stress the reason for why this is important. What does matter is getting to this answer as quickly as possible.

And how do you get to this quickly? It starts with getting the scope and simplicity right. Most founders and teams commit the cardinal sin of thinking that more features = better. More features = my product will be more liked. More = my product will be more quickly adopted.

The truth couldn't be further from this.

The key to building an effective MVP is to keep the scope tight and leave the crap (pardon my French) out. This is easier said than done. The temptation is to add, but the instinct should be to subtract.

Note that this is not a license to build something that comes across as unfinished. Minimum viable does not mean half-assed. Build a functioning car without bells and whistles, not a chassis on four wheels with no steering (no self-driving here). Put another way, we don't sacrifice quality and completeness at the altar of the MVP.

Getting the scope right is an exercise in restraint. We must plan and measure twice but cut once.

How do you actually do this? Think not of features, but of the capabilities the product absolutely needs to have. Think about the problems the user wants solved. Everything else is fluff. A waste of time and money. 

I’d go as far as to exhort you to think in singular terms – problem, not problems. The MVP should attempt to solve one problem, one pain point that the end user has. And do it really, really well.

Trade-offs are your friend.

Now let’s talk about the second problem we discussed earlier -- over-engineering and over-building.

For most products, your MVP should take somewhere in the order of two to six weeks from start to finish. I say most, not all. There are few hypotheses that can’t be proven with something that is built in under two months.

By and large, this timeframe is sufficient to build a viable, and dare I say, delightful product experience. But only if your team understands the trade-offs it needs to make.

The figure below will illustrate the trade-offs for you.

Scope is what the product does.

Cost to build is, well, self-explanatory.

Time to market is how long it’ll take to build it.

This is a well known concept in software development. Yet many get it wrong.

You never get all three of these. Life is such. You have to pick two, and you must prioritize the two you pick, at every opportunity.

This discipline is hard and it is where most teams falter.

You can’t have everything you want in your MVP, have it cost less, and have it be built faster.

So what do you do?

My personal leaning is generally towards keeping the scope and the timeline tight. This automatically brings down the cost. A short time to market has the added benefit of getting your solution in the hands of your customer early. This gets you feedback early, which in turn helps you understand what you need to change or improve. Rinse and repeat this process ad nauseam. This iterative flywheel is extremely important so you zoom in on building something that will eventually find product/market fit.

In conclusion

Building your MVP is part art, part science. It is a process of a hundred little tradeoffs and applying good judgment at every step. This applies to your initial MVP but also to the constant iterations and tweaks that you’ll make to your product as you understand the needs and pain points of your customers better.

So my recommendation to non technical or first time founders often is – don’t burn all your capital and energy on the MVP. The MVP is just the beginning. It’s not version 1.0. It’s version 0.1.

If you survive out of the gates, and keep learning what your customers want, you will survive long enough to build the future you envisioned and more.

About the author

Vineet Thanedar has been invited to contribute to the grIP Brief as a “Friend of grIP”. Vineet has been building software for the past twenty years. Over the course of this time, he has built, led the development of, or helped bring to market over a dozen new and innovative software products. He has significant experience in building software products from the ground up and more generally, the zero to one stage of startups.

Vineet currently runs Version One Labs, a software development studio and consultancy that builds customer-facing and internal software products for founders, early stage startups, and tech enabled traditional businesses.

Prior to Version One Labs, Vineet was Co-founder and Head of Product and Engineering at Oncue, a venture-backed startup that serves the moving industry. He previously also co-founded a consumer social app, and led software engineering at Crunchbase, the well known database and platform of startups and financings. He started his career as an engineer at Qualcomm. Vineet has a Masters and Bachelors degree in Computer Science.