What Is a Minimum Viable Product? Why You Should Build That First

Kyle Gawley
Kyle Gawley
Gravity Founder
What Is a Minimum Viable Product? Why You Should Build That First

One of the fastest ways to kill your startup before you even get started is attempting to build a fully-featured, all singing, all dancing product from day one.

I understand – it's easy to fall in love with your idea, and you want to show off your skills and impress your customers with the most impressive, awesome product when you launch.

This approach is insanely risky. You're taking a massive shot in the dark by trying to determine what your customers want based on your own ideas. You may end up wasting months of your time or pouring your hard-earned cash down the drain.

Nothing kills a startup faster than blowing an entire budget building a full-featured, beautiful product that nobody wants. This will kill your business before you even get started.

You might think that this doesn't apply to you because you're a developer and you have the luxury of building your product at no cost.

Do you really want to waste six months of your life working on the wrong product that nobody wants? Then have to spend another six building the right product?

Even if you're not pressed for time, nothing will kill your motivation faster than pouring your heart and soul into building the wrong product. I've wasted months of my life doing this, and it sucks!

Why SaaS Products Fail

Unless you're a psychic who can read the minds of your future customers, it's unlikely that you'll be able to build your product and accurately solve your customer's problems on the first attempt.

Building a product is like falling in love. You become infatuated with your product, but you also become blind sighted and overlook many of its faults.

You believe it's the most amazing product in the world, but your customers don't feel this way – at least not initially. They just want your product to solve their problem and make their pain go away.

It's impossible to solve your customers' problem without first understanding what their problem is.

You cannot build a product in a vacuum.

What is a Minimum Viable Product?

Instead of building a fully-fledged product from day one, a minimum viable product (MVP) is the most basic version of your product that you can build, that still solves the core problem your customers are facing.

It's almost the lazy-mans way of building a product; you're doing the bare minimum amount of work to enable you to ship something as quickly as possible and start gathering feedback from your customers.

An MVP isn't an entirely functional, all singing, all dancing product. It just needs to provide enough value for a customer to use it.

You may not even write any lines of code to create your MVP; it could be a set of wireframes or an interactive prototype built with InVision. The less time and money you can invest at this stage the better.

The goal of the MVP is to get a product into your customer's hands as FAST as possible. This enables you to test whether your product effectively solves the problem you are addressing.

You then use the feedback from this exercise to inform the next iteration of your product. This method ensures that you're building features that address your customers needs and that they will be prepared to pay for.

This way, you're reducing the amount of time and money you're risking building features by validating them in the real world, with real customers first.

I've built a lot of products over the years, and one thing I've learnt is that the first version you release to the world is rarely even close to the final product (unless you're extremely lucky).

I wasted a lot of time and money when I started by spending months of my life building products without any customer feedback and learning the painful lesson that no-one wanted them when I finally launched.

Now I test EVERY product idea with a smoke test (covered in my free downloadable guide to generating profitable SaaS ideas) followed by an MVP.

At my software agency, our customers almost always have the same flawed mindset and approach us with a full-featured product spec. The first thing we do is tear it apart and distil it down into an MVP. We build this first and help them to get the MVP into the hands of early users for feedback before we do any more development work or decide on features.

Instead of blowing a $50,000 product development budget in one shot, we split this into 4-5 sprints of $10k starting with an MVP. This ensures that the budget is spent wisely over time, developing a revenue-generating product that people want rather than throwing $50k at the wall and hoping it sticks.

Case Study: Get Invited

When I started building my second business – Get Invited – I'd learnt some harsh lessons from my first product, so the first thing we did was to build an MVP. It took less than a day to make and looked horrendous, but we pitched it to a prospective customer (Ulster University).

We weren't trying to sell the product at this point; we just wanted feedback from a real potential customer.

We received lots of criticism, feedback and ideas and then used this to inform the next iteration of Get Invited, before presenting it to our first customer again.

They were so delighted that we had used their feedback to build a product that solved their needs that they took an enormous risk and became our first customer, trusting us to sell tickets for their art festival (and handle their money).

During this festival, we sold real paid-tickets on our platform, and we received even more useful feedback from real ticket-buyers.

You can probably guess what I'm going to say next – we used that feedback to build the next version of the product.

Rinse and repeat.

The latest version of Get Invited in 2018

Had we have opted for spending six months building a full-featured ticketing system on day one with no customer input, we would have ventured down a very different and unsuccessful path.

Those initial customer discovery conversations provided insanely valuable feedback to inform our product roadmap and determine what features we should be focusing on, that would help us to secure paying customers.

My co-founder and I had the luxury of building the product ourselves at zero cost, but I still don't believe that's a good strategy; your time is precious too. You can always make more money, but you can't make more time.

If you waste six months building software that no-one wants, and then you have to spend another six months correcting your mistakes, a competitor can swoop in and grab your market.

Plus, you've just spent twelve months getting your first customer, when you could have done that in 2-4 weeks.

If you're investing your precious time or your hard earned cash into a product, make sure you're spending every penny wisely, and every decision is getting you closer to having paying customers.

The fastest, low-cost and risk mitigated way to do this is to build an MVP and then develop your product in a series of iterations that are informed by real customers (not your mom who you convinced to try your product and give you some feedback).

If you want to learn more, a great book on this subject is The Lean Startup By Eric Ries.

Download The Free SaaS Boilerplate

Build a full-stack web application using React, Tailwind, Node.js and Express.