How viable is your MVP?

The fact you are shipping a "minimum" version of your product does not mean it should be mid or unusable by your users.

As you embark on your indie hacking journey, perhaps inspired by this newsletter (you're welcome 🤗), you'll likely encounter the acronym MVP. In this issue of the BBoJS newsletter, let's dive straight into understanding what an MVP is(and isn’t).

WTF is an MVP?

MVP stands for Minimum Viable Product and here is how Wikipedia defines it:

A minimum viable product (MVP) is a version of a product with just enough features to be usable by early customers who can then provide feedback for future product development

As an indie hacker, until you launch a version of your product your customers can use a.k.a MVP, you are mostly just guessing.

And no, an MVP is not a Figma design 👀. It is a minimum and viable version of your product that you put in the hands of your users and see what they think about it. An MVP also allow you get feedback that will aid your iteration, pivot, or otherwise.

Without an MVP, all you have is an idea with no evidence that it’s something people really need or will pay for. In fact, the sooner you have something out there, the quicker you will know if folks will pay for it or not.

Just ship it?

So as we have established earlier, it’s important to ship quickly, but there is a downside to the current "just ship it" culture: it may lead to underwhelming MVPs that fail to deliver even the basic features that your product is advertised to have.

As I develop the MVP for Hagfish, I keep pondering on what truly defines a great MVP. Where does one draw the line between something minimal but useful and something that's just not usable at all?

And I am not the only one thinking this way, JR Farr, CEO & Co-founder of Lemon Squeezy had this to say about the current state of MVPs 👇🏾

I feel like the idea of MVP has turned into sloppy products and it’s terrible for customers. - JR Farr, CEO & Co-founder of Lemon Squeezy

Take for example Hagfish, if after launching the MVP, you can’t create an invoice even though Hagfish promises a better modern invoicing management experience, would you call that a great MVP? Absolutely not!

Or folks can effortlessly register and log in to Hagfish, but the process of creating an invoice involves a painful and seemingly worsened experience compared to your previous methods. Does that still qualify as a great MVP? The answer still remains no!

You are probably getting where I’m going with this but let’s see what Pieter Levels has to say about the subject matter:

A lean or minimum viable product doesn't mean it can be shit! It has to actually function, users have to be able to use it. - Pieter Levels from his book Make

Colourful language there Pieter, but I think you get the point - Users have to be able to use your MVP!

Viable viable viable

What does the world viable mean? It means capable of working successfully.

To the perfectionist, this doesn’t mean your product should be free of bugs 🐞(there will always be bug). What this means is that your users can do the stuff they came to the product for successfully.

Just enough features to be usable

I hate to break it to you, but user authentication (login, sign up, etc.) is not part of your MVP; it's just baseline requirements.

In fact, getting things like user authentication out of the way is one of the reasons I built The Boring JavaScript Stack to aid indie hackers to focus one what matters as you build out your MVP and iterate on your products.

When I say features, I mean the value you said the users of your product will have; your MVP should be able to enable that in some form.

Minimum does not mean Mid - Kelvin Omereshone

For instance, imagine your product is a to-do list app (bear with me). Basics like adding, deleting, and marking tasks as completed are the essentials. The MVP's unique value lies in features such as prioritizing tasks, setting due dates, or organizing tasks into categories. These features deliver the promised value to users and should be present, in some form, in your MVPs.

You might be thinking, “But Kelvin, isn't the ability to add, delete, and mark tasks as completed what makes a to-do list 😭?” Yes, you are right, but I can do that on the iPhone’s Reminder app. So if that's what you're offering, I might as well just use that app, no 👀?

Bugs 🐞 are fine

As mentioned earlier, it's acceptable to have bugs when shipping your MVP, but they shouldn't be so impactful that they hinder users from carrying out operations.

When releasing your MVPs, ensure you have a mechanism to gather feedback from early users and swiftly address issues. Nothing is more frustrating than critical bugs going unaddressed, causing significant inconvenience for users.

Your MVP should be SLC

I heard the acronym SLC from JR Farr for the first time and it really resonated with me. In fact, it gave a name to how I’ve thought about building products be it MVPs and beyond.

SLC is a termed coined by Jason Cohen, Founder at WP Engine and it stands for Simple Loveable, and, Complete.

I really like the idea of an SLC and I don’t think you have to substitute the acronym MVP for a newer one SLC(please not another acronym 😅). However the mindset is what’s important and what you have to think about as you build your products.

Let your MVPs be simple, loveable, and complete.

Understand: even though the essence of an MVP is to foster learning, it would be a disservice to your users to ship something that is not both simple to use and loveable. Without this simplicity and an element of love, it won’t be complete enough for them to eagerly anticipate and embrace future iterations of the product.

So build your MVPs with an SLC mindset.

Further reading

• Your customers hate MVPs. Make a SLC instead.

• How we ship at Lemon Squeezy

• The Build chapter of Make