A la fecha de este artículo, ya pasaron once años del lanzamiento del App Store de Apple y hay disponible más de 2.000.000 de aplicaciones para iOS y casi 3.000.000 para Play Store de Android.

Al crear un nuevo producto digital, y en particular uno exitoso, el secreto está entre quien lanza primero la app de algo revolucionario (por ejemplo Uber) o quién la escala apropiadamente (el caso de las Stories, innovado por Snapchat, pero que terminó siendo popularizado por Instagram).

Suele decirse en esta industria que “el primero en hacerlo, es el primero en tener éxito” y si bien puede ser cierto en la mayoría de los casos, no siempre se da así. Sin dudas es un gran debate para tener: ser el primero en hacerlo o escalar una idea a un nuevo nivel.

Este artículo explica los dos componentes principales para la planificación de un producto digital, pensándolo particularmente para una app mobile: el mínimo producto viable (MVP, de sus siglas en Inglés) y el roadmap. Ambos comparten estrategias y tácticas que se pueden aprovechar para construir un gran producto de valor rápidamente.

{misc-bullet1}

Planificación ante todo

Construir un producto que llegue a la luz del día, que realmente solucione uno o varios problemas de los usuarios y que además la experiencia sea memorable es un trabajo muy estratégico y táctico.

Para esto se necesitan dos componentes principales y controlar algunas variables que hacen la diferencia. Los componentes son:

1. Mínimo producto viable, o MVP.
2. Plan de ejecución, o Roadmap.

Las variables que se deberían poder controlar o gestionar son:

1. Equipo
2. Cliente (si es desde una agencia)
3. Metodología

Sin los dos componentes principales va a ser muy complicado que el producto se ejecute y sea lanzado correctamente; y además hay muchas chances de que no sea un buen producto. Las variables van a impactar en el día a día de trabajo y, por supuesto, en la calidad del entregable, hasta cierto punto.

{misc-bullet1}

El mínimo producto viable

Antes de empezar a trabajar en un plan de ejecución, hay que definir el producto y su versión mínima, MVP. Mínima porque se basa en qué tan rápido se puede lanzar al mercado.

El MVP es el producto que tiene el mínimo de funcionalidades que son fundamentales para solucionar un problema de los usuarios, puede ser también para ofrecer un servicio nuevo o para mejorar la experiencia de un servicio existente. En este MVP se ancla la propuesta de valor de una startup, empresa u organización. Estas funcionalidades deberían satisfacer a los primeros usuarios, que se animan a nuevas soluciones y tienen una actitud más proactiva a explorar productos digitales.

Como sucedió con el online banking, sólo unos pocos usuarios y clientes bancarios se adentraron en las primeras versiones (en los 90’s y principios del 2000). Estos usuarios (que se los llaman early adopters) se veían intrigados con explorar una nueva herramienta o, muy probablemente, tenían un problema con el banking offline y descubrieron la solución que buscaban en lo digital. Tomó mucho tiempo migrar a la gran mayoría de los usuarios al online banking, pero hay una curva de crecimiento notable.

{misc-bullet1}

Un gran ejemplo es Uber. Ofreció una nueva modalidad de transporte en grandes ciudades, compitiendo con los taxis. La primera versión probablemente fue muy poco conocida por los usuarios actuales, y tenía sólo una sola ciudad, un solo tipo de vehículo (no estaban ni diferenciados), pero una propuesta clave: el transporte se acerca a dónde lo pide el usuario, el conductor sabe el destino con su recorrido y se monitorea en tiempo real.

Simple pero efectivo para viajar por el mundo, en donde no todos manejan el mismo idioma o confían en los taxis. Exitoso, porque ofrece una solución para los pasajeros y ofrece remuneración para conductores.

{misc-bullet1}

Definir el MVP

Si no está bien identificada la propuesta de valor o el problema a solucionar, va a ser muy difícil definir un MVP con las funcionalidades que realmente son necesarias. No debería ser un pedido de los dueños o gerentes (los stakeholders) ni algo que se veía muy bueno en otra app. Estas funcionalidades deberían estar pensadas si son fundamentales para solucionar un problema de los usuarios o si ofrecen

Las startups generalmente necesitan lanzar su producto rápidamente y la definición del MVP tiene que ser más agresiva (pero nunca de menor calidad).

Además, se podría investigar rápidamente si esta solución o propuesta de valor es la primera en el mercado. Con eso se puede decidir si se toma un tiempo adicional para lanzar un producto que supere a la competencia con un MVP más completo o diferente; o bien, lanzarlo rápido para poder empezar a penetrar en el mercado antes de que sea tarde.

