Analizando en detalle el Mapa de Segmento de Cliente de nuestra aplicación

Terminamos nuestra primera versión del Value Proposition Canvas para nuestra aplicación web que nos proporciona información de zonas permitidas de vuelo. Esta noche, mi cerebro ha consolidado mis ideas y he soñado cómo mi avión partía para Bahamas, con mi cuenta en el banco con muchos ceros (positivos se entiende). Además leí el post en el que Héctor detallaba cómo profundizar en el Customer Map… ¡manos a la obra!

Nos acercamos a nuestra pared con los post-it, café en mano y empezamos a pensar de nuevo. ¡¿De verdad yo escribí esto ayer?! Desde luego que no estaba inspirado, no. Toca darle un buen repaso a todo esto porque hoy me parece que no tiene sentido nada de lo que escribí. Pero esta vez, vayamos por partes….. como dijo Jack El Destripador.

Analicemos uno a uno los bloques del mapa de segmento de cliente.

Customer Jobs

Volvamos a plantearnos el origen, ¿a quién me estoy dirigiendo? Pues a pilotos de drones que van a realizar un vuelo y necesitan planificarlo. Ojo, pero cuál es el contexto, porque el piloto también tiene que prepararse el bocata, la coca-cola, etc para su tarde de vuelo, pero no es eso lo que nos preocupa. Nuestro contexto era la planificación del vuelo en sí mismo, es decir, de los condicionantes a la hora de volar. Bien, con esto anterior considerado teníamos:

• Planificar la misión de mi vuelo. Bueno, esto sí parece coherente. Es lo que hago habitualmente antes de salir a volar, con mayor o menor detalle, pero así lo hago.
• Comprobar la meteorología del día y la hora. Aunque haya hecho una planificación “ligera”, al menos este parámetro, siempre se comprueba, no me vaya a ir a volar y me caiga la de Dios es Cristo. Sí, tiene sentido.
• Asegurarme que tengo los permisos y licencias al día. Bueno, sí, tengo un DJI Phantom…. Comprado en Amazon y sin control ninguno. Nadie me ha preguntado mi DNI ni me ha hecho firmar nada. ¿Qué dice la ley? Vale, esta sí que tiene realmente sentido validarla.
• Registrar el dron ante AESA. Bueno, eso si eres “legal”. ¿Pero de verdad para volar un dron de 30 euros tengo que registrarlo en AESA? Pues como tengo mis dudas, tendré que investigarlo.
• Creo que sí queda claro, que volar el dron es un de los trabajos a realizar. Esta casi, casi, la podría dar validada. Cuidado un momento, ahora que pienso, ¡qué error si lo hago!, ¿y si no planifica el piloto…? A validar.

Parece que con los customer jobs no hemos metido mucho la pata. Al menos, pienso más o menos lo mismo que ayer y me he reafirmado en que es necesario validar de manera importante dos temas.

Pains

La madre del cordero. Como no resuelva bien esto, mejor no hacer nada, no voy a poder ni comprar las maletas….. Habíamos definido tres pains importantes: no sé dónde puedo y dónde no puedo volar incluso habiendo planificado anteriormente porque la base de datos de este tipo de información es ininteligible y las pocas aplicaciones que existen en el mercado no tienen información detallada.

Veamos, ¿realmente no sé dónde se puede y dónde no volar un don? La realidad es que sí lo sé, o al menos sí, si me molesto en buscarlo, claro. Lo que realmente me molesta es tener que navegar por esa página infumable… ¡vaya! ¡esto es otra cosa! ¿será el pain realmente que me molesta consultar esa web? Poco usable con información que hay que interpretar, etc… Está claro que me lo han explicado cuando obtuve mi licencia de piloto de drones, pero ¡claro! una cosa no quita la otra… simplicidad ante todo. Pues parece que puedo reformular este pain. Es más parece que lo debo fusionar con el de la información ininteligible…

Vayamos a por el pain restante: “las apps existentes no tienen info precisa y actualizada”. Pensemos… como mucho te vienen unos círculos rojos alertando de que no puedes volar ahí pero ni están todos los que se indican en la base de datos oficial, ni la información de restricciones tiene ese nivel de detalle. Por no decir de las restricciones temporales NOTAM. Bueno, creo que este está bien. Lo dejaremos así y ya lo validaremos.

Gains

Los “nice to have”. Sí, pero cuidado, son deseables, pero van a marcar que los usuarios se decanten por mi web en lugar de las de otros. Repasemos. Disponer de la información meteorológica en tiempo real….. claro. Es obvio. Si estoy en casa y me desplazo para volar y resulta que se levanta un viento que inhabilita el vuelo pues me quedo con cara….. me pego un viaje a lo bobo que podía haber resuelto con un vistazo a la información meteorológica antes de salir. Pero es muy incómodo estar cada media hora consultando, una aviso, eso es lo que mi web tiene que hacer, ¡mandarme un mail con los cambios de meteorología! Parece que no está muy mal este gain.

Continuemos…. avisos en tiempo real de que estoy invadiendo una zona prohibida o próximo a ella. Pffff, ahora visto así, me suena bastante mal. En teoría yo he planificado, ya debería saber dónde me estoy moviendo, lo que me gustaría saber es si se ha lanzado algún NOTAM de última hora… ¡eso! ¡eso es lo que estaría bien!

El último: identificación del dron ante las autoridades. Ya he tenido un “sustillo” con esto por volar en zonas prohibidas, así que estaría bien. Bueno, un sustillo, un buen susto…. de hecho me hubiese metido en un buen problema. Un momento, ¿he dicho problema? Vaya, esto no es un gain es un pain en toda regla. Y de los gordos, además, ya que me puede costar dinero. Este está muy mal colocado, me lo llevo al bloque de pains. Eso es, aquí es donde tiene que estar. Por lo tanto, nuestro Canvas queda de la siguiente forma:

Ahora sí, ya podríamos salir a validar nuestras suposiciones acerca del problema de nuestro segmento. Vemos que no ha cambiado gran cosa, pero sí que hemos entendido mejor el problema y con ello, reformado y reorganizado varios supuestos. Ya podríamos elaborar los primeros tests. Pero antes, vamos a profundizar, como hemos hecho con el bloque de segmento de cliente, en el bloque de propuesta de valor. Esto lo veremos en el siguiente post de experiencia.