¿Cómo son las hipótesis del modelo de negocio de una aplicación de planificación de vuelos para drones? (I)
Analizamos cuáles son las hipótesis de nuestra app de vuelo de drones
En los últimos posts hemos profundizado en el concepto de hipótesis, en su definición y gestión de las mismas a la hora de diseñar nuestro modelo de negocio. Vamos a continuar con nuestro modelo de negocio de la aplicación de planificación de vuelos para drones basada en una aplicación web. Para ello, conviene, si no lo habéis hecho ya, que leais los post anteriores donde se explicaba cómo extraer las hipótesis de negocio a partir del canvas y cómo formularlas y documentarlas, de manera que podamos seguir la exposición sin perdernos.
En este post, nos centramos en las hipótesis que se derivan del Value Proposition Canvas, es decir, aquellas que nos definen el ajuste problema-solución.
Si recordamos nuestro modelo, estaba basado en una aplicación web de membresía con pago mensual de una cantidad fija, pero con un “gancho” inicial de pequeñas funcionalidades gratuitas.
Hipótesis de Propuesta de Valor
La primera de nuestras hipótesis relacionadas con el segmento de cliente es:
- Los pilotos de drones necesitan planificar sus vuelos con anterioridad para evitar imprevistos.
En este momento, hemos de trasladar a hipótesis no sólo el segmento de mercado en sí sino todo el canvas de segmento de cliente incluyendo Pains, Gains y Customer Jobs.
Considerando que todas las notas pueden ser hipótesis en sí mismas, podemos elaborarlas un poco más como sigue:
- Los pilotos de drones planifican sus vuelos con anterioridad teniendo en cuenta permisos de vuelo y meteorología.
- La labor de planificación es ardua ya que la información de áreas restringidas al vuelo es rebuscada y compleja de entender.
- Las herramientas actuales, sean apps, webs, etc no tienen información tan detallada como la web oficial y supone un riesgo en ocasiones.
- La identificación del dron cuando vuelo se hace complicada si las FF.SS me solicitan la identificación_.
- Posibles cambios de última hora tanto meteorológicos como de restricción de vuelos (NOTAM) no me son notificados a no ser que los mireproactivamente_.
Con estas hipótesis tendríamos identificado el problema que merece ser resuelto, aunque hay que validarlo.
de poco sirve construir un modelo de negocio sobre algo que no es un Pain real o sobre una solución que no resuelve ningún Pain
Por otra parte, tendremos que identificar la solución que mejor encaja en los clientes, que también habremos de validar: ajuste problema-solución.
En este caso, podemos enlazar hipótesis de solución con su correspondiente Pain y el Product and Service que genera el Pain Reliever:
- La solución ideal será un sitio web que muestre información procesada, en tiempo real, y sencilla de entender sobre las zonas con restricciones de vuelo a través de un mapa.
- El sitio web mostrará información meteorológica en tiempo real de las zonas donde se realizará el vuelo, lanzando avisos en caso de cambios de última hora_.
Como vemos, las hipótesis encierran las «funcionalidades» que ha de tener nuestras solución y que se representan en las notas en el módulo de Products and Services. Antes si cabe de continuar elaborando hipótesis de negocio, deberíamos salir a validar las que ya tenemos: de poco sirve montar un modelo de negocio sobre algo que no es un Pain real o sobre una solución que no resuelve ningún Pain.
En el siguiente post, veremos las hipótesis correspondientes derivadas del propio modelo de negocio, es decir, del Business Model Canvas.
Autor
Desarrollando y creciendo productos tecnológicos que los clientes realmente necesitan. Ahora, definiendo la estrategia de producto en la proptech RESIDELIA.