Is Your MVP Too Big? Is Your MVP Stuck in Development Hell?

Building an MVP is the first milestone toward our dream of creating a product that can achieve product-market fit. MVP stands for Minimum Viable Product, and it’s composed of two critical words: “Minimum” and “Viable.” From an agile methodology perspective, this means starting with the smallest possible product that we can quickly deliver to users to gauge their interest. Will they “like” it? Will they pay for it?

A Dystopian Tale

Imagine this dystopian scenario: a company starts building its first MVP. They begin with ideation, identifying customer jobs, pains, and gains, and crafting Pain Relievers and Gain Creators into a product. Initially, the product is small, fitting the “Minimum” part of MVP.

But then, the founders or CEO pitch the product to investors. Each investor provides feedback, often mentioning buzzwords that tempt the founders to add more features to the MVP. This cycle continues, and the MVP grows increasingly complex. The founders and CEO chase buzzwords, the product team designs new features, and the engineers rush to implement them.

As the MVP grows, none of its functionalities are truly “done” or usable. Testing becomes harder and more expensive, productivity declines, and trust issues emerge. The dream of releasing the MVP becomes vague. The number of personas to satisfy increases, delaying the onboarding of early adopters. The product and development teams grow demoralized, craving the satisfaction of seeing their work impact users.

Under investor pressure, panic sets in. Frustration mounts as validating the MVP seems impossible. Eventually, the strategic team decides to scale back and rethink the MVP. They drop features, focus on specific customer personas, and simplify the MVP. Resources are wasted, and no one is happy.

Common Pitfalls

You might relate to this dystopian tale, or maybe not. But this scenario happens often. I’ve heard this story multiple times in different places, and even experienced it myself in personal projects.

What’s Wrong? Why Does This Keep Happening?

• Excitement, distractions, and external opinions can derail us from our goals. This is one of the hardest parts of building an MVP: ensuring it’s “Minimum” enough to deliver and validate with early adopters.
• Our desire for quick results can lead us astray. The drive for initial funding or perfection can make us forget the essence of MVP. We get lost, drop our compasses, and struggle to find our way back.
• Over time, we may lose sight of what “Minimum” and “Viable” truly mean.

How to Know If Your MVP Is Too Big?

• Delayed Release: If you keep postponing the release to early adopters.
• Growing Personas: If the number of customer personas keeps increasing.
• Lack of Milestones: If there are no small achievements to celebrate for a long time.
• Complexity: If testing and development become increasingly complicated and unmanageable.

The Cost of a Too-Big MVP

• Wasted Resources: Money, time, and opportunities are squandered. Teams become frustrated and morale plummets. The project may never reach the market or fulfill its potential.

The Definition of MVP

Let’s return to the basics: what is an MVP (Minimum Viable Product)? The definition can be quite vague. How do we determine the “minimum” for our product? How do we know if our product is “viable”?

Please take a look at this image below:

MVP Illustration by Henrik Kniberg

Henrik Kniberg’s article offers a helpful illustration to understand the concept of MVP better, I recommend you to read it later. Though the analogy represented by the illustration might not be perfect, it’s worth exploring.

An MVP is often misunderstood. It doesn’t mean delivering a product in pieces. A fragmented product wouldn’t be useful to customers.

Building a Product for Alice

Imagine we have a customer named Alice. She needs to travel from point A to point B daily. Currently, she walks, which is tiring and time-consuming.

We decide to build a car for Alice. Delivering an MVP doesn’t mean giving her a single tire — that’s just a Minimum Product, not a Minimum Viable Product. Alice won’t be happy until the car is complete, which takes a long time.

Instead, we could start with a simpler solution that Alice can use right away, like a skateboard. This initial product is both minimal and viable. By giving Alice the skateboard, we can quickly gather feedback and iterate. This is an MVP.

Thinking in Abstract

When building a product, we shouldn’t rush to a solution. For example, In a tech company, every problem we want to solve should be ended up solved by an App while App isn’t always the answer. We should first understand the problem at an abstract level, design an abstract solution, and then create a tangible implementation that iteratively getting improved.

For instance, Alice’s problem is transportation. She doesn’t specifically want a car; she wants a solution to her transportation issue. Giving her a car might waste resources and not make her happy. Perhaps a competitor offers her a bicycle, solving her problem more effectively.

The “Big Bang” approach carries significant risks. An iterative approach lowers risks and increases the chances of building a product that satisfies customers.

Conclusion

Remember the essence of MVP: “Minimum” and “Viable.” Here are some lessons I’ve learned, ingrained in me since my time at Apple Developer Academy:

• Start with problems close to you — those you or your immediate circle experience.
• Avoid jumping to solutions. Sometimes, the answer isn’t an app but a simpler approach.
• Engage with your user persona regularly. Gather feedback, understand their pains, wants, and dreams.
• Deliver something simple and quick that addresses user needs. And start iterating from there.

Many successful startups began with simple solutions. For example:

• Gojek: Before building their app, they started as a call center connecting drivers and customers.
• Sayurbox: Initially sold groceries on Instagram and door-to-door before becoming a leading e-groceries company.
• Airbnb: Began with founders renting out space in their apartment to conference goers.
• Instagram: Launched as a simple photo-sharing app with filters.
• Twitter: Started as a side project for sharing short status updates.

MVPs are central to Agile Development. They help mitigate risk, gather valuable feedback quickly, and speed up time-to-market. It’s like starting a healthy lifestyle: complicated plans can be overwhelming, but small, manageable steps like jogging or eating less junk food are achievable and impactful.

I hope this article helps you build a better product that can grow and change the world!