Alineamiento de equipos de Producto e Ingeniería
Producto e Ingeniería son lo mismo pero nos empeñamos en separarlo. Vemos los orígenes de la fricción y planteamos cuatro ideas para prevenirla.
Producto e Ingeniería son dos caras de la misma moneda. Si Producto no funciona, Ingeniería no puede tener éxito. Y viceversa.
Sin embargo, cierta tensión entre ambos es inevitable y posiblemente hasta sea sana. El secreto del éxito consiste en mantener un balance equilibrado entre las necesidades de unos y otros que garantice lo único que verdaderamente importa: dar valor continuo a nuestros clientes.
En el post de hoy hablaremos de por qué sucede esta fricción y cómo podemos prevenirla, centrándonos en Startups o ScaleUps con un máximo de unas 150 personas entre Producto e Ingeniería. Por encima de ese número la complejidad organizativa puede requerir de soluciones distintas a las que planteo en el artículo.
Orígenes de la fricción entre Ingeniería y Producto
Los orígenes de la fricción entre ambos roles provienen de unos objetivos que, mal entendidos, pueden parecer enfrentados.
Por un lado, el rol de Producto consiste en construir el producto adecuado para nuestros clientes. Por su parte, el objetivo principal de ingeniería es construir el producto de la forma adecuada. Puede sonar parecido, pero no es lo mismo.
Producto generalmente siempre pide más. Presionado por mover las métricas que importan para la compañía y, en teoría conocedor de las necesidades de los usuarios, plantea iniciativas de forma constante para tratar que el producto haga más fácil la vida a estos impactando en el negocio.
Por su parte Ingeniería, presionado por mantener el producto actual en funcionamiento y preocupado por el aumento de la complejidad y de la deuda técnica que se puede acumular, suele preferir dedicar más tiempo a mantenimiento y optimización que a añadir nuevas funcionalidades.
El comportamiento de ambos grupos es completamente racional. En realidad los dos se están preocupando por el cliente aunque de distinta forma. El problema es que si no somos capaces de ponernos en el lugar del otro y entender sus necesidades, podemos llegar a un punto de bloqueo que se torna destructivo: tener a Producto e Ingeniería enfrentados.
Cómo evitar el bloqueo entre Producto e Ingeniería
Producto e Ingeniería deben reportar a la misma persona
Si Producto e Ingeniería no pueden tener éxito el uno sin el otro, si su destino está intimamente ligado, ¿por qué nos empeñamos en que reporten en dos ramas distintas de la organización?
Crear esta división artificial sólo consigue promover el tipo de conflicto que queremos evitar, por ejemplo, a nivel de objetivos. Lo último que queremos es que Producto e Ingeniería planteen cada uno los suyos de forma independiente.
Y es que, cuando así sucede, resulta que los objetivos de unos suelen chocar con los de otros. Un caso típico es el de que Producto planee una serie de iniciativas de cara a un trimestre, para descubrir más tarde que Ingeniería ha decidido realizar mejoras internas en la aplicación que restará la mitad de capacidad de esfuerzo del equipo.
En mi experiencia, cuando reportan en líneas distintas, este tipo de conflictos se detectan demasiado tarde y terminan afectando a lo único que de verdad importa, entregar valor al cliente.
Mi propuesta a este respecto es sencilla. Dejemos de separar a Ingeniería y Producto a nivel organizativo. Ambos departamentos deben reportar a una misma persona. En algunas empresas el cargo de CTO incluye las dos ramas. En otras el CPO. Algunos proponen crear un nuevo rol llamado CPTO que veo con buenos ojos. Si la empresa es todavía lo suficientemente pequeña, el CEO suele ser la persona que aunará y coordinará las dos ramas.
Sea como fuere lo importante es que haya una persona que tenga la visión de conjunto de Producto e Ingeniería y se asegure de que los esfuerzos van todos en la misma dirección.
Estructurando los equipos adecuadamente
La Ley de Conway viene a decir que cualquier organización produce diseños que son copias de sus estructuras de comunicación internas.
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. — Melvin E. Conway
Podemos hablar de que hay dos formas principales de organizar equipos. O bien los organizamos alrededor de la tecnología (equipos web, frontend, backend…), o bien los organizamos en torno a objetivos de producto (adquisición, onboarding, pagos…).
Cada una tiene su momento y sus ventajas. Generalmente en empresas de producto maduras se tiende a optar por la segunda: equipos multidisciplinares en torno a un objetivo de negocio común.
Las ventajas son varias, pero principalmente la que me parece más importante es que permite dotar a los equipos de una misión y hacerles responsables de la misma, lo que facilita el alineamiento interno.
La desventaja de este modelo es que si bien favorece avanzar en los objetivos de Producto, Ingeniería puede sufrir más porque los ingenieros se encuentran repartidos en distintos equipos lo que les impide compartir y aprender entre ellos. Para solucionarlo se suelen generar guilds (gremios) transversales que les permiten tener el soporte del resto de los miembros de la empresa que trabajan sobre una misma tecnología.
Entendiendo las necesidades del otro
Como en cualquier relación humana, esforzarse por entender las necesidades de nuestros pares suele tener recompensa.
En el caso que nos ocupa, si un Product Manager se preocupa por entender las necesidades de Ingeniería, le será más fácil ganarse el respeto del equipo cuando necesite argumentar cualquier iniciativa o esfuerzo. En este sentido, los Product Managers con cierto background técnico tienen cierta ventaja sobre aquellos para los que la tecnología es un medio ajeno.
Del mismo modo, cuando un Engineering Manager muestra interés por las métricas de producto y por entender el impacto que consigue con cada una de las iniciativas que lanza el equipo, demuestra también al Product Manager que está realmente implicado con la misión del equipo. Este alineamiento de intereses facilita que se prioricen esfuerzos propuestos del lado de ingeniería, porque si no tuvieran un impacto directo en el negocio no las plantearía.
Priorizando los datos sobre las opiniones
Todos podemos tener opiniones, pero si no las respaldamos con datos y argumentos razonados, no vamos a conseguir convencer a nadie de que reme en nuestra dirección.
Si Producto lleva continuamente iniciativas al equipo de Ingeniería sin expresar el por qué es importante hacerlas, es totalmente comprensible que Ingeniería prefiera dedicar su tiempo a fortalecer la aplicación antes de añadir más grasa sobre el producto.
Igualmente, si Ingeniería plantea una iniciativa a Producto sin hablar del impacto en el negocio, tampoco puede esperar que se reciba con entusiasmo. Dedicar un sprint a refactorizar esa parte del código está genial, pero o explicamos en términos de negocio cómo eso va a mejorar la vida a nuestros usuarios o no esperemos que Producto lo compre.
“If we have data, let’s look at data. If all we have are opinions, let’s go with mine.” ― Jim Barksdale
Conclusión
El éxito de Ingeniería y Producto depende íntimamente el uno del otro. Separándolos sólo conseguimos sumar fricción a una relación que de por sí ya sufre cierta tensión natural.
Esta fricción puede derivar en bloqueo y conflicto, afectando a lo único que verdaderamente importa, atender las necesidades de nuestros clientes haciéndoles su vida más sencilla. Por lo tanto, es vital tratar de evitarlo. En el artículo de hoy hemos visto cuatro ideas sencillas que nos pueden permitir hacerlo:
Haciendo que Producto e Ingeniería reporten a una única persona
Estructurando los equipos adecuadamente
Entendiendo las necesidades de cada uno de los equipos
Priorizando los datos sobre las opiniones
No son las únicas, y seguro que hay muchas otras ideas que se pueden poner en práctica para alinear a ambos. Si te tienes que llevar alguna idea de este artículo, el mejor consejo que te puedo dar es no separar algo que en realidad es lo mismo.
📝 Referencias
How To Create Harmony Between Engineering & Product Teams – Built In
The healthy tension trap – John Cutler
Engineering vs Product — Turning Tension into Triumph – TheProductFul
Engineering Org Design: Code-centric vs. Product Goal-centric Teams – ICONIQ Growth
The Line Between the Product Team and Engineering? – Jama Software
🙌 ¡Comparte!
Cómo siempre, muchas gracias por estar ahí. Si te ha gustado el post y crees que le podría interesar a alguien de tu entorno sé libre de reenviarle este correo. También puedes utilizar estos enlaces para compartirlo directamente en Twitter o LinkedIn y así contribuirás a que esta lista llegue a más gente.
Muchísimas gracias de antemano, Simón.