My Journey to Simple, Lovable, Complete Products

Over the past few weeks, I have been studying and learning a lot about the Minimum Viable Product (MVP) approach. In my 30-year career as a software engineer, I have undoubtedly experienced a lot, and my own standard continues to be that I am always learning.

Throughout those years, I often found myself in situations where I had to build the key features of a product, either to convince customers of my (or my company’s) capabilities, or to help founders with a minimal version of their product idea to find investors. It often didn’t matter what we called it, because there was usually a consensus that this first version of the product had to be compelling.

Rejecting the ‘Quick and Dirty’ Approach

As I began to research the topic of building MVPs as a product for entrepreneurs, founders, or even existing companies, I noticed that there are quite a few different views on what exactly an MVP should be.

Of course, there are always people who think everything is clear, who don’t listen to what others have to say, and who consider their interpretation of the matter to be the only truth. But I am not one of those people. I need the exchange with others, and as a self-taught individual, I also need time for self-study to form an opinion and my definition.

Sustainability and quality in the development of a software product are absolutely essential to me. That’s why the idea of “just throw something together quickly and dirty as long as it seems to work” doesn’t appeal to me. I am too much of an aesthete to just throw some input fields somewhere and let the user find the submit button. No, it doesn’t work that way.

This was clear to me, and in all my years of software development, a good architecture and an appealing UI have always been part of the game.

Although the common opinion seems to be that an MVP can be hastily assembled and is only meant to show that the product or use case works, I have a different view. To prove that something works technically, there are concepts like Proof of Concept (PoC) or prototypes. But we’re talking about MVPs that have to convince real users.

Low-Code and No-Code Solutions: A Critical View

I have noticed a large faction relying on no-code and low-code solutions. While they offer an easy entry point, I am convinced that they are neither sustainable nor solid. The most important reason why they cannot be a long-term solution is simply the dependency on a vendor. The product is not really your product but, to put it bluntly, part of a subscription system. In addition, all standardized modular solutions have inflexible and limited customization options.

Even if the advantage is that no programming knowledge is required for the implementation and there are usually many tutorials and templates available, the disadvantages described above are too serious to speak of sustainability in terms of risks such as costs and scalability due to the hard dependency on the provider.

I am convinced from experience that you need real substance to get a solid product or project off the ground.

Learning from ‘Lean Startup’

What exactly is an MVP? Looking at Eric Ries’ definition from “Lean Startup”, an MVP is “the version of a new product that enables a team to collect the maximum amount of validated knowledge about customers with the least amount of effort”. I think this definition is very generic. What it does not say is how exactly this works! The MVP concept usually involves creating a small product that can be tested easily and inexpensively. You bring the product to market quickly and then learn from customer experience and feedback. If the product is not successful, you abandon it, but if it has potential, you invest more. MVP development is iterative and relies on a stable team.

Defining ‘Minimum Viable’

“Minimum viable” can mean just about anything, depending on the perspective of those involved. Yes, it can be, as I prefer, the one core feature. But what does that look like? And when is a product viable? When it just works or is functional?

In the manner shown below, a product is also minimum viable.

That may be a bit of an exaggeration, I know, but it fits the definition. I hope there are no more users out there who would expect this. But who knows?

In my experience, although the MVP concept offers a fast approach to product development and marketing, the “viability” aspect is often not given enough attention. The focus is very much on the “minimum”, while the “viability” of the product is overlooked, which can result in many start-ups losing the trust of their potential customers.

Focus on Core Features

This made me think about my approach and, in retrospect, about the values I have always held in developing software. The core of my thinking, whether at the product level or at the coding level, is to avoid unnecessary complexity whenever possible.

Simply said: Keep it simple!

Simplicity means not overloading and offering things with little or no value. I believe in keeping it simple, focusing on the essentials, and giving the user a great user experience. By that I mean a few features, but they should be finished and not half-baked. The application should not give the impression that the user is the alpha tester. The features that are there have to be finished, which does not mean that it has to be a complete application with all features, but a useful application with the critical feature or features of the highest quality. This includes a very good user experience.

Earlier this year, I developed the MVP for a New York-based founder in the Web3 space. The core feature, the cross-chain swap from Bitcoin to Ethereum, was carefully worked out and turned into an iOS mobile app with a focus on the core idea.

The app doesn’t look unloved and unfinished. It gives the user the feeling of a great product.

The Evolution to SLC Products

Recently, a friend sent me a LinkedIn article about the SLC approach to product development that really caught my attention.

The next step in realizing MVPs is Simple, Lovable, Complete (SLC).

The “minimum” needs to be replaced with “simple”. Features should not be a matter of quantity, but should be a matter of value to the user. The product must be fun to use, even if it has only a few features to begin with.

It is often said that a “viable” product must be functional, but not necessarily “lovable”. A “lovable” product is one that customers want to use. The “lovable” principle of the SLC approach requires a redefinition of purpose.

While the “viable” principle of the MVP focuses on the needs of customers, the “lovable” principle of the SLC aims to develop what customers really want and to design it in such a way that they enjoy using it or are enthusiastic about it. Enthusiasm ultimately leads to commercial success. This automatically makes me think of Apple, which has always scored with simplicity.

SLC: A Step Beyond MVP

The difference between MVP and SLC lies mainly in the concepts of “complete” and “product”. While MVP aims to create a working product that solves basic customer problems and has the necessary features to survive and be accepted, the “complete” element in the SLC concept focuses on the product consistently performing a specific task without appearing to be missing anything.

I love this approach. It is exactly my idea of a good and useful product. It’s the way I think and work.

Please don’t get me wrong, the MVP is not a bad method for product development and marketing, if applied correctly. As I understand it, the SLC approach aims in the same direction, and I see it as a new level, with a stronger focus on usefulness through simplicity.

At the end of the day, it’s about companies creating products that deliver real value to customers in a way that they want to use and enjoy every time they use them. And this is the gap that the “ Simple, Lovable and Complete” approach fills.

Cheers!

This article was originally published on Medium on
November 29, 2023: https://levelup.gitconnected.com/my-journey-to-simple-lovable-complete-products-9583d35bc863