Desarrollando productos exitosos: El caso de Deiser y su proceso de discovery continuo.
Contexto
Tras un desarrollo y lanzamiento de apps exitosas para Jira, Deiser decidió enfocarse en evolucionar el departamento de producto con el fin de iterar las apps actuales y convertirse en un lab de productos in-house capaz de idear y validar apps para toda la suite de Atlassian. Pidieron ayuda a mendesaltaren para implementar un proceso de discovery continuo y aportar en la estrategia de producto de la compañía.
Deiser es, en origen, una consultora que se ocupa de diseñar e implementar en sus clientes soluciones y metodologías agile a través del universo de los productos Atlassian. Estos productos se construyen para clientes como BBVA, Siemens, Glovo, Iberdrola o Iberia.
El reto
El reto que nos proponía Deiser era el de desarrollar un proceso de discovery continuo para que pudieran crear nuevos productos de la manera más óptima. Esto suponía definir el procedimiento de recopilación y análisis de información de este proceso para que puedan lograr tener una comprensión completa y profunda de los objetivos, alcance, limitaciones y audiencia. La meta era que pudieran alcanzar autonomía, habilidades en la ideación y validación de nuevos productos con agilidad de manera interna.
No obstante, el objetivo más inmediato no consistía en desarrollar productos exitosos sino en adquirir las competencias necesarias para aplicar una metodología de discovery nueva de manera que pudieran desarrollar de manera más ágil e intuitiva estos productos o apps.
El segundo reto era que el equipo lograra adquirir el criterio necesario para adaptar este proceso a las distintas circunstancias del mercado y el público objetivo.
El proceso (Fases del Proyecto)
La primera pregunta que les asaltaba siempre era ¿por dónde empezar a desarrollar, cómo acotar los mercados o áreas de servicios de Atlassian?, ¿cómo sabremos que estamos empezando por el lugar adecuado?, ¿a qué usuarios deberíamos dirigirnos?
La respuesta siempre es más sencilla de lo que esperamos: saca de la ecuación todos los factores de riesgo posibles y quédate con las variables de las que tengas mayor conocimiento. Más adelante, con mayor conocimiento, certidumbre y aprendizajes, estaremos en disposición de arriesgar más.
Nuestro proyecto constaba de estas 3 fases principales:
- La inmersión: Teníamos que entender el ecosistema interno y externo de su mercado y empresa para poder proponer un proceso adecuado a su contexto.
- La creación del proceso discovery continuo adaptado: Desde la ideación de un producto hasta la validación del encaje en el mercado.
- Estadios de validación: Visible en cada una de las fases.
Solución
Como todo proceso, el proceso de discovery que diseñamos para Deiser es flexible y dibuja un escenario ideal de la metodología implementada. Delineada por sus épicas, fases y artefactos.
Así se queda el proceso que diseñamos:
No siempre seguiríamos todas las fases ni usaríamos todos los artefactos, porque el valor de un proceso está en saber adaptarlo a cada contexto en particular.
Profundizando en la solución: Creación del Discovery Continuo
El proceso discovery se compone de la fase de ideación, la definición, construcción, lanzamiento y validación.
Fase de ideación
En esta fase se realiza un brainstorming de ideas con diferentes stakeholders de la compañía que tienen valiosos insights sobre los potenciales usuarios, el mercado y sus tendencias.
Cuando trabajamos esta fase, una de las tendencias que observamos durante el brainstorming es que el equipo giraba todo el tiempo entorno a las mismas ideas de manera inconsciente y había que generar alguna dinámica para crear respuestas más disruptivas. En este caso usamos el Opportunity Solution Tree para desbloquear.
Tras esta sesión, se curan las ideas y se envían al framework de priorización para decidir qué idea debería ser el germen de nuestro próximo un producto. El framework por el optamos fue el RICE (Reach, Impact, Confidence, Effort). Lo elegimos sobre otros frameworks como el ICE porque, por nuestro contexto con multitud de áreas de desarrollo de productos y tipologías de clientes, una variable importante era el alcance (Reach) que tendría cada idea. El siguiente paso es ir definiendo el producto con un product canvas.
Para ello hacemos desk research y entrevistas con usuarios para validar la idea o refinar la propuesta de valor. En esta fase inicial que testeamos, las entrevistas no nos dieron un feedback positivo para validar la propuesta de valor, pero en fases iniciales como la ideación esto no es un síntoma de que debamos abandonar. Si este es el caso entendamos los insights de las entrevistas y volvemos a definir la propuesta de valor buscando el problem-solution fit. También podemos pensar en bajar a tierra prototipos de producto que añadan valor a las entrevistas y ayuden al usuario a entender cómo sería nuestro producto.
Definición
Tras entender mejor necesidades y problemas de los usuarios realizamos una definición más completa con el documento de requerimientos de producto (PRD). Lo importante es que registrara de la forma más específica posible los requerimientos que debemos tener en cuenta para desarrollar el producto. También nos gusta volcar aspectos adyacentes a su desarrollo (propuesta de valor, usuarios, etc) que nos proporcionarán foco para desarrollar su estrategia de negocio y lanzamiento posteriormente.
En nuestro caso, por ejemplo, obviamos gran parte de las especificaciones de diseño puesto que al tratarse de apps desarrolladas para la suite de Atlassian (durante nuestra prueba, trabajamos con un producto para Jira) siempre tenemos que usar el sistema de diseño de Atlassian y no se puede innovar en este sentido. Asimismo, gran parte de su flujo y arquitectura del producto también estaba condicionado por este entorno, pero era importante mapearlo. Volcamos por tanto cosas como propuesta de valor refinada, usuarios objetivo y sus user persona, eventos de analítica sobre el producto, flujos de decisión y navegación, arquitectura o no-gos del proyecto, es decir, aquellas cosas que se iban a quedar fuera en un MVP.
Construcción
Por la naturaleza del ecosistema de Deiser, construir un producto resulta incluso más ágil que diseñar un prototipo animado porque además, para ello tendríamos que captar a usuarios (que no suele ser fácil en muchos sectores). Con este criterio, no incluimos la fase de validación en este paso y se pasa directamente a desarrollar un MVP que se testeará en el mercado real. En el caso del producto que desarrollamos, el equipo de desarrollo lo construyó en un tiempo récord, implementando incluso la analítica de datos en él.
Mientras trabajamos en un plan Go-to-Market Plan donde definimos y terminamos de bajar a tierra una estrategia de marketing: usuarios y selección del mercado objetivo, canales y acciones de promoción, canales de distribución, pricing, calendario de lanzamiento etc
Lanzamiento
Realizar un plan de lanzamiento en un entorno tan específico como un marketplace es complejo y existen algunas limitaciones a tener en cuenta. Una de ellas es la descarga del producto, que sólo puede realizarse desde la landing page en el marketplace o desde el propio producto (Jira), ambas con una estructura predefinida: sólo podemos cambiar el copy y las imágenes para ser persuasivos y posicionar el contenido de manera orgánica.
Intentamos compensar estas carencias experimentando más con canales de promoción como puede ser el patrocinio de newsletters.
Validación de mercado
La definición de este marco de validación es a menudo una de las partes más desafiantes en el desarrollo de un producto. Muchos intentan establecer una 🪄 fórmula mágica✨ que dicte el tiempo exacto que se necesita para alcanzar el ‘product-market fit’. ¿La verdad (para sorpresa de nadie)?: no existe un marco temporal universal y perfecto.
Aquí contábamos con una complicación: previo a la adquisición del producto, estábamos a merced de las métricas que nos ofreciera el marketplace y nada más que las suyas. Sí se podían trazar campañas, pero no si un usuario que ha descargado o visto un contenido es el mismo que ha comprado ya que se registran como diferentes usuarios. Por otro lado, se podía medir la conversión de trial a pago, pero no medir el funnel en la parte de Marketing. Es decir, había una gran parte de la analítica que se escapaba a nuestro control.
¿Cómo intentamos solucionarlo?
- Implementando una buena analítica dentro del propio producto.
- Contrastando los datos con nuestro Sales CRM.
- Poniendo al equipo de ventas y sales a trabajar en el seguimiento de la captación.
Esto es lo que implementamos para la validación:
- KPIs. Seleccionamos unos KPIs que marcarían el éxito del producto. En esta fase lo principal es adquirir y activar usuarios. Fijamos hacer seguimiento de los WAU, MAU, Stickiness y retención. Por supuesto, para todo ello debíamos definir qué eran usuarios activos en nuestro producto.
- Matrices. Diseñamos matrices específicas para la validación del producto y el encaje del mercado. La primera tenía como ejes el porcentaje de ejecución de lo propuesto en el plan de lanzamiento Go To Market vs. las métricas seleccionadas para validar el producto. La segunda, es una matriz conocida, y tiene como ejes el valor del usuario y el entendimiento de usuario.
- Tiempos. Acordamos revisar trimestralmente las métricas y actualizar las matrices. También podríamos decidir un nº de revisiones máximo antes de decidir si abandonar el producto. El equipo acordó 4: un año completo desde el lanzamiento.
Durante todo el proceso se contemplaba ir iterando el producto con el feedback que iríamos recogiendo de nuestros usuarios mediante grabaciones de sesión, entrevistas y analítica de producto y también ir validando la solución y el encaje en el mercado con las diferentes matrices diseñadas y los KPIs seleccionados.
¿Qué hemos conseguido?
Durante los 9 meses que estuvimos aplicando el proceso de discovery continuo para el lanzamiento y validación de nuevos productos, cubrimos todas las fases descritas en el proceso desde 2 productos distintos.
- Gomood, el primer producto que se ideó, desarrolló y lanzó siguiendo la metodología de discovery continuo diseñada, hasta el lanzamiento.
- Budgety, un producto ya creado y lanzado antes del comienzo de este proyecto, al que le dimos solidez aplicando las partes del proceso que nos habíamos saltado.
GoMood en particular, ganó el primer premio en el CodeGeist Unleash de Atlassian, el hackaton del gigante centrado en desarrollo con AI y galardonado con un premio de $30K.
Conclusiones / Aprendizajes
- El equipo de discovery ganó en foco y alineamiento gracias a la creación y refuerzo de las dinámicas y la documentación de los proyectos.
- Implementación del “cerebro compartido” — aterrizar nuestro know-how en herramientas colaborativas como Whiteboards, Figma o a Confluence.
- El resto de la compañía conoce mejor qué hace el equipo de discovery de producto y está más motivado para aportar y así crear las sinergias necesarias para fortalecer este proceso, sobre todo necesario con marketing y comerciales.
- Gracias a la victoria de nuestro producto en Atlassian Unleash, el equipo de discovery dentro de la organización de Deiser ganó todavía más peso y autoridad. Nos consta que en los sucesivos proyectos podrán desbloquear mayor presupuesto y tener mayor libertad a la hora de experimentar con nuevos canales y fórmulas para desarrollar y lanzar sus productos.
- Transmitimos la importancia de conectar las métricas de producto con el negocio para tener una visión más clara a la hora de perseverar o abandonar una idea.
- Ganamos en resiliencia y aprendimos a adaptarnos a los tiempos y compromisos ajenos a nuestro control que nos podían desviar del proceso o no desarrollarlo con toda la rigurosidad que hubiera sido preferible.
Muchísimas gracias a Deiser por dejarnos compartir y a Fani Sánchez por el proceso.
