¿Interesa una herramienta para planificar el vuelo de un dron con anterioridad?

En el penúltimo post vimos cómo podíamos validar nuestras hipótesis a través de prototipos funcionales o no y en el anterior contamos cómo la validación de más alta fidelidad proviene del diseño e implementación de Productos Mínimos Viables.

Retomando nuestra aplicación web de planificación de drones nos encontramos con varias hipótesis que son de alto riesgo para la viabilidad del modelo de negocio. Si recordamos el Value Proposition Canvas:

y las hipótesis que definimos al respecto, observamos que las más arriesgadas son realmente las de utilidad, es decir, mi segmento objetivo, ¿tiene los pains que he identificado? En este caso deberíamos centrarnos en el segmento, que si recordamos era el de pilotos de drones y en el principal pain identificado que es: “es extremadamente incómodo descifrar la web con la información de restricciones de vuelo por zona”.

Entrevista

Desde el punto de vista de la optimización de recursos y presupuesto, lo primero que deberíamos pensar en hacer es una entrevista. Debemos elaborar un cuestionario en el que tratemos de extraer la máxima información sobre las hipótesis que queremos contrastar. En el cuestionario debemos evitar las preguntas con respuestas como sí o no ya que no nos proporcionan información, inclinándonos por preguntas abiertas como: “cuando tienes un vuelo, ¿cómo lo planificas?”, “¿qué problemas te encuentras en dicho proceso?”, etc. Es necesario extraer el máximo de información sin invertir un sólo céntimo en desarrollo. En posts posteriores, abordaremos el tema de las entrevistas más en profundidad.

Website de Aterrizaje (Landing Page)

Como complemento a nuestras entrevistas, en paralelo, vamos a montar una landing page en la que usemos ya el nombre de nuestro dominio web de manera que Google nos empiece a conocer (y a posicionar). Esta landing contendrá información de nuestra aplicación, de las funcionalidades que implementará y, sobre todo, del problema que resuelve. Hemos de captar la atención del visitante indicando qué problema estamos solucionando, si no, se irá de nuestra web de la misma forma que llegó.

Pero, ¿cómo van a llegar a nuestra web? Esta es una buena pregunta. El posicionamiento SEO de Google, hará su trabajo, e irá colocando la web en función de las palabras claves de búsqueda, pero este posicionamiento, sólo funciona bien si la web es dinámica, es decir, si ponemos contenido de manera habitual. Nuestra landing inicial, ni por asomo será así, por lo tanto tendremos que recurrir al posicionamiento por SEM es decir, anuncios en Google y SMO , es decir, anuncios y publicaciones en Redes Sociales para buscar esa llegada a los potenciales clientes.

Una cosa muy importante y que sería de pecado mortal no incluir en la landing, es una Llamada a la Acción. Es decir, proporcionar al visitante la opción de realizar una acción en nuestra web, la que nosotros queramos. Por ejemplo: registrarse para recibir información cuando la web definitiva esté en marcha, hacer un like en nuestra página de Facebook, seguirnos en Twitter, etc. Lo más recomendable, es que se registre, ya que de esa forma obtendremos sus datos (correo electrónico) para “volver a la carga” a cazar a ese potencial cliente en el futuro.

MVP de Baja Fidelidad

Los prototipos anteriores nos permiten medir el interés, es decir, medir si realmente existen los pains que hemos identificado, pero no si la funcionalidad y la forma de usar nuestra aplicación se corresponde a como la habíamos concebido. La landing puede ser un buen comienzo pero, en ocasiones, los clientes se quedan “fríos”, es decir, esperan algo más. Aquí es donde entraría el Producto Mínimo Viable de baja fidelidad como indican Steve Blank y Bob Dorf en El Manual del Emprendedor.

En nuestro caso, el MVP de baja fidelidad debería tener la funcionalidad suficiente para sintetizar los pain relievers de nuestras hipótesis más arriesgadas.

• Información sencilla, fácilmente entendible y en tiempo real de mi zona de vuelo.
• Información en tiempo real de restricciones temporales NOTAM.

Desde este punto de vista, nuestra web habrá de implementar un mapa con información sobre él de las zonas de no vuelo tanto temporales como permanentes así como información de alturas de vuelo permitidas, etc, es decir, una síntesis sencilla de lo que indica la web de ENAIRE sobre dichas zonas. No tenemos que tener el mapa más chulo de internet ni la mejor apariencia estética, sólo ofrecer la funcionalidad de la hipótesis que queremos testear y medir. El objetivo no es tanto monetizar, como medir el impacto, interés y cómo usan los suscriptores nuestra web. Por lo tanto, lo que debemos hacer es:

• Implementar un portal web en el que los usuarios se deban registrar con sus datos.
• Ofrecer una funcionalidad gratis que sea la de restricciones de zonas de vuelo geográficas sobre un mapa. Sencillo, con código de colores y leyendas. Nada más.
• Acceso con pago a información más completa sobre dichas zonas: alturas de vuelo, NOTAM y resto de parámetros sobre el mismo mapa.
• Implementar un sistema que descargue la información de la web de ENAIRE, la interprete y sea capaz de “pintarla” sobre el mapa. Esta parte será la más intensiva en recursos y en la que más haya que invertir, pero ojo, la inversión es mínima en comparación con el desarrollo completo de la aplicación antes de la salida a mercado.
• Conectar la web con alguna herramienta de analítica, por ejemplo Google Analytics.

Una vez hecho esto, mediremos los indicadores principales, que en nuestro caso serán:

• Número de registros de usuarios del servicio gratuito y tiempo de permanencia en la web,
• Número de conversiones a usuarios de pago,
• Número de visitas semanales por usuario a la página.

Con esta implementación de funcionalidades y la información registrada, debería ser más que suficiente para validar o invalidar las hipótesis que hemos planteado. Si tenemos una alta tasa de visitas a la web pero nadie se registra, deberíamos empezar a pensar que el tema no va bien. Si tenemos muchos registros “gratuitos” pero pocos de pago, habría que pensar en que algo no estamos haciendo bien: el usuario no conoce el potencial de la información que ofrecemos (no comunicamos bien nuestra propuesta de valor), o simplemente con la información gratuita es suficiente y el resto no es un pain, etc

medir la reacción de los clientes a nuestro MVP es fundamental, sin ello, todo nuestros esfuerzo sirve de poco

Nos adentramos en el apasionante mundo del análisis de datos para la validación o invalidación de nuestras hipótesis. Este análisis nos puede conducir a la directa invalidación, a la validación parcial o a la validación total. Las dos primeras conllevarán un pivotaje más o menos dramático, es decir, desde la reformulación completa de nuestras hipótesis de problema y solución, hasta ligeras modificaciones en cuanto a pains o gains. O directamente a dar en el clavo con lo que habíamos supuesto y comenzar a consolidar nuestra aplicación mejorándola en el aspecto estético y funcional.