Cómo definir un alcance MVP en 3 horas

Cuando una empresa de procesamiento de pagos en etapa inicial me contrató como gerente de productos, la empresa luchaba por crear y entregar un sistema de administración de inventario de manera oportuna. La solución implementada fue una aplicación de teclado simple que no era fácil de usar y, como resultado, estaba causando una pérdida significativa de clientes. Mi trabajo consistía en liderar un equipo encargado de construir el sistema de inventario que expandiría las capacidades de la aplicación más allá de la funcionalidad del teclado.

Debido a que teníamos que operar en una línea de tiempo truncada, creé un enfoque simple pero radicalmente eficiente para concebir, diseñar y construir un producto mínimo viable (MVP) con características principales que coincidieran con lo que buscaban nuestros usuarios. El proceso condensó el alcance de un MVP en una sesión intensiva de tres horas, en lugar de días o semanas, y ahorró a nuestro equipo meses de desarrollo.

Este proceso acelerado de determinación del alcance de MVP se puede utilizar para guiar a cualquier equipo de producto y se puede aplicar a la creación de cualquier producto cero a uno.

Descripción general del caso de uso

Problema: la funcionalidad de teclado simple de la aplicación no brindaba a los usuarios, que eran proveedores, la capacidad de administrar el inventario o seleccionar artículos para agregar al pedido de un cliente.

Restricciones: el liderazgo de la empresa quería una solución entregada en ocho semanas; una posible ronda de recaudación de fondos dependía, en parte, del éxito de una versión mejorada del producto.

Contexto: A partir de un análisis del mercado y después de pasar tiempo con muchos de nuestros usuarios, determiné que estos proveedores necesitaban un sistema de gestión de inventario para optimizar su flujo de ventas. Los vi procesar los pedidos de los clientes: primero, escribieron los artículos solicitados en hojas de papel, usaron calculadoras para contar los artículos y luego ingresaron los pedidos en la aplicación. Estaban usando tres herramientas cuando deberían haber necesitado solo una.

Solución: necesitábamos desarrollar una solución que permitiera a los usuarios cargar sus inventarios en un catálogo digital, administrar esos inventarios y tocar artículos seleccionados para agregarlos al carrito de compras de un cliente, todo dentro de la aplicación.

La decisión del Design Sprint

Como ya sabíamos qué producto necesitábamos desarrollar, opté por renunciar a un sprint de diseño típico: un taller de cuatro a cinco días en el que los equipos colaboran para identificar un desafío comercial importante, recopilar ideas de los clientes sobre cómo resolver el problema, desarrollar un concepto para un producto, diseñar un prototipo y comenzar a probarlo.

Los sprints de diseño son un método efectivo para construir MVP, para aquellos que necesitan identificar problemas centrales y que tienen un tiempo apreciable disponible para desarrollar soluciones. Sin embargo, en las empresas en etapa inicial o en las nuevas unidades de negocios en las organizaciones existentes, los problemas centrales suelen ser evidentes: se han desarrollado conceptos y, por lo general, se ha determinado el ajuste del producto/mercado antes de incorporar a los gerentes de producto, ingenieros y diseñadores.

El siguiente diagrama de flujo desglosa los pasos que tomé cuando decidí que la mejor manera de proceder con este proyecto era omitir el sprint de diseño y comenzar con la sesión de tres horas, también conocida como el inicio del equipo. En esa reunión, los participantes intercambiarían ideas y generarían docenas de ideas para características, y luego reducirían la lista a solo lo que se requería para el MVP.

El proceso de desarrollo de MVP

Preparación

Antes de la sesión de tres horas, querrá recopilar información sobre sus personajes de usuario al conversar y observar a los clientes actuales o potenciales y realizar estudios de mercado.

Luego, cree una presentación para los diseñadores e ingenieros. Debería explicar:

• El problema que estás tratando de resolver.
• El producto que estás construyendo.
• Cómo el producto resolverá ese problema en términos de métricas y UX.
• El impacto previsto del producto en su negocio y el de su cliente.
• Las misiones y objetivos a nivel de empresa y de equipo y los resultados clave (OKR), así como la forma en que el producto ayuda a cumplir esas misiones y lograr esos OKR.

La presentación debe dar a los diseñadores e ingenieros una comprensión sólida del producto para continuar con el alcance del MVP.

La reunión inicial de tres horas

El inicio debe involucrar a todo el equipo de desarrollo, permitiéndoles participar en cada etapa del proceso, desde la ideación y la creación de la historia hasta el desarrollo del concepto MVP. Esto incluye gerentes de producto senior, junior y asociados; propietarios de productos; prospectos de productos (si corresponde); diseñadores de experiencia de usuario; ingenieros de software; e ingenieros de control de calidad.

