Modern continuous delivery methods demand the use of hypotheses, not requirements, to deliver what customers want. Startups and developers should embrace continuous experimentation and adaption right from the start. So thinking and researching MVPs and writing this down as the closest I could get to define an MVP process or startup process.

First, you should have a hypothesis, you don’t really build something because you can but you want to know what is the right thing to build, what do my customers care about? Also aim to have a tight and measurable hypothesis that's clear and defined.

Then you want to build this, and ideally, you want to build the minimum possible to disprove that hypothesis, if you can’t then you keep going, then you're going to need to measure it, because you can’t disprove or prove something if you don’t measure.

Once you measure you can start to learn and iterate, and as you iterate onwards, you will then start building or altering on that first phase. You can see that build, measure, iterate phase it continuous you keep going round and round and round. Although we have a scale at the end of the diagram above, it's better to think of that as a build measure iterate phase as well there no real distinction between them.

Think about the clarity of what you are trying to achieve, because when you want to measure something you want something that’s singular and within your aim. I speak to a lot of startups but when I ask them what their benefit is, I get a list. It's really always good to start with a really clear and singular mission, something that you can deliver that’s really crisp to your customers.

You want to make sure it's measurable. If you can’t measure it, you can’t know if you succeed against your metric, you might not know what's the right value to get to is but you need at least to have a measure to know where you are in relative terms.

The hypothesis is incredibly important for you to frame what your business is around.

M{x}P

MVP stands for a minimum viable product, its the first product that you build and is the product that gets your startup through the product-market fit phase. It's not a prototype so it's not to be confused with a prototype. A prototype is something you create to see if your idea is feasible if it's like a hardware idea or helps you find a happy path for UX for your users to know how they experience your web app or mobile app. Or just to get a visual so that people can see what are you trying to build. So an MVP is not a prototype, and there are certain situations where you build a prototype before you build an MVP or you might have both an MVP and a prototype to be testing things on the side.

This is the minimum number of features to test your hypothesis, and it is very important because a lot of people overbuild their MVP. It's very common, and you especially see a lot of overbuilding when you have people who never been around software development teams before or worked in a software development team. And overbuilding happens when you build features beyond what is needed to test your hypothesis.

If you want to give a good example of an MVP lets take Lyft for example. What is Lyft trying to solve originally when they first released their product? They are trying to see if peer-to-peer transportation could work. So the minimum number of features they need to test their hypothesis is:

1. Driver to be able to sign up and log-in.
2. Rider to be able to log-in and signup.
3. The rider is able to request a driver and the driver to be able to find that rider.
4. A form of payment to be exchanged between the two parties which they can take their cut off.

That's all the basic features needed without all the features you see now on Lyft like share your ride on social media or add a stop or hundreds of other features you see now which if they had on their MVP it would have been overbuilding.

There are other kinds or other terms referring to the Minimum Viable Product:

Viable: It's the most referred too commonly and it's a completely new product to test new dimensions of the product.

Usable: Minimum Usable Product is to get your product in the hands of customers and make sure it's usable and get early feedback.

Lovable: If you release a minimum lovable product, you are assuming the product existing in the market is disliked by the customers. And you are releasing a minimum lovable product saying that like I think I can do better than x competitor and here's why.

Testable: Minimum Testable Product is good for risky business assumptions for example Airbnb or Lyft.

“If you aren't embarrassed by the first version of your product, you shipped too late.”
Reid Hoffman, LinkedIn CoFounder

Remember it should be very minimal and it doesn't matter how great the UI or UX looks. It just needs to be functional because you are trying to prove a single hypothesis with the minimum number of features.

I've met a lot of startup founders who are perfectionists (I'm a perfectionist too) but you shouldn't wait until you product is perfect but until it's functional and useful at least at a basic minimal state and ship it out and get people using it and see if they actually like it. Because if they need it and want it they will not really care how it looks like or how beautiful it is. They're going to just start using it immediately. How many people actually care what Lyft looks like. Few people only care because when you need a ride you need a ride. Why do you care if there's a button for me to request a ride? A way to pay the driver. Great, I'm all set.

So it's good if you are a perfectionist that there is someone on the team to push you to ship before you are ready.

Let's take a look at the approach of how you think about your hypothesis or MVP. So if you can imagine this pyramid or stack of what a product is, so this is what you want at the end. You want everything colored in, everything completed, usable, valuable, reliable of course, to scale, and to be a great experience that's beautiful for your users.

I spend a lot of time with people trying to build MVPs and we all try to take a slice of them and build them out. If your a designer there’s a very good chance you’ll start from the top and you’ll have an incredibly beautiful MVP or if your an engineer with an infrastructure background, you’d have an incredibly scalable product, or if your a site reliability engineer, its gonna be reliable, if you're on the business side and get that proposition right, it would be really valuable, or if your an application engineer you’d make a really usable product.

But the question is which one of these do I do? But the simplest way to describe it is if you focus on one of them you don’t want to go super wide.

You want to actually touch on all of them. So imagine this as an approach, your MVP needs to address a certain slice of everything, that's why its really important to think what's the minimum feature that will allow you to build that exact thing.

Product Evolution

MVP is obviously not a customer-facing term, while your first customers are gonna be your early adopters and your product will still need work.

If we are trying to solve the hypothesis of transportation for people we might start with a skateboard then move to a scooter then get more complicated from there. That's why an MVP should be the really bare-bones, it shouldn’t be the wheel or tire and you don’t release it until you have a car. That's an overbuild.

Don’t get distracted with features outside your scope and don’t get distracted by things that don’t prove your hypothesis at its basic core level.

It's better to have something that flows and can be progressively useful as you go on. Each one of these phases could be considered a product. If you were to build the wheels in the first phase and the engine in the second, you wouldn’t have something useful whereas here I can get A to B in the first phase “skateboard to bike to car, I can still achieve the same goal you are trying to do, your vision from one place to another but better and better over time and it's still a minimum viable product at each stage.