Man wearing backpack trying to decide which direction to go

Have you ever had that feeling of not knowing where to start? For writers, it’s called writer’s block. Painters call it blank-canvas syndrome. Entrepreneurs & technologist refer to this phenomenon as analysis paralysis, an affliction experienced by all at one point or another. It’s like having a stroke of genius for the next big idea, but not knowing where to start.

So let’s start by clearly defining the MVP:

A minimum viable product (MVP) is the version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least amount of effort.

Sounds simple … so what’s the issue?

MVP is one of the most misunderstood terms in our product jargon today. We’ve heard from many a client that MVP is really just a crappy version of a product that is an embarrassment to show to customers. Over and over, the dialog goes like this, “let’s just remove these features and call it the MVP version.” Just last week, we heard, “just make it good enough to launch!”

But the purpose of the MVP is to LEARN about customer demand and usability before over-committing resources. To make sure that we are only building what customers want. An MVP is NOT a fully usable product that will delight customers. It is simply a learning vehicle.

So, what’s the problem?

Marty Abbott talks about the need to stay competitive, and how firms need to build great products but they also need to lend these products to the uses and misuses of their customers and learn extensively from them in The Power of Customer Mis-Behavior. He’s basically telling us to focus on discovery and learning what customers really need, not what they say they want.

The point of an MVP is to validate or invalidate a specific hypothesis. This is why we recommend starting discovery as soon as possible and relying heavily on user testing of prototypes. But for some reason, most people hear the word Product and assume that it means the first version of a product. And so, they build that version, release it and guess what…no one likes it. Well…no Duh!

But where to start?

Our advice is this: 一 Don’t wait for the perfect product. Create an MVP and start discovery immediately.

Discovery Happens Along Two Dimensions:

  1. Discovery of the “What” something should do – is product discovery in defining or expanding an MVP. Discovering “What” the feature set (stories) needs to be successful.
  2. Discovery of the “How” something should work to accomplish the best outcome of the what – this is a hybrid of technical and product discovery meant to find the fastest or best path to a result.

Seems straight forward, but many clients have challenges keeping it simple.

One common way companies have overbuilt MVPs is by applying an old prioritization technique used for requirements. Each requirement is tagged one of the following:

  • Must-have
  • Should-have
  • Could-have
  • Would like to have/won't-have

"Must-haves" are the essentials, "should-haves" are really important, "could-haves" might be sacrificed, and "would-likes" probably aren't going to happen.

The problem with this is at least 60% of any requirements list gets classified as “musts.” Several stakeholders demand their request is a “must” and fight like wild dogs to avoid “could” or “would” status.

A vicious cycle is created as stakeholders realize that nothing except “musts” will get done. If it gets to the point where more than 60% of requirements get classified as “musts,” there may even be some “musts” that don’t get done. In some organizations, a stakeholder stampede is triggered every time someone says “MVP,” leading to a bloated first release, unless someone steps in to put stricter limitations on the requirements.

At the same time, other MVP creation pitfalls we commonly see and warn our clients about include:

  1. Making a poor product. The word “minimum” in MVP does not mean bad, buggy or barely usable. “Minimum” means that the scope should be stripped of anything extra. but whatever features remain should be done in an intuitive and user-friendly way. Products should be unique to what the customer is likely to by relevant to size.
  2. Building a product to sell. Change the sales approach for future customers, sell on risk shift – not features. Move to discovery vs. sales-lead contract-based product development.
  3. Difficulty in defining the minimum. Often, you want your first product to be as beautiful as it can be, and you are reluctant to throw away all the nice features you've thought of. As a result, you spend too much time and money, and, even more damaging, lose focus on the core features. The rule of thumb when defining the scope of your MVP is “can we launch without this or not?” This should be your main criteria and then add all the bells and whistles later when the idea is validated.

Our recommended approach to avoid these pitfalls and launch a successful MVP is based on market-driven analysis with a minimum set of features identified for the go to market strategy.

The need for speed

Speed is everything when testing an MVP. Many clients resist launching until a product is “perfect,” but here’s the news flash – it will never be perfect, and holding out for that status could ruin your product going forward.

According to Openview, 50% of SaaS companies fail in their first year due to misunderstanding their market, while 95% close up shop within five years for the same reason. But strong, early MVP assessments allow you to determine whether you’re onto something (or not) in a low-risk environment.

When it comes to launching an MVP, progress is better than perfection. The only goal is to put together a scaled-down version of your product or service and see whether clients are willing to buy in.

If your company is struggling with getting their MVP to market, AKF Partners can help you implement a product strategy consistent with your innovation needs.

Photo by Kun Fotografi from Pexels