Simple, Lovable & Complete – SLC an alternative to MVPs?
What is the best way to develop your application? Is it the buzzword of the tech world – MVP or is there something else? Today we’re discussing a slightly different iteration on MVPs and that is – Simple Lovable Complete (SLC).
Minimum Viable Product, otherwise known as MVP, has been the leading buzzword of the software development world for some time now. Matter of fact, it was first coined in 2001 by Frank Robinson and later made popular by Eric Ries’ ground-breaking book “Lean Startup”.
Way back then, software development as we know it, has only recently become widespread enough to begin formulating new frameworks and approaches to various project management techniques.
Back in those days, aside from the great dot-com bubble, we see most project management approaches surface. Same year in fact (2001) the Agile Manifesto was created, and many PM frameworks and methodologies appeared.
And though today we’re discussing MVPs vs SLC approaches, its far easier to convey our ideas comparing their root origins.
Now, many would argue that Agile gave rise to the Lean model, some would argue the reverse; some say that the holy scripture that is Agile Manifesto gave birth to everything except Waterfall, others reasonably point the origin of “Lean” module to Henry Ford or the company “Toyota” and manufacturing industry.
Regardless we’re not going to divulge into that PM slap fight…
What we want to postulate is that Lean and Agile models of software development differ in their fundamental goal. At least as it is today.
Agile vs Lean – What is their fundamental goal?
What’s their goal?
Elementary our proverbial Watson!
But aside from the obvious: saving costs, improving margins, streamlining development lifecycles and other fancy sounding tech-business words?
The answer is somewhat tricky.
That’s because many use these two approaches interchangeably, even in the professional sphere. It’s not difficult to imagine why, both models have evolved to resemble each other more than some would like to admit. Both:
- focus on iterative software development with high reliance on customer feedback;
- focus onorganizing the workflow to better optimize the processes involved;
- put high value on self-governance philosophy, and less centric approach to development;
- But most importantly: both models put a heavy emphasis on continues improvement.
However, their priorities among their objectives differ:
Lean puts its main focus on eliminating wasteful processes, unwanted meetings, essentially cutting the “bureaucracy” to its minimum.
Whereas Agile’s main purpose is to promote collaboration between everyone involved, stakeholders, developers and customers.
You can see how those two would contradict each other. Agile requires constant communication between everyone. This means constant meetings, reports, updates etc.
Lean on the other hand, once the planning phase is complete, begins its iterative approach; however, with each step of the process, it looks inwards and cuts out any extra or superfluous processes. It naturally leads to less meetings, less updates and reports etc.
What we’re trying to say is that the Lean model makes happy developers, who receive less overhead, less interruptions and especially less contradictory information to “their vision”.
Agile on the other hand, true to its reactive nature, focuses primarily on client feedback and incorporates changes on the go far quicker and reliably.
Wait, but what does all that has to do with MVP’s and SLC’s?
Before we get there, lets re-iterate some things about MVPs!
In a Nutshell – Minimum Viable Product (MVP)
Many wrongfully assume an MVP as a product itself. They assume that an MVP is a product with minimum viable functionality to be used by clients on release. Nothing could be further from the truth.
Here is Eric Ries’ definition of the MVP:
Minimum Viable Product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.
A Minimum Viable Product (MVP) is essentially a data-driven scientific approach to development of applications. It heavily relies on feedback from the end-user and on the fly changes to the core of the product. Its main appeal to developers is testing the market viability of the product in order to jump ship as soon as possible in case it is doomed.
Building an MVP, takes a lot of homework and planning: examining user needs, building extensive feature lists, prioritizing these features according to their viability and necessity.
Once that is over, it starts small and focuses on delivering the most basic core feature to their customers and continuing adding planned features according to their client’s feedback to maximize customer satisfaction.
What’s our point? Things have somewhat deteriorated
Though the holy mantra of every Agile Manifest enthusiast and MVP fanatic (us included) nowadays is proclaiming MVP’s as Agile centric model (disregarding that originally MVP was a Lean creation) and stating that Agile/MVP is all about supplying value to the end client.
We would like to play the devils advocated and argue that it is no longer the case.
That is possibly due to its popularity in the development world which has led to fundamental misunderstanding and misuse (wilful or not) of the model. You see, every company you ask on the market whether they develop MVPs or not, will say – yes, of course! They would be crazy not to, after all it is *the* buzzword of the decade.
This all leads to companies appropriating the step-by-step model of an MVP approach but adapting it to primarily favour themselves – the developers.
The reality is that now days the discussing among developers on MVPs is more M than V.
Everyone experiences crunch time; everyone is always pressed by deadlines. So inevitably, whether the project started off as an MVP, or not, the question arises: “what is the absolute minimum that we must deliver to satisfy the customer’s needs?”
Developers have began using the MVP as an excuse to deliver an incomplete product and adjusting it on the fly. Building a 0.1 version, releasing it in Alpha/Beta and slowly building the product towards its planned scope (v1.0).
Arguably that is the whole point of an MVP – testing the viability, introducing the simplest feature, gauging its market necessity, and introducing intended features. However, at the end of the day, your customers can always tell that they are using a 0.1 version of a product that might or might not miss features to make it complete.
What can you do? Introducing SLC
You might be wondering why have we brought up Lean and Agile earlier, and made such emphasis on their goals? Originally MVP much like Agile was all about putting the most commercially viable and satisfactory product to the end user focusing on value. Many would argue that wrongfully using MVPs does not discredit the model itself, and that is absolutely true.
However, reality and life often take unexpected turns, usually for the worse. And the main problem with MVPs as some see, it is the overall planning and scope of the products. When building MVPs, developers start from the most basic core feature and build from there, but they always plan in advance, and plan big!
The core issue with MVP is the promise that the product makes to its customers, yes, they start simple but due to its inherent plan, it always feels lacklustre, incomplete. Because everyone involved knows this is not the final product – its early access.
So, using the Lean methodology, some have proposed cutting the MVP of all its waste! Drumroll please…
What is SLC and what does it bring the table?
In comes – Simple, Lovable & Complete (SLC).
An evolution on the MVP approach, achieving the same goals of building cheap, small products. Designed to get products quickly out of the door to the customer and testing the market viability of the idea. And if it doesn’t work, jumping off with minimal losses.
SLC proposes that the initial plans focus primarily and only on the core simple, lovable and complete feature.
Let’s deconstruct that:
Simple does not mean Minimum
Simple implies intentionality. With MVPs, the conversation often revolves around the minimum requirements that must be delivered to satisfy the end-user. Note “minimum” as in “not-full”.
Whereas having the simple feature be the star of the plan from the get-go. It focuses the team entirely on supplying one a single feature that fully satisfies the end-user.
It’s all about promising a simple solution to a simple user story! Customers can be very forgiving as long as you don’t overpromise. A splendid example of this is Google Doc’s. At its release had only 3% of its competitor’s functionality (Microsoft Word); yet, it was great at what it promised – simplicity and collaboration.
Another example would be Snapchat, that originally provided one simple function. One tap for a picture that is taken there and then, sent, received and instantly deleted. Everything else, like videos, filters, social media features etc. came much much later.
Complete is not the same as completed
The product must be complete, it must satisfy the core promise that it aims to achieve. Hence it must be developed as if it were a final product, a v1.0, from the get-go. Customers want to use a finished product that solves their pain points, and provides them value, makes it feel like it is a finished product, whatever that may be.
The problem with MVPs is that often they outright declare that the product is in development, more features to come etc. This screams to the customer that they are being used as Guinee pigs for testing, and no one enjoys that feeling.
It does not mean that no more features can’t be added later, however the product upon its release will always fulfil its main promise. All the extra bells & whistles are simply bonuses and improvements to the core product.
Lovable products are those that are designed to be enjoyable
When developing MVP projects, we rarely focus on the clients wants, rather their needs. And that might sound perfectly fine, however it has the fundamental problem of disregarding the client’s choice. “More features” does not equal success.
And often times good brand reputation, fantastic UI, memorable UX, or even smaller things like knowing your target audience and prioritizing/relating to their user stories makes all the difference.
So, what do we have? A SLC!
A fully designed simple application, with a simple core feature, that is fun to use, fun to share and brings instant and constant value to the customer is what SLC is all about!
Most importantly, a SLC product does not require constant investment or ongoing development, it already adds business value. It’s perfectly possible for your product to continue evolving for years to come into v3.0 and v4.0 with more features and functionality.
There is also no rush to with SLC products to add features or fix issues. Due to its design, it already provides value, and there are no broken or missing features. A SLC product that suddenly and unexpectedly ceases to be sponsored, doesn’t fall apart, it has already achieved its planned goal. An MVP that suddenly runs dry, is simply an incomplete product.
And if a SLC fails, well it was one single feature app, an experiment with minimum investment. Much like an MVP, it’s there to allow product owners to test a hypothesis, if it failed, well it still succeeded as an experiment.
On the other hand, if it succeeds, there is no rush to add anything new, it already does what it meant to do. It already provides you and your clients value.
You can start planning and building a v2.0 by asking for feedback from existing users on what they would like in the next iteration.
And finally remember – not every application must have dozens of features and be complex.
Sometimes it’s enough to be – Simple, Lovable & Complete.
With that, we finish our dive into the SLC, we really enjoyed playing the devil’s advocate for this topic. By the three articles we have already dedicated to MVPs, it will come to no surprise that we still believe in it and will continue singing its praises and using in our own projects. However, since we believe in best-fitting scenarios, SLCs are and always will be on our radar. After all, we’ve just been selected among the Top Enterprise Software Development Companies by Designrush – and EBS Integrator lives to the title.
But what do you think dear reader? Do you think focusing on a single core feature as if it were a final product is the right way to go? What experiences have shown you that perhaps MVPs are being misappropriated as an excuse?
Please tell us in the comments section below, and as always.
Stay classy business and tech nerds!