I like the Netflix series “Is it cake?” where bakers attempt to mystify guests by crafting cakes that strikingly resemble everyday objects. Through visual illusions, they manage to deceive the guests, leaving viewers unable to distinguish which is which until the host slices them open with a knife.

At times, you need to slice through things to truly understand what’s inside. The same goes for shiny terminologies. In the IT industry, people often use jargon and buzzwords to overhype their work. It happens all the time that when you slice open a ball, it’s actually a cake!

Today, I will slice open one of the most misused terms — MVP (minimum viable product) — and examine its true meaning. Additionally, we’ll explore how we can apply the learnings from The Lean Startup method to our product development process.

The minimum viable product (MVP) is one of the most abused terms in the modern lexicon of software development. I sometimes wish our industry would drop it from our collective vocabulary.

I’ve observed a recurring misuse of the term ‘MVP’ (minimum viable product) in the industry. It is commonly misunderstood and used to describe ‘the initial version of a product,’ which deviates from its correct definition.

You should sense something’s off when you say, “We need to develop this, that, and 500 other things in our MVP,” because the ‘M’ in MVP stands for ‘minimum.’ If your MVP is far from being minimal and lacks a clear hypothesis about what can be learned from its release, then you’re likely misusing the term.

Using correct terminology is crucial, particularly in product development, as it facilitates clear communication and a shared understanding of core concepts. The term ‘MVP’ plays a pivotal role in shaping the mindset of teammates and establishing their fundamental problem-solving approach. When individuals have varying interpretations of ‘MVP,’ the conflict can be significantly intensified.

It is widely recognised that Eric Ries popularised the term in his book ‘The Lean Startup.’ To fully comprehend the rationale behind his promotion of the concept, it is important to examine the contexts in which it applies. He didn’t promote MVP as a silver bullet. We must grasp its appropriate usage and understand how to effectively apply it in real-life scenarios.

It is about managing extreme uncertainty

Eric Ries made it crystal clear in his book, The Lean Startup method is for entrepreneurs who need to effectively manage extreme uncertainty.

“This is a book for entrepreneurs and the people who hold them accountable. (…) The concept of entrepreneurship includes anyone who works within my definition of a startup: a human institution designed to create new products and services under conditions of extreme uncertainty. (…) A startup is an institution, not just a product, and so it requires a new kind of management specifically geared to its context of extreme uncertainty.”

— The Lean Startup

Startups need to allocate resources carefully; otherwise, they risk quickly depleting their capital and facing closure. Establishing a sustainable business under limited resources is a key challenge for the survival of startups.

Startups also face the challenge of managing extreme uncertainty. This means they often have no clue whether their new ideas will actually hit the mark with the market or not. They need to engage in a continuous process of improving and pivoting their solutions to find the right answer a.k.a product/market fit.

I understand the temptation to label any of your first product version as an MVP just because it sounds cool and everyone’s doing it. However, let’s not succumb to the buzzword hype without carefully examining the real meaning.

If you truly want to call your product an MVP, it’s crucial to keep the possibility of the final product open rather than closing it off. Let’s say you have a list of 30 development items that are mandated by important stakeholders and have been agreed upon, confirmed, laminated, and sealed.

In this scenario, the emphasis is on completing and releasing these items rather than actively seeking product/market fit. Therefore, if your plan is to initially develop 10 out of 30 items and deliver them in three batches, It simply remains as the first version of your product, not an MVP.

It should be Build-Measure-Learn, not Build-Build-Build

What distinguishes your product as an MVP is whether you approach it scientifically or not. It is essential to formulate key hypotheses before releasing the product and maintain an open mindset towards experimentation.

“A true experiment follows the scientific method. It begins with a clear hypothesis that makes predictions about what is supposed to happen. It then tests those predictions empirically. Just as scientific experimentation is informed by theory, startup experimentation is guided by the startup’s vision.”

— The Lean Startup

Let’s say I observed that people face difficulties while eating egg tarts because crumbs fall onto their clothes and they end up with dirty fingers. Based on this observation, I formed a hypothesis that states: “If we can modify the shape of the egg tart and improve its wrapping, consumers would be more inclined to purchase them.”

The next step involves baking a different shape of egg tart, such as a bar-shaped one with paper wrapping, and conducting testing with potential consumers. That is MVP. It doesn’t have to be a website or an app. Sometimes all you need is a simple piece of paper, an email, or an Instagram account — whatever can be utilised to test your assumptions.

