MVP, 💩 y deuda técnica
Las claves para empezar, tener éxito y cómo hundirte en la miseria cuando acaricias el éxito (en menos de 10 minutos - de lectura)
En este post hablaré de algo muy importante para toda startup. Cómo hacer un producto... y no morir en el intento (o al menos tener alguna oportunidad más) por qué vas a fallar, ¿lo sabes verdad?
Hoy hablaremos sobre el archiconocido MVP (Producto MÃnimo Viable) que nuestro amigo Erik Ries en su famoso libro Lean Startup acuño por primera vez. Mi adaptación adaptación personal la llamo MMP (MÃnima mierda viable), pero antes, para llegar con éxito al desarrollo de ese primer producto hemos de validar el mercado para tener éxito. Por último, hablaremos de MSP (Maximum Sustainable Product) para cuando lo empiezas a petar y tu MVP se queda corto y entonces aparecen otros problemas que no tenÃas previsto...
Antes de nada, si es tu primera vez en estos posts, te animo a que leas un poco más sobre mis locuras del estilo: Éxito y fracaso entre cubatas y ArquÃmedes, ¿Qué es emprender? y la super serie de inversión para startups seed, seguro que luego esto no te parecerá tan raro...
To MVP or not to MVP
La premisa básica de un producto mÃnimo viable es:
Aporta valor con el mÃnimo producto posible
Testea rápido y valida que realmente hay valor (idealmente que alguien esté dispuesto a soltar la pasta, "No money, NO party")
Itera OR mejora OR pivota
Y ya está. Fin de artÃculo.
A partir de aquà hablaremos de la justificación del por qué este acercamiento al éxito es mejor que el tradicional waterfall development. Como siempre, sencillez no implica facilidad y menos aun éxito.
El principal riesgo del desarrollo en cascada es la gestión de la incertidumbre. En un escenario de desconocimiento máximo, hacer, hacer y hacer sin una validación genera que el producto desarrollado simplemente no tenga la respuesta del mercado esperado.
Básicamente, no sabemos lo que el mercado necesite exactamente (Seguramente, ni el propio mercado sepa qué es lo que necesita). Y por ello, nuestro primer producto es muy posible que pueda ser un gran fracaso. Del que podremos aprender algo, seguro. Pero la pregunta, es ¿Podrás llegar a una segunda versión sin morir en el intento?
Si nuestro negocio es en algo que conocemos a la perfección, un mercado conocido y tenemos claro lo que debemos hacer, cómo dirÃan los yankees: "Go big or Go home". Seguramente la incertidumbre que tengas con el negocio sea mucho menor y es posible que tengamos más probabilidades de éxito, (siempre y cuando controlemos todos aquellos aspectos clave del negocio). En el mundo startup ese escenario de partido raramente suele ser caso. No es lo mismo montar un restaurante, y seguro que no es fácil, pero si no es nuestro primer local muchas incógnitas seguramente no haya, al menos no tantas como si decidieses abrir una tienda de todo a 100. No sé si me explico...
¿La pregunta es por dónde empezamos con nuestro MVP?
El secreto (no lo puedes compartir con nadie eh!) es no hacer nada, de producto claro. Encontré un artÃculo fantástico de First Round Review, un VC americano con un blog excepcional que hablaban sobre el MVT, (MÃnimum Viable Test).
If you focus on MVTs instead of MVPs, you get closer to the heart of the question: Can you predict success before you launch? I believe the answer is yes. With the right approach, you can make a strong prediction about your chance of success and reduce (not eliminate) your chance of failure.
En resumen, viene a decir que antes de incluso empezar con tu MVP, primero tienes que validar los tests que te permitan entender dónde tendrás éxito.
Encuentra tu propuesta de valor. Foco en acciones, muchas veces ni siquiera saben lo que quieren. Pero si saben como solucionan un problema, qué acciones toman para conseguirlo. Hazlo KISS: Keep it simple stupid. Sencillo, fácil de entender. Joder que la mitad de este planeta odio tener que pensar...
Lista tus supuestos: ¿Por qué esto no funcionará?
The #1 riskiest assumption is building something people don’t want. Y-Combinator
Por enumerar algunos:
Riesgo de ejecución: ¿Eres capaz de hacer lo que estás prometiendo?
Marketing: ¿Sabes llegar a tus potenciales compradores?
Tamaño de mercado: ¿El pastes es suficientemente grande y atractivo?
Testea el la unidad atómica
Esto no va de átomos, pero si la principal partÃcula está mal, toda la casa que vas a construir en centro se derrumbará si esta tiembla.
Basta, quiero empezar a hacer
Y cuando ya tengas confianza suficiente sobre todo lo anterior, es el momento de ponerse a trabajar de verdad, a lanzar ese primer producto, esa primera mierda viable. Y digo mierda, por que hay un dicho en el sector que si no te sientes avergonzado de tu primer producto, es que vas tarde. Le has dedicado demasiado tiempo.
Realmente tienes que validar tu propuesta de valor en su esencia. Y esa esencia puede ser que todo el proceso sea extremadamente fácil, suave y bonito. Esa esa puede ser tu diferencia. Un proceso que para la gente normal suele traumático, lleno de fricción tu lo simplificas y le poner las letras bonitas. ¿Cuánta gente no estarÃa dispuesta a pagar para ciertos trámites con la administración? por poner sólo un ejemplo... Busca tu valor, diseña tu primera mierda y a vender.
Joder que estamos en esto para hacer pasta, no? Si la gente no paga más de lo que gastas, señores no es una empresa. Es una ONG con problemas de financiación. Si tienes alguien que aguante el chiringuito, pues podrás aguantar, pero no eternamente. A los padrinos se les suele terminar la paciencia bastante rápido...
una vez saques tu MMV, es momento de aprender, mejorar e iterar. Cuando hagas varias veces esto llegarás al momento del MSP (Maximum Sustainable Product). Ahà es donde la fiesta sólo habrá empezado.
Maximum Sustainable Product
O lo que es lo mismo, tienes un problema de cajones. Lo has conseguido, product market fit (Me pregunto, ¿Porqué nos gustarán tanto estas mierdas anglosajonas?). Creces sin parar y no dejas de desarrollas más y más funcionalidades, mejoras de usabilidad y tests a cascoporro.
Hasta que llega un dÃa que tu querido CTO te dice:
Hemos de parar y reimplementar el backjandemauer. Nos llevará mÃnimo 3 meses (tu sabes que serán 5 o 6) Sino lo hacemos, o los servidores petarán y dejaremos de dar servicio.
Llegaste demasiado pronto a ese producto mÃnimo sostenible y necesitas hacer cambios importantes en el producto que te permitan crecer.
Te asaltarán varias dudas, ¿Tienes el equipo preparado para esta evolución? ¿Estaré medio año sin nuevas funcionalidades? ¿Cómo voy a justificar este cambio al consejo? ¿Si no lo hago qué puede salir mal? ¿Si lo hago, y la liamos en la migración a quien corto las pelotas? ¿Si...?
Ese dÃa llegará si todo va bien. La pregunta es si has llegado en el momento correcto, con el equipo correcto y la decisión es clave para la compañÃa. A veces con gastar un 50% más en infraestructura es justificable. La gestión de la deuda técnica, eso ya es harina de otro costal. Tarde o temprano lo pagarás. (Y suele ser caro 😥)
Pero hemos venido a jugar, no?
Cómo dice el dicho, ojalá tengamos esa guerra que luchar. Seguramente aun quede un poco para llegar.
Yo, que he pasado por algo similar te aseguro que es duro, pero cuando ves luego los frutos compensa.