Build a Minimum Loveable Product

You've validated your micro-SaaS idea and are ready to start building the product.

The obvious next questions are

1. Which features should the product include in its first version?
2. How long should you take to build it?

Through this post, I provide you with a framework to identify your initial product features, how to decide what to include or exclude from the first versions, and continue building upon it.

Before jumping into MLP, let's first understand what MVP is and why it's not enough in today's times.

What is a Minimum Viable Product (MVP)?

Eric Ries popularized the term minimum viable product in his book The Lean Startup as that version of a new product that is just usable enough by early customers who 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.

When MVP still works

MVP is not dead though. It still works, given the right kind of problem statements.

Suppose you're building something that simply doesn't exist in the world, and it's something that people really want and have no alternative to getting it except from you.

At this time, people will accept a textbook MVP, simply because they have no frame of reference to compare it with. Or better yet, because they have no alternative to replace your MVP with.

Why MVP is not enough in 2021

Over the past few years as smartphone penetration boomed, products matured, product design and user experience matured, people's expectations have increased.

No longer does a quickly thrown together prototype cut it. People expect a minimum level of good UX and ease-of-use, else they'll leave your app before even giving it a proper try.

In fact, in 2021 great UX might be one strong reason people pick your product over incumbents. That's what happened with Transistor.fm, who made podcast hosting simple and easy.

People expect good aesthetics that make a first impression, simply because that's what they have become used to from the plethora of beautiful and well-designed apps out there in the world.

People expect products to be fully functional as advertised. Buggy products are not acceptable, and in fact people might quickly take to Twitter or social media to let others know that a product is unreliable.

Source

The MVP mindset intensely focuses on building the bare minimum, and that often leaves users frustrated and drives them to seek alternative solutions. Stiffer competition means that people WILL compare your product to alternatives in the market, it's inevitable. And unless you provide something unique and valuable that nobody else does, people are likely to leave.

All these reasons and more make MVP a dated concept, especially in the context of SaaS products. But above all, I think the MVP mindset makes product builders think too heavily about the "minimum" and often so at the cost of "viable".

That's a common pitfall and to avoid that, I propose the MLP framework.

What is a Minimum Loveable Product (MLP)?

A great new concept that I've fallen in love with and personally follow in every product I build is MLP, or Minimum Loveable Product.

The term MLP was first coined by Brian de Haaff, the co-founder of Aha!, in his book Lovability.

Its definition is an extension of what Eric Ries already introduced to the world with MVP. With MLP though, you are trying to build the minimum "loveable" product, with a focus on no matter how small or feature-stripped the first version of your product is, it is sufficient to deliver a delightful experience to your user.

Minimum Viable Product and the burnt pizza analogy

Jiaona Zhang, who is currently VP of Product at Webflow (this blog is built using Webflow) introduced the burnt pizza analogy to her students at Stanford.

“Say you’re trying to test whether people like pizza. If you serve them burnt pizza, you’re not getting feedback on whether they like pizza. You only know that they don’t like burnt pizza. Similarly, when you’re only relying on the MVP, the fastest and cheapest functional prototype, you risk not actually testing your product, but rather a poor or flawed version of it."

A great practical example of Minimum Loveable Product is the Apple iPad. All the tablets that came before Apple's tablet were MVPs.

MLP vs MVP

If you're new to all these terminologies, I understand that it can be confusing. Bear with me, you'll wrap your head around it soon enough.

Build an MLP when you are solving a problem that's already understood by people, and an MVP when people don't easily understand a problem.

Build an MLP when you can clearly define and understand a market and you are trying to stand out from the existing tools. Build an MVP when you're trying to gauge if there even exists a market to serve.

An MLP can be built when you know exactly what customers want. An MVP is when you don't know what customers want, and therefore you want to throw things at the wall as quickly as possible and see what sticks.

Perhaps the clearest distinction of MVP vs MLP

An MLP is necessary if you are building in a market where several large and well-known alternatives already exist. An MVP is the right approach for a new market with barely any alternatives, or those solutions are not yet known by the masses.

While building an MLP, you make a dedicated effort to succeed with that idea. With MVP, you are trying to determine quickly whether the idea can succeed or whether it will fail.

Building an MVP means you're ready for failure and also ready to pivot quickly as you learn more about the market. Which means you should make tech and architecture decisions that help you move fast above anything else. Scalability or good architecture design is a concern to pay attention to while building an MLP.

Finally, the end goal of an MLP is that the customers who use it find it sufficient in functionality and experience to be able to "love" it. With an MLP, you're building just enough that a customer with (hopefully) a real pain point would "tolerate" and continue using your product while you validate your assumptions.