Si el producto cubre un nuevo mercado, una nueva idea o una nueva forma de encarar un problema entonces el MVP debería ser construido y lanzado rápidamente y así conseguir las respuestas necesarias para saber si el rumbo que se tomó fue el correcto, y así tener el espacio para pivotear el producto.

Si bien la idea de lanzar un producto y darse cuenta de que no funciona como se esperaba no es agradable, le da mucha experiencia al equipo y un montón de información sobre qué fue lo que falló. Es súper importante no quedarse parado sobre lo que estuvo mal o de quién fue la culpa, sino de cómo se muta el producto para lograrlo.

En Aerolab, tomamos decisiones difíciles pero muy importantes al empezar un proyecto o un producto: ¿Qué es lo mínimo que debería incluir el MVP, para que sea hecho rápido y de la mejor calidad posible? Por supuesto, creemos muy importante explicar el objetivo y el sentido de un MVP bien definido y repetirlo cuantas veces sea necesario. Si usamos la palabra mínimo, tiene que estar muy cerca de la palabra rápido, sino esa reunión va a salir muy mal.

La idea es poder diferenciar qué funcionalidades son importantes y cuáles no. Debería ser una pregunta tan simple como: ¿Sirve el producto sin esta funcionalidad? Al definir el MVP, esta pregunta debería estar siempre presente.

En el ejemplo de Uber, el mínimo para el usuario es elegir un destino, ver el mapa cuando llega el conductor, ver el recorrido, pagar y listo. Para el conductor es ver el pedido del vehículo, tener el destino cargado y poder terminar un viaje. Todo lo demás es extra (pero no menos valioso): el chat, las calificaciones, los descuentos, notificaciones, etc. El producto puede funcionar con sólo lo mínimo, pero por un corto tiempo. Si en el corto plazo no evoluciona, alguien lo va a agregar antes, o lo va a hacer mejor.

Desde el día uno, es muy difícil tener visibilidad acertada de la evolución del producto o de esos extras. La respuesta está en los usuarios, en quiénes lo usan. Generalmente la definición del MVP viene de una necesidad muy precisa, pero la evolución y calidad del mismo parte de los insights y del uso del producto (y, por supuesto, del mercado).

Depende del producto y de la app pero la definición del MVP va a darle sentido al roadmap y un claro objetivo al equipo. Armar un roadmap se va a basar en tres elementos:

1. Propuesta de valor (que debería venir definido con el MVP)
2. Funcionalidades
3. Tiempo

{misc-bullet1}

Roadmap

{misc-bullet1}

El plan de ejecución, o roadmap, es una guía estratégica que determina cómo llevar a cabo la construcción y lanzamiento de un producto. No sólo aplica a productos digitales sino también a cualquier tipo de plan de negocios, organizaciones, etc. Debería orientar a uno o varios equipos para que no hagan las cosas a la deriva. Un roadmap bien hecho debería dar fechas con bastante anticipación y ayuda a planificar otras áreas del negocio.

Un gran producto nace a partir de un gran roadmap que haya sido estratégico y único para ese producto, no debería ser una plantilla.

La definición del MVP y el roadmap tienen que convivir de forma simbiótica, que uno necesite del otro; y que si uno cambia, el otro también. Esta simbiosis se basa en los tres componentes mencionados anteriormente y la dinámica que entra en juego entre ellos:

La propuesta de valor, que prioriza y da sentido a las funcionalidades; y el tiempo en el que se enmarca esta construcción (depende de los deadlines o de las estimaciones).

En el roadmap, lo que no entra en ese marco de tiempo no quiere decir que queda fuera del producto, sino que encaja en las próximas versiones del producto, o en su evolutivo.

{misc-bullet1}

Cómo armar un roadmap

Para darle forma a la explicación, hay que construir un producto de ejemplo. Hay que construir una app para sacar pasajes de avión que compara entre el precio regular y el precio en millas, para averiguar qué conviene más.

Lo primero que hay que hacer es definir el MVP, bajo la regla comentada anteriormente (lo mínimo posible). Para darle énfasis:

1. Si la app no tiene un comparador de precio con millas, no funciona (obviamente).
2. Si no tiene un buscador de recorrido, no funciona (a menos que la idea sea mostrar sólo promociones genéricas, pero no es el caso)
3. Si no tiene un acceso a la aerolínea para reservar el pasaje (en millas o en precio), no funciona (y se podría discutir si puede omitirse).

Listo. Pensarlo por la negativa es más fácil que pensar qué cosas debería tener para que funcione, porque es fácil tentarse y pensar que todo es necesario.

