Always Build an MVP (Minimum Viable Product)

June 20, 2021

Last year, I wrote a post about how MVP isn’t the right approach for every new product and how sometimes building an MLP or Minimum Loveable Product is the better way.

It’s important for one to acknowledge their own mistakes and update their learnings continuously. I’m writing this post to say that - I was wrong.

What is an MVP or Minimum Viable Product?

The most common answer to this question:

An MVP is that version of a product with just enough features to attract early-adopter customers and is just usable enough that those customers can then provide feedback to the team. This feedback should help the team generate validated learnings and guide them on future product development and features.

Looking at this definition, one might be tempted to define a list of features for the product they want to build, and then pick the minimum set of features to build in the v1 or MVP so as to launch it quickly.

That’s also where we go wrong. To find the right approach, let’s ask the next question.

What is the purpose of a Minimum Viable Product?

I like the answer by Frank Robinson best:

The MVP is the right-sized product for your company and your customer. It is big enough to cause adoption, satisfaction and sales, but not so big as to be bloated and risky. Technically, it is the product with maximum ROI divided by risk.

An MVP is not just about the software you write, but also

  • the distribution channel(s) you pick,
  • the way you repeatedly acquire customers,
  • solving a tiny problem well enough to lead to revenue and (if not revenue, at least)
  • retention in using the product

Maximum ROI divided by risk

The biggest risk factor of building a new product is not the product development itself, it’s whether - you can find something that people want, that people are drawn towards organically, that people sign-up on their own, use in its raw version, derive value out of, continue using, perhaps even pay a small amount, and most importantly come back to demand for more functionality to better satisfy their needs.

An MVP should therefore satisfy all aspects of the typical funnel such as AARRR:

  • Acquisition
  • Activation
  • Retention
  • Referral
  • Revenue

How to build a Minimum Viable Product

You’ve probably come across this image before. Looking at this, it’s obvious that the MVP needs to be a skateboard.

The image, like all other graphics and literature about MVP myopically on the product and not on other aspects that are equally important such as distribution, and validating the biggest risks of the product (such as “do people want to travel from point A to point B faster?”).

The skateboard does all this.

Credit: Henrik Kinberg of Crisp

Your MVP should be like a skateboard.

Where we went wrong with DelightChat

Now that we are 8 months in, I can see clear paths where we could have re-arranged parts of our journey like lego blocks and achieved a significantly better outcome today.

DelightChat launched on the Shopify App Store last week (announcement post coming next week). We are finally figuring out how to acquire customers via the App Store.

The path we took - Minimum Loveable Product

Instead of building a skateboard, we tried to build a small and feature-less car.

The primary reason for doing so - we believed that the only way to build this product is through an MLP, and not an MVP (skateboard).

While today the car we have is in decent shape, being used by 25 brands, 50+ support agents who are sending >2000 messages/day, the journey to building this car could have been approached differently.

We would have had to build the car anyway. All the features that are needed in a helpdesk would have gotten built in due time, there’s no 2 ways about it.

Choosing an MVP path would have meant that we figured out a repeatable acquisition channel, and therefore talking to customers, far earlier.

From where I stand today, I can see how we could have launched 6 months ago with a different version of the product.

Here’s one such way: Build a self-service widget

We recently built a widget that whose purpose is to become the central place to contact a brand or get answers to their questions for website visitors.

The widget makes the following easily accessible to every visitor of an ecommerce brand: 

  • Contact us form
  • Social media links
  • Order status - Find your order fulfilment, refund, etc. status. Track your order. Raise issues such as cancellation, refund or exchange requests.
  • Help Center & FAQs - Make every important and common question accessible in one-click and searchable.

Building the MVP of this product would have taken us 1-1.5 months. But the more important aspects are:

  • We would have launched on the Shopify App Store and build a repeatable channel of acquiring customers.
  • Ideal customers would be those high volume of website visitors => lots of orders => therefore support tickets would need a helpdesk to manage support.
  • We would have started collecting early feedback from these customers, our exact target market, way before we could by actually building a helpdesk (which is an insanely complex piece of software).

This would have been a skateboard.

It’s Day 0

One of our investors reminds us often (and we’re grateful for it) that it’s still day 0.

We’ve made mistakes sure. The present could have been different based on past decisions, of course.

But now that we are here, and if it is indeed day 0 of a 10-year journey, what should we do today?

What should our next steps be, given everything we know today and all the resources we have available?

I’m so pumped about the future and the things we’re doing next. Onwards 🚀

💌 Enjoyed reading?

I write a weekly newsletter called ☕️ Sunday Coffee where I share my learnings about building profitable SaaS businesses and living a good life. Check out the newsletter archives. I think you'll like it!

You'll be joining 863 others who read my newsletter every Sunday morning. Best had with a cup of fresh coffee ☕️

You can also subscribe to the newsletter via RSS feed.