How to build MVP products?

There are a lot of blogs on the internet that explain what an MVP is and why product managers fail if they do not follow MVP principles.

Here are two average blogs by an average writer trying his hand at answering these questions:

  1. 5 reasons why entrepreneurs & products fail? | by Sandeep Chadda | Apr, 2022 | Medium
  2. Minimum Viable Product Ft. Iron Man | by Sandeep Chadda | Bootcamp (uxdesign.cc)

But the question still remains. How do you really think about building an MVP product?

Having a loving dog by your side can give you the right environment to ship great products. by Berkay Gumustekin on Unsplash

Reading is not my thing

If reading is not your thing and you would rather watch a video, then you can view this workshop that contains a summary of all these blogs and more.

I always try to conduct workshops in under 1 hour, however I guess I love talking :(

How do I even start?

For a moment stop thinking of your features as product capabilities and think of these as experiments.

So, what is an experiment?

Experiment is not …. “Let us do something and see what happens.”

“Let us ship this product and see how customers respond”. A lot of product managers use this language colloquially. That is called shooting in the dark and not product experimenting.

To get some help on understanding experiments, let me take you back to Grade 3.

My son (3rd grader)and I predicted that lemons, when connected in series behave like a battery. Honestly, this was no experiment. We just saw it on youtube.

So, this is how we conducted our experiment.

Hypothesis: Lemons conduct electricity

We built the experiment: Connect 5 lemons; Make Cu Anodes and Zinc Cathodes; Connect these anodes and cathodes with a wire. Check the voltage using a multi-meter

We measured our findings: We checked the voltage across these lemons using a multi-meter. We found that when we connected 9 lemons in series, we generated almost 0.7V. Enough to light up an LED.

We learnt that: Lemons do operate like batteries therefore hypothesis validated.

How cool is that isn‘t it. Next time your phone is discharged, and you don’t have a charger, just use lemons :)

The question is what any of this is to do with product management. The key terms here are (1) Hypothesis (2) Build (3) Measure (4) Learn

Hypothesis: Hypothesis is just a prediction. We generally write a hypothesis in this form:

If we [do this]

then [users may do this quantitatively]

that results in [that objective].

For example, for one of my product experiments I had a hypothesis, that

“If we [enable recent search] then [60% of the users will use recent search for navigation] and this may result in [our NPS increasing from 12 to 23.]

Build: Based on this hypothesis, I built an experience. Even before including the experience in my product, I tweeted about it to hear some response from our power users. I got nearly 1k likes across multiple shares.

Now, my solution hypothesis validation was a tweet. It could be a video. It could be interviewing some customers etc.

Here, when we shipped this capability, it was very raw. It was nothing production ready and there were performance issues, and we could not even replicate this experiences across browsers. We could take these liberties because we were just validating our hypothesis. It was very bare bone.

I can’t believe I had dogs even in my product Day 0 experience :)

Measure: Once I shipped this feature, I measured whether I am getting customer metrics to validate what I shipped.

This is the exact feature we shipped

Learn: Based on the data we got, we learnt whether our hypothesis was validated or invalidated.

A typical experiment follows this trajectory. Now my question to you is that if you start looking at every feature like an experiment where you will only know the efficacy of the investment after you release the feature, how deep would you like to go in the build phase. Do you want to smoothen every corner and ensure every chink in the armor is secured or would you rather ship something and learn from it?

This mindset is what is required to ship an MVP. What is the minimum product that you can ship so that you can learn from customer feedback, usage, adoption, metrics etc.

MVP in PM interviews

When you are attending PM interviews and you are asked to build an MVP, one easy route to take is to perform an ROI assessment.

For each feature you propose perform a value versus cost assessment. E.g.

  • Feature 1 | Low Value | Low cost
  • Feature 2 | High value | Low cost
  • Feature 3 | High value | Medium cost
  • Feature 4 | Medium value | High cost

Here value could be the value to the customer, the value to the company, your learning after shipping the product, revenue etc. while cost is the cost to implement a product feature. The cost can be a high level guesstimate.

In this case, you can articulate “High Value” and “Low/ Medium cost” features that complete your scenario for the MVP release.

Here completing the e2e scenario is very important. Do not articulate features in an MVP that do not complete the e2e scenario for the user else it is not a product that is shippable.

I hope this helps you understand how to build hypotheses, create experiments, and ship MVPs. Read this blog in combination with the other 2 blogs that I mentioned above to get a better understanding of this term.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store