Cabecera personalizada

El blog de Mikel Niño
Industria 4.0, Big Data Analytics, emprendimiento digital y nuevos modelos de negocio

The Minimum Viable Product (MVP) understood as a tactic -and not as a product-

We have analyzed before the concept of Minimum Viable Product (MVP), one of the basic tools in Lean Startup methodology. We can find several references detailing the most common mistakes when putting this concept into practice. I think that most of them are caused by how literally we take the "labels" used in a methodology to call its different tools (in this case the MVP). In this post I want to highlight some of the ideas that I find most important to solve these confusions.

Most of the misunderstandings come from using the word "Product" and from the traditional sense we give to this notion in a context of digital solutions development (even when using incremental methodologies), where we usually build prototypes or partial products oriented to a functional demo of how the final solution (or part of it) will be used. In these cases we are talking about coding all or part of the final software product, when in fact the concept of MVP, despite its name, is more linked to the idea of a "contrasting tool" (no matter its implementation) with which we can offer our customer [1] an interaction whose result we want to analyze and [2] a complete perception of the value contained in what the final solution could be, but without necessarily having implemented the complete solution already. Therefore, we are not talking of "products" in a traditional sense, but of a series of "tactics" that can be used in order to expose our proposal of solution to our potential customers.

Given that the degree of development of our solution and, most importantly, our certainty about how correct it is, will vary as our work progresses, depending on that progress we will use different MVP approaches. Just to set some examples, if we are taking our first steps and we have just an idea of our solution's main features and how to describe them to customers, we can build a "landing page" with that information in order to gather (and analyze!) signs of interest from potential customers. If we have a clearer idea of the process that solves the problem, before investing too many resources in programming, we could use certain tactics ("wizard of Oz", "concierge") to solve manually all or part of the process without having to build all the necessary software for its automation, but being able to provide a potential customer with a simulated experience of using the final product.

As we can see, we have a set of different "MVP tactics", some of them closer than others to the traditional idea of a digital product, but all of them based on the notion of the MVP as a means to an end (contrasting and learning), that is, a set of tactics supported by elements of different nature and with varying degrees of "real" software development, but always oriented to validate whether our proposal of solution is the right approach and there are potential customers interested in it.

[Haz clic aquí para la versión en español de esta entrada]

No hay comentarios:

Publicar un comentario