So, if you want to call your product an MVP, you need to have clear answers to these questions:

• What kind of problem are you trying to solve?
• Which hypothesis are you attempting to test?
• What data or findings are you aiming to gather?

Let’s say when you tested the bar-shaped egg tart with potential consumers, they didn’t respond positively to the idea. They expressed a preference for a quick solution to wipe away crumbs and clean their fingers. In such a case, the next version could be a package that includes egg tarts and a wet tissue. That could be your second minimum viable product.

In this example, you have completed one round of the Build-Measure-Learn feedback loop by building something, testing your idea, and gathering data. For startups, it’s important to keep the wheel spinning fast, putting in minimal effort and gaining maximum insights, and constantly adjusting the product. If you’re just Build-Build-Build without validating your ideas, then what you are creating cannot be classified as an MVP.

In these cases, your product is probably NOT an MVP

We’ve discussed the context and approach to MVP development. Now, let’s slice open your product and find out whether it qualifies as an MVP or not. If any of the following sounds familiar, your product is unlikely to be an MVP.

• What you have to build is already predetermined, leaving no room for exploration.
• Decisions are always made in a top-down manner, without input from practitioners.
• You are operating within a culture that does not embrace failure.
• You are solely focused on building without conducting any testing or learning from the process.
• Suggestions are based on personal preferences or leap-of-faith assumptions rather than being driven by customer or data insights.
• Scope creeps; People want to add features and functions ad hoc without a clear rationale.
• People call it ‘agile’, but it’s simply a waterfall development process divided into multiple batches.
• People call it ‘MVP’ by cramming everything they can implement within a short timeframe, without properly identifying the most critical problems or formulating hypotheses.

Whether it is MVP or not, what can we do to improve product development process?

It is important to have a clear understanding of what you are building. Whether it turns out to be an MVP or not, there is value in adopting the mindset of The Lean Startup. Let’s explore how we can enhance the productivity and maturity of our development process.

1. Use correct terminology

The Lean Startup method doesn’t work in every situation. Some projects require predetermined requirements with limited uncertainty. Then try to avoid using the term ‘MVP’ when it’s not. Could it be an ‘alpha version,’ a ‘proof of concept,’ a ‘pilot,’ or simply ‘version 1.0’? Put in some effort to precisely define your work and make sure it’s accurately communicated.

2. Ask questions

If you’re unsure about what you’re building, don’t hesitate to ask questions. Why are we developing this product? Who will benefit from it? What do we aim to achieve by releasing this product? Why add more features without a valid reason? Keep asking why until you find out the core value of the product and real cause of the problem.

By posing these questions, the team will explore the product vision, business outcomes, and customer responses, which will result in incorporating more Measure-Learn activities. Most importantly, these questions provide meaning to your work. If you truly believe in its value, you’ll feel good about what you’re building.

3. Focus on the most critical problem

The critical first question for any lean transformation is: which activities create value and which are a form of waste?

— The Lean Startup

Money, time, and our brain power are all limited resources. Utilise them efficiently and avoid overloading yourself with a million things based purely on assumptions. It’s important to prioritise problems and focus on the most critical one. Tackle one issue at a time.

4. Talk to people

It’s shocking how many people say they’re practicing user-centered design, but rarely talk to actual users. Don’t be one of them.

— The User Experience Team of One

Create a prototype, recruit the right people, and talk to them. It’s as simple as that. Remember, we are not our users, and unless we talk to them, we will never truly grasp how they feel about our solutions. Without their input, the feedback loop will be incomplete.

5. Nurture a culture that embraces failure

Failure is a valuable learning opportunity. Conduct retrospective sessions, encourage people to take risks and learn from their mistakes. Stop blaming others. If your corporate culture doesn’t embrace failure as a valid option, people will be hesitant to propose new ideas. Innovation thrives in an environment where failure is accepted and seen as a stepping stone towards progress.

I strongly believe in the importance of using terminology accurately. Moreover, when you come across a term that you’re unfamiliar with, the willingness to delve deeper, study, and make it your own is crucial for personal growth. Avoid using jargon simply because others are doing so; instead, think critically and develop your own vocabulary.

If we have a solid understanding of the ‘Lean’ approach and embrace its principles, we can make a significant positive impact on our teammates and the overall working culture. I hope this article helps you in your journey to create a better workplace for yourself and those around you.

More articles written around this topic