#5 Diseñando la prueba de concepto de nuestro nuevo producto
En esta newsletter hemos ido contando cómo hemos dedicado unas pocas semanas a analizar una nueva idea de negocio desde el punto de vista del problema, del mercado y del cliente. Y ahora por fin, empezamos a definir la solución que tenemos en mente.
Con ello comenzamos la fase de validación. Una fase que gustará a los más puristas de producto y que pinta de la siguiente manera:
En esta segunda parte del proceso, lo que queremos conseguir es:
Definir el modelo de negocio. Hasta ahora hemos jugado con una idea de negocio a alto nivel pero debemos empezar a proyectar detalles como el precio, los canales de adquisición, las alianzas estratégicas o la estructura de costes, entre muchos otros. Aquí el objetivo es tener una idea completa del negocio futuro que poder incluir en las pruebas que hagamos.
Crear una prueba de concepto. Antes de escribir una línea de código diseñaremos un prototipo de la solución a varios niveles que poder probar en el mercado. (La carta de hoy se centra en este paso).
Construir y evolucionar un MVP. Construir una versión de la solución que incluya una mínima unidad de valor que poder lanzar, compartir y probar frente al mercado. En todo ese ejercicio de pruebas, lo natural será seguir evolucionando la solución con lo aprendido.
Buscar señales de PMF. Con la solución en el mercado, saldremos a adquirir y retener los primeros clientes. Este es un objetivo estratégico de la compañía para considerar la oportunidad inicialmente validada. Aquí no nos preocupa hacer cosas que no escalen.
Validar canales y escala. Aquí sí pensamos en eficiencia y hacer cosas que escalen. También en ampliar la inversión, ampliar el equipo dedicado, etc. Con unos primeros clientes disfrutando satisfactoriamente del producto, en esta última fase buscamos encontrar señales de escala, de viabilidad del modelo de negocio y de rentabilidad. En nuestro visión de compañía, cada línea de negocio del portfolio debe al menos aspirar a facturar entre 3 y 10M€ de ARR. Dejaríamos de invertir en un producto que no muestre capacidad de conseguirlo.
La prueba de concepto
Este es el primer acercamiento visual a la solución.
Entendemos esta prueba de concepto o prototipo como tener un diseño de la solución completamente detallado a nivel interfaz y experiencia de usuario. (No somos muy dogmáticos con los términos, creo que la idea se entiende.)
Hablamos de un prototipo pero en realidad son dos. Un prototipo del MVP que lanzaremos a corto plazo y un prototipo de la solución “final” que vemos a largo plazo. ¿Por qué? Porque vamos a utilizar cada uno con un objetivo diferente.
Esto es un reto importante para Óscar, nuestro diseñador de producto dedicado a esta línea de negocio, que tiene la complicada tarea de pensar en micro y en macro de manera paralela. Ponerse el sombrero de visionario para el largo plazo y al mismo tiempo ser capaz de pensar en un producto básico y sin mucha filigrana que poder salir a testear. El pobre me está sufriendo estos días, recortando todo lo que podemos por muy guay que parezca. Como diseñador es difícil podar la solución que tienes en tu cabeza para hacer un MVP básico y gris.
Memes aparte, el cómo lo estamos definiendo no tiene mucha magia. Utilizamos Figma para el prototipo y nos organizamos de manera asíncrona con Notion y Loom, aunque agendamos varios puntos de contacto (reuniones) en las que pelotear cosas e ir bajando los detalles.
¿Y por qué dos prototipos?
Por un lado, el prototipo del MVP nos sirve para lanzar algo al mercado que testear lo antes posible. Le sirve al equipo de Ingeniería para planificar el trabajo de implementación y ponernos manos a la obra. También desde producto podemos hacer discovery con potenciales clientes. Aunque sea básico nos permite ver si tiene sentido ante el mercado y muy importante: ver qué cosas de las que hemos dejado fuera del MVP son realmente necesarias y en caso de serlas, cuáles son más prioritarias que otras.
No vemos hacer discovery e implementar como algo binario y secuencial. Primero haremos discovery con el prototipo del MVP mientras construimos el MVP. Una vez lanzado, haremos discovery con el producto lanzado y seguiremos construyendo la visión del producto. A Steve Blank le gusta esto.
Y ya por otro lado, el prototipo de la solución “final” nos sirve para intentar vender el producto ya con tentative sales. La diferencia es que aquí estamos mostrando la visión final intentando convencer a clientes para que “se sumen” y crean en el proyecto hasta que tengamos la versión de la solución que resuelve su problema. Quizá como beta testers, o con una pre venta. Veremos. Aquí lo explica bien JJ:
De la misma manera, como venimos del modelo de distribución por partners y aunque esta nueva idea de negocio priorice el canal directo hemos visto interés en empresas que tienen en su base de clientes nuestro segmento. El prototipo de la solución final nos sirve para proyectar este producto y alcanzar acuerdos estratégicos que nos metan gasolina en la adquisición.
Reconozco que muchas de estas cosas que comento son nuevas para nosotros. Quiero que seamos cautos y mantengamos todo el equipo un perfil inversor de limitar el downside y maximizar el upside. Si esta idea no la validamos en una ventana de tiempo limitada, a otra cosa. Y así.
Están siendo estas semanas de muchos retos pero personalmente las estoy disfrutando como nunca. No puedo hablar en nombre del equipo pero veo que la energía es otra, todos brillando y subiendo el nivel. Hay algo de magia en crear algo nuevo.
Después de tres semanas fuera he hecho un pit stop en Madrid y he podido hablar de estas y otras cosas con mi amigo Danny. Hemos brindado por crear cosas nuevas y por encontrar esas señales que nos propusimos a principios de año.
Nos vemos en la siguiente, suscríbete para no perdértela (:
He escrito esta carta escuchando Beautiful Strangers, de Kevin Morby.