Por ejemplo, integrar un sistema con machine learning para detectar preferencias de viajes y análisis de precios suena súper avanzado y world-class, pero no es parte de la definición del MVP, incluye un montón de esfuerzo extra y tiene varias dependencias difíciles de estimar. Si esa funcionalidad entra en el roadmap, la fecha de lanzamiento se aleja bastante. No obstante, si el MVP lanzado funciona y tiene un mercado, integrar este sistema puede volverse prioritario y puede hacer que el producto escale a otro nivel.

Depende de cada caso, pero el objetivo es encontrar lo mínimo que le dé valor o una solución a los usuarios. En este caso es comparar y recomendar usar millas o pagar el vuelo. Ahora bien, si ya otro producto similar que lo hace, la definición de este MVP debería ser diferente, o, por lo menos, la experiencia debería ser superadora.

Cuando se puede definir bien el MVP, las funcionalidades extra quedan para las versiones evolutivas del producto, y normalmente llega a nombrarse como backlog, que es la lista de funcionalidades (y tareas) que no fueron priorizadas para esta etapa de trabajo.

La fecha de lanzamiento puede definirse por el tiempo del desarrollo de las funcionalidades del MVP, o por una fecha definida por el negocio (generalmente son definiciones estratégicas de cambio o presentación de marca, lanzamientos en conjunto o campañas). Si la fecha es inamovible, se le llama fixed deadline y todo debe planificarse considerando esa fecha límite. Depende bastante de cuánto tiempo hay disponible desde el comienzo, pero un fixed deadline puede ser complicado y limitante para el producto. No todo es negativo, porque hace que la planificación sea mucho más importante y la definición del MVP sí o sí sea agresiva.

Para el ejemplo de la app de millas vs precios, el roadmap se va a armar con base en el tiempo que necesite la construcción del MVP. Para empezar a definirlo es necesario refinar a alto nivel las funcionalidades y estimarlas con el equipo que vaya a ejecutarlo.

Primero hay que detectar si las tres funcionalidades principales necesitan de otro desarrollo o funcionalidad previa para poder ejecutarlas, a eso se le llaman dependencias. Las funcionalidades son:

1. El buscador de recorrido
2. Comparador de precio con millas
3. Acceso a la web de la aerolínea para reservar el pasaje

Para hacer el buscador se necesita tener un servicio de listado de aerolíneas y destinos con aeropuertos internacionales que además filtre por aerolíneas que ofrecen vuelos con millas. Este primer desarrollo es una dependencia para el buscador y el comparador.

En segundo lugar, se necesita generar o utilizar uno o varios servicios para conseguir los precios de esos trayectos en moneda corriente, y lo mismo para conseguir el costo en millas. Y así sucesivamente.

Estas nuevas definiciones van a ayudar a estimar con mayor visibilidad y precisión la cantidad de tareas que hay que realizar. Además, las dependencias son las que hay que realizar primero, así que también define un orden de prioridad. Todo el equipo debería ser parte de esta etapa, ya que una dependencia que no se detectó con tiempo va a convertirse en un bloqueante más adelante o en tiempo extra que no se estimó y complica el roadmap.

En esta imagen, podemos ver un primer roadmap para la app de vuelos con millas con estimaciones de mentira. Primero las dependencias y las historias Must Have:

{misc-bullet1}

Además del orden de prioridad, es importante entender el esfuerzo requerido para desarrollar cada funcionalidad y sus dependencias, para poder decidir estratégicamente cuánto recursos y cuánto tiempo son necesarios para realizarlo.

Generalmente se diferencian las funcionalidades entre las que tienen que estar sí o sí (Must Have) y son parte de la definición del MVP, las que deberían estar (Should Have) y las que estaría bueno que estén (Nice to Have). Este sistema es un nivel más avanzado que funciona o no funciona y establece una escala de impacto para cada parte de un producto.

Volviendo a uno de los puntos del principio del artículo, es normal que, trabajando en una agencia o en un producto propio, haya diferentes partes que exijan el desarrollo de algunas funcionalidades que no son principales para el MVP (básicamente querer convertir un nice to have en un must have). Si bien pueden sumar bastante valor, pueden retrasar la fecha de lanzamiento o reducir la calidad de otras funcionalidades.

Para este caso, hay que saber negociar y justificar el roadmap frente a exigencias de terceras partes cuando se pone en riesgo la fecha de lanzamiento o la calidad del producto. Es mucho más seguro y tangible negociar y defender fechas que cosas más subjetivas como la calidad (y que depende de otras cosas). Como se mencionó más arriba, la gran mayoría de las historias nice to have deberían quedar en el backlog, algunos should have deberían poder sumarse, y todos los must have deberían estar en el roadmap de lanzamiento.

