Validate your assumptions

I've been studying MVP's lately, since I think it's again one of those things that are hard to take a grip on in many situations. MVP stands for Minimum Viable Product, and god that word monster has many names. Minimum Marketable Feature, Minimum Viable Solution, Minimum Viable Experiment... The list goes on and on and it consists of different things depending on who you ask about it. I've even seen that people talk about MVP when they build over 4 months of a feature and call it MVP - not to say that even I've thought of it differently and used it totally wrong.

If you think on it, MVP should be the thing you do BEFORE you do anything else. It's the EXPERIMENT you give to your users to validate your assumptions either correct or incorrect. It's idea is to see how the users react and how they feel. It's there to prove that the 6 month thingie you're about to build really is the thing that solves real customer problems the way you thought it would. And don't get me wrong, MVP is usually thought to be a tool for product managers and marketing, but hell, it is an effective tool to any development or business problem if you understand the mindset.

It all starts with a problem

Usually when you're faced with a problem, you automatically make assumptions about the problem and probably an solution idea for it based on those assumptions. Those assumptions should be validated, and MVP is a good tool for that. Your job as a product manager is all about solving problems based on assumptions. If you think that it's based on a fact, I'd ask you to prove it through some metric or real life data (ok, sometimes it's possible, if the metrics were there before the problem and it was measured already). But in most cases, the problem is mostly qualitative data based on the thing people told you or based on your own observations, history, surroundings etc. These are all biased and yes, they give you assumptions, but not proven data about the solution.

The main thing in this, is the mindset of suspecting everything that is not quantifiable. Even your own thoughts that you know for sure because you've been to the industry for last 15 years. Don't believe in anyone, not even yourself. Or have you ever been incorrect about things that you were sure about? MVP is a tool to make sure you do the right things or learn from it to provide better solutions. The idea of it is to pinpoint the assumptions you have on, prioritize them by their risk and to prove them easiest and cheapest way possible.

So what do you need: A problem and a solution idea, try to think of assumptions you have on the solution. Because of GDPR we could take a problem that a website would need to identify the user so that no-one else could hack his account. A two factor authentication through an SMS could be a solution for this, since it requires the user to input a code to the login from the physical device (mobile phone) that is in his possession. We're assuming here that every user has a mobile phone or the user is always carrying the one connected to his account. We're also assuming that the users aren't disabled in any way that they can use the phone. We're assuming that there's always a cellular network available. We're assuming that the user who logs in, is the one who is carrying the phone and the other user credentials are only in his head. What about if he forgot the phone home or the phone was stolen? How can he now use the software and? This was a bad example of everything, but as you see, there's a lot of assumptions we make even though the solution was kind of an easy one. Next I'd be open minded if the user had any other solution to this problem currently - it might affect the outcome totally. Especially when you're building a new product or service, also competitor analysis is a good to keep in mind ;)

Proving the assumptions through hypothesis

Next step after identifying the assumptions would be to prioritize the assumptions by their risk. It might not be easy and there are several methods for this one, others might use educated guess or just the difficulty to prove it versus the risk of the problem. You're choice how you can organize them as soon as you know what is necessary and important to prove.

Taking the most risky and easiest to prove would be a good starting point, just because it's cheap! The easier the assumptions are to prove, the better. You're going to prove them through MVP, but before that you have assumptions that aren't actionable. So, we need to make them actionable. Here comes the hypothesis to help you out! You can create hypotheses out of those assumptions quite easily. To prove them we need a few things: PERSONA A that has the PROBLEM B because of REASON C. And if we provide SOLUTION D, it's proven by METRIC E. There are different styles to do this, not all of them have metrics or reasons, but this is what I'd use, since it forces me to think about the things written in capital letters.

So, user personas are a help, since you might have to think about several different users or user groups. If we incorporate the problem and reason, we have to think about WHY our solution would work. And we only can prove our success based on some metric, something that can be measured. Whether it was # of users using our feature, conversion rate, change in revenue or anything. This forces us to prove our assumptions through measuring them. When thinking of measurement, always set a line for it, a minimum criteria for success. When the minimum criteria for success is met, you know for sure it will work.

Defining the minimum criteria for success can be hard and many times you just do an educated guess. But when you at least think of it, it's better than to go without it. For example we could try to monetize the criteria, how much does it cost to develop vs. how much our metric should move so that it pays back. There's quite a good line, if it's at least the same amount, every percent over proves it should be developed and if it goes under it, we shouldn't create it. But it always depends on what you are doing, it might be customer satisfaction or the lead time in development that you're trying to affect. Really this method can be used in many things, not only in product management.

In the end the MVP awaits

Now that you've identified the problem, assessed the assumptions, created a hypothesis and tied it to a metric of some sort, you can start proving it. In your hypothesis are just questions and the data to prove your assumptions were right. Now go ahead and build your MVP and experience with it! But remember, the more easier and cheaper you do it, the more hypothesis you can prove and eventually find the ideal solution for the problem your users are experiencing. So, the MVP is an experiment to prove your assumptions and get real life reactions out of users. It's not the baseline for new feature, it's the baseline on proving if your assumptions were right or wrong and the process before it should be the point where you think how to prove it. If you were wrong, prepare to throw the solution away or improve it in small steps.