En Continuum trabajamos tanto con startups como con grandes empresas (las llamadas “enterprises”), y nos encanta trabajar con ambos. Pero seríamos ciegos (y giles) si no nos diéramos cuenta que la naturaleza de startups y enterprises difieren lo suficiente como para tener técnicas y formas de trabajo diferentes según cada caso.
Por lo mismo me sorprende muchísimo cuando muchas startups llegan a nosotros y parten de la misma forma que la industria tradicional: Con un “request for proposal” o equivalente, que describe (en mayor o menor detalle) tooodo lo que quieren que diseñemos y construyamos.
Quizás la mayor contribución de Steve Blank (autor del “Startup Owner Manual” y padre del Customer Development) ha sido diseminar la idea de que las startups no son versiones en miniatura de las empresas grandes tradicionales. Las startups son algo diferente. Las startups son una organización dedicada a buscar un modelo de negocios repetible y escalable, y recién una vez que tienen éxito en eso se empiezan a convertir en empresas más tradicionales. Antes no.
Por lo mismo, si tu startup requiere de una empresa (seamos nosotros o sea otro partner) para hacer los primeros MVPs, no imites a las empresas tradicionales. Es un error.
¿Y por qué es un error?
Simple: Por muy buena que sea la visión inicial de una startup, lo primero que hay que hacer es transformar el cerro de hipótesis y suposiciones iniciales en conocimiento y aprendizaje validado. Y construir un MVP es elmedio para llegar allí, no el fin en sí mismo. Lamentablemente muchas startups deciden hacer un MVP ”big-bang”, que toma un par de meses en desarrollarse y donde se ponen a prueba una docena de hipótesis de una sola vez. En vez de probar hipótesis de a poco, se opta por “construir la app y ver qué pasa”. Citando a Eric Ries:
Desafortunadamente, si el plan es ver qué pasa, un equipo tiene el éxito garantizado — en ver qué pasa — pero no ganará necesariamente aprendizaje validado. Esta es una de las más importantes lecciones del método científico: si no puedes fallar, no puedes aprender.
Y claro, uno cumple el objetivo (ver qué pasa), pero ¿qué pasa si la reacción de los usuarios es tibia (y suele ser así en los primeros MVPs)? ¿Falló la propuesta de valor? ¿O la comunicamos mal? ¿O la app es difícil de usar? ¿O el segmento de usuarios es el equivocado? ¿O genera interés pero no retención? Sepa Moya.
Peor aún: Muchas startups queman todo el capital que han levantado en un único MVP. Así que después de ir y ver que pasa, si los resultados no son tremendamente positivos, la startup muere de inanición.
¿Y cómo evitamos este problema?
Obviamente no hay una fórmula única y segura, pero sí varias técnicas y enfoques que ayudan:
Lean UX. Nuestro enfoque práctico a la experiencia de usuario ha tenido resultados fabulosos con nuestros clientes (y nos ha llevado aconferencias a mostrar nuestra metodología). Al fin y al cabo, si el MVP es un medio para validar suposiciones y a veces un MVP es relativamente caro, cabe preguntarse qué otros medios hay. Lean UX trae las técnicas de la disciplina de la experiencia de usuario para testear y prototipar barato y validar (y muchas veces clarificar y explicitar) las hipótesis y suposiciones sin tener que hacer un diseño gráfico acabado o escribir cientos o miles de líneas de código. No me voy a expandir mas sobre este tema, pero puedes saber más acá y acá. (¿Interesado en ver esto aplicado a tu startup? ¡Contáctanos!)
Un roadmap de aprendizaje, no de features. Recuerda: Tu startup en su frase temprana tiene como objetivo validar y aprender lo que nadie (o muy pocos) ha validado o aprendido antes, en lugar de ir e implementar todos los features que has visto en la competencia o los referentes de tu startup.
Por ejemplo, Zappos (venta de zapatos online, vendido a Amazon por mil millones de dólares) no partió emulando todas las características de una tienda online. Ellos simplemente fotografiaron zapatos de la tienda física mas cercana, pegaron las fotos en una web (sin carro de compra ni nada) y validaron si alguien estaba dispuesto a comprar zapatos. Una vez que efectivamente había gente que compraba zapatos (y el fundador de Zappos tenía que ir a comprar personalmente dichos zapatos a la tienda y enviarlos por correo al comprador) empezaron a construir un sitio web decente.
¿La lección? No te preocupes de cómo tu MVP va a validar sus hipótesis.Preocúpate más bien de qué hipótesis y suposiciones quieres validar primero.
Normalmente, eso lleva a pensar más en qué cosas pueden echar abajo toda la idea (ej: si la hipótesis de que “la gente comprará zapatos sin probárselos primero” falla, no tiene sentido hacer mucho más). Ordenar las hipótesis de tu startup por orden de prioridad es un ejercicio iluminador.
Y además, nos permite a empresas como Continuum ayudarte mejor. Podemos ver cómo construir de la forma mas barata y rápida posible las cosas claves que ayudarán a despejarte el camino en el bosque de las hipótesis a validar, en lugar de desarrollos interminables que duran muchos meses. Podemos tomar las decisiones correctas cuando haya que decidir entre hacer algo híper robusto o híper flexible. Podemos incluir mejores analíticas desde el principio, en lugar de perderse en la maraña de datos (muchas veces mudos) de Google Analytics.
Así podemos ayudarte a tener usuarios, ingresos y levantar inversiones, y no sólo quedarnos en diseñar y construir software.
¿Y por qué debiera creerles?
Porque aprendimos esta lección en la práctica. Por allí por el 2010, y con la mejor de las intenciones, empezamos a trabajar con startups haciéndolo como mejor sabíamos. Para ser sinceros, compartimos las culpas con algunas startups en no encontrar la manera correcta de descubrir conocimiento válidado y también más de una vez optamos por el “construir y ver qué pasa”.
Nos gusta y nos enorgullece construir productos muy sólidos técnicamente, elegantes, bien hechos, bien testeados, bien diseñados, atractivos. Pero no nos conformamos con hacer bien la pega técnica y estética.
También queremos que los productos que hacemos tengan montones de usuarios felices y productivos. Por eso nos cuestionamos constantemente la forma en que hacemos las cosas, las tratamos de mejorar, aplicamos y compartimos lo que aprendemos.
¡Pero tampoco obligamos a nadie a seguirnos! 
Your comment