Digital Stories

The MVP or the Minimum Viable Product continues to create buzz in the world of product development, and it’s not hard to see why – the MVP can be a difficult concept to grasp, but it sure is promising enough to keep everyone on their toes. It has lured me too, and only after falling really hard for it did I come to recognize some of its pitfalls. From initial fascination to my present-day take on the MVP, I will share my own eye-opening journey with you towards building a product that is both minimum and viable.

 My story attempts to clarify the MVP’s role in the product development process to help you set the right expectations in order to build a real MVP. In other words, finding the right solution to your users’ real problems.

The MVP promise

A poster child of the Lean methodology, the MVP is presented as an essential stage in the product development cycle, and without question, it is a great way to figure out if your idea has legs. The way I see it, the core functions of the MVP are perfectly summed up in the following three phrases:

• The MVP helps you get to market faster, with a validated product;

• The MVP should incorporate your core differentiator so that you can monetize your product with minimal resources;

• The MVP is a good foundation for the future development of your product;

The MVP is an up-and-coming concept, but the truth is: for it to really deliver on its promise, you might need to do more than just practice what it preaches. It’s not impossible to build an MVP by the book. However, keep in mind that concepts are not precisely out-of-the-box features that will magically glue everything together.

When you're wearing the Product Owner hat, more often than not, the MVP will prove to be both a real challenge for your team and a puzzling concept for your clients. The key to getting it right? Set clear expectations for everyone involved in the product development process.

Expectations vs. Reality

I clearly recall the moment I discovered the acronym ”MVP.” During that time, I was immersing myself in the Lean and Agile methodologies’ preachings, and it felt like I had discovered a brand new world of software development. I soon became convinced that terms such as Business Model Canvas, Scrum Methodology, MVP, etc., were perfect representations of the approaches and processes that seemed to have naturally evolved out of the Waterfall Methodology’s downfall. I finally felt that I had a thorough understanding of all these concepts and I truly believed in them.

However, as time passed and as some software products were successfully launched while others didn’t get to see the light of day, that sense of clarity that once felt so real began to fade away. What had happened? Let’s just say that theory finally met practice, and they didn’t get along so well. The experiences I’ve had so far building MVPs have definitely altered my initial understanding of the whole concept. Here’s what I’m actually thinking today when I hear people juggling with the term MVP:

What they say / What they really mean

Client: I just want the MVP / I have a very limited, fixed budget, but I want it done asap.

Software Company: Let’s try to scope an MVP / You don’t have a clear understanding of what you’re trying to build.

Software Company: Let’s descope this to get to the MVP / You’re either not focusing on the right thing, or we don’t think it’s feasible (due to the lack of budget, time, or because of other reasons).

Software Company: MVP v.2 / Yet another chunk of functionality 

Everyone: Light MVP or Full MVP? / We’re not getting anywhere

So, is there a way to prevent such misunderstandings, get everyone on the same page and start building a real MVP? Well, there are certainly some things that would help.

To get everyone aligned, put your vision of an ideal MVP aside for a second. Now demystify the whole concept, and focus on the one thing that matters – finding real solutions to your client’s real problems. Picture the final goal with a product mindset. And don’t forget to harness the power of data and focus on users. When it comes to their needs, users always know best.

The musts when building a real MVP

So how does a real MVP come to be? For now, I’ll just highlight a few of the most important prerequisites for building a real MVP:

• You have a clear vision of the product and its impact

Understanding the ‘whys’ of what you’re trying to build is critical. Everyone involved in this early stage of the development process will surely leave their mark on your product, so you have to make sure your team’s actions and decisions are aligned with the product vision.

• You reconcile all stakeholders

It is essential to acknowledge the needs of everyone involved in building an MVP – your product team, your engineering team, and your client must all feel that they’re speaking the same language. Don’t forget to treat the budget and the timeline as you would treat your team, as they too can experience burnout.

• You adopt the Product Mindset

The Agile development process requires your team to shift from a project mindset to a product mindset, which means focusing less on execution, and more, a whole lot more, on the final goal – finding a real solution to a real problem. Don’t forget users are your best friends, and their feedback will help you prioritize.

• You keep things real

If you’re outsourcing the development of your product, make sure the company you’re partnering with shares similar values to yours. Communicating openly is essential, even more so when the stakes are high. Honesty and empathy are the foundation of solid and long-lasting partnerships.

A real MVP is your product

Perhaps the best way to regain clarity is admitting that you were lacking it in the first place. And no one’s to blame for that – concepts such as the MVP are, after all, theoretical by nature. it’s so reassuring to believe that once you’ve mastered the theory, you can just rely on it, and then things will work out as they should.

The way I see it, if you’ve managed to build a real MVP, you’ve already won. You’ve identified an actual problem and came up with a sound solution for it. Of course, your journey doesn’t end here. Still, you’ve already passed the most difficult test with flying colors: you’ve managed to reconcile everyone by setting clear expectations, and you’ve also laid the foundation of your future product by building not an ideal, but rather a real MVP.

Daniel Markovits, Director of Engineering at [e-spres-oh]

If this is your target, but your MVP journey hasn’t started yet, or if it just doesn’t seem to be going in the right direction, we can hop on to guide your next steps. We’re just one click away and ready to help.