Silos de datos entre Engineering y Producto
Los PMs y los ingenieros usan herramientas, lenguaje y plazos diferentes. Así se forma el silo – y qué lo soluciona de verdad.
By Ellis Keane · 2026-03-16
En algún momento, la «alineación producto-engineering» se convirtió en un título de trabajo en lugar de algo que simplemente ocurría cuando personas competentes trabajaban juntas. Las empresas contratan ahora a personas dedicadas cuyo único propósito es asegurarse de que dos grupos de personas inteligentes – que comparten el mismo espacio de trabajo de Slack, asisten a los mismos standups y teóricamente trabajan hacia los mismos objetivos – puedan entender realmente lo que está haciendo el otro grupo. Los silos de datos entre engineering y producto que hacen esto necesario no son un problema de personas. Son un problema de herramientas.
Los PMs y los ingenieros se comunican bastante. El problema es que trabajan en sistemas completamente diferentes, y los silos que se forman entre esos sistemas son estructurales – integrados en la arquitectura de cómo los equipos modernos eligen sus herramientas. Ningún grado de «alineémonos con más frecuencia» soluciona un problema donde las propias herramientas no tienen conciencia unas de otras.
Las dos realidades
Aquí me baso en nuestra propia experiencia construyendo Sugarbug, porque lo vivimos cada día y creo que los detalles concretos son más útiles que la versión abstracta.
El lado del PM (que en nuestro caso soy principalmente yo) vive en Notion. Las especificaciones se escriben allí, se rastrean prioridades, se registran conversaciones con clientes, se catalogan solicitudes de funcionalidades en listas que crecen semana a semana. Notion es donde vive el «por qué» – por qué estamos construyendo algo, qué dijo realmente el cliente, qué contexto estratégico hay detrás de una decisión determinada. Es desordenado, es extenso, y es donde ocurre el pensamiento más importante antes de que se escriba una sola línea de código.
Mientras tanto, nuestros ingenieros viven en Linear y GitHub. Linear contiene las tareas, los ciclos de sprint, las cadenas de dependencias y los issues bloqueantes. GitHub tiene el código, los pull requests, los hilos de revisión donde la gente discute constructivamente (con suerte) sobre los detalles de implementación. Ahí es donde viven el «cómo» y el «cuándo» – cómo se está construyendo algo, cuándo se entregará, qué hay en el camino.
Ambas realidades son precisas, ambas esenciales, y están completamente desconectadas entre sí. La brecha entre ellas es donde los requisitos quedan obsoletos y el retrabajo empieza a acumularse.
Cómo se forman realmente los silos de datos entre engineering y producto
Es tentador pensar que esto es una elección deliberada – que alguien decidió mantener la información separada. En la práctica, el silo se forma a través de un comportamiento completamente razonable que nadie pretendía que fuera dañino.
Un PM escribe una especificación en Notion, la enlaza en Slack al canal de engineering y considera que la entrega está hecha. Un ingeniero lee la especificación, crea tres issues de Linear a partir de ella y empieza a construir. Hasta aquí, todo funciona.
Pero entonces la especificación cambia – una conversación con un cliente desplaza la prioridad, o el contexto del negocio evoluciona. El PM actualiza el documento de Notion y deja una nota en Slack sobre el cambio. El ingeniero, inmerso en una sesión de codificación, no ve el mensaje de Slack durante horas. Para entonces ya ha construido dos de las tres funcionalidades según la especificación antigua, y el tercer issue en Linear todavía hace referencia a requisitos que ya no existen.
Nadie fue descuidado aquí. Nadie «falló en comunicar». La información vivía en un sistema y el trabajo ocurrió en otro, y el tejido conectivo entre ellos era un mensaje de Slack que quedó enterrado bajo otros hilos antes de que la persona adecuada lo viera.
Esto ocurre repetidamente – en cada especificación, cada sprint, cada trimestre – y la desviación se acumula. La brecha entre lo que producto cree que está ocurriendo y lo que engineering está construyendo realmente se amplía con cada entrega que depende de que alguien note un mensaje en el momento adecuado.
Por qué «mejor comunicación» no lo arregla
He estado en retrospectivas donde el ítem de acción era «comunicar los cambios de forma más proactiva», y (con cariño) eso es el equivalente organizativo de decirle a alguien que simplemente sea más organizado. Suena accionable, hace que la página de Confluence parezca productiva, y no cambia absolutamente nada sobre el sistema que causó el problema. Hemos ejecutado ese mismo ítem de acción de retrospectiva tres veces – lo comprobé.
La razón por la que una mejor comunicación no resuelve los silos de datos entre engineering y producto es que la comunicación ya está ocurriendo – los datos existen, las decisiones se están tomando y registrando. Solo se registran en herramientas que no tienen conciencia unas de otras.
Notion no sabe que una especificación ha sido descompuesta en tres issues de Linear. Linear no sabe que los requisitos detrás de un issue cambiaron en Notion hace dos horas. GitHub no tiene idea de que el PR que se está revisando implementa una funcionalidad cuya prioridad acaba de ser degradada en el tablero de Notion del PM. Cada herramienta funciona exactamente como fue diseñada – simplemente no fueron diseñadas para funcionar juntas.
«Hay una cierta comedia oscura en pasar el lunes por la mañana confirmando que las herramientas por las que pagas no se han alejado silenciosamente de la realidad durante el fin de semana.» – Ellis Keane
Lo que ocurre entonces es que los PMs reflejan manualmente los cambios de Notion en Linear cuando cambian las especificaciones, los ingenieros contactan a los PMs en Slack para preguntar «¿sigue siendo este el plan?», y los líderes pasan sus lunes por la mañana cruzando tableros para detectar desviaciones. Hemos visto cómo quemamos varias horas a la semana en lo que equivale a sincronización manual de datos entre herramientas que, en teoría, ya deberían conocerse entre sí.
Cómo se ve realmente una solución sistémica
El instinto cuando ves una brecha entre dos herramientas es construir un puente – una automatización de Zapier, un webhook, un script de sincronización. Para flujos de trabajo simples y predecibles (cuando un issue de Linear pasa a «Hecho», actualizar un estado en Notion), eso funciona bien.
Pero los silos de datos entre engineering y producto involucran contexto, no solo estado. El PM no solo cambió un campo de estado; reescribió un párrafo en la especificación que cambia lo que «hecho» significa para dos de los tres issues de Linear. Los webhooks de estado simple omiten los cambios a nivel de requisitos a menos que añadas lógica de diferencias y mapeo semántico, lo cual la mayoría de los equipos nunca llega a construir.
Lo que realmente necesitas es algo que entienda las relaciones entre los datos a través de las herramientas – no solo «esta página de Notion está vinculada a este issue de Linear», sino «esta sección de la especificación describe los requisitos para este issue, y esa sección acaba de cambiar». El objetivo es mapear automáticamente las ediciones de especificaciones a los issues afectados, en lugar de confiar en que alguien note y propague el cambio.
Esa es la diferencia entre una capa de sincronización y un grafo de conocimiento. Una capa de sincronización copia datos entre herramientas. Un grafo de conocimiento rastrea cómo se relacionan los datos, detecta cuándo cambian esas relaciones, y muestra los cambios a las personas que necesitan saberlo.
Estamos construyendo Sugarbug para funcionar de esta manera – conectando las herramientas que los PMs y los ingenieros ya usan (Notion, Linear, GitHub, Slack, Figma) en un grafo de conocimiento que mantiene las relaciones entre especificaciones, tareas, código y conversaciones. Todavía estamos al principio (honestamente, hay mucho que aún no hemos resuelto sobre cómo hacer que la detección semántica de diferencias sea fiable a escala), pero el grafo principal funciona y ya ha detectado situaciones de desviación de especificaciones que se habrían convertido en retrabajo.
Los silos de datos entre engineering y producto se forman porque las herramientas están estructuralmente desconectadas, no porque las personas se comuniquen mal. La solución es conectar los datos a nivel de relaciones, no añadir más canales de comunicación.
Qué puedes hacer esta semana
No voy a pretender que la única respuesta es «usar Sugarbug». Hay cosas que puedes hacer ahora mismo, con las herramientas que ya estás usando, para reducir los peores efectos del silo de datos producto-engineering.
Haz que las referencias cruzadas sean explícitas, bidireccionales y con responsable asignado. Cada especificación de Notion debería tener una sección «Issues de Linear» al final que enlace a los issues que generó, y cada issue de Linear debería enlazar de vuelta a su especificación fuente. Asigna a una persona por especificación la responsabilidad de las referencias cruzadas – no a todo el equipo, una persona, con su nombre en ello. Probamos la versión de «todos son responsables» y (predeciblemente) nadie lo era. Los enlaces se irán desviando con el tiempo de todas formas, pero tener un responsable nombrado significa que hay alguien a quien contactar cuando se detecta la desviación.
Establece un ritual de «cambio de especificación» con un disparador, no un recordatorio. Cuando una especificación cambia de forma sustancial (no errores tipográficos – cambios reales de requisitos), el PM actualiza los issues de Linear vinculados antes de cerrar la pestaña de Notion. No después, no «cuando tenga tiempo» – antes de cerrar la pestaña. El comentario en cada issue afectado debería ser una línea: qué cambió, enlace a la sección actualizada, y si los criterios de aceptación del issue siguen siendo válidos. Hemos descubierto que vincular la actualización a una acción física (cerrar la pestaña) funciona mejor que depender de la memoria de alguien, porque la memoria es exactamente cómo se formó el silo en primer lugar.
Realiza una revisión de prioridades de 15 minutos los viernes. Una persona (rotación semanal) muestra las 5 principales prioridades del PM en Notion y las 5 principales del sprint de engineering en Linear, una al lado de la otra. La pregunta no es «¿son idénticas?» – no lo serán, y eso está bien. La pregunta es «¿hay alguna que se contradiga activamente?» Si la prioridad número 1 del PM no aparece en ningún lugar del sprint, esa es la conversación para el lunes, no una actualización de estado.
Estos son procesos manuales, y tienen una vida útil limitada. Con cinco ingenieros y dos PMs, son tediosos pero funcionan. Con quince ingenieros, tres PMs y un equipo de diseño que añade Figma al mix, las relaciones entre herramientas se multiplican más rápido de lo que nadie puede rastrear a mano. Pero te enseñarán dónde están realmente tus peores brechas de alineación producto-engineering – y ese valor diagnóstico vale el esfuerzo aunque eventualmente automatices todo.
Ya sea que la solución a largo plazo sea Sugarbug o algo más (obviamente creemos que estamos construyendo lo correcto, pero soy parcial), el problema de colaboración entre gestión de producto e ingeniería solo se resuelve cuando las propias herramientas están conectadas a nivel semántico, y los humanos pueden centrarse en tomar decisiones en lugar de transportar contexto entre aplicaciones.
Si tus referencias cruzadas manuales aguantan, aprovéchalo mientras dure. Si sigues teniendo los mismos ítems de acción de retrospectiva sobre comunicación, el problema no es tu gente. Es tu arquitectura de datos.
Conecta Notion, Linear, GitHub y Slack en un grafo de conocimiento – para que los cambios en las especificaciones lleguen automáticamente a los ingenieros correctos.
Q: ¿Cuánto tiempo lleva configurar Sugarbug para un equipo de producto-engineering? A: La conexión inicial lleva minutos por herramienta – autenticas Linear, GitHub, Notion, Slack y Figma vía OAuth, y Sugarbug empieza a construir el grafo de conocimiento de inmediato. El grafo se vuelve útil de forma significativa en uno o dos días mientras ingiere tus datos existentes y empieza a mapear las relaciones entre especificaciones, issues y conversaciones. Todavía estamos refinando el flujo de incorporación, pero el objetivo es que no necesites configurar nada más allá de conectar tus cuentas.
Q: ¿Sugarbug reemplaza a Linear, Notion o alguna de nuestras herramientas existentes? A: No. Sugarbug se sitúa junto a tus herramientas existentes y las conecta – no reemplaza ninguna de ellas. Tus PMs siguen escribiendo especificaciones en Notion, tus ingenieros siguen trabajando en Linear y GitHub, y Sugarbug mantiene las relaciones entre ellos para que el contexto no se pierda en el camino. Piénsalo como el tejido conectivo entre las herramientas que ya usas.
Q: ¿Puede Sugarbug detectar cuando cambia una especificación en Notion y alertar a los ingenieros correctos? A: Esa es una parte central de lo que estamos construyendo. Cuando una especificación cambia en Notion, Sugarbug identifica qué issues de Linear están vinculados a ella y muestra el cambio a los ingenieros que trabajan en esos issues. Todavía estamos iterando en la parte de detección semántica (determinar qué cambios son sustanciales frente a cosméticos), pero la vinculación entre herramientas y la detección básica de cambios funcionan.
Q: ¿Cuál es la diferencia entre una herramienta de sincronización y un grafo de conocimiento para este problema? A: Una herramienta de sincronización copia cambios de estado entre aplicaciones – cuando un issue de Linear pasa a «Hecho», actualiza una casilla de verificación en Notion. Un grafo de conocimiento rastrea cómo se relacionan los datos: esta especificación describe los requisitos para estos tres issues, y los criterios de aceptación cambiaron, lo que afecta a los dos issues que aún no se han entregado. La diferencia importa más cuando los cambios son semánticos, no solo a nivel de estado.
Q: ¿La alineación producto-engineering es un problema de comunicación o un problema de datos? A: En nuestra experiencia, casi siempre es un problema de datos que se diagnostica erróneamente como un problema de comunicación. Los equipos se comunican – simplemente lo hacen a través de herramientas que no tienen conciencia unas de otras. Arreglar el flujo de datos entre esas herramientas tiende a resolver los problemas de alineación que ninguna cantidad de retrospectivas o reuniones de sincronización podría solucionar.