Recientemente tuve la experiencia de ver a fondo una compañía “de producto” sin estructura de Product Management. Este es un pequeño análisis de los problemas que detecté y una ratificación de la importancia del rol de producto.
“Debería funcionar…”
Mi primer impresión fue bastante buena. Tenían un modelo innovador donde áreas que en otras compañías están más separadas trabajaban en conjunto para crear el producto.
La idea era simple:
- Hay un área de negocio que entiende a dónde va la industria y lo que se necesita del producto a nivel mercado
- Hay un área de UX que sabe sobre el usuario y cómo hacer un producto “friendly”
- Hay un área de tecnología que sabe cómo construir el producto de la mejor manera, eficiente, escalable, etc.
Esas áreas trabajan juntas en un producto, y son un mismo equipo.
Definen juntos que construir y las prioridades. Miran juntos la salud del producto y que debería mejorarse.
…Así definido debería funcionar, ¿no?
¿Qué cosas no funcionaban?
Detecté una serie de problemas que lo resumo en 5 puntos principales.
1. Backlog y Priorización
Uno de los aspectos que me pareció más grave fue la falta de un backlog explícito y priorizado visible para cualquier miembro del equipo (o de la compañía).
Eso no significa que no se supiera “que hacer a continuación”, pero si que cada quien tenía su imagen en la cabeza de cómo era ese backlog, y la priorización era una discusión basada en opiniones que se tenía todos los días.
Quizás más grave aún, existía un roadmap anual pre-existente, basado en estimaciones hechas por el equipo de IT en base a descripciones de una línea. Si bien a nivel directivo estaban las puertas abiertas para modificarlo si se detectaban cambios de prioridades, constantemente en la discusión de “cuándo hacer funcionalidad X” salía la frase “dijiste que lo íbamos a tener en Y fecha”.
No existía esa idea de trabajo como un solo equipo, donde se negocia que hacer y todos entienden por qué. Se veía más como un cliente y una software factory, cuándo se cae en las discusiones de contrato.
De más está mencionar los problemas de este enfoque: discutir constantemente las prioridades de todo el año complica mucho el delivery, hace cambio de enfoque constante porque es basado en opiniones, limita mucho la capacidad de introducir nuevas ideas… y muchos más 🙂
El mantenimiento de este artefacto es una de las tareas principales de un Product Manager, y con ese rol en el team, no hubiese faltado jamás.
2. Data-drivenness
Casi a la par de este problema estaba la falta de decisiones basadas en datos.
¡En primer lugar por la falta de datos! Si bien había datos básicos del CRM (propio y de muy difícil acceso), faltaba por ejemplo la implementación correcta de una herramienta de medición del producto en sí y su funnel.
Y de la mano de eso, una falta de objetivos claros y concretos.
Esto te lleva como decía antes a una priorización basada en opiniones, y casi más grave aún, a no mirar el resultado de lo que se pone en producción.
Ponés el foco en el “output” en lugar del “outcome”, cómo una software factory, lo cual a nivel empresa de producto no tiene sentido. Te hace evitar iterar una funcionalidad entregada que podría entregar más valor, porque justamente “ya salió” y ponés el foco en “lo siguiente que tiene que salir” en lugar de qué esperábamos de ese feature.
Nuevamente, el Product Manager es el que necesita esta información para vivir. Sin esto su rol carece de sentido. Comprueba si está haciendo un buen trabajo por el outcome no el output. Por ende teniendolo en el equipo, jamás se hubiese llegado a una situación así.
3. Scope y entregas incrementales
Otro problema de esta interacción entre “negocio” y “tecnología” es que en general se recibe un requerimiento, se estima en “N” semanas o meses, y luego se prioriza y pone en el roadmap.
Y por eso terminamos con una lista de proyectos gigantes, con alto grado de incertidumbre sobre el esfuerzo y valor de cada uno.
Cuando trabajamos con un Product Manager Digital, en general es quien está acostumbrado a las entregas incrementales, los MVPs, y a pensar junto al equipo de IT cómo ese feature lo dividimos en entregas pequeñas (por ejemplo de 15 días o menos) que entregen constantemente valor incremental al usuario (aprendiendo en el medio y cambiando la dirección del proyecto en base al resultado de esas entregas).
Y en general, esas entregas incrementales me hacen pensar en el principio de pareto, y que “partes” de esa idea me dan el 80% del valor para construirlas primero. Lo que conduce a que quizás proyectos de 5 meses, luego de 1 mes aportaron 80% de lo contribuirían si lo construimos totalmente, y no avanzamos con el resto para dedicarnos a otros proyectos que ahora se vuelven más prioritarios que ese 20% restante.
4. Product Discovery y Customer Development
Ya hable sobre la falta de datos en la toma de decisiones, pero otro aspecto que es muy difícil lograr sin Product Management de por medio es Product Discovery y Customer Development. Para resumirlo con ambas me refiero a la exploración continua de necesidades de clientes, interacción constante con ellos, y experimentación rápida para evaluar el impacto de las ideas que tenemos.
No puedo hacer suficiente hincapié en la importancia de estas actividades. Pero para resumirlo en 2 problemas:
- Las ideas que tenemos están basadas en nuestros supuestos de lo que los clientes quieren, que 70% de las veces es incorrecto.
- La única forma que tenemos de darnos cuenta es construirlo y ver como el 70% de lo que hicimos falla. Tremendo desperdicio.
Estas actividades requieren una serie de skills difíciles de desarrollar, y son tareas que consumen mucho tiempo, por lo que no tener nadie avocado al rol de Product Management hace casi imposible su realización.
Y es la mejor forma de lograr innovación que capture valor, posiblemente la mejor forma de medir la performance de un Product Manager.
5. Conocimiento del negocio de Productos Digitales
Un último punto no menor, es que en general es excelente (y necesario!) contar con un área de negocio que conoce a fondo la industria y los players de la misma, y establece contactos de años con proveedores y partners. Conoce las tendencias, los modelos de negocios, son idóneos para hacer benchmarks y tener ideas innovadoras en aspectos intrínsecos de su nicho.
Pero en general por cuestiones lógicas (casi por restricciones de tiempo diría) es imposible que también conozcan toda la industria de productos digitales. Para poner un ejemplo bien genérico, cuando trabajé en e-commerce de turismo, las áreas de negocio se involucraban 100% en entender la comparación de precios con la competencia e incluso cómo mostraban ciertos productos las otras OTAs. Pero desde el área de productos digitales reconocíamos a Amazon como líder de e-commerce, y hacíamos benchmark con ellos para ver qué innovaciones a nivel tecnología podíamos hacer en el checkout (por citar un ejemplo).
En mi caso por ejemplo, pase por 4 industrias distintas, y tengo algo de conocimiento de cada una de ellas. Pero todo el tiempo estuve en productos digitales, por lo que mi experiencia más profunda está justamente ahí, en entender cómo es el negocio de un producto digital y cómo mejorarlo, trayendo ideas que pueden ser de productos de otras industrias a la mía.
Ambos conocimientos son complementarios, y cuando ambos roles están juntos se potencian.
¿Por qué el rol de Product Manager ayuda a estos problemas?
El Product Manager orquesta
Ya en cada problema indiqué la mejora que aporta el rol de Producto, pero me parece importante sumar un punto adicional: prácticamente la principal función del Product Manager es orquestar (y les recomiendo este artículo para profundizar la idea).
Es decir, sumar el rol de Product Management no aplaca el valor de ninguna de las otras funciones. Todo lo contrario, las potencia. Puede aprovechar el conocimiento de negocio para conducir experimentos de innovación poderosos. Puede aprovechar el conocimiento del equipo de tecnología para que propongan innovaciones conociendo las necesidades de los usuarios.
Cuando hablamos por ejemplo de priorizar, los mejores Product Managers lo que hacen simplemente es traer todos los temas a la mesa, sumado a números y preguntas inteligentes para que todo el equipo pueda decir que es lo más importante construir en este momento.
Dueño de las tareas
Alguna de los problemas que mencioné antes (por ejemplo la falta de un backlog visible para todos) no se da porque el equipo no sepa que lo necesita, sino porque nadie tiene la responsabilidad explícita de llevarlo adelante.
Quizás parezca menor, pero cuándo una persona es responsable de que “estos problemas” que mencioné no ocurran, y se lo evalúa por ello, es quizás la forma más directa de que desaparezcan.
Skillset
Hablar del skillset del Product Manager podría llevar un buen tiempo, y seguramente sea para un nuevo artículo. Pero en un resumen de alto si volviera a mencionar los problemas que vimos (backlog y priorización, decisiones data-driven, scope y entregas incrementales, etc) lo bueno de contar con alguien experimentado en Product Management es que justamente ya construyó los conocimientos y herramientas que le permiten hacer esto efectivamente, y compartir estos skills y mindset con el equipo para “subir la vara”.
En resumen
El rol del Product Manager es esencial para lograr un producto exitoso. Si tuviese que elegir uno de todos los puntos mencionados, sin duda orquestar el trabajo de todas las disciplinas para lograr que todo el esfuerzo del equipo brille adentro del producto es el más vital.
¡Me encantaría escuchar sus opiniones y experiencias!