MVP Product Management

The Concept of a MVP

In my career as a product manager, I ‘ve seen MVP being used (or misused) a lot, especially when it came to developing net new products. Take a look at products like Google Duo, WhatsApp, and Dropbox (back in its starting days) as an example, I’ve learned that if you get your requirements right (talking from the product management perspective here, of course there are other important elements as well, like marketing), the concept of a MVP can be a boon for product managers. As I have seen over the years from other products as well as my own ones, a few concepts could come in handy for product managers when thinking about Minimum Viable Products:

  1. MVP does not always mean alpha or beta product quality – Often time you will hear from various people in the organization, let’s get it out and get the bugs & feedback from customers. While the purpose of a MVP is to get feedback from customers, it is not necessarily a replacement for your test strategy. For a MVP product, it is not important that you release the product with tons of features but rather that whatever minimum you build works so well so that consumers love it. If you get the buggy product out, you will soon realize that consumers are getting frustrated and you are wasting valuable time getting feedback on bugs and fixing those vs things more worthwhile about the product. I have gone through it and it was painful as well as a waste of time coordinating between bug reporting and reproduction.
  2. How to decide for a minimum MVP feature set – This is the hardest question PMs have to answer – when do we say we are ready with version 1.0? There are so many variables playing into your MVP that this can be very circumstantial. It includes variables like time-to-market, free or freemium or a paid only version, management pressure, a completely-new concept or me-too product, available resources, and – most important – company culture. But while thinking about MVPs, PMs should keep few things in mind –
    1. Make sure you understand your requirement classification criteria very well. “Must Have” and “Nice to Have” requirements should be clearly defined in your backlog, be very critical about “Must Haves”. It won’t make for a good MVP if you have most “nice to have” and little to no “Must haves” in it. I would always go to the bucket of “Must haves” in the MVP first (even if related to one or two EPICs) even if I have to leave out “Nice to Haves”. Do one thing but do it so well that customers just fall in love with your product.
    2. Minimum Viable or Minimum Buyable – I have heard this concept of Minimum Buyable from many people. It is certainly interesting if your product is to have a paid version (not relying on free/advertising revenue only). The idea is simple: While I might use and like an MVP product, I may not pay for it. For companies in the freemium space or producing paid-only product versions, it becomes very important to get a version 1.0 out there that people will pay for (especially if they want to monetize version 1.0 itself). Product management can look at various tools to conduct their analysis especially in relation to pricing questions:
      1. Competitive Analysis – especially relevant if the product you are building is similar to what already exists on the market. Completion doesn’t always have answers but if most of them have a similar set of features in the paid version, customers will most likely expect that from yours as well.
      2. Focus groups and surveys – sure, this sounds very old fashioned but they still are powerful tools to get some ideas. Surveys can be especially powerful if you have a way to reach out to a large pool of potential customers (either your existing base of legacy products or new ones).
      3. Conjoint Analysis – Complicated and time consuming but if you have the needed time and resources: go for it.

Now: I joined Avira just over nine months ago and I’ve already seen good evidence of some of these best practices in this company. One example is having a critical look at requirements to identify potential MVPs and make sure a MVP product works well.

Take the Avira Software Updater we released a couple of months ago: It is a shining example of this best practice. It has a limited but essential feature set, it works with no quality issues whatsoever, and we continue to receive great customer feedback on how to further augment the product to make their lives easier, better, and more secure.

Moving down the road, the newest version of our Avira Online Essentials (more information about it coming soon! 😉 ), is being built with a minimum feature set that we have identified using various customer studies (usertesting.com, on-premise usability reviews, customer surveys, and more).

Are you curious about the products mentioned above now? Then take a closer look at our Software Updater.