El poder del MVP
Hay mucha literatura sobre productos mínimos viables (MVP). No creo que pueda aportar nuevas ideas, pero compartiré mi perspectiva basada en una experiencia con un cliente.
Un producto mínimo viable (MVP) es una versión de un producto con las características justas para satisfacer a los primeros clientes y proporcionar retroalimentación para el desarrollo futuro del producto.
Pongamos contexto. El cliente era una empresa europea líder en el campo inmobiliario—aunque el dominio importa poco aquí. El equipo de producto imaginaba un producto complejo para vender a sus clientes. Para medir la aceptación de los usuarios, ejecutamos múltiples pruebas A/B para encontrar el enfoque más exitoso. El producto era sencillo de implementar, pero decidir qué usuarios deberían ver qué era otra historia. Teníamos que considerar la ubicación del usuario, la ubicación de búsqueda, la última visita, etc. El número de variables era grande, así que ejecutamos las pruebas durante casi medio año para reunir datos significativos.
Este tipo de experimento requiere métricas adecuadas, así que medimos todo. Una vez terminada la prueba, el equipo de análisis hizo su trabajo—y los resultados nos decepcionaron. Quedaron muy lejos de las expectativas. Sin embargo, una pequeña parte del producto resonó fuertemente con los usuarios, y un mes después el equipo de producto construyó un nuevo producto alrededor de ella.
Ahora comienza la historia real. El nuevo producto carecía de las reglas complejas del anterior: sin lógica de ubicación, sin historial de visitas, sin patrones de búsqueda. Los clientes tendrían una sección especial en la página para mostrar sus productos y compartirla como quisieran. Como la parte orientada al usuario ya existía de la prueba anterior, era hora de hacerlo real y empezar a vender.
Tuvimos una reunión para definir la arquitectura y el plan de implementación. Dos equipos de ingeniería, el jefe de tecnología y el propietario del producto—unas 14 personas en salas virtuales a través de países—discutieron el mejor enfoque y estimaron la finalización. Alguien señaló que, dado que los clientes debían comprar el producto, necesitaríamos involucrar al equipo de comercio. El equipo de productos crearía un nuevo microservicio, y el equipo web consumiría y procesaría esos datos para habilitar el producto para cada cliente.
La complejidad se acumulaba de nuevo. Las estimaciones iniciales apuntaban a tres meses mínimo—probablemente más, dada la coordinación entre ingeniería, marketing y diseño. Escuchando estas discusiones, pregunté al propietario del producto: "¿Cómo venderán este producto a corto plazo?" La respuesta desbloqueó un camino más fácil. Inicialmente, un pequeño equipo de ventas contactaría solo a los clientes más importantes. Después, evaluarían qué otros clientes podrían estar interesados.
Con esta información, propuse un enfoque poco ortodoxo. En lugar de construir el sistema complejo, coordinar múltiples equipos y bloquear el lanzamiento hasta que todo estuviera hecho—¿por qué no hardcodear los IDs de clientes? Unas pocas líneas de lógica, y listo. Cada vez que se vendiera el producto, alguien enviaría un email al equipo, y añadiríamos el ID en minutos. Esta solución no escala, pero no pretendía hacerlo. Como las ventas se manejarían manualmente al principio, podíamos controlar el ritmo de adquisición de clientes.
La propuesta fue bien recibida. Podíamos empezar a vender antes y aliviar la presión sobre los equipos de ingeniería. En solo una semana teníamos el producto listo y vendido al primer cliente. Durante los meses siguientes, los equipos trabajaron a un ritmo relajado en la implementación final—una que eliminaría los pasos manuales.
Esa es la historia. Esto es lo que aprendí:
- Mantén la implementación lo más simple posible. Llegarás al mercado antes y podrás relajar algunos plazos.
- Involucra a los equipos de ingeniería temprano en la definición del producto. Diferentes perspectivas revelan mejores soluciones.
- Comparte la visión completa del proyecto con los ingenieros, no solo su parte. El contexto moldea mejor arquitectura.
En conclusión: seguiré practicando lo que considero uno de los rasgos más importantes en un desarrollador—la pereza. Ese instinto me impulsa a encontrar la forma más simple y rápida de resolver un problema.