Una de las técnicas más estudiadas e interesantes que se han introducido en estos años son las de Discovery Product. El Discovery Product consiste en estudiar o en tratar de resolver incertidumbres acerca del alcance o dependencias. Sin embargo, puede ser una técnica peligrosa que nos derive en una cultura de proyecto predictivo sobre un producto adaptativo, al tratar de definir todo el trabajo antes de empezar ¿Es una buena técnica? ¡Lo analizamos!
¿En qué consiste?
El Discovery Product es una técnica nacida en los últimos años para tratar de generar información en los productos antes de comenzar. Su objetivo suele ser responder a la pregunta: ¿qué vamos a hacer?
Para ello, se utilizan multitud de técnicas nacidas al calor de Agile como pueden ser: Lean Inception, Design Thinking, Design Sprint, User Story Mapping o Impact Mapping. Todas estas técnicas son interesantes pero, como siempre, podemos caer en la cultura tradicional de ser predictivos en vez de adaptativos. Recordemos que el Manifiesto Agile dice en su cuarto valor:
“Respuesta ante el cambio sobre seguir un plan”
¡Cuidado! Este valor no invalida el disponer de un plan y de una estrategia de producto que aporte luz. Ahora bien, el objetivo de un equipo es entregar valor en vez de tratar de cumplir el plan. El plan debe ser una herramienta que nos aporte foco ante las dudas y que nos permita adelantarnos a situaciones en las que podríamos entregar menos valor (dependencias).
User eXperience (UX), el rey del Discovery Product
Un amigo Arquitecto Software me decía “no hay nada peor que un UX”. Su frase, aunque muy dura, iba dirigida a cualquier persona (UX o no) que antepone su visión en un producto sobre todas las demás. Muchos UX consideran que su trabajo es el más relevante porque están al principio del ciclo de vida. ¡Y ese es el problema!
La disciplina de User Experience debe ser continua, constante y no relegarse a los primeros compases de un producto porque, entonces, se acaba convirtiendo en un proyecto más, cuyo único objetivo es desarrollar lo que otros han definido en una fecha impuesta.
A mi entender, el UX (como labor y no como persona) incorpora muchas actividades interesantes que son clave para el desarrollo de producto: conversaciones con clientes, user research, mediciones, encuestas… Todas estas labores son imprescindibles cuando queremos entregar valor. Ahora bien, el valor es la concatenación de muchas labores, una mejor definición no garantiza el éxito. De hecho, muchos productos digitales de éxito tuvieron poco UX en sus inicios, porque se centraban en el valor por encima de una “experiencia de usuario definida y completa”. No hay mejor manera de dar una buena experiencia a nuestros usuarios que entregando valor, todo lo demás son hipótesis sobre lo que creemos que ocurrirá.
Objetivos del Discovery Product
Por encima de relegar el Discovery Product a una mera “fase de análisis con herramientas modernas”, el descubrimiento de producto debe tener varios objetivos a conseguir:
- Estrategia de producto
- Roadmap a largo plazo
- Backlog inicial de trabajo
- Métricas de producto definido
- Definición de usuarios y sus motivaciones
- Requisitos no funcionales claros
- Línea gráfica inicial (si aplica)
Un Discovery debe darnos luz sobre todos estos objetivos por encima del alcance. Tratar de tener un backlog hiperdetallado en un momento inicial puede retrasar demasiado nuestra entrega de valor.
Un primer alineamiento sobre nuestro producto y sus objetivos, sumado a un estudio de las métricas que nos ayudarán a validar que vamos por el buen camino, nos puede servir para tomar muchas decisiones de manera rápida y acertada durante el desarrollo del producto.
Además, analizar los diferentes tipos de usuarios a quienes nos dirigimos y prestamos servicio es clave para entender cómo construir la tecnología. De hecho, técnicas como las Historias de Usuario o TDD se centran mucho en cómo el usuario convive con nuestro producto, frente al análisis tradicional que mira lo que hace el producto sin pensar en el usuario.
Y por último, muchos equipos tienden a generar una línea gráfica del producto (siempre que tenga parte visual). Ahora bien, esta línea no puede retrasarnos. Recordemos que los productos digitales como Facebook o Amazon han evolucionado su visualización con pequeños cambios a lo largo del tiempo.
Discovery versus Delivery
Un buen producto suma experiencia de usuario, negocio y tecnología, es decir, todos deben ser un equipo para entender el problema que queremos resolver y proponer soluciones.
Con la mentalidad tradicional, los departamentos de negocio o ventas definían a los equipos técnicos lo que tenían que hacer. Estos, a su vez, se limitaban a desarrollar aquello que estaba definido, sin mirar resultados. En caso de un error de entendimiento, los dos departamentos disputaban la culpa de lo sucedido y mientras el producto generaba un valor muy bajo.
En una mentalidad de Producto donde queremos entregar valor, la clave es la inspección contínua a medida que entregamos resultados. Adaptarnos rápidamente con los datos que nuestro producto proporciona. Por tanto, debemos evitar entender el Discovery Product como una tarea previa al Delivery Product. Discovery y Delivery deben ser continuos y alimentarse uno al otro.
Discovery Producto nos brinda información sobre problemas o puntos donde generar valor. El Delivery nos permite construir un producto que aporte valor y cambio a nuestros usuarios. A raíz de ese cambio, necesitamos un nuevo Discovery, por lo que esto genera un bucle infinito mientras nuestro producto genere valor.
Por tanto, el Discovery Product siempre será positivo si está unido a un buen Delivery que valide su trabajo y siempre que se hagan de manera conjunta.
Y tú, ¿realizas Discovery Product?