Si un must have quedó en el backlog, entonces se priorizó mal o el roadmap está en economía de guerra y hay que saber establecer expectativas con el equipo y los stakeholders del negocio (los que pusieron la plata básicamente).

{misc-bullet1}

Imprevistos

La mayoría de las veces los planes no salen exactamente como fueron concebidos al principio de un proyecto, y necesita ser iterado varias veces según lo que sucedió en el recorrido, cómo es el equipo, el cliente y la metodología. Con mayor conocimiento y preparación estas iteraciones deberían ser cada vez menores o menos significativas. Lo importante es siempre tener en vista el deadline y la propuesta de valor.

Para cubrir esto, hay que tener un margen en el roadmap definido para imprevistos o tiempos de contingencia. Puede ser sumando un pequeño extra a las estimaciones o generando un tiempo entremedio de algunas funcionalidades. En un producto digital este margen debería ser diferente al bug fixing, porque realmente es un tiempo por si algo sale mal o no como fue planeado.

Lo que siempre sucede con roadmaps que tienen tiempo de contingencia es que el cliente, el equipo o el mismo Product Owner o Manager asume que todo va a salir bien y que el equipo es tan senior que no va a haber bugs. Todo eso es falso. Cuando se asume que todo va a salir perfecto se le llama wishful planning, que se basa en deseos y falsas expectativas. Mucho cuidado con esto, porque puede aumentar la presión y frustración del equipo y setear objetivos inalcanzables.

Ahora, en nuestro roadmap debemos considerar el Plan con contingencia. En este caso es tiempo para hacer bug-fixing, que siempre es muy necesario.

{misc-bullet1}

Si se estuviese construyendo la app millas vs precios, y el desarrollador principal cambia de empresa o se enferma, los tiempos pueden ser impactados. Puede pasar que aparezca un bloqueante inesperado, o que un error sea mucho más complicado de resolver de lo que se esperaba. Son ciento de posibles situaciones que pueden hacer que algo salga mal y el roadmap quede fuera de tiempo.

Si ese es el caso y no había contingencia en el roadmap, es importante transparentar los bloqueantes y los pasos a seguir para lograr el objetivo o, en todo caso, ajustarlo.

Otro ejemplo de imprevisto, y ya mencionado previamente, es la presión de terceros (puede ser un stakeholder, un inversor, el negocio, etc). No siempre sucede pero se suma alguna persona importante en alguna reunión y pide que se agregue una funcionalidad que tenía mucha expectativas de que esté (o que la competencia tiene). Además, por desconocimiento de la tarea, asume que no tiene dependencias o es fácil de hacer. Acá la estrategia vuelve a la misma del principio, poder comunicar claramente el objetivo del MVP, los tiempos y riesgos que puede traer una tarea no planificada y poder lograr un acuerdo.

Por suerte existen muchos stakeholders que saben un montón de productos digitales y de desarrollo, o que no traen presión sin sentido y son un gran motor para hacer un gran producto digital.

En Aerolab insistimos que los stakeholders deberían ayudar a tomar las decisiones correctas, y, si no lo pueden hacer, los ayudamos a que empiecen a pensar en el producto, en sus usuarios y en la estrategia del MVP. No hay que olvidar que son stakeholders por alguna razón, y sus decisiones son muy justificadas.

Se puede tener riesgos que son, por un lado, algo predecibles o, por el otro lado, tener imprevistos completamente inesperados en el transcurso del desarrollo de un producto. Lo único que ayuda en el segundo caso es la experiencia, la suerte y saber reaccionar rápidamente.

Acá hay que tomar decisiones difíciles. Algunas funcionalidades no van a poder entrar por más que se agreguen más personas al equipo o por más esfuerzo que se pida. Lo recomendable es empezar a mover las funcionalidades que son nice to have o should have al evolutivo del producto (o también se lo nombra como “fase 2”).

Es mucho más seguro retrasar algo nice to have del roadmap del MVP que agregar un desarrollador a hacer eso sólo, o, aún peor, sacrificar la calidad y terminación de las funcionalidades must have.

La cantidad de personas deberían aumentar la calidad del producto final. No siempre se trata sobre la cantidad de cosas que se pueden hacer al mismo tiempo.

{misc-bullet1}

Las variables