Minimum Marketable Product, Minimum Remarkable Product, Minimum Launchable Product

The what?

I know, I know. I came across these terms for the first time today while researching to write this post. And I went through the literature so that I can tell you to safely ignore it.

If you understand and embody the concept of MLP, you don't need to think about any other frameworks or terminologies that you may discover while researching on Google.

How to build an MLP for your Micro SaaS idea

Alright, let's put aside theory and dive right in.

Here are the steps you should loosely follow to building an MLP.

1. Understand the #1 problem you're trying to solve

What's the #1 reason someone would want to use your Micro SaaS product over existing alternatives?

Is it that existing options have poor UX? Great, create a well designed and easy-to-use product. You'd be surprised to know how often people switch to an easier to use tool, simply because they are fed up of the poor UX that they encounter repeatedly.

Is it that existing alternatives are very expensive? Carve out a minimum set of features that people are paying a lot of money for and charge 1/10th for your v1 product. This might not work for very large customers, but vast majority of customers who are small or mid-sized are always looking for affordable alternatives.

It might not just be raw quantum of pricing, but certain companies targeting Enterprise customers have very complicated pricing slabs and tiers that are designed to give their sales person more room. In such a case, coming out with a competitor product which has a simple, easy-to-understand pricing is how you attract customers.

Are existing alternatives lacking certain features that leaves a subset of users very dissatisfied? Great, your MLP should specifically address that problem by building functionality that attracts these dissatisfied users. Side note - This is perhaps one of the best ways to go about building a new product.

In all cases, it involves understanding the problem you are solving and the exact reason why someone would use your product.

2. Design a simple product that solves the top customer needs satisfactorily

Once you have identified the #1 reason, it's time to decide on a feature set for your product that solves your customer's top pain points satisfactorily.

Let's take an example - People want to add a feedback tracking tool inside their product, so that they can collect user feedback automatically. However, the existing solutions don't allow them to embed the feedback tracker within their tool.

That's your entry point into providing value that customers seek, but are not getting as of today.

Having understood the #1 problem, you also have to understand other requirements that fall under the "minimum" set of things you need to do to build a "loveable" product.

These could be:

• existing solutions are all well designed and aesthetically pleasing => your minimum loveable product needs to be well designed too
• existing solutions are affordably priced with a easy to understand pricing structure => your MLP also needs a simple pricing structure that's affordable

In general, you want to analyze your competitors and understand

1. What they are doing well
2. What users value from among those things

In your MLP, you need to cover the intersection of (what they are doing well) x (what users value from among those).

3. Set a short timeline for building your MLP

No matter what you build, building in isolation for too long is dangerous. The main reason for that is - you get to know too late whether your assumptions about what the user really values are on point or off course.

"But Preetam, you just told me to build a Minimum Loveable Product. And now you're saying I got to build it quickly?"

Yes, that's exactly what I'm saying.

Short timeframe depends on what you are building, and the size of your team.

For example - with SuperLemon (WhatsApp plugin for Shopify), Sankalp and I built a MLP in 2 weeks time.

How?

We identified precisely the way we could do better - build an easy to setup app, and design beautiful looking widgets that blend in with your store.

The minimum set of features required were - the ability to configure the text within the chat button (eg. "Chat with us"), and the option to select between 4 different design and colour options based on the user's preference of having a large button or a small one.

That's it! That was our MLP and we grew it to 2,000 users in 40 days before we added a new set of significant features to the app.

"My product is more complicated than that! I can't build an MLP in 2 weeks."

That's okay! I totally understand.

With DelightChat, which is customer support software for ecommerce stores, we are taking a significantly longer duration to build our MLP than we did with SuperLemon. A little over 3 months, to be exact.

Let's set the record straight - I'm uncomfortable with long development timelines. But in this scenario, it can't be helped.

We need to do it this way because the product is complex and needs time for development. And also because building anything lesser than the MLP we have designed would not appeal sufficiently to ecommerce merchants to use DelightChat over existing alternatives.

But most importantly, and it would be misleading if I didn't disclose this, we have the runway in terms of monetary capital to afford 3 months of product building. And hence we can afford to take the time.

But even then, we are

• focusing deeply on the core UX, functionality and value proposition that will draw the initial set of users in, and delight them
• ruthlessly prioritizing features that can be built later, that are not dealbreakers for the initial userbase

And that's precisely what you need to do as well.

--

If this post managed to get through to you, then you now have the required framework and understanding to build an MLP version of your Micro-SaaS product.

So what's the next step?

Let's figure out a simple and easy pricing structure for your product!

from Hacker News https://ift.tt/3kUHc2w