Unsplash

Are you abusing the term, Minimum Viable Product?

Matthew Akino-Wittering

If you've worked in a software team, you'll have heard the term Minimal Viable Product and everyday vocabulary. Unfortunately, in my experience, the idea of an MVP is frequently misunderstood and abused to deliver a project within a time box. After which, the product development team would pivot to another project. Not before making some very minor changes based upon user feedback.

Unsurprisingly, this practice produced disappointing software and frustrated customers. Therefore, an MVP has to be more than just minimal functionality to delight our customers. Ideally, after the initial release, sustained development would satisfy all the desired outcomes and polish experiences that didn't perform as expected.

However we choose to make an MVP, we need to make it meaningful.

Brian Pagán

Sadly I believe these behaviours stem from utilising an internal technology team as an onsite software agency. Furthermore, I suspect this comes from an I.T. project mentality to procure customer solutions for the current operational problems.

These behaviours are the antithesis of modern software development and prevent organisations from becoming product companies. But through transparency, careful management of expectations, and autonomy, a product development team will deliver a valuable, usable, and feasible product.

While the metaphors present in Henrik Kniberg article "Making sense of MVP (Minimum Viable Product) – and why I prefer Earliest Testable/Usable/Lovable" are perhaps a little confused. If you intended to build a car, I think you'd start with a simple automobile.

Skateboard, Scooter, Bicycle, Motorcycle and Car by  Henrik Kniberg

But, the concept does highlight the need for deliberate iterations and pragmatism, which evolves the software complexity to delight customers.

To get you off to a good start, you should be able to articulate the following clearly to find your MVP:

  1. Who will use your product?
  2. What is the problem you're solving?
  3. What value does your product create? For example, redefine an existing industry, time savings or financial returns.
  4. Is it feasible, and when can it be delivered?
  5. How will the product be monetised, subscriptions or advertising?
  6. Out of all the validated ideas, what is the core functionality?

In Kniberg's article, the "skateboard release" is a crucial point and first production release. Getting to this point is a big triumph and something to celebrate. But your initial version is where the real work starts. It's the point where we being collecting quantitive data from usage and qualitative feedback from customers under production conditions. That's the point of the MVP. Build enough to learn and improve. It will be quite an emotional point as we understand whether our initial version is valuable and usable. However, armed with this new information, we can start the journey of continuous discovery and iteration.

Therefore, I think Kniberg is correct to recommend considering this initial release as your Earliest Testable Product. To that end, I feel that Product Managers should modify our language to suit the audience carefully convey this point. Highlighting it will take successive versions to produce the Earliest Loved Product.

Effectively communicating this point is tricky, as most don't understand the Minimum Viable Product concept. Depending upon the audience, saying prototype may be divisive or confusing. So instead, choose to describe the collection of features as an initial release. Where appropriate, I want to talk about our software in this fashion, as I believe it prepares others to expect further releases to accomplish the desired outcomes.

Minimal Product Timeline

As the product development team includes ideas postponed from the skateboard release, you'll edge closer to the desired MVP and later on a Viable Product. By regularly and carefully factoring in feedback, we can adapt to meet the market's needs and delight our customers. But what we're doing is so much more than adding features.

The following diagram tweeted by Jussi Pasanen epitomises the anatomy of a great MVP. Our products are so much more than a collection of features. They must be usable, reliable and well designed for our customers to have a positive experience.

So, I hope the above was helpful. To close out this short essay, I'd like to leave you with a few closing thoughts which might help you in future.

  1. Use MVP sparingly as it's a loaded term, and be upfront with everyone about the scope.
  2. To help articulate the vision, try writing out the validated ideas as desired Outcomes or ORKs. These techniques will give further structure and allow you to translate them to Epics and Stories easily.
  3. Prioritise your Stories carefully to be lean. It may seem obvious, but prioritising the wrong items can be expensive. Try using the User Story Mapping technique to help confirm priorities to achieve the desired outcome and avoid confirmation bias.
  4. Find a noun appropriate for your organisation to best label the initial release. Skateboard may work for you. But depending on the audience, I use "prototype" or point out "this version is our initial release".
  5. Try to be unemotional about your work and earnest that the feedback is welcome and valuable. Continuous discovery is crucial to ongoing innovation and success.
  6. Finally, attempt to quickly release minor changes discovered through customer feedback after the initial release. Doing so will generate a lot of goodwill for internal products.