Este es un artículo traducido, escrito originalmente por Marty Cagan.
Aquí te dejo el artículo original.
En la traducción de este artículo, el genérico será femenino al referirse a ti como “una persona”. En ningún caso damos por hecho cuál es el género con el que te identificas, ni pretendemos herir tu sensibilidad. La voz del narrador es masculina ya que el artículo original fue escrito por Marty Cagan, que se identifica con el género masculino.
Equipos de producto vs. Equipos centrados en funcionalidades específicas
Este artículo probablemente va a molestar a mucha gente.
Lo siento, pero el grado de ruido y confusión que rodean el rol de producto y compañías tecnológicas cada vez es mayor. Además, veo problemas y comportamientos problemáticos que se están institucionalizando en conferencias, cursos y, los que se llaman a sí mismos, programas certificados de producto.
He hablado de estos problemas varias veces, específicamente en el artículo y la charla sobre Equipos de producto empoderados (Artículo por traducir al castellano – Empowered Product Teams). Sin embargo, mucha gente escucha solo lo que quiere escuchar y me he dado cuenta de que debo ser mucho más explícito.
Así que a pesar de que este artículo pueda ser doloroso de leer, si has estado frustrada y has recibido información contradictoria y mensajes confusos por parte de gente del mundo de producto, si tienes paciencia, espero que este artículo te aporte tan necesaria claridad.
Equipos de Producto vs Equipos de entrega (Delivery Teams)
En el mundo tecnológico, hay tres tipos diferentes de, los mal llamados, “equipos de producto”.
Los “equipos de producto” que nos encontramos de manera más habitual son los “equipos de entrega” (delivery teams / equipos de delivery). También se llaman “equipos de desarrollo” (dev teams) o “equipos scrum” (scrum teams) o “equipos de ingeniería” (engineering teams) y si tu empresa ejecuta algún tipo de SAFe (Scaled Agile Framework), desgraciadamente entras dentro de esta categoría. Esta tipología de equipo cuenta con un cierto número de desarrolladores y una product owner. La product owner en este modelo es lo que llamo “administradora de backlog”. Alguien tiene que hacer este trabajo administrativo, pero todo gira entorno a entregar output (entrega de tareas, no de valor per se), y tiene muy poco que ver con lo que me preocupa en términos de la necesidad de una innovación real y consistente en nombre de nuestros clientes (es decir, la entrega de valor a los clientes).
He escrito en otros sitios sobre por qué este modelo sólo está replicando, aunque de manera embellecida, el desarrollo en cascada (waterfall) y no se utiliza en compañías que realmente desarrollan producto digital.
Este artículo trata realmente sobre la diferencia entre los otros dos tipos de equipos llamados de producto.
Equipos de Producto vs Equipos centrados en funcionalidades específicas
Advierto que voy a introducir una nomenclatura que no es estándar y ciertamente no se ha llegado a un consenso sobre ella. Pero necesito introducirla porque hoy, como industria, nos referimos a estos tres tipos de equipos como “equipos de producto” o “squads”. Pero como verás, mientras que parecen iguales a simple vista, son dramáticamente diferentes, especialmente cuando hablamos sobre el rol del product manager.
Cuando escribí sobre las virtudes de los equipos de producto empoderados, me refería a lo que voy a seguir llamando equipos de producto. Específicamente, son equipos cross-funcionales (producto, diseño e ingeniería); están enfocados y medidos por los outcomes / resultados (en vez de outputs / tareas entregadas); y están empoderados para descubrir cuál es la mejor manera de solucionar los problemas que se les han expuesto.
El propósito de un equipo de producto en este sentido es resolver problemas de forma que los consumidores o usuarios adoren, a la vez que trabajan para el negocio.
Al contrario de lo que me gustaría, sé que solo un pequeño porcentaje de equipos son realmente equipos de producto en este sentido.
Es mucho más habitual ver que los equipos no están para nada empoderados. En contraste, están ahí solo para servir al negocio.
En este artículo, me voy a referir a esta tercera clase de equipos como equipos de funcionalidades específicas / feature teams. En este caso estoy cambiando un poco la definición establecida para equipos de funcionalidades / feature teams, pero estoy utilizando este término porque ayuda a subrayar que estos equipos están centrados en la entrega de tareas (outputs). Funcionalidades y, ocasionalmente, proyectos. Habitualmente, proporcionadas al equipo en forma de una lista priorizada, llamada roadmap.
Product Managers de un equipo de producto empoderado vs. Product Managers de un equipo de funcionalidades específicas
Aquí es donde necesito ahondar.
Recalquemos que en producto siempre hay cuatro riesgos:
- El riesgo de valor (¿la gente comprará el producto pero elegirá usarlo?)
- El riesgo de usabilidad (¿los usuarios pueden entender como usarlo?)
- Riesgo de factibilidad (¿podemos construir el producto con el tiempo, herramientas y tecnología que tenemos?)
- El riesgo de la viabilidad del negocio (¿esta solución es apta y funciona para las diferentes dimensiones de nuestro negocio?)
En un equipo empoderado de producto, la product manager es explícitamente responsable de asegurar el valor y la viabilidad; la diseñadora es responsable de asegurar la usabilidad y la líder técnica es responsable de asegurar la factibilidad. El equipo lleva a cabo esto colaborando de verdad (próximamente traducido al castellano) de manera intensa en un vaivén, con el objetivo de descubrir una solución que funcione para todas las patas y cubra todos los requerimientos.
Cuando hablo y escribo sobre lo difícil que es ser una verdadera product manager de un equipo empoderado de producto es precisamente porque es difícil poder asegurar el valor y la viabilidad. Si piensas que es fácil, por favor, lee este artículo (próximamente traducido al castellano).
Sin embargo, en un equipo de funcionalidades específicas / feature team, aún tienes (con esperanzas) una diseñadora para asegurar la usabilidad, y tienes ingenieras para asegurar la factibilidad, pero, y esto es crítico que lo comprendas: el valor y la viabilidad del negocio son responsabilidad de las stakeholders o de la persona ejecutiva que pidió la funcionalidad en el roadmap.
Si dicen que necesitan que construyas X funcionalidad, eso significa que esperan que X funcionalidad entregue una cantidad de valor, y ellas creen que esa funcionalidad X es algo que es viable para el negocio.
Merece la pena puntualizar que aunque la stakeholder es la que es implícitamente responsable del valor y de la viabilidad, siempre encontrará una manera de echarte la culpa a ti y a tu equipo si sus esperanzas acerca de los resultados no se ven satisfechas. Ha tardado demasiado tiempo, el diseño era malo, capacidades críticas fueron excluidas del desarrollo para llegar a la fecha de entrega, etc. Es un tema ya conocido y he escrito ampliamente sobre este problema.
Superficialmente, un equipo de funcionalidades y un equipo realmente empoderado de producto son considerados squads. Así que parecen similares, pero las diferencias salen a la luz cuando indagamos en ellos.
Empecemos con el rol de la product manager. En un equipo empoderado de producto, en el que la product manager necesita asegurar el valor y la viabilidad, tener un conocimiento profundo de la usuaria, datos, la industria y especialmente del negocio (ventas, marketing, finanzas, soporte, legal, etc.) es absolutamente innegociable.
Sin embargo, en un equipo de funcionalidades, este conocimiento está (en el mejor de los casos) disperso entre todas las stakeholders.
En cualquier caso, espero que esté claro que las responsabilidades de la product manager son muy diferentes en estos dos equipos.
El trabajo de la product manager en un equipo de funcionalidades se ha denominado habitualmente como un tipo de facilitación, “pastoreando a las ovejas” para que una funcionalidad sea diseñada y desarrollada, o se ha comparado con algún tipo de líder cross-funcional débil y poco claro que realmente no es responsable de nada en concreto. Estos equipos de funcionalidades van a pensar habitualmente que hacen product discovery, pero realmente solo es diseño y quizás algo de testing de usabilidad.
Pero hay otras consecuencias de tener un rol centrado en las funcionalidades en el rol de la product manager.
Como el equipo no está empoderado – para ser claro, cuando te han dado un output que entregar no estás empoderada en ningún sentido – es muy complicado atraer y retener product designers reales (alguien con herramientas en diseño de servicios, diseño de interacciones, diseño visual y user research).
En la gran mayoría de casos en los que tenemos equipos de funcionalidades, la diseñadora (si hay una) es una diseñadora gráfica. Esto no significa que el diseño gráfico o visual no sea importante, pero lo que es relevante aquí es que ahora hay una gran diferencia entre el rol de la product designer y el de una diseñadora gráfica – alguien necesita saber gestionar el diseño de interacciones y hacer algo de research. Por eso es muy común que se presione a la product manager para que ocupe estos espacios y realice estas tareas sin cubrir.
Hay otras consecuencias negativas que subyacen de esta situación, ya que no es difícil aprender a utilizar las herramientas que utilizan las diseñadoras, pero es difícil aprender a hacer buenos diseños y research con usuarios. Tristemente, muchas product managers nunca han tenido la oportunidad de trabajar con una product designer realmente profesional, así que ni tan siquiera saben lo que se están perdiendo.
Si eres lo suficientemente afortunada de tener una verdadera product designer en tu equipo (al menos hasta que se vayan a otra compañía en la que pueda utilizar sus habilidades en su totalidad), entonces habitualmente (y correctamente) cuestionan cuál es el propósito de la product manager, ya que no es complicado adoptar las responsabilidades adicionales de una product manager de un equipo de funcionalidades al estar haciendo la mayoría del trabajo.
El resultado es que los equipos de funcionalidades, el rol de la product manager es principalmente la gestión de proyectos, y parcialmente (sin habilidades) diseñar.
Hay habitualmente una frustración similar con las ingenieras. La product manager que realmente es una gestora de proyectos está a menudo en desacuerdo con la manera en la que las ingenieras creen que deberían estar trabajando. No hace falta mencionar que en este modelo, las ingenieras están relegadas a la entrega, el desarrollo, y tal y como he dicho muchas veces, si este es el caso, solo estamos percibiendo la mitad de su valor real (así que de nuevo, las buenas querrán dejar la empresa y unirse a equipos empoderados de producto dónde realmente pueden practicar sus habilidades).
Solo por cerrar este punto crítico, cuando escribo que la product manager necesita “estar entre el mayor talento en una compañía” y “la CEO debería ver a la product manager como una potencial líder de la compañía” y “la product manager fuerte es la CEO del producto”, no estoy hablando en definitiva de la product manager de un equipo de funcionalidades / feature team.
Indicadores de un equipo de producto vs. equipo de funcionalidades
Llegados a este punto, con esperanzas, ya sabes si estás trabajando en un equipo de funcionalidades o un equipo empoderado de producto, pero he aprendido que a la gente habitualmente le cuesta admitir cuando están en un equipo de funcionalidades.
Aquí te dejo unos tests que puedes aplicar a tu equipo:
- ¿Te dan hecho el roadmap con funcionalidades priorizadas y fechas o te encargas de ver qué problemas debes resolver con outcomes de negocio?
- ¿Hay algún solape entre tu rol y el rol de tu diseñadora?
- ¿Hay algún solape entre tu rol y el rol de tu delivery manager?
- ¿Te pasas la mayor parte del día haciendo gestión de proyectos?
- ¡Has intentado utilizar OKRs, ha sido un desastre, ya sea que terminó siendo rechazado o se entregó una combinación artificial de resultados y funciones?
- Tienes un equipo de misioneros o de mercenarios (artículo por traducir)?
- ¿Cuál es el grado de responsabilidad que tienes?
Si bien los equipos de productos y funcionalidades parecen muy similares en la superficie, son dramáticamente diferentes en la forma en que operan, el nivel de empoderamiento y responsabilidad y, especialmente, las responsabilidades de la product manager.
Puedo decirte que, con pocas excepciones, los mejores equipos de producto en las mejores empresas se basan en el modelo de equipo de producto empoderado. Sin embargo, admito que incluso en las que considero que son las mejores empresas de productos, no todos los equipos de producto están capacitados. En realidad, algunos son equipos de funcionalidades. Generalmente esto se debe a que el liderazgo aún no confía en ese equipo en particular. A veces, primero es necesario ganarse esa confianza. Y a veces el problema es que la líder quiere dictar soluciones.
Nunca he tratado de ocultar mi fuerte preferencia por equipos de producto verdaderamente empoderados. Pero creo que ahora necesito ir más allá de simplemente abogar por equipos empoderados; necesito destacar de los equipos de funcionalidades, los problemas que causan (artículo por traducir) y los malos resultados que brindan.
Hoy en día, innumerables empresas se dan cuenta de la inutilidad del modelo de equipo de entrega / delivery teams y saben que necesitan transformarse en una verdadera empresa de productos impulsada por la tecnología, pero creen que pueden «marcar esa casilla» haciendo cambios superficiales para pasar a estos equipos de funcionalidades.
Al terminar aquí, quiero enfatizar la diferencia entre ser product manager para un equipo de producto capacitado y serlo en un equipo de funcionalidades. Es un trabajo completamente diferente, que requiere un conjunto de habilidades muy diferente. Probablemente ni siquiera debería ser el mismo puesto de trabajo.
Es triste para mí que tantas diseñadoras e ingenieras nunca hayan estado expuestos a una verdadera product manager y nunca hayan podido trabajar en un equipo verdaderamente capacitado. Por eso sostengo que hay tanto talento subutilizado y por eso sigo intentando persuadir a la gente para que intente trabajar como lo hacen las mejores empresas.
Una cosa que puedes hacer de inmediato es que la próxima vez que leas un artículo o un tuit relacionado con el producto, asistas a una conferencia o asistas a alguna capacitación sobre el producto, consideres si la autora, oradora o capacitadora está hablando sobre el modelo de equipo de producto empoderado, o del modelo de equipo de funcionalidades.
ACTUALIZACIÓN: He publicado un artículo de seguimiento (artículo por traducir) que aborda muchas de las preguntas que he recibido sobre esta publicación.
Desde el equipo de The Hero Camp, esperamos que hayas disfrutado de la lectura de este artículo traducido al castellano. Esperamos habértelo hecho más accesible.
¡Hasta la próxima!
