La figura del Product Manager o del Agile Product Manager (Product Owner) es una figura clave en las empresas porque debe aunar muchas áreas clave. Un buen Product Manager debe equilibrar el negocio, la tecnología y la experiencia de usuario, tratando de crear un producto que maximice valor resolviendo un problema complejo. Sin embargo, muchos Product Managers cometen algunos errores básicos que son esencial para hacer su labor. ¡Los repasamos!
Error 1: No hablar con los usuarios
Un buen Product Manager debe generar valor a través de su producto. Para ello, debe entender, analizar y dominar el entorno donde su producto trabaja. Es decir, debe entender muy bien el problema que queremos resolver, cómo va a ser nuestra solución y la estrategia que vamos a seguir para conseguirlo. Una buena estrategia de producto se basa en escenarios que nos adelanten las opciones más probables que podrían aparecer.
Para plantear una buena estrategia, es clave el conocimiento del mercado. Sin embargo, el mercado es cambiante porque las necesidades de los usuarios e interesados evolucionan al mismo ritmo que el mundo. Aquí está una de las claves, debemos conversar contínuamente con los usuarios. Es más, un buen Product Manager fomentará que los Developers del Producto también tengan esta conversación de manera habitual.
Si queremos entregar valor, debemos hablar con las personas que nos van a decir el valor que les entregamos. Y aquí, es clave hacer un buen análisis de usuarios: ¿qué tipos hay? ¿qué necesidades tienen? ¿pagarán por el producto? ¿cómo les afecta?
Por tanto, un buen Product Manager hará un análisis de todos los stakeholders y tratarán de satisfacer en la medida que interese sus necesidades. Una buena táctica puede ser invitarlos a la Sprint Review para que conozcan de primera mano el producto y puedan opinar in situ.
Producto Grande o Pequeño
Es cierto que, en productos pequeños es más sencillo tener “a mano” a los usuarios y hablar con ellos o estudiar cómo trabajan. Cuando hablamos de productos grandes con miles de usuarios quizás no sea tan fácil. El tamaño influye en estas conversaciones. Ahora bien, un buen Product Manager debe buscar la manera de recibir ese feedback.
En productos grandes es habitual usar estadísticas y métricas de uso que nos den información sobre los usuarios. Esto nos permite entender muy bien cómo podemos proponer mejoras y darles valor. Si la mayoría de las personas cuando se acercan a un cajero quieren sacar dinero: ¿no tendría sentido poner esa opción en primer plano?
El fallo con los productos pequeños es que, muchas veces, vivis a base de acuerdos con clientes. Si un cliente nos dice lo que tiene que hacer el producto, aseguramos unos ingresos pero también es verdad que le damos un poder al usuario de decidir el devenir de nuestro producto. Este tipo de planteamientos suelen tener mal futuro porque, un buen producto, debe tomar sus propias decisiones pensando en sus clientes y en la estrategia organizativa. Cada cliente suele pensar en su problema particular, no en opciones globales. Este tipo de acuerdos generan soluciones simples que no suelen ser replicables, difícilmente escalables y disparan los costes de mantenimiento.
Error 2: No hablar con el equipo
Quizás este sea un problema que puede ser bastante más grave que el primero cuando aparece. Muchas empresas toman medidas que alejan al Product Manager de su equipo. Algunas empresas crean departamentos de Producto, otras empresas crean una minijerarquía entre el Product Manager, Product Owner o Analistas de Funcionales, y algunas subcontratan el desarrollo.
Todas estas medidas alejan el “qué vamos a hacer” con el “cómo lo vamos a hacer”, dos dimensiones clave para poder generar valor. El valor es el resultado de entender muy bien a nuestros usuarios e interesados, construir un producto que genere soluciones y volver a escuchar a los usuarios.
Por tanto, un buen Product Manager debe tener conversaciones constantes con su equipo. Si usamos Scrum, el Agile Product Manager o Product Owner, tiene un papel clave en muchos elementos. Ahora bien, en otros equipos que no usan Scrum, se genera una sensación de distancia que puede provocar resultados catastróficos (en términos de entrega de valor).
El caso más habitual es tener Product Managers que venden features que su producto no hace y, después, obligan al equipo a “correr” para alcanzarlo. Esta estrategia convierte el producto en un “corre-calles” contínuo para alcanzar fechas pactadas por personas que no demuestran conocer el desarrollo del mismo. El equipo suele quemarse con esta situación y, peor aún, la deuda técnica se dispara negativamente. Todo esto termina por afectar al servicio que el producto genera y, muchas veces, acaba destruyendo la imagen del producto.
Error 3: Product Goal
El tercer error es el resultado de los dos anteriores. Cuando las conversaciones no están alineadas entre interesados y el equipo suelen aparecer diferentes expectativas que acaban chocando con el tiempo.
Una vez, estuve trabajando en un producto durante un año entero pensando que el objetivo era dar un servicio para comercios que querían vender online. Tras este periodo, un interesado clave con mucho conocimiento nos dijo que estábamos equivocados, que lo que buscaba nuestra empresa era un producto para desarrolladores avanzados que necesitaran una pasarela de pago segura ¡Un cambio radical!
Estas situaciones, además de ser desagradables, nos provocan muchas reuniones de alineamiento y de debate sobre muchas de las decisiones que vamos tomando. Este ruido nos resta efectividad y nos “quema” como equipo. ¡Es muy difícil entregar valor para estar discutiendo contínuamente sobre otros temas!
¿Para qué?
La clave es tener un Producto Goal, un objetivo que responde a la pregunta: “¿Para qué construímos este producto?”. Tenemos que tener muy claro nuestro objetivo, sobre todo para poder tomar decisiones clave. Recordemos que, en un problema complejo, tendremos muchas opciones para resolverlo. Al haber muchas opciones habrá que decidir cuáles ejecutamos y, lo más difícil, cuáles no.
Una vez definido nuestro “para qué” solo tenemos que decidir las métricas que nos guiarán ese Product Goal. Debemos tener métricas de valor que nos den pistas sobre nuestros resultados y métricas de éxito, que son aquellas que validan que hemos conseguido nuestro objetivo.
Cómo Product Manager tenemos que liderar esta conversación. Cuidado, este debate es interno y externo, nuestro Product Goal y métricas deben estar alineados tanto fuera del equipo como dentro del mismo. Puede que fuera del Scrum Team estén las personas que “pagan la fiesta” pero dentro están los que construyen nuestro producto, debemos estar todos a una.
Y tú, ¿cuál de estos tres errores has cometido?
