Los asiduos a esta lista de correo me habréis escuchado decir que la labor de un Product Manager es fundamentalmente estratégica, definiendo el qué y el por qué, mientras que la parte de la ejecución suele recaer en el equipo de ingeniería, quienes definen el cómo y el cuándo.

Este modelo funciona muy bien cuando tienes un equipo pequeño y autónomo, capaz de desarrollar funcionalidades de principio a fin, sin tener que gestionar dependencias externas. Sin embargo, cuando la organización crece y empiezan a aparecer las dependencias, la parte de la ejecución se complica.

De repente el equipo ya no es independiente, y la iniciativa que el Product Manager quiere empujar se da de bruces contra la burocracia interna. El PM ya no tiene sólo que coordinar a su equipo, si no que tiene también que influir y tratar de planificar el trabajo de otros equipos para poder sacar algo adelante.

Y entonces, ¿pasa el Product Manager a encargarse de gestionar la ejecución en ese momento? ¿O debe ser el Engineering Manager de su equipo quién se encargue de alinear a los otros equipos? ¿O quizás debe haber una figura por encima de ambos?

No tengo una respuesta clara la verdad. En mi experiencia personal, tiendo a rellenar el hueco, porque ya he vivido demasiadas iniciativas que han descarrilado porque nadie ha sido capaz de alinear a varios equipos en la misma dirección.

Y es que esta una de las mayores desventajas del modelo de squads de Spotify, el cuál todos copiamos sin pararnos a pensar las consecuencias de hacerlo. Consecuencias tales como el aumento de la complejidad, la creación de silos y los conflictos de prioridades.

Bajo este modelo, que ni siquiera es invención de Spotify por cierto (los sistemas de organización matricial vienen de los 50), los equipos y los PMs tienden a esquivarse y optimizar localmente. Su producto, su área, sus métricas.

Pero ¿qué ocurre cuando la organización necesita mover una iniciativa que requiere del esfuerzo y la coordinación de varios equipos? ¿Quién se supone va a hacer esa labor? ¿Están los PMs preparados para hacerlo?

Este año he llevado una de estas iniciativas. Teníamos que sacar un producto adelante que necesitaba de la interacción y el alineamiento de casi todos los otros equipos de la empresa. Mi lista de stakeholders al inicio era de cerca de 40 personas.

No se me caen los anillos al decir que probablemente este año he hecho más Project Management que Product Management. Era simplemente lo que necesitaba la empresa en este momento dado. Y de todo se aprende, que decía mi abuelo.

Esta experiencia me ha hecho mirar con otros ojos la disciplina de la gestión de proyectos. A veces miramos con desdén a los Project Managers, precisamente quizás porque les asociamos a la ejecución, mientras nosotros queremos estar en la estrategia. Pero la realidad es que no hay estrategia sin ejecución. Son dos caras de una misma moneda.

Y resulta que un proyecto, entendido como un esfuerzo temporal para lograr una meta, nos puede ayudar a ejecutar en ciertos casos. También en empresas de producto.

Un ejemplo claro, como comentaba, es cualquier esfuerzo transversal que requiera de la coordinación de varios equipos.

Hoy en día, por ejemplo, para un esfuerzo con un principio y fin claro, apostaría por crear un equipo de proyecto extrayendo a los miembros de los otros equipos necesarios para llevarlo a cabo.

Podemos no salirnos de nuestro modelo mental, y llamarlo squad. La clave es que será un squad temporal. Y como a cualquier otro, queremos dotarle de autonomía para acometer su labor, esquivando las dobles y triples líneas de reporte, que es lo que mata cualquier iniciativa conjunta en una organización matricial.

Básicamente lo que quieres evitar es reuniones con más managers que ingenieros, que es lo que sucede si intentas desarrollar la iniciativa apoyándote en los squads actuales. Y es que en una reunión en la que tengan que colaborar tres squads ya metes mínimo a 3 PMs y 3 EMs, que tienen que estar al tanto de todo, y que, además, tienen sus propios OKRs y prioridades de las que preocuparse.

Probablemente también sea incluso más justo para los equipos. Es más honesto saber de antemano que este trimestre vas a tener un ingeniero menos, que tenerlo dentro del squad formalmente pero no poder contar con él porque está haciendo trabajo para otros.

Y hasta aquí el comentario de hoy. Si habéis tenido experiencias similares tratando de mover proyectos transversales en la organización y habéis sufrido para hacerlo, me encantaría saber cómo lo habéis solucionado. Podéis dejar un comentario aquí o encontrarme en Twitter o LinkedIn.

Estrategia de Producto

Proyectos en empresas de producto