Uno de los mantras más extendidos entre las startups es que antes de construir «nuestro producto soñado» debemos construir primero un MVP (producto mínimo viable) para realizar validaciones con los usuarios. Y aunque esto es cierto también es una afirmación que se puede malinterpretar porque te lanza a la construcción directa y antes de ponernos a construir el MVP podemos dedicar tiempo a realizar validaciones previas que nos minimicen la probabilidad de construir el producto equivocado. Dicho de otra forma, dedicar tiempo a validar problemas y clientes es siempre una muy buena inversión de tiempo y recursos.
Si nos ponemos a construir el producto, aunque sea un MVP, sin validar problemas o segmentos de clientes es muy probable que dediquemos meses de trabajo y recursos en algo que va a costar encajar en el mercado porque lo hemos realizado totalmente de espaldas al cliente. Según CB Insights, el 35% de las startups fracasan porque no existe una necesidad clara de mercado para su producto.
Validar el problema primero puede reducir drásticamente este riesgo y maximizar las posibilidades de éxito.
Así que vamos a hablar un poco de esto.
1. Por qué validar problemas es crucial antes de construir un MVP
Cuando hablo en clase sobre Business Model Canvas y Desarrollo de Clientes siempre suelo hacer mucho énfasis en todo el trabajo previo que hay que hacer para entender a nuestros clientes, hablar con ellos (siempre hablamos del Mom Test), caracterizarlos y, sobre todo, entender el contexto en el que se mueven y si, realmente, tienen el problema que nosotros creemos que tienen.
De hecho, suelo hacer mención al famoso framework de Y Combinator sobre los «ingredientes» de un buen negocio:
- Gran problema que tiene mucha gente.
- Demanda creciente y urgencia en que el problema sea resuelto.
- Los clientes necesitan que se les resuelva el problema sí o sí.
- Están dispuestos a pagar mucho por la solución (y ésta nos deja un buen margen).
- El problema es recurrente u ocurre con frecuencia.
En ninguno de estos «ingredientes» hablamos del producto, estamos hablando del cliente, su contexto y, sobre todo, el problema que tiene que resolver y con cuánta frecuencia le ocurre.
Antes de ponernos a construir un producto hay muchas cosas que tenemos que conocer y validar y, de hecho, si hablamos de un producto tecnológico y complejo, más nos vale construir sobre cimientos sólidos antes que el «edificio se nos venga abajo».
Construir sin validar es como intentar hacer volar un avión sin haber probado antes sus motores. Esto nos lleva a:
– Malinterpretar el feedback del mercado.
– Gastar recursos resolviendo problemas inexistentes.
– Iterar sin dirección clara.
Cuando los clientes rechazan un MVP cuando se lo ponemos por delante, los fundadores enfrentan un dilema:
– ¿Rechazan el producto porque no resuelve el problema?
– ¿O porque el problema nunca fue tan relevante como pensaron?
Fuente: CB Insights y Maxim Poulsen.
El 42% de las startups fracasan porque no logran alcanzar el Product-Market Fit (PMF) así que validar problemas evita que las startups intenten encarar la fase de escalado antes de tiempo e inviertan demasiados para expandir un negocio que, realmente, aún no tiene encaje claro en el mercado y en los clientes.
En SaaS, esto es especialmente crítico. Según un informe de OpenView, el 80% de las startups SaaS fracasan porque pierden enfoque o no logran identificar a su cliente ideal en las primeras etapas.
2. El camino inteligente: validar el problema primero y después construir el MVP
Como decía antes, antes de ponernos a construir un primer MVP funcional que resuelva el problema de nuestro cliente, deberíamos haber validado previamente muchas cosas y, aunque pueda parecer paradójico, podemos construir algún MVP para validar sin que éste responda a la resolución del problema.
¿Perdón? ¿Esto tiene algún sentido? Aunque soy consciente que puede parecer extraño y estemos faltando a algunas de las tesis básicas sobre un MVP, también podemos usarlos para validar problemas (que llevan implícitos al cliente) y la propuesta de valor.
Un MVP es un producto barato y rápido de diseñar destinado a validar un modelo de negocio y a aprender de la reacción de los usuarios. Por tanto, es algo que responde a preguntas como «¿hay usuarios dispuestos a usar mi producto y mi servicio?» «¿están dispuesto a pagar por ello?» y que, por tanto, puede usarse para múltiples cosas:
- Capturar leads y testear el interés de alguien en el producto o propuesta de valor
- Recoger feedback de los usuarios
- Resolver gran parte de las necesidades del cliente (cubrir el 80% de las necesidades del cliente pero solamente con un 20% de las funcionalidades y especificaciones de nuestro «producto ideal)
En esta categoría de MVPs destinados a validar problemas entran cosas como:
- Landing Pages: crear una página simple explicando la solución para medir el interés con formularios o botones de registro. Algo que podemos hacer con Unbounce, Carrd, Google Sites o WordPress.
- Videos explicativos: como hizo Dropbox, usar un video para mostrar la idea sin construir el producto completo. De hecho combinaron un vídeo describiendo el producto con una landing para registrarse en una lista de espera. A esto se le conoce como MVP de «prueba de humo».
- Encuestas y entrevistas: hablar con potenciales usuarios para entender sus problemas. Podemos usar herramientas como Typeform o Google Forms si enviamos formularios o también pautar entrevistas cara a cara.
- Anuncios simulados: crear campañas con Google Ads o redes sociales para medir interés en tu propuesta y, en base al feedback recibido, tomar decisiones con los datos.
3. Algunos casos Reales
Además del caso de Dropbox, otro ejemplo clásico que suelo comentar en clase es el de Zappos.
Antes de construir su plataforma de e-commerce, su fundador vendía zapatos tomando fotos en tiendas locales y publicándolas en línea para validar la demanda.
¿Por qué? Porque en 1999 nadie se planteaba comprar zapatos por Internet, es decir, Nick Swinmurn (el fundador) no sabía si «comprar zapatos por Internet» era un problema o necesidad que se estaban planteando los clientes
Su aproximación fue bastante «pirata» pero efectiva: sacar fotos de las zapaterías de su barrio y publicarlas en su «supuesto» e-commerce para ver la reacción del público y la demanda de pedidos. Esto es mucho más ágil que construir un e-commerce desde cero, comprar stock de zapatos y planificar toda la logística de envío.
Jeff Bezos con Amazon arrancó, realmente, con un enfoque parecido haciendo un dropshipping con los libros.
Otro ejemplo que me gusta mucho es el de Buffer.
Validaron su idea de una plataforma para programar publicaciones en redes sociales con un par de versiones de landing pages que mostraban la propuesta de valor de la empresa y que, si te interesaba, te llevaba a un formulario a modo de «lista de espera» (primera versión) y que, posteriormente, mejoraron a una landing que mostraba los planes y precios para cualificar/segmentar a los interesados por el plan que les interesaba (precio que estaban dispuestos a pagar, es decir, el famoso willingness to pay).
4. Las ventajas de validar problemas primero
Llegados a este punto, las ventajas de validar los problemas antes de construir el producto son bastante claras pero, no obstante, vamos a hacer un repaso rápido:
- Ahorro de tiempo y dinero: iterar sobre ideas baratas es más eficiente que rediseñar un producto completo
- Mayor confianza para potenciales inversores: validar implica mitigar riesgos y cuántos más riesgos hayamos controlado más interesante va a ser nuestro negocio para potenciales financiadores
- Evitar errores de Pre-PMF: validar asegura que estás resolviendo un problema relevante antes de intentar hacer crecer el negocio y morir por el camino.
Fuente: Point Nine Capital.
5. Algunas ideas finales
Construir un MVP antes de validar el problema es como lanzar una flecha sin apuntar al blanco. Validar primero no solo te ahorra recursos sino que también establece una base para poder encarar una fase de crecimiento sobre pilares sólidos.
Como dijo Reid Hoffman, fundador de LinkedIn: «Si no te avergüenza la primera versión de tu producto, probablemente has lanzado demasiado tarde.»
Pero recuerda, esa versión inicial debe estar construida sobre un problema validado y el problema validado también lleva implícito el segmento de clientes al que nos vamos a dirigir.
Hasta la próxima. Nos leemos pronto.
Imágenes: adaptaciones propias de CB Insights, Max Poulsen y Point Nine Capital, Adweek, Joel Gascoigne en Medium, RDNE Stock project en Pexels y GIPHY
Sé el primero en comentar