You’re doing MVP wrong!

It’s Monday 9:30 in the morning. Employees everywhere inside Sydney CBD offices are making their way to gather against a wall.

What’s happening here? It’s standup time!

My team and I, gather around a post-it clad wall each morning. We talk about what our goals for the day, tasks at hand, and any problems that we anticipate throughout the day.

Wait. WTF is a standup? You may ask.

Standups are quick meetings introduced in Agile ways of working. Agile is a way of delivering work. If you haven’t encountered it yet, then I suggest you try and walk over to your IT department. In there you might see some signs of Agile through post-its on the wall, standup meetings occurring, etc. We will talk about what Agile means in my later posts.

Anyway, back to my story. It’s a brand new day, and once again we are standing up. This time we have a special guest. We have our project’s Chief Architect trying to motivate us. This morning he is talking to us about MVP (Minimum Viable Product).

He describes the concept of MVP using a car factory analogy. Each function dedicated to building functional portions of the car. So for example, there’s a dedicated team for making the windows, the tires, seatbelts, engine, etc. For our project, the groups are divided into functional portions such as reporting, client-facing, infrastructure, and so on.

He goes on to describe that when we release a product increment of our software, we can expect to have the car to have one window, one tire, no seats, no seat belts, and then we build from there.

Hmmm, that doesn’t sound right. Does it? This guy is telling us that for each incremental deliverable, we will be producing a non-functioning car. Only until the end of the project will we find out if all our outputs match to make up a car at the end. And fingers crossed that it all works out in the end!

The finished product. Ta da!

Frankly, this analogy pisses me off. It sets a team to fail in many ways: It tells them it’s ok to do a half-ass job, it’s ok if we create something that is not usable, and it sends the team to uncertainty wondering if they are ever going to hit their deadline.

I want to debunk this shitty definition of MVP for the sake of people in teams who are being led the wrong path.

MVP does not equal shit

“MVP doesn’t mean it’s going to be a shit product!”,

Says my tech co-founder (aka my husband) as we work on the functionality and design of a new app we are building for PilipinasHoops.com. I have just told him that it will be ok not to have particular functionalities because it’s only an MVP release. Realising that after making this call it would create a bad user experience in the app.

I was startled by his response. He was right! Just because we are releasing an MVP, it doesn’t mean that it is acceptable to release a shit product. Oh my, I have fallen into a very common trap of thinking I can get away with a crappy product for MVP. It’s time to bring myself back to reality.

It’s so easy to use MVP as an excuse for a half-ass product which no one will be delighted to use. It’s also a balance not to get into the spiralling hole of features for the sake of features just because it has to be perfect at the beginning.

The whole point of MVP is to prove your initial hypotheses they could be about your users, your market, your initial offer, etc. so that you can use the information to iterate to the next version.

Here’s an MVP example: You are creating a new menu for your cafe. You know that you can make lots of delicious meals but want to know which ones will be your best sellers.

For your MVP menu, you choose to serve among many burgers that you can make — a cheeseburger, a pasta dish which is bolognese, and a baked pastry which is a beef pie. All reliable and straightforward type of dishes for lunch.

MVP Menu

Say your restaurant opens, and your cheeseburger becomes a hit. You noticed that people are requesting for different modifications of your burger. So you iterate and add more burgers in your existing menu. You start to create a burger with beetroot (yes we have and love them in Australia), another with egg (yes, we like that too), another with chicken, etc. And they all start to sell well.

Iteration 1 — Added 3 more burgers in the menu

Then you noticed that no one is ordering any dishes apart from the burgers, so you iterate again and remove the other dishes from the menu. Now you concentrate your efforts on the burgers instead.

Next iteration — we will be selling burgers only bro!

That is the essence of MVP. A usable product that helps us learn a little bit more about your market, product, and users. Then iterate from there.

Minimum Very(unlovable) Product

I laughed when a friend told me a few weeks ago that his company is adopting Agile ways of working. He says that he especially likes MVP. How corporates find an approach to treating it as a Minimum Very (un)loveable Product.

Sadly, this is the truth of the game. Mention MVP to execs and they squirm a bit. They say no to it. That’s because they start to picture all the half-assed products produced in their previous projects which left them never happy. Hence they opt for the big-bang approach. Building it all at once because in their mind there is no way that functionalities will be left out.

So what are they doing wrong?

First up, people are treating MVP as a shit quality product because they are eager to go to market. But when it finally hits the market they find out no one is using it.

Second is when an MVP is released, people don’t measure and monitor how their products are used. In the corporate world, there is no intent to look back and iterate on the product because the project has moved on. By damn, there’s a five year, ten years, and the 15-year roadmap ahead. They are so busy planning for the next supposed strategic product than seeing the performance of the released product. They miss something extraordinary — a living and breathing product is live and is currently being used by customers out there. But even if the customers are unhappy with the product now, that is now the operations problem and not the people who created it.

In fact, this is a typical scenario in the corporate world. No time to measure, learn, and iterate. It makes me think, why use the term MVP when you are not applying the soul of it? No wonder MVP gets a bad rep.

MVP as Minimum Viable Problem

MVP as Minimum Viable Problem is my favourite definition. It’s linked directly to an immediate problem we are trying to solve. By this definition, MVP serves its unique purpose of giving us insight into your market, users, and offerings.

When we built PilipinasHoops.com, our minimum viable problem was will people be interested enough to play our game? Every decision on the features and experience is directly linked to serve an answer to that question. Once proven that yes there is a market, we then iterated on the product feature and experience.

How do I do MVP right then?

How can corporates start to use MVP correctly and take advantage of its value?

1. Release usable products. If it isn’t going to benefit anyone once it’s out on the market (internally or externally), then don’t refer to it as an MVP. That’s just a half-assed product. Think again.

2. Get an accountable Product Owner. One that knows product ownership and has the kahunas to make the calls. Preferably, test their vision of an MVP. We may need to talk about what a Product Owner is later on.

3. Stop the car analogy (for fuck’s sake!). If you still are really into that then use this one. You want to build a Ferrari when your users will only drive it like a Camry (or Volvo if you’re not Aussie — you get the idea :) )

Hey! Thanks for reading! I’m Juliet Lara, I write about life, learning, tech, startups, and communication.

If you enjoyed reading this entry then please share the love by clicking those clapping hands. They give me a boost to keep going :)

You can get in touch with via twitter @julietlspeaks