Como se mencionó al principio se necesitan varios componentes para planificar de forma exitosa y controlar algunas variables que deberían hacer la diferencia. Estas variables son: equipo, cliente o stakeholders y metodología.

Podría decirse que un wishful planning puede ser exitoso, si todas las condiciones de esas variables se dan de forma perfecta. Se podría resolver todas las tareas rápido y eficientemente si:

1. El equipo que se armó para ejecutar el producto es estratégico, experimentado y prolijo.
2. El cliente o los stakeholders acompañan en el roadmap, las definiciones y la propuesta de valor. Y, por supuesto, si el producto y su MVP está muy bien pensado y visionado.
3. La metodología para ejecutar el plan está alineada con los deadlines, la capacidad y forma de trabajo del equipo y el tipo de entregables intermedios que se buscan.

La planificación y la ejecución de un producto se cruza con docenas de variables, algunas controlables, otras no. Estos son algunos criterios para tener en cuenta sobre las variables que se pueden controlar:

1. El equipo debería ser lo más diverso posible para que surjan ideas y soluciones variadas e innovadoras. Por ejemplo, tener personas con un perfil más ejecutivo para liderar reuniones, planificaciones y definiciones, o personas más técnicas para solucionar desafíos complejos; o personas con mucha motivación que quieran probar y aprender cosas diferentes, etc.
2. Conocer en profundidad los procesos y la estructura del cliente, del equipo y/o de los stakeholders. Esto incluye tener en consideración a las personas involucradas desde el principio al final, cuáles son los objetivos grupales y personales de cada uno, que tipo de riesgos y miedos pueden tener, y hasta qué teléfono y computadoras usan.

Mientras más variables se contemplan dentro del plan y más se incluyen en la estrategia, es mucho más probable que se pueda ejecutar el producto de forma exitosa.

En Aerolab, uno de nuestros objetivos es que nuestros clientes terminen un producto no sólo con el producto en mano, sino también con su equipo empoderado y sabiendo ejecutar un proyecto de ese nivel y calidad.

Esta lista de variables a tener en cuenta puede continuar mucho más, pero la regla a seguir es simple y algo obsesiva: especular un número de posibles rumbos del proyecto a corto, mediano y largo plazo. Caminos optimistas y pesimistas para los cuales se arma algún plan y con eso se dispone de herramientas para enfrentar la mayor cantidad de situaciones.

{misc-bullet1}

Evolutivo

{misc-bullet1}

Ningún producto con un buen roadmap se queda en la primera versión. Solo basta con imaginar si Instagram se quedaba con su simple pero encantador “fotos con filtros retro”. Por el contrario, si querían incluir en su app stories, chat, empresas, related posts, y compatibilidad para iPad, no hubiesen lanzado nunca.

Para evolucionar un producto y armar un roadmap de fase 2 estratégico hay que traer herramientas que son del mundo del research de user experience, algunas dinámicas de ideación y hasta un poco de marketing digital.

Realizar pruebas con usuarios de forma reiterada es importantísimo para el producto, el feedback de la gente que lo usa debería pesar mucho más que una investigación, números o pedidos de un stakeholder. Muchas veces se construyen cosas tomando referencias del mercado, pero si el producto es nuevo, la experiencia debería ser única para él.

Mucho de lo que aparezca en las pruebas con usuarios puede que sea crítico para la primera versión del producto, y puede haber cosas que son pequeños insights para mutar el producto a siguiente al nivel.

También puede haber factores externos, como lo que sucede en el mercado o la industria en sí (las nueva herramientas/dispositivos que van lanzando Apple, Google u otros) y también deberían impactar en el evolutivo del producto. Por ejemplo, la interfaz de Instagram se fue adaptando a las tendencias de los sistemas operativos iOS y Android.

De todos modos, es importante saber diferenciar entre nuevas funcionalidades en un evolutivo, contra la visión del producto a largo plazo. Algunas cosas afectan al versionado iterativo del producto, y otras cosas van generando un nuevo rumbo al negocio.

Hay una metodología muy conocida y súper efectiva que son los Design Sprints, que pueden ser un buen experimento para ejecutar y poder validar algunas ideas o hipótesis que se tengan sobre el producto (tanto en su comienzo, como para el evolutivo).

{misc-bullet1}

Todo listo

Armar un producto digital es un desafío emocionante que tiene tantas matices que es difícil tener una fórmula o secretos que funcionen siempre y para todos los casos. Mucho tiene que ver con experiencia y visión, otras cosas tienen que ver con el producto y a veces es un poco de suerte. Sin embargo, este artículo debería dar lugar a experimentar, aprender, ajustar y tener un lanzamiento exitoso.