Consejo rápido: aunque no es ortodoxo, recomiendo incluir ingenieros antes de la etapa de construcción. Por lo general, brindan excelentes ideas y sienten pasión por el producto que intentan mejorar. A la mayoría de ellos les gusta participar en la determinación del alcance del MVP; les ayuda a involucrarse más en el proyecto y ser valorados por los otros equipos.

Reúna a todos en una sala de conferencias o espacio de trabajo virtual. En nuestro caso, éramos 10 personas. Bloquea tres horas.

El producto y los viajes del usuario (60 minutos)

1. Entregue la presentación. (15 minutos)

2. Comience a identificar todas las personas de los usuarios de su producto. Aunque aún no haya identificado ningún flujo o función de trabajo, puede definir la cantidad de flujos que deben construirse. (10 minutos)

   Sugerencia rápida: no haga demasiada ingeniería agregando más personajes de los necesarios. Después del lanzamiento de MVP, los comentarios de los clientes revelarán si necesita funciones adicionales.

   Ejemplo de caso de uso: teníamos tres personas: el gerente de la tienda (o administrador), el cajero y el cliente final. Había otras personas potenciales de alto nivel, como el propietario de la tienda, pero para los propósitos de un MVP, el administrador podría cubrirlos.

3. Mapee el viaje del usuario de principio a fin. Asigne un color a cada persona para ayudar a identificar cada paso del flujo que encontrará un usuario. Para reuniones en persona, coloque notas adhesivas en una pared o use una pizarra. Para reuniones virtuales, use un tablero FigJam o algo similar. (35 minutos)

   Sugerencia rápida: haga que el equipo comparta todas sus ideas y sea granular. Cada paso del flujo se convertirá en una característica que se creará, y cada usuario tendrá un flujo independiente, pero el proceso de delinear los pasos será el mismo.

   Ejemplo de caso de uso: aquí está la lista de características de nuestro personaje de cajero:

   • Abra la aplicación de punto de venta.
   • Inicie sesión con un PIN.
   • Identifique el primer artículo para la compra del cliente.
   • Identificar la cantidad del artículo.
   • Identifique cualquier artículo adicional para la compra del cliente.
   • Agregue un descuento en un artículo (si corresponde).
   • Totalice el costo de todos los artículos en el carrito de compras (en este punto, se muestra el precio total de compra, incluido el impuesto sobre las ventas).
   • Procesamiento completo de pago y pago.
   • Confirma la compra.
   • Permita que el cliente agregue una propina.
   • Cierra la venta.
   • Mostrar el total de todas las ventas diarias.
   • Se agota el tiempo de espera después de un período predeterminado de inactividad (por ejemplo, cinco minutos).

   Nota: Esta lista detalla la mayoría de las características que pensamos para esta persona. Se nos ocurrieron alrededor de 60 funciones en total en todas las personas, con una superposición mínima, ya que el cajero, el gerente de la tienda y el cliente final interactúan con la aplicación de diferentes maneras. Dependiendo del tipo de producto que estés desarrollando, puede haber una superposición de funciones significativamente mayor entre los tipos de usuarios.

   

Características esenciales de los viajes de los usuarios (45 minutos)

1. Agrupe las funciones para cada tipo de usuario en las partes discretas de cada viaje de usuario en una pizarra real o virtual. Luego, dibuje una línea horizontal en la pizarra. Encima de la línea, identifique los conjuntos necesarios para que el producto funcione. Debajo de la línea, coloque las funciones que es bueno tener pero que pueden esperar hasta versiones posteriores. (30 minutos)

   Sugerencia rápida: divida a los diseñadores e ingenieros en grupos para completar este paso, luego vuelva a reunirse para comparar notas. Esto es especialmente útil en reuniones de 10 personas o más.

   Ejemplo de caso de uso: para nuestra aplicación, teníamos 12 conjuntos de funciones en este punto, que cubrían la carga de artículos en el catálogo de inventario, el precio, la selección de artículos para agregar al carrito de un cliente, el pago y el cierre de la venta, reordenar bajo inventario, y más. Eventualmente redujimos el número de conjuntos de características a cuatro.

   Este proceso de eliminación nos ayudó a determinar que el inicio de sesión de seguridad de un usuario no era necesario en la primera iteración de la aplicación. Tampoco estaba agregando un descuento o una propina. También decidimos que el cajero no necesitaba poder mostrar el total de todas las ventas diarias como parte de un MVP, aunque el gerente de la tienda o el propietario sí.

2. Refinar la lista de características. Pregunte "Si esto se omitiera, ¿funcionaría el producto?" Si la respuesta es sí, deje esa característica fuera del MVP; guárdela para una iteración posterior del producto. Si la respuesta es no, debe incluir esa función en el MVP. Al final de este proceso, sabrá lo que realmente se requiere para que su producto sea funcional. A menudo, esto consistirá en solo tres o cuatro funciones para cada conjunto. (15 minutos)

   Nota: Evite crear demasiados conjuntos de funciones en el MVP. Si bien debe anticipar las opiniones discrepantes sobre lo que es más importante incluir, es su trabajo como gerente de producto tomar la decisión. Has investigado y tienes datos para respaldar tus decisiones. En mi experiencia, muchos productos se construyen inicialmente con más solidez de lo necesario, y la mayoría de las empresas preferirían poner algo en manos de los usuarios para que lo prueben y obtengan comentarios lo más rápido posible.

Diseño, pruebas e ingeniería de productos (75 minutos)

1. Pida a los diseñadores que integren las funciones principales en un diseño alámbrico del MVP, que los ingenieros utilizarán para construir la arquitectura del producto. (45 minutos)

2. Permita que los especialistas y diseñadores de productos trabajen juntos en algunas pruebas ligeras de UX del diseño de estructura alámbrica. (15 minutos)

   Nota: Hay muy pocos escenarios de administración de productos en los que debe crear sin involucrar al cliente final, pero en el caso de pruebas y desarrollo rápidos, puede probar un prototipo de diseño internamente o con amigos y familiares que no conocen su producto. Si están confundidos, algunos de sus usuarios también lo estarán.

3. Entregue los wireframes diseñados a los ingenieros para que comiencen a construir la arquitectura del MVP. No tendrán todo lo que necesitan, ni el tiempo, para crear una solución completa, pero pueden comenzar y la arquitectura que construyan se usará al completar el MVP. Mientras tanto, los equipos de producto y diseño pueden continuar probando sus esquemas con miembros internos del equipo o amigos y familiares que actúan como usuarios. Hacer que los equipos trabajen simultáneamente en este paso ahorra tiempo. (15 minutos)

A medida que se vuelva más experto en el uso de este proceso, será más fácil identificar qué características son componentes centrales de un MVP y cuáles se pueden construir más adelante. La práctica también evitará que construyas las cosas incorrectas: es posible que tengas algo en mente para la lista "más tarde", solo para descubrir posteriormente que ningún cliente lo quiere.

Resultados y conclusiones clave

Antes de nuestros esfuerzos, nuestra aplicación era un teclado con los números del 0 al 9, un punto decimal y un botón de carga. Debido a esta limitación y al flujo de trabajo ineficiente que creaba, en el transcurso de un año, nuestra retención había sido baja: alrededor del 20 %. Aunque habíamos estado adquiriendo nuevos usuarios más rápido que nuestra competencia, los habíamos estado perdiendo casi tan rápido.

A lo largo del proceso de creación del MVP, construimos cuatro conjuntos de características clave, todos los cuales tenían un alcance mínimo pero de alta calidad. Un usuario podría ahora:

1. Cargue artículos en el inventario directamente desde un dispositivo móvil simplemente usando una cámara, ingresando un nombre e ingresando un precio.
2. Seleccione esos artículos y agréguelos al carrito de compras de un cliente.
3. Cierra la venta mientras ves los artículos que se venden.
4. Ver la cantidad de artículos vendidos en un período de tiempo determinado.

A los clientes les encantó el producto mejorado. La tasa de retención fue del 45 % entre los nuevos usuarios que aprovecharon la funcionalidad del catálogo para pagar al menos cinco veces durante la primera semana de carga de artículos.

Gracias a la eficiencia de nuestro proceso de determinación del alcance de MVP, construimos y entregamos nuestra aplicación completamente terminada en aproximadamente dos meses. Es probable que ese proceso hubiera llevado cuatro meses o más con un enfoque de desarrollo tradicional, si es que el producto se hubiera construido alguna vez.

Este proceso acelerado ahorra tiempo y dinero. Un sprint de diseño completo puede ser costoso. Comenzar con la reunión inicial hace que mi proceso sea más económico desde el principio, y esos ahorros se amplifican por el cronograma de desarrollo general mucho más corto.

Sin embargo, los dos procesos también pueden funcionar en conjunto: si su equipo ha completado un sprint de diseño para definir un problema comercial central y la solución que necesita crear, puede usar mi proceso para definir su alcance de MVP de manera más eficiente.

Recuerde que este proceso es solo el comienzo: un MVP es un trabajo en progreso que se perfeccionará en versiones posteriores. Una vez que esté completamente construido y listo para ser entregado, recomiendo agregar un interruptor beta que los usuarios puedan desactivar para volver a la experiencia de la aplicación anterior. Aprovechar el software de comportamiento, como Heap, para rastrear cuántos usuarios ejercen esta opción le dará una buena idea de lo que debe agregarse o cambiarse para mejorar su producto en la próxima iteración.