Ir al contenido
  1. Blog/

Creación y evolución de un equipo de producto: aplicando el product trío y dual tracking

·2236 palabras·11 mins· loading · loading · ·
Product Management Teams Product Trio Roles Dual Track
Ángel J. Ramos
Autor
Ángel J. Ramos
Staff Cloud Architect @ DoiT
Tabla de contenido
Product management desde las trincheras - Este artículo es parte de una serie.
Parte 7: Este artículo
En esta entrada de la serie Product Management desde las trincheras, te llevaré a través del proceso de creación de un equipo de producto desde cero, compartiendo mis aprendizajes y desafíos. Aplicando conceptos de la disciplina de CPS (Complex Problem Solving) y centrado en la resolución de problemas, detallo cómo implementé el concepto del product trío y dual tracking para balancear el descubrimiento y la entrega de funcionalidades. Además, reflexiono sobre la importancia de la adaptabilidad y la evolución del equipo para enfrentar retos cambiantes y necesidades emergentes en un entorno corporativo dinámico.

En esta entrada de la serie Product Management desde las Trincheras, me gustaría continuar con uno de los aspectos que tocamos en la entrada anterior, en la que veíamos que los equipos de producto deben alinearse con la estrategia de la compañía. En esta nueva entrada, quiero contar cómo me enfrenté al proceso de creación de un equipo de producto desde cero.

Como comenté en la primera entrada, fui la primera persona de producto en la compañía. Cuando aterricé, el equipo de producto era un one-man business, aunque pronto me asignaron a una persona con buen conocimiento del negocio, que me ayudó a entender la organización, la competencia y la propuesta de valor, junto con los productos.

Planificación del Equipo
#

Cuando entras en una posición de este nivel, normalmente haces un business case sobre cómo afrontar ciertos retos que pueda tener la organización en un contexto dado. Como parte de este proceso, ya tenía un mapa de composición del equipo con el que quería enfrentar estos retos. A continuación, os lo explico:

Visión sobre la composición del equipo de producto ideal para esta aventura
Visión sobre la composición del equipo de producto ideal para esta aventura

Mi modelo mental para la construcción de equipos suele ser el mismo, algo que he aprendido de la práctica del CPS (Complex Problem Solving). Creo firmemente que hacer producto es una disciplina problem-centric, y como tal, el problema define el equipo.

Modelo Mental: Product Trío
#

Además, complemento este concepto con el del product trío. Para quienes no conozcáis el término, básicamente define el liderazgo de un equipo de producto como un triunvirato entre el product manager, el product designer y el tech lead. Cada uno se encarga de la arquitectura funcional, la arquitectura de la información y la arquitectura tecnológica, respectivamente. De ahí los bloques de Product Management Team y Customer Experience Team, correspondientes a los equipos de product managers y product designers respectivamente, con algunos matices que comentaré un poco más abajo.

De esto tenemos una clase muy chula de como se relacionan estos perfiles en el Curso Avanzado de Product Management de The Hero Camp.

Dual Tracking
#

Otro mecanismo que me gusta trabajar en mis equipos es el concepto del dual tracking. Tenemos un camino (track) de discovery, que explora el espacio de los problemas, y otro de delivery, que se centra en la entrega de funcionalidades. Estos dos modos de funcionamiento se entrelazan en el día a día de los equipos, pero es crucial tener perfiles que entiendan y hayan trabajado de esta manera.

Composición del Equipo
#

Empecemos a desgranar por qué este planteamiento de equipo.

Product Managers
#

Había tres equipos de desarrollo disponibles, así que mi primera intuición fue asignar un product manager a cada equipo para garantizar una dirección estratégica. Aquí sigo el modelo de Single-threaded Leadership (STL) de Amazon, delegando la responsabilidad de alcanzar los objetivos definidos.

Así mismo creo que cada PM debe estar dotado de una serie de recursos de desarrollo, de ahí que hiciera una asignación uno a uno para que no tuviera problemas de canibalización de las iniciativas.

Customer Experience
#

Para el equipo de Customer Experience, creía que 5 personas era el número adecuado para poder asignar un product designer a cada uno de los equipos, que se encargará de toda la parte de definición estratégica de la experiencia de cliente, y luego tener dos personas que pudieran encargarse de ayudar a estos equipos a trabajar en la parte de customer/user research para levantar información e insights a través de mecanismo principalmente de design thinking que nos permitan entender mejor cuales son los pain points de los clientes así como potenciales soluciones para los mismos.

Data Team
#

Para el equipo de datos, mi pensamiento fue en cubrir perfiles tres tipos de actividades que creo que eran relevantes para nosotros como equipo de producto.

Primero, el data engineer, que sería la persona encargada de llevar el dato donde tiene que estar en el formato que se requiere (que me perdonen los más cafeteros por la super simplificación del rol).

Segundo, el científico de datos que me permitiera llevar a cabo la explotación de esos datos y extracción de insights de los mismos a través de algoritmos de machine learning, por ejemplo para la gestión del churn, la segmentación de los clientes, y un largo etcetera.

Finalmente, un perfil más relacionado con lo que es la visualización, que nos ayudará a crear los cuadros de mando que ibamos a utilizar como brújula dentro de los equipos y dirigir las conversaciones con los equipos de producto.

Otras partes del equipo
#

Una vez abordado los equipos que componen ese product trío, veamos los otros equipos que creía que tenía sentido tener.

Agile Coach
#

El Agile Coach nos ayudaría a establecer mecanismos para un rendimiento óptimo, creación de buenas prácticas y alineación con las líneas estratégicas de la compañía.

Solution Scouting Manager
#

Mi razonamiento es que como parte de la estrategia de M&A tendríamos que estar mirando fuera de la organización qué soluciones dentro del ecosistema podrían ayudarnos a complementar nuestra propuesta de valor para conseguir los objetivos que acordáramos con el fondo y un perfil que me ayudaría a curar esa información sobre la dinámica del mercado para mi como CPO.

En mi experiencia en X by Orange, haciendo ese rol, es que es un trabajo a tiempo completo de ahí la inclusión de este rol en la organización de producto.

Equipo de Experimentación
#

El último equipo que incluí fue un equipo dedicado a la experimentación, por varios motivos:

  1. No sabía que me iba a encontrar en el departamento de tecnología y que ancho de banda iba a tener para implementar con lo cual me quería garantizar una minima capacidad de desarrollo
  2. Como parte de las iniciativas del solution scouting manager, podríamos querer lanzar algo en paralelo sin distraer a los equipos de producto
  3. Ya no solo implementar sino incluso lanzar algunos experimentos que por lo que fuera no se podían abordar dentro de los equipos de producto y tuviéramos que acometer en separado
  4. En mi experiencia algunos CEOs suelen tener pet-projects y quería garantizarme en cierto modo que eso no nos distrajera de otras cosas.

Reflexión y Ajustes
#

Después de leer todos estos párrafos sobre el racional detrás de establecer el equipo de producto para este contexto concreto, hay algunas clarificaciones que me gustaría hacer.

La primera es que obviamente esta composición del equipo era mi carta a los reyes magos, que pronto iba a descubrir que no me iban a traer.

La segunda es que bajo la circunstancia en la que se estaba presentando este equipo, a mi me servía para varios propósitos en el proceso de selección:

  1. Mandar un mensaje que establecía mi conocimiento sobre la profesionalización de la disciplina de producto para un contexto dado.
  2. Crear un efecto anclaje sobre los roles, responsabilidades del equipo así como el tamaño del mismo para acometer los retos que se me proponían por delante, que por razones obvias no puedo comentar pero que os podéis figurar conociendo el contexto de un private equity.
  3. Para entender como de seria era la propuesta de modernización de la forma de hacer producto en la organización, es decir comprobar un poco cual era el skin in the game de la organización.

La tercera clarificación quizás más táctica, también creo que más obvia, es que existe un ramp-up a la hora de contratar, hacer el onboarding del equipo, etc. y no sucede desde el minuto uno, todo tiene su tiempo, además de qué tienes que ir estableciendo unos principios y una cultura de trabajo que si entran muchas personas a la vez en una organización es muy difícil de gestionar.

Esta composición inicial del equipo era mi ideal, aunque pronto descubrí que no todo sería posible. La composición final del equipo antes de mi partida era de 24 personas, distribuidas en cuatro equipos: Product Managers, Customer Experience, Product Owners y Product Operations.

Product Managers
#

Equipo de product managers, uno por equipo, una combinación entre personas provenientes de distintas partes de las organización pero con potencial de llegar a ser product manager y otras personas, PMs profesionales interinos que contraté via consultoras de producto como era Thiga en este caso, que me ayudarán a ser agentes del cambio dentro de la organización y que tuvieran una mentalidad ya de producto formada.

Un aprendizaje que tuve en esta línea, es que yo era muy reacio a abrir una posición de PM para contratar directamente en la organización porque entre mis valores está tener cierta responsabilidad para con la gente que contratas, es decir no me sentía cómodo trayendo a un product manager sacándole de otra organización para traerle en una organización en la que la práctica todavía estaba muy en pañales, pero después me di cuenta que a pesar de ser un sentimiento totalmente válido, creo que es un sentimiento muy paternalista y creo que abordado con total transparencia a los candidatos, no tiene porqué afectar dado que hay personas que este tipo de situaciones les motivan, como casualmente me paso a mí al tomar la posición como CPO donde todo estaba por construir.

Customer Experience
#

Equipo de customer experience, aquí estoy muy contento con la composición del equipo, y tuve mucha suerte de contar con una persona que había entrado un par de meses antes que yo en la organización y que me ayudo a establecer una visión para ese equipo, finalmente expandiendo el equipo hasta tener un PD por equipo y un par de personas flotantes cubriendo: Research, diseño de la experiencia de usuario, diseño de la interfaz de usuario y los test de usuarios, y todos sus procesos asociados.

Product Owners
#

Equipo de product owners, cómo comentaba en anteriores entradas, para garantizarme la capacidad de desarrollo me quedé con el equipo de POs, la realidad es que en mi visión de equipos de producto como habéis visto no creo en la figura del product owner, en este caso para mi era un equipo transitorio, en el que algunos POs pasarían a PMs y otros pasarían a otros roles de la organización.

El propósito que cubrían en este caso concreto, era el de descargar de las tareas más tediosas del delivery a los PMs y el de hacer de enlace con los equipos de desarrollo que no tenían una actitud tan proactiva como esperábamos. Dentro de este equipo tenía algunos perfiles con mayor capacidad de gestión de proyectos, más project managers, que se encargaban de algunos proyectos (es decir iniciativas con un claro inicio y fin, con un alcance) pero que recaían dentro de mis funciones y que en cierto modo me ayudaban a mantener el rumbo establecido.

Product Operations
#

Este equipo lo construí a base de perfiles reciclados también de otras partes de la organización y que me ayudaban a compactar los procesos y las tareas más internas del equipo de producto, así mismo también ayudaban para descargar tareas al resto del equipo, por ejemplo: formaciones de los productos a los distintos stakeholders, generación de informes, análisis de algunos datos, preparación de algunos procesos y comunicaciones.

Conclusión
#

Hasta que llegamos a ser este equipo, no fue un camino sencillo, nos fuimos adaptando en base a los eventos que se producían dentro de la organización, re-estructuración de departamentos, compras de organizaciones y poco a poco intentando cubrir los huecos que teníamos de las distintas funciones dentro de un equipo de producto para los objetivos que nos habíamos propuesto.

Además la composición de los equipos sólo es una dimensión en cuanto a la gestión de equipos de producto, hay otra buena parte que me gustaría comentar en la siguiente entrada sobre la creación de la cultura del mismo y en este caso del upskilling en la disciplina de producto de las personas que componían el equipo para conseguir que fueran esos agentes del cambio dentro de la organización hacia una mentalidad de gestión de producto, porque no olvidemos lo que he dicho en anteriores posts, producto somos todos, y necesitaba que esa mentalidad estuviera en cada conversación que tuvieramos con los distintos stakeholders.

En resumen, la creación de un equipo de producto desde cero es un proceso complejo que requiere una planificación cuidadosa y adaptabilidad. A través de la combinación de diferentes perfiles y la implementación de metodologías como el product trío y el dual tracking, se puede establecer un equipo capaz de enfrentar los retos del negocio de manera efectiva. La evolución de la composición del equipo y la adaptación a las circunstancias internas y externas son claves para el éxito.

Hasta aquí la entrada de hoy. Espero que os haya gustado y, sobre todo, que hayáis aprendido. Me gustaría que comentárais si vosotros hubierais creado la misma visión del equipo de producto originalmente y qué otras dimensiones hubierais tenido en cuenta. Un saludo y hasta la semana que viene.

Product management desde las trincheras - Este artículo es parte de una serie.
Parte 7: Este artículo

Relacionados

Construyendo Equipos de Producto Efectivos: Estrategia y Organización
·1502 palabras·8 mins· loading · loading
Product Management Teams Estrategia Roles Roadmap
El ancho de banda del equipo de producto: herramientas y estrategias para entender la capacidad de los equipos
·1809 palabras·9 mins· loading · loading
Product Management Teams Datos Toolkit Collaboration Backlog
Desvelando el Backlog: Secretos para Priorizar con Éxito
·3455 palabras·17 mins· loading · loading
Product Management Liderazgo Estrategia C-Level Transformación Backlog