¿Por qué compraría un cliente nuestra aplicación de planificación para vuelos de drones?

Revisado el canvas del mapa de Segmento de Cliente del caso práctico, llega el momento de revisar nuestra propuesta de valor. Es cierto que es muy osado meterse con ella sin haber validado antes, con clientes, nuestras hipótesis sobre pains, gains y customer jobs, pero si conocemos el sector, no estaremos cometiendo disparates (aunque seguro estaremos equivocados en muchas cosas).

Rellenamos nuestra taza de café y miramos fijamente el recuadro. Lo primero, hay que describir brevemente la idea de solución de partida, que sirve para orientarnos: una web para la planificación de nuestros vuelos con dones.

Pain Relievers

Veamos, tenemos dos pain relievers para tres pains:

• “información sencilla y útil en tiempo real de mi zona de vuelo y restricciones” que cubría estos pains: incomodidad de consultar la web con información de las zonas retringidas y las apps existentes carecen de información detallada. Perfecto, sí, pero ¿qué es información sencilla y útil? ¿más texto? o mejor, ¿una representación visual? Eso es, eso aliviaría mi frustración de consultar la web. Si puedo traducir esa información detallada a una representación visual ¡lo tendría! Vale, reformulamos… “representación visual en mapa, en tiempo real de las restricciones en mi zona de vuelo”. ¡Siguiente!
• “Información en tiempo real de cambios en las zonas restringidas de vuelo NOTAM” que cubría el pain… un momento, ¿qué pain? pero… si creo que se repite….. ¿en qué estaba pensando? Esto no tiene sentido. Lo puedo incorporar en el pain reliever anterior, ¿verdad? “representación visual en mapa, en tiempo real de las restricciones en mi zona de vuelo”. Bien, está claro que tengo que incluir TODA la información: permanente y temporal de restricciones de vuelo.
• Por cierto, lo que había considerado un gain “identificación ante las autoridades de mi dron” me di cuenta que era un pain Por lo que, el considerado antes gain creator lo tengo que pasar abajo: “identificación de mi dron en vuelo con su identificador en el registro de AESA” es un pain reliever en toda regla.

Gain Creators

Pasemos ahora al módulo de los gain creators:

• “Información meteorológica en tiempo real sobre mi zona de vuelo”. La verdad es que esto estaría genial como complemento en mi web: un mensajito a móvil una hora antes de irme a volar si la cosa cambia está francamente bien. Pero claro, seguro que lo podemos expresar un poco mejor: “alertas meteorológicas ante cambios en zona de vuelo”. Especifica más “lo que estaría bien”. Información meteorológica es muy genérico, puede ser de cualquier tipo….
• “Aviso en caso de intrusión en zonas restringidas”. Bueno, eso sí que estaría bien, sí. Me permitiría volar seguro sin preocuparme dónde están los límites y con tranquilidad.

¿Se me ocurre alguna cosa más que “estaría bien tener”? Si este fuera el caso, donde tendría que ponerlo es en el módulo de gains del Value Proposition Canvas, en el módulo de gain creators tendría que poner cómo generar ese gain (aunque en muchos casos veremos cómo casi casi son iguales en formulación)

La verdad es que, haciendo una revisión, un gain sería que pudiese volar con la tranquilidad de “tener todo atado”. Se trata de un gain muy emocional pero oye, al fin y al cabo, compramos por impulsos, deseos y sensaciones, más allá de la utilidad que le encontremos (y si no que se lo digan a Aliexpress). Vamos a poner este gain adicional al cual, no hace falta añadir un gain creator ya que los que existen ya lo cubre.

Products & Services

Finalmente, y como comentaba Héctor en su post, esto lo hacemos al contrario de como lo cuenta Alex Osterwalder en su libro. Con los pain relievers y gain creators hemos de ser capaces de definir una serie de características de nuestro producto. A lo mejor no somos capaces de cubrirlos todos, pero sí al menos los más importantes.

Lo primero es qué aspecto tiene mi solución. Revisamos el post-it y vemos que indicamos que nuestra solución sería una «web con la que poder realizar las planificaciones» de nuestros vuelos. Fácil acceso y fácil uso. Será una web no estática que necesitará una lógica en servidor y una lógica en el cliente para dotar así de gran potencia y fiabilidad a nuestra solución. ¿Qué necesita la lógica de nuestro servidor? ¡Está claro! “Una conexión a la base de datos de zonas restringidas al vuelo actualizada a cada hora” y todo ello “representado en un mapa para su fácil comprensión”. Un momento, esto es sin duda una característica de nuestra solución… ¡y no lo hemos puesto en nuestro canvas! Nuevo post-it, escribimos y pegamos. Veamos, estas dos características nos cubren de sobra los dos pains que contemplábamos. De hecho, como vemos en el Canvas actualizado de arriba, la primera característica nos “cubre” los dos pains y, la nueva característica añadida, nos cubre el pain de sencillez de la información. ¡Vaya! ¡Las cosas encajan! (cuidado con creernos nuestras propias mentiras).

Uff, me queda el pain de identificación de mi dron… pero no tengo ni idea de cómo cubrirlo. ¿Cómo lo puedo implementar? Satisfacerlo supondría, de alguna manera, que mi solución estuviese ¿certificada? por alguna entidad, pero ¿cuál? Creo que este tiene mucha miga… de momento no lo voy a abordar. Quizá durante el Descubrimiento de Clientes se me ocurra algo.

Ahora, vamos a ver si merece la pena cubrir algún gain. Vimos que tiene mucho sentido incluir la información de meteorología, sí, mucho sentido. No es crítico, pero tiene sentido. Si analizamos el otro gain, vemos que no debe ser muy complicado implementar una funcionalidad para él: tenemos una representación geográfica de mi zona de vuelo y de las zonas restringidas, si soy capaz de enviar la posición de mi dron en tiempo real a mi web podría recibir un aviso si me paso de la raya… ¡Genial! ¡Terminado!

Sólo una pregunta más, ¿por qué los products and services no los damos por validados ya? Al fin y al cabo son implementaciones de funciones. NO. No dejan de ser hipótesis (que veremos más adelante) técnicas. Esto quiere decir que pueden o no ser realizables. Un ejemplo rápido: si tenemos un pain que es que los recursos de La Tierra se están agotando, un pain reliever (un poco burdo) sería que la humanidad se mudase al planeta similar más cercano (probablemente a varias decenas de años luz). El producto en este caso podría ser un “puente aéreo” entre el nuevo planeta y La Tierra, pero claro, ¿es realizable? Obviamente, con la tecnología de hoy en día, no, no es viable. Pero esto denota dos cosas, o mejor, más bien una, que nuestro pain reliever no es real. Pero esto sólo lo sabremos si son los clientes los que no lo dicen.