Cuando le preguntas a un Product Manager qué es lo que hace, varias respuestas pueden surgir: escribir especificaciones, construir los roadmaps, averiguar el MVP, brindar asistencia a los clientes, analizar métricas, entre otros. Aunque, si retiras las capas, hay un elemento en común: la priorización. Priorizar significa construir el producto correcto para el usuario correcto en el tiempo correcto… eso es product management.
Una manera simple de acercarse a la priorización es a través de la matriz ROI. Uno analiza las posibles opciones y los costos y beneficios de cada uno de ellos. Luego escoge aquellos con el ROI más alto. Si bien esto funciona en la teoría, la realidad es mucho más variable.
En mi experiencia en Product Management, he aprendido algunas lecciones de priorización que se ven contradictorias a primera vista:
Una tabla de priorización de features asume que sabes cuales son los features que consideran desarrollar. Aunque ese no siempre sea el caso.
En una etapa temprana de producto, lo que buscas es un product-market fit. En un producto más establecido, muy probablemente buscas un feature-product fit. Puede que no sepas qué necesitas para hacer un producto o feature exitoso.
Esto me sucedió cuando estaba desarrollando Dropbox Extensions. Queríamos más colaboraciones semanales de usuarios (CSU), y no sabíamos qué desarrollar. Nuestro objetivo era encontrar aquel feature-product fit.
En vez de features, lo que priorizamos fue el tiempo y aprendizaje. Lo que hicimos fue hablar constantemente con usuarios y así fue como encontramos motivaciones implícitas. Hablamos con usuarios que habíamos logrado retener, usuarios que lo usaron una vez y lo abandonaron, y con usuarios que nunca lo habían usado. Tomamos las hipótesis y desarrollamos experimentos. Pensamos en maneras para acelerar los experimentos. Optimizamos nuestro proceso de aprendizaje. Nuestro lema era “aprende más rápido”. De esa manera fuimos capaces de pasar las 100 mil CSUs en pocas semanas.
A veces, los productos o features que lanzas no funcionarán. En ese momento no sabrás qué hacer. Lo que necesitarás priorizar es el aprender rápido para ahorrar tiempo.
¿No enfocarte en lo que quiere el cliente? Eso no tiene mucho sentido. ¿O, sí?
Cuando recién me incorporé a Dropbox, era el Product Manager de un equipo interno de herramientas de análisis. Una gran compañía como Dropbox tiene diversos requerimientos de análisis. El equipo había sido ambicioso y estaba desarrollando y manteniendo 8 productos diferentes. Todos con 8 ingenieros. Esta gran carga de trabajo en mantener los productos estaba perjudicando al equipo. La mayoría de esas herramientas eran semi críticas o importantes para los usuarios, así que no había productos obvios que se pudieran detener.
Estábamos atrapados entre la espada y la pared. Pero teníamos que salvar al equipo. Redujimos brutalmente. Redujimos el desarrollo a 1 producto y mantuvimos un par más en soporte vital. Fue doloroso. Sentimos que estábamos defraudando a muchos clientes. Si no reducíamos nuestras tecnologías, habría provocado la renuncia del equipo. Con el tiempo, nos recuperamos y fuimos capaces de volver a crecer.
En otro momento, mi equipo estaba proponiendo un trabajo fundacional para la eficiencia de los desarrolladores. Decidimos invertir el 30% de nuestro tiempo en ello. El cliente obtuvo algún valor? No directamente. Pero manteniendo felices a los ingenieros e incrementando su productividad, optimizaríamos el rendimiento futuro.
Para priorizar, hay otra entidad que considerar más allá de los usuarios: el equipo en sí mismo. Enfocarnos en los deseos de los clientes mientras descuidamos las necesidades de nuestro equipo es la receta para el desastre.
Priorizar es más un arte que una ciencia. Mientras la matriz ROI es un indicador, no puedes confiar en este por completo. Aunque, en algunos momentos, la situación es diferente y lo que necesita trabajarse es descaradamente obvio. Sin embargo, a veces no lo vemos.
Yo también he sido culpable de complicar demasiado las cosas. Hace un par de años en Dropbox, recuerdo una reunión particularmente larga sobre la priorización. Nos pasamos horas hablando sobre el potencial de la integración de productos. Pero un número hizo nuestra priorización obvia: 250M. Ese era el número que debíamos conseguir de usuarios comunes entre Dropbox y Gmail. Para ayudar a nuestros usuarios, teníamos que desarrollar la mejor experiencia en la integración de Dropbox y Gmail. Construímos la integración y se convirtió en una de las mejores aplicaciones en el ranking de apps de Gmail casi inmediatamente.
Toma un paso hacia atrás y mira el panorama general. Qué podría ser lo obvio? Podría ayudar el ver la data. En un equipo anterior, lo que nuestros usuarios amaban más era esta pequeña herramienta de visualización de data. Un ingeniero lo había desarrollado en su tiempo libre. No fue tan obvio para nosotros que eso era tan valioso. Aunque, una vez que miramos la data y luego hablamos con nuestros usuarios, logramos ver lo obvio.
La priorización no trata solo de mejorar tu producto. El proceso que rodea a tu producto también es parte de ello.
Volviendo a mi equipo de analítica, tuvimos 1 problema en particular que estaba causando un gran agotamiento al equipo. Teníamos un canal de Slack para soporte y toda la compañía los llamaba. Imagina recibir más de 30 requerimientos ad-hoc para 8 bases de código diferentes al mismo tiempo.
En este caso, no era importante que mejoremos el producto. Lo que teníamos que mejorar era el proceso real de product management. Hicimos 2 cosas para arreglarlo. Pasamos 1 sprint entero como un equipo en documentación. Luego configuramos una instancia con Zendesk con respuestas automáticas. Con un proceso mejorado, logramos entregar una mejor y más rápida experiencia a nuestros clientes.
En otra instancia, priorizamos procesos alrededor de la integridad de data: contratamos a un equipo de ingenieros de data, clasificamos datos de la fuente-de-la-verdad. Esto fue porque los usuarios no estaban usando nuestras herramientas de analítica porque la data no era de confianza. Ahí no había nada que podamos hacer para el producto. Teníamos que mejorar el proceso subyacente en el que se basa el producto.
Descubre nuestras soluciones y cómo podemos ayudar a tu empresa alcanzar sus objetivos de transformación digital.