Si estás en el área de tecnología y ya tienes algunos años de experiencia, probablemente hayas visto algunos proyectos fracasar. Si eres nuevo, hay algunas consideraciones que tienes que tener en cuenta para evitar tropezar con la misma piedra que ya muchos lo hicieron.
El enfoque tradicional (o cuando no tienes experiencia)
Normalmente, cuando somos nuevos en el área, no hacemos distinción entre crear una startup y un negocio tradicional. Encaramos nuestro proyecto de software de la misma manera en que lo haríamos al abrir un restaurante. El problema es que una startup tiene muchos más riesgos y factores impredecibles que no encontramos en un negocio tradicional. Esto pasa tanto cuando la idea es nuestra, o bien cuando trabajamos en la idea de un cliente.
El enfoque tradicional sería planificar el desarrollo del producto completo, con todas las funcionalidades que pudiéramos imaginar. Crear un producto completo podría durar al menos nueve meses, o incluso años.
Lo que comúnmente pasa en este enfoque es que luego de mucha inversión de tiempo, dinero y esfuerzo, finalmente lanzamos el producto, pero el mercado no responde como esperábamos. Nuestros clientes no entienden nuestro producto, no lo saben usar o peor aún: no lo necesitan.
El enfoque moderno
Un enfoque más moderno y adoptado ya ampliamente en la industria del software es construir el producto de manera incremental.
Comenzamos con lo que se llama un Producto Mínimo Viable (PMV), que es simplemente la versión más reducida de nuestro producto que podemos lanzar para comenzar a aprender de nuestros usuarios.
Realizamos ciclos de desarrollo (iteraciones), y al final de cada ciclo lanzamos una nueva versión de nuestra app, aumentando su complejidad y cantidad de funcionalidades, además de incorporar los aprendizajes obtenidos de las versiones anteriores. De esta manera, vamos ajustando nuestro plan y “moldeando” nuestra app a medida que la construimos.
Obviamente, este enfoque resulta mucho más efectivo, ya que reduce el riesgo de fracasar al incorporar el feedback del usuario a medida que vamos construyendo el software.
¿Cuándo es lo más temprano que podemos recibir feedback?
En el enfoque anterior, si bien es enormemente mejor que el tradicional, requiere que lancemos primero el producto para poder empezar a aprender de nuestros usuarios. Construir un Producto Mínimo Viable podría tomar varias semanas o incluso meses de desarrollo.
¿Cómo podemos hacer para aprender lo antes posible? La respuesta está en el prototipado. Hoy en día existen muchísimas herramientas que nos permiten crear prototipos lo suficientemente realistas de nuestro producto, prácticamente indistinguibles de una aplicación real. Los prototipos realistas nos permiten colocar nuestras ideas ante los potenciales usuarios y observar cómo ellos reaccionan ante nuestra propuesta.
Podemos comparar esto con una película de Hollywood. Cuando vemos una película del Viejo Oeste, lo que en la pantalla aparenta ser una ciudad de esa época es en realidad una fachada construida en un set de estudio. De la misma forma, nuestro prototipo es solo una fachada de nuestra aplicación real. Esto es suficiente para tener feedback accionable y comenzar a realizar mejoras en nuestro producto, ¡antes de comenzar a construirlo!
Construir un prototipo, además, es significativamente más barato y rápido que construir un producto real.
Design Sprint
Existe un método, ideado en Google Ventures, que nos permite bajar a tierra esa primera versión de nuestra idea a un prototipo tangible y realista, y además validarla ante potenciales usuarios reales. Y lo que es mejor: ¡todo esto en solo 5 días!
Este método se llama Design Sprint, y es un enfoque muy utilizado hoy en día por las empresas de tecnología más renombradas del mundo para reducir riesgos y responder preguntas críticas en sus proyectos de manera temprana.
Explicándolo de forma resumida, cada día tiene un objetivo claro y concreto:
Día 1: Entender. En este día se realizan dinámicas específicas para alinear al equipo, encontrar riesgos ocultos y definir el foco del resto de la semana.
Día 2: Idear. En el segundo día se generan soluciones en cantidad. Y al final del día, cada participante termina con una propuesta.
Día 3: Decidir. El objetivo de este día es converger todas las soluciones generadas a una sola.
**Día 4: Prototipar. ** Todo este día es dedicado a la construcción de un prototipo realista. Pareciera imposible, pero con un poco de práctica, es posible construir un prototipo de alta fidelidad en un solo día.
Día 5: Testear. Finalmente, el prototipo es presentado ante 5 potenciales usuarios para evaluar su reacción y recibir feedback en entrevistas individuales.
Al finalizar un Design Sprint, los aprendizajes son evidentes. Y lo mejor de todo es que es un método que funciona (lo dice la evidencia), y te permitirá evitar cometer grandes errores y corregir tu producto antes de comenzar a construirlo.
Si tienes una idea y quieres lanzarla al mercado, o trabajas con clientes para ayudarlos a desarrollar sus proyectos, aprender el Design Sprint te será sumamente útil. ¡Y te ahorrará muchos dolores de cabeza!
Para aprender el método y practicarlo paso por paso, te invito a que tomes el Curso de Design Sprint en Platzi. No te arrepentirás 😉
Curso de Design Sprint Aplicado
