Introducción
El trabajo del Product Owner tiene mucho que ver con el descubrimiento y la validación. Para ambos tipos de trabajo la comunicación cercana y efectiva con los clientes y usuarios es esencial.
El descubrimiento parte del dialogo acerca de cuál es el problema, dolor o limitación del estado actual de las cosas. Frecuentemente ese descubrimiento detona la necesidad de construir una solución al problema traducida en un producto de software.
En otras oportunidades el descubrimiento puede tener que ver con la detección de un producto que puede prestar un servicio que el mercado todavía no descubrió qué necesita, o por lo menos no existe como producto de software.
Cualquiera que sea la fuente del descubrimiento el Product Owner si se decide a iniciar el desarrollo de un producto, lo estará haciendo basándose en un sinnúmero de hipótesis.
La forma más efectiva de validar las hipótesis de un producto siempre sea la validación con clientes y usuarios reales que puedan interactuar con el producto mientras se construye y no cuando ya esté totalmente construido.
Investigación de Clientes
Al construir un producto se produce un fenómeno similar a la paradoja del huevo o la gallina; es decir, primero se define el producto y luego el cliente o al revés.
Concebir un producto, construirlo y luego salir en búsqueda de clientes no es un trabajo fácil y de hecho el mundo esta lleno de productos que se fabricaron y luego no se vendieron.
Encontrar clientes con un problemas y a partir de ahi derivar un solución/producto implica menos riesgo pero a su vez trae el gran desafío de identificar el segmento del mercado global que contiene potenciales clientes [Watts17].
Si el producto es para el consumo dentro de una organización el fenómeno se repetirá, en lugar de construir el producto y luego imponerlo a los usuarios funcionara mejor determinar quienes son ellos y qué características de un producto necesitaran.
Una forma simple de segmentar un mercado es considerar variables como ubicación geográfica, es decir no hacer un producto para el mundo entero sino para un mercado más pequeño y definido [Pichler16]. Esta simple distinción geografía reduce grandemente la complejidad sistémica del producto que se intentara desarrollar.
Cuando un segmento esta bien definido, o por lo menos más reducido, será mas sencillo tratar de interpretar el problema o necesidades de los clientes del segmento. Sin embargo esto llevara muchas veces a la existencia de prioridades en conflicto.
Existen varios técnicas que un Product Owner puede utilizar para tratar de dilucidar con un grupo de clientes que podría ser prioritario, la base de estas técnicas siempre es la comunicación efectiva que permite que alguna de las partes en contraposición acabe descubriendo que puede mover su opinión sin ver sus interés seriamente lastimados.
De esas técnicas “Buy a Feature” que es parte de Juegos de Innovación [Hohmann06] es una de las que mejor funciona a la hora de dilucidar con un grupo de clientes con opiniones en conflicto que vale la pena o no incluir en un producto.
Una vez definidos los segmentos resulta muy util emplear técnicas como Personas [Cooper04] para poder identificar y entender que objetivos y expectativas tendrá un grupo de usuarios con el producto.
Las personas pueden tomar diferentes formatos que van desde los más sencillos a los más complejos y crearlas puede tomar mucho o poco tiempo, pero lo que yo recomendaría es mantener la simplicidad tanto en el formato y el la inversion de tiempo en su creación. Después de todo siempre debe ser posible cambiar la descripción de estas personas a medida que se va entendiendo mejor el producto y sus potenciales usuarios.
Personas es una excelente técnica para conceptualizar usuarios potenciales pero tiene la limitación de que no permite recolectar retroalimentación real acerca de cómo los usuarios utilizarían la aplicación [Adzic09].
En la practica si se tiene un esqueleto que camina este debe presentarse a los usuarios reales para ver cómo interactúan manos en el teclado con el producto que se esta desarrollando.
En este punto enfatizó que es vital que los usuarios “toquen” el producto, es decir que puedan verlo e interactuar con él, solamente así se puede saber cómo se comportarían y si el producto resolvería alguna de sus necesidades o no.
Antes de construir un esqueleto que camina se podrían utilizar técnicas para tratar de entender qué quieren los clientes, como por ejemplo observar sentados junto a ellos como hacen realmente su trabajo y cuales son los problemas o limitaciones que experimentan. Entrevistas y grupos focales también pueden servir para el mismo objetivo.
Lo anterior siempre trae el riesgo de caer en una larga fase de análisis en papel y con discusiones pero sin construcción del producto de software en sí. Por esta razón recomiendo hacer las cosas en paralelo, es decir, tener a los usuarios cerca, ver qué quieren hacer con el producto, implementar rápidamente y mostrárselos para ver si es lo que querían.
Descubrimiento de Productos
Durante la fase de descubrimiento del producto existen varios aspectos que luego contribuirán positivamente con los resultados que el producto puede alcanzar. Estos aspectos se basan en poder entender que harán los usuarios con el producto, es decir cómo interactuaran con él.
Para poder apreciar las interacciones de los usuarios con el producto es necesario que estos puedan verlo y es ahi donde intervienen instrumentos como diseño de la experiencia de usuario, diseño de la interacción y diseño visual.
Este tipo de diseño puede realizarse con herramientas de software o mejor aun todavía solamente con papel y marcadores, la idea siempre es mantener la simplicidad y permitir que cualquier cambio sea tan rápido como borrar o dibujar de nuevo.
Técnicas que vienen en formato de Juegos de Innovación [Hohmann06] son especialmente útiles para permitir “ver” con mayor claridad que características podría tener un producto.
Sin embargo descubrir un producto en papel no es lo mismo que verlo funcionando en una computadora o dispositivo móvil por lo cual urge validar la hipótesis de cómo podrá lucir realmente en esos dispositivos.
Abordar el desarrollo del producto de software usando un concepto de arquitectura como el Esqueleto que Camina [Hunt99] permite ver en pantalla el producto desde el primer Sprint y así descubrirlo con los usuarios de manera efectiva.
Conclusiones
Partimos de la observación de que la correcta definición de un producto no existe como tal antes de construirlo; por tanto se necesita un proceso de descubrimiento y aprendizaje continuo en el cual interviene todo el Equipo Scrum junto con los stakeholders, clientes y/o usuarios finales.
Este proceso de aprendizaje requiere ser dinámico y para esto herramientas ligeras y comunicación efectiva son fundamentales. Al abordaje de la arquitectura del producto también debe estar acorde con la adaptabilidad que se requiere para un aprendizaje dinámico.
Finalmente el Product Owner será el actor que articulara al producto y sus clientes, en esta función sus habilidades interpersonales, comunicativas y de negociación serán vitales.
Bibliografia
Watts17 Watts G., 2017. Product Mastery: From Good To Great Product Ownership, CreateSpace Independent Publishing Platform
Pichler16 Pichler R., 2016. Strategize: Product Strategy and Product Roadmap Practices for the Digital Age, Pichler Consulting
Hohmann06 Hohmann L., 2006. Innovation Games: Creating Breakthrough Products Through Collaborative Play, Addison-Wesley Professional
Cooper04 Cooper A., 2004. The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity, Sams – Pearson Education
Adzic09 Adzic G., 2009. Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing, Neuri Limited
Hunt99 Hunt A., Thomas D., 1999. The Pragmatic Programmer: From Journeyman to Master, Addison-Wesley Professional
