Magia oscura

Delimitar un MVP es un delicado equilibrio que puede hacer o deshacer una empresa. Todos hemos visto proyectos donde el gasto excesivo en un MVP demasiado ambicioso drenó los recursos y llevó al fracaso. Por otro lado, también hemos visto proyectos y oportunidades desvanecerse porque el MVP no era lo suficientemente interesante y más tarde alguien más lo clava; era una buena idea después de todo… En mis más de 15 años de realizar proyectos y co-crear con muchas personas diferentes, he encontrado estos desafíos una y otra vez, y he tenido mi parte de fracasos y éxitos.

Compartiré mis experiencias y historias de guerra para ayudar a algunos de ustedes a navegar por este terreno complicado.

¿Vale la pena?

MVP, para mí, debe responder solo a una pregunta: “¿Vale la pena mi tiempo?” Y debo gastar la menor cantidad de recursos posible para responder a esta pregunta. El objetivo es poder mostrar lo suficiente a unos pocos clientes/usuarios (o a inversores a veces) para que puedan sentir lo que el producto podría ser, entenderlo y validar que las características que considero importantes son realmente importantes. Los usuarios deberían usar el 100% de las características del MVP de manera natural y pedir algunas más. Eso significaría éxito. Si hay características que realmente no usan, significa que estoy sesgado para hacer cosas que me gustan o que la idea necesita trabajo. De cualquier manera, necesito repensar cuál es realmente el punto del producto que atrae a los usuarios.

Futuro asegurado

Escalabilidad, estabilidad, código limpio, características “geniales” no son importantes y no gasto tiempo en eso; por supuesto, con la experiencia, las cosas salen limpias de manera natural y si has desarrollado tu flujo de trabajo a lo largo del tiempo para automatizar la escalabilidad, entonces puedes tener una solución escalable y limpia en la etapa del MVP, lo cual me sucede la mayor parte de las veces. Pero realmente no dedico tiempo extra a la escalabilidad. Si puede manejar 10 o 20 usuarios, eso está bien.

¿Qué debería haber?

Una heurística fácil sería: si le cuento a alguien acerca del producto por primera vez, ¿cuántas características realmente necesito mencionar (y cuáles) hasta que realmente comiencen a escuchar (destello de interés)? Esas son las características del producto que necesito añadir. Y necesito agregarlas lo suficientemente bien para que la gente las entienda y las pruebe, y así poder contar la historia. Cuantas menos características necesite para contar la historia, mejor puedo centrarme en realmente cumplir esa promesa de calidad y utilidad, incluso si el MVP en sí no resuelve completamente el problema aún. Se trata de que las personas crean en tu promesa de que la herramienta revolucionará sus vidas.

Asombroso pero descartable

Debería estar absolutamente bien tirar el MVP y empezar de nuevo después de un exitoso recorrido MVP. Siempre es mucho más fácil reescribir que escribir. Y cuando ya tienes la confianza y el respaldo de tus usuarios, compañeros e inversores, y has identificado tus características críticas, realmente puedes centrarte en llevar ese producto al centro de atención y prepararte para el éxito.

Esa vez que lo llevamos al extremo

Aquí hay un ejemplo muy ilustrativo de hace tiempo. En 2009, formé parte de un proyecto artístico que requería la creación de una aplicación para iPhone (los iPhones y las aplicaciones eran realmente algo nuevo en ese entonces). Era una aplicación técnicamente muy desafiante que dependía en gran medida de un diseño de UX muy específico, y teníamos casi sin tiempo para ello.

Teníamos que recrear la aplicación de mapas de iPhone pero agregar navegación giro a giro (el iPhone no hacía eso en ese entonces) y añadir instrucciones extras que hicieran que la gente se perdiera e interactuara con otras personas en cada giro del camino y aún así llegar a su destino al final (aunque podría tomar bastante tiempo).

Tuvimos poco más de 3 semanas para hacer esto (un equipo de producción de 2, solo yo programando) y necesitábamos que la aplicación se probara extensivamente y que las instrucciones adicionales estuvieran diseñadas a la perfección. Parecía casi imposible…

Mi colega en ese momento (y socio comercial durante muchos años después), Rui Guerra, tuvo la brillante idea de que el primer prototipo necesitaba estar listo para pruebas unas pocas horas después de la primera reunión. Tenía razón.

Lo hicimos corriendo a comprar cuadernos y bolígrafos, dibujando mapas aproximados e instrucciones en cada página y enviando a todos en el laboratorio a la calle pretendiendo que los cuadernos eran un teléfono. Esto resultó ser crítico y todas las decisiones de diseño más importantes se tomaron usándolo extensivamente durante dos semanas mientras yo luchaba para desarrollar la primera versión funcional de la aplicación.

La aplicación evolucionó de algo tonto a increíblemente interesante al iterar sobre esos cuadernos, y el MVP en realidad se alcanzó antes de que se construyera la primera versión rota de la aplicación.

Cuando logré que la aplicación finalmente funcionara, ya sabíamos exactamente cómo diseñar las instrucciones para que fueran divertidas para nuestros usuarios y, no solo eso, logramos cumplir con la fecha límite; el proyecto fue un éxito. Se podría argumentar que no era un MVP, sino un prototipo, pero estoy seguro de que si la aplicación no hubiera funcionado, simplemente habríamos diseñado e impreso cuadernos realmente bonitos y aún así hubiéramos tenido éxito en el proyecto. Los cuadernos definitivamente respondieron a la pregunta “¿Vale la pena mi tiempo?” y sin eso, nos habríamos rendido.

Espero que esto ayude a alguien, y les deseo a todos un gran éxito.