This content originally appeared on DEV Community and was authored by Víctor Solà
En Adevinta Spain llevamos dos años invirtiendo en mejorar todos los procesos relacionados con una de las fases más clave del desarrollo de un producto digital: la fase de descubrimiento, en inglés Product Discovery. En este artículo explicaré el porqué de esta inversión estratégica, los detalles de lo que estamos haciendo y lo que hemos aprendido durante este proceso.
¿Cómo trabajamos en Adevinta Spain?
Desde hace ya algunos años tenemos una cultura y metodología propia de trabajo: PEAK (Prioritization, Empowerment, Alignment, Knowledge). Es un marco que nos ayuda en el día a día a tomar decisiones, organizarnos mejor y tener más visibilidad y autonomía. Si te interesa entender mejor qué es PEAK, te recomiendo que veas esta charla.
Como muchas otras empresas de desarrollo de software, dentro del marco de PEAK, desarrollamos nuestros productos digitales de la siguiente forma:
- Trabajamos en equipos de producto multidisciplinares (perfiles de producto, diseño, análisis de datos y desarrollo).
- Nos organizamos en equipos con una misión clara.
- Definimos objetivos y hacemos seguimiento de métricas de forma trimestral para alcanzar esos objetivos (OKRs).
Nos enfocamos en intentar mejorar de forma continua nuestros productos y la forma en la que trabajamos. Por ello, en el área de producto hemos invertido principalmente en 2 grandes iniciativas ligadas a la mejora constante:
- Scrum Revamp: iniciativa para mejorar y estandarizar cómo utilizamos el framework de Scrum dentro de los equipos de producto.
- Product Discovery: iniciativa enfocada a ayudar a los equipos de producto a entender mejor qué es lo siguiente que deben desarrollar para poder lograr sus objetivos e impactar sus métricas asociadas.
En este artículo nos centramos en explicar esta segunda iniciativa.
¿Por qué creímos necesario invertir en Product Discovery?
Poner a usuarios y clientes en el centro del desarrollo del producto forma parte de nuestros valores en Adevinta. Como organización estamos convencidos de que la forma de tener éxito a largo plazo es tener el mejor producto y, para lograrlo, creemos firmemente que el camino correcto es poner el foco en las necesidades implícitas y explícitas de nuestros usuarios y clientes.
Intentamos ser lo más eficientes posible. Queremos invertir nuestros recursos en desarrollar aquellas cosas que nuestros usuarios y clientes necesitan y no desperdiciar recursos por el camino. Pero no somos perfectos.
Hace unos años, cuando analizamos cómo veníamos desarrollando nuestros productos, nos dimos cuenta de que teníamos algunos problemas que nos alejaban de esta visión:
- Diferencia en los procesos: no todos los equipos trabajábamos de la misma manera la fase de descubrimiento. Utilizábamos metodologías y herramientas distintas y dedicábamos un volumen de recursos bastante desigual en función del equipo.
- Poca alineación con las necesidades de nuestros usuarios: a menudo nos encontrábamos desarrollando funcionalidades que no estaban alineadas de forma clara con una necesidad de usuario o cliente.
- Poca exploración de posibles soluciones: debido a algunos sesgos cognitivos (que todos padecemos), algunos equipos se enamoraban de la primera solución que les venía a la mente para solucionar un problema u oportunidad. No explorábamos más opciones.
- Foco en la funcionalidad en vez de en la necesidad: muchas veces nos focalizábamos en entregar funcionalidades en vez de entregar valor a usuarios y clientes.
Con el fin de solucionarlos, decidimos empezar a trabajar en una iniciativa que nos ayuda a conseguir los siguientes objetivos:
- Establecer un marco de trabajo estandarizado entre los distintos equipos de la organización para la fase de descubrimiento.
- Conseguir que una mayor parte de los desarrollos estén focalizados en solventar necesidades de nuestros usuarios y clientes.
- Explorar múltiples posibles soluciones para un problema u oportunidad, y no quedarnos con la primera idea que nos viene a la mente.
- Rebajar el nivel de incertidumbre de nuestros desarrollos. Estar más seguros de que lo que estamos desarrollando va a impactar a nuestros objetivos y métricas asociadas.
- Reducir el desperdicio de recursos de desarrollo. Validar posibles soluciones antes de desarrollarlas por completo y descartar ideas de forma más rápida y económica.
- Facilitar la innovación y la diferenciación.
¿Cómo empezó la iniciativa? El piloto de Dual Track
Para empezar, establecimos un grupo de trabajo heterogéneo, con perfiles de diversas áreas de la empresa (Producto, UX, Agile Coaches), para definir el marco de cómo queríamos que los equipos trabajaran en la fase de descubrimiento. Invertimos tiempo en aprender de lo que se estaba haciendo en la industria, lo que estábamos haciendo internamente y, sobre todo, en definir nuestro modelo futuro sobre la fase de Product Discovery.
A esta iniciativa piloto la llamamos Dual Track, con la intención de ayudar a los equipos a entender que hay 2 tipos de trabajo que suceden de forma simultánea: todo aquello que hacemos para entender qué debemos desarrollar (Product Discovery) y todo aquello que hacemos para desarrollar (Product Delivery).
Cuando tuvimos desarrollado el modelo de cómo queríamos trabajar la fase de descubrimiento, empezamos con formaciones a 3 equipos de producto. Las formaciones consistían en explicar el modelo, los beneficios y algunas técnicas en detalle a través de sesiones teóricas y prácticas. Estas sesiones las organizaban y dirigían nuestros perfiles de Research Ops.
Realizar el piloto nos permitió detectar muchas mejoras, tanto en el contenido de las formaciones como en la interacción entre los perfiles de Research Ops y los equipos.
Extendiendo la iniciativa a todo el grupo Adevinta
Esta misma necesidad de mejorar el conocimiento sobre Product Discovery que teníamos en Adevinta Spain, se detectó a nivel de todo el grupo Adevinta en el momento en que nosotros estábamos finalizando nuestro piloto. En base a esta necesidad, empezamos el desarrollo de una formación más global. Tomando de base los contenidos del piloto de Dual Track y complementándolos con la visión, el conocimiento y las experiencias de otros compañeros del grupo Adevinta.
Todo este trabajo acabó cristalizando en un curso sobre Product Discovery que os voy a detallar a continuación.
Nuestro curso sobre Product Discovery
La formación se compone de un curso online que se consume de forma autónoma y de sesiones presenciales donde se pone en práctica el contenido teórico. Las sesiones prácticas permiten a los equipos practicar las distintas técnicas aprendidas durante el curso, siempre trabajando sobre retos reales con los que el equipo de producto está lidiando en ese momento. Todas las sesiones prácticas son conducidas por un discovery coach que facilita y prepara la sesión.
También hacemos seguimiento del progreso del equipo a través de una plantilla que mide la madurez en distintas áreas de la fase de Discovery. El equipo rellena la plantilla justo antes de empezar la formación y otra vez a los 6 meses de haberla finalizado. Este sistema nos permite comparar la evolución y medir el impacto que ha tenido el curso en los distintos equipos.
El contenido del curso es el siguiente:
Módulo 1: Product Discovery basics
En este módulo hacemos una introducción a los conceptos más básicos:
- Qué entendemos por Product Discovery y cuáles son sus distintas fases.
- Qué entendemos por Product Delivery.
- Qué es el concepto de Dual Track.
- Cómo participan los distintos perfiles de un equipo multidisciplinar en la fase de Discovery.
- Cómo incluimos la fase de Discovery en nuestras rutinas de Scrum.
Módulo 2: Alineamiento y captura de oportunidades
En este segundo módulo explicamos la importancia de estar alineados a nivel de equipo de producto para poder realizar Product Discovery de forma correcta y cómo podemos capturar y priorizar oportunidades para la consecución de nuestros objetivos. Algunas de las cosas que contamos en esta sección son:
- Cómo funciona el framework de OKRs y cómo nos permite como equipo saber en qué nos debemos enfocar, cuáles son nuestros objetivos en un período de tiempo determinado y cómo vamos a medir el impacto en esos objetivos.
- Qué es una oportunidad para un equipo de producto y cómo la diferenciamos de una solución. Cómo escribir una oportunidad de forma correcta.
- Cómo podemos capturar oportunidades para nuestro equipo de producto. Tipos de fuentes de información sobre oportunidades para equipos de producto. Diferencias entre investigación cualitativa vs. cuantitativa y entre investigación actitudinal vs. investigación sobre comportamiento.
- Cómo mapear las oportunidades de un objetivo específico a través de la técnica del Opportunity Solutions Tree. Esta técnica, creada y popularizada por Teresa Torres, es una de las técnicas clave del curso. Puedes aprender más sobre ella en este enlace.
- Cómo priorizar las oportunidades a atacar primero. Qué factores se deben tener en cuenta cuando estamos priorizando oportunidades y cómo combinarlos.
Hay 2 sesiones prácticas en el módulo 2; la primera consiste en construir un opportunity solutions tree con un objetivo y key result del equipo. La segunda consiste en hacer un ejercicio de priorización de oportunidades para ver qué oportunidad atacamos primero.
Módulo 3: Explorando oportunidades
En el tercer módulo hablamos en detalle de cómo explorar una oportunidad y cómo adquirir conocimiento para poder plantear soluciones más efectivas a posteriori. Algunos de los contenidos en el módulo 3 son:
- La técnica del Opportunity Canvas. Esta técnica, originalmente descrita por Jeff Patton en este artículo, nos ayuda como equipo de producto a mapear todo lo que sabemos sobre una oportunidad y, más importante, todo aquello que no sabemos y sobre lo que queremos investigar antes de lanzarnos a pensar en una solución. En Adevinta hemos construido nuestro propio Opportunity Canvas en función de nuestras necesidades.
- Cómo seleccionar qué técnica de investigación es más adecuada en función de las preguntas o dudas que tenemos sobre una oportunidad. Diferencias entre investigación cualitativa e investigación cuantitativa y entre investigación actitudinal frente a la investigación sobre comportamientos, y cuándo aplicar cada una de ellas.
La sesión práctica del módulo 3 consiste en construir un opportunity canvas para la oportunidad priorizada al final del módulo 2.
Módulo 4: Ideación y generación de hipótesis
Una vez tenemos la información suficiente sobre una oportunidad empezamos con la fase de ideación de posibles soluciones. En el módulo 4 hablamos de:
- Qué es ideación y qué no cuando la realizamos en el contexto de Product Discovery.
- Cómo articular un taller de ideación en un equipo de producto.
- Distintas técnicas de ideación divergentes para crear múltiples posibles soluciones, como por ejemplo el “How might we …”, “The worst possible idea” o “Heaven and hell”.
- Procesos para seleccionar opciones y priorizar soluciones a validar en la siguiente fase, como puede ser el “Combine and refine” o la técnica ICE de priorización.
- Cómo definir hipótesis como fundamento para la experimentación.
La sesión práctica del módulo 4 consiste en realizar un taller de ideación, practicando distintas técnicas para generar soluciones sobre nuestra oportunidad priorizada anteriormente. El taller de ideación es una de las sesiones que recomendamos hacer de forma presencial.
Módulo 5: Validación
El módulo 5 es el último módulo de nuestro curso sobre Product Discovery y en él hablamos sobre cómo validar suposiciones sobre nuestras soluciones antes de desarrollarlas por completo en la fase de Product Delivery. En este módulo hablamos de:
- Qué es una suposición y qué tipos de suposiciones existen.
- Cómo balancear entre riesgo y time to market.
- Cómo detectar y mapear suposiciones sobre nuestras soluciones y cómo priorizar cuáles hay que validar.
- Técnicas de validación en la fase de Discovery, como por ejemplo el smoke test, el concept test, el concierge test o el extreme programming spike.
- Cómo utilizar la técnica del Validation Canvas para organizar tu fase de validación.
La sesión práctica del módulo 5 consiste en completar el validation canvas para coordinar qué experimentos vamos a realizar como equipo para validar suposiciones sobre nuestra posible solución antes de pasar a la fase de delivery.
Qué hemos conseguido, aprendizajes y próximos pasos
A día de hoy han pasado por el curso más de 53 equipos de producto y, en total, hemos formado a más de 700 personas en todo el grupo Adevinta. Hemos progresado mucho pero todavía nos falta formar a varios equipos y seguir mejorando nuestros procesos. Además, hemos iterado de forma continuada la formación, introduciendo mejoras y nuevas técnicas sobre todo gracias al feedback que nos han proporcionado los asistentes en las diversas olas en las que hemos ido desplegando el curso.
El curso sobre Product Discovery no es un fin en sí mismo. Lo que pretendíamos con esta iniciativa era realmente impactar en cómo los equipos trabajan en su día a día haciendo desarrollo de producto. Hemos conseguido establecer unos mínimos comunes en cómo y cuándo los equipos deben hacer Discovery y hemos introducido ciertas técnicas que ahora los equipos utilizan de forma habitual.
Durante este proceso hemos aprendido mucho. Algunos aprendizajes clave y consejos:
- Definir un marco metodológico para equipos muy diversos, con experiencias previas diferentes y madurez desigual no es tarea fácil. Se necesita tiempo, voluntad y, sobre todo, soporte a nivel ejecutivo.
- Una formación es un producto que necesita iteración. En nuestro caso ha sido clave lanzar un piloto y aprender sobre el mismo antes de lanzar la formación a toda la organización. También la recogida de feedback continuo y la iteración del contenido nos ha permitido elevar el nivel del curso de forma constante.
- Incluir a perfiles variados en la definición del modelo y en la creación de los contenidos de la formación ha enriquecido el contenido. Nos ha costado más tiempo pero al final ha sido más fácil que los equipos incorporen los aprendizajes.
- Las sesiones prácticas son clave. El aprendizaje se produce a través de la práctica en situaciones reales de desarrollo de producto. Combinar teoría como base y práctica nos ha permitido que los equipos integren las técnicas de forma más rápida.
- El acompañamiento es esencial. En nuestro caso el guiar las sesiones prácticas y hacer seguimiento y acompañamiento al equipo a través del perfil del discovery coach nos ha ayudado a que la formación no se vea como un esfuerzo puntual sino a provocar el cambio real en la forma de trabajar.
Agradecimientos y enlaces de interés
Para montar nuestro modelo (y también nuestro curso) de Product Discovery nos hemos inspirado en artículos y modelos ya existentes en la industria. A continuación os dejo una selección de algunos enlaces que nos han inspirado y que creo pueden ser interesantes para profundizar más:
- Dual Track Agile by Marty Cagan
- Dual Track Development is not Duel Track by Jeff Patton
- Introduction to modern Product Discovery by Teresa Torres
- Product Discovery, a Practical Guide for Product Teams by Tim Herbig
- Opportunity Solutions Tree: Visualize your thinking by Teresa Torres
- Opportunity Canvas by Jeff Patton
- Design Kit Methods by Ideo.org
- Forming Experimental Product Hypotheses by Chris Compston
- Idea Validation - Much More Than Just A/B Experiments by Itamar Gilead
El desarrollo del curso de Product Discovery habría sido imposible sin el trabajo incansable de Alba, Ari, Austin, Julia, Liz, Simmone y Tarra.
En futuros artículos compartiremos más detalles sobre nuestro modelo y sobre cómo estamos aplicando algunas de las técnicas clave de nuestro curso de Product Discovery.
La foto de la portada es de Nobel Mitchell en Unsplash.
This content originally appeared on DEV Community and was authored by Víctor Solà
Víctor Solà | Sciencx (2022-02-16T09:20:50+00:00) Cómo hemos desarrollado nuestro modelo de Product Discovery en Adevinta Spain. Retrieved from https://www.scien.cx/2022/02/16/como-hemos-desarrollado-nuestro-modelo-de-product-discovery-en-adevinta-spain/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.