Long Suciu pasó años construyendo la cadena de herramientas que conectó los objetivos con la ejecución en más de 30 equipos de producto en Gartner. En este segmento de su conversación con Patrycja Radwanska en la serie Let’s Talk Operations, recorre cómo la organización pasó de objetivos en PowerPoint y epics en proyectos de Jira desorganizados a un sistema integrado donde Productboard alojaba la estrategia y Jira gestionaba la ejecución – y cómo esa integración hizo que 70 product managers fueran mediblemente más productivos.
El punto de partida: objetivos en presentaciones, ideas en tickets de Jira
El problema que Suciu heredó era de altitud. Todo el mundo estaba trabajando en la herramienta equivocada al nivel equivocado. Los objetivos y metas vivían en presentaciones que los product managers actualizaban manualmente, copiaban en otras presentaciones, y luego presentaban en revisiones mensuales que consumían horas de preparación por minutos de discusión. Mientras tanto, Jira – que debería haberse reservado para la ejecución – se había convertido en el vertedero de todo: ideas, peticiones de funcionalidades, conceptos a medio formar y elementos de trabajo reales, todo mezclado en backlogs que crecían sin límite.
Los product managers dedicaban sus días sumergidos en tickets de Jira en vez de pensar estratégicamente en roadmaps. Los epics no eran paquetes de trabajo organizados vinculados a objetivos. Eran cubos. Las cosas se echaban dentro. La conexión entre lo que la organización quería conseguir y lo que los equipos estaban construyendo realmente existía solo en la cabeza de unos pocos individuos, y cuando esos individuos cambiaban de rol o dejaban la empresa, la conexión desaparecía por completo.
“Los product managers deberían ser pensadores estratégicos y estar pensando en construir roadmaps y generar ideas, mirando idealmente a seis o doce meses vista en vez del día a día.”
El descubrimiento de herramientas: Quantive, Productboard y la consolidación
El primer intento de Suciu por resolver el problema de trazabilidad fue manual. Capturar objetivos en una hoja de Excel. Mapearlos a epics. Lo abandonó rápidamente: con 70 product managers, nadie iba a mantener un mapeo Excel-a-Jira a mano.
El proceso de descubrimiento de herramientas llevó a dos plataformas. Quantive se convirtió en la plataforma de gestión de objetivos: el lugar donde vivirían los OKRs. Productboard se convirtió en la plataforma de roadmap y gestión de producto: el lugar para ideas (cosas que podrías hacer pero no vas a hacer todavía) y roadmaps (cosas que vas a hacer). Jira se mantuvo como la capa de ejecución.
La arquitectura era lógica. Objetivos en Quantive. Elementos de roadmap en Productboard, vinculados a epics en Jira. Un solo ticket de Jira podía trazarse a través de un epic hasta un elemento de roadmap hasta un objetivo. Las personas adecuadas trabajarían a la altitud adecuada: los VPs mirarían objetivos, los product managers trabajarían en Productboard, los equipos de desarrollo ejecutarían en Jira.
La realidad fue más desordenada. Quantive nunca logró la adopción que Suciu necesitaba. La gente no quería entrar en otra plataforma más. El punto de inflexión llegó cuando Productboard introdujo soporte de OKRs de forma nativa, lo que significó que objetivos y roadmaps podían vivir en la misma herramienta. La consolidación fue transformadora. Los product managers podían ahora asociar objetivos con funcionalidades, y cuando una funcionalidad estaba lista para construirse, un clic creaba el epic de Jira directamente desde Productboard.
El efecto upstream: un Jira más limpio
El beneficio más inesperado de la integración con Productboard fue lo que le ocurrió a Jira. Se limpió. Cuando las ideas y los elementos de roadmap vivían en Productboard, Jira dejó de ser el lugar donde cada pensamiento se volcaba como un ticket. Jira pasó a ser representativo del trabajo que realmente iba a ocurrir – no todo lo que podría ocurrir, podría pasar, o alguna vez le pareció buena idea a alguien que ya no trabajaba en la empresa.
Esto tuvo un efecto en cascada sobre la salud de los equipos. Los backlogs se redujeron. La relación señal-ruido mejoró. La planificación de sprint se aceleró porque había menos ruido que filtrar. Y los product managers que habían estado dedicando sus días en Jira – revisando tickets, actualizando estados, ahogándose en detalle operacional – finalmente podían dedicar su tiempo a estrategia, ideas y el horizonte de seis a doce meses que su rol realmente demandaba.
Vender el cambio: apoyo del CTO y encontrar campeones
La historia de adopción merece estudiarse porque ilustra un patrón que Suciu encuentra repetidamente. La venta a nivel de equipo fue relativamente directa: Productboard resuelve el problema de tener ideas que no quieres perder y un roadmap que necesitas mantener, sin crear un backlog infinito de tickets de Jira. Los product managers entendieron la propuesta de valor inmediatamente.
La capa de gestión de objetivos fue más difícil. Conseguir que la dirección senior usara un sistema de registro para OKRs en vez de revisar presentaciones requirió el patrocinio del CTO. Suciu atribuye al apoyo personal del CTO – trabajando directamente con el equipo de dirección, dirigiéndoles a Quantive (y después a Productboard) para revisar objetivos – el haber sido el punto de inflexión. Sin ese respaldo de arriba abajo, la plataforma habría seguido siendo una herramienta usada por entusiastas e ignorada por todos los demás.
La otra palanca fue encontrar campeones internos. Suciu describe estar atento a señales: un product manager que había trabajado con OKRs en una empresa anterior, alguien que se entusiasma cuando ve las funcionalidades, una persona cuyo entusiasmo sería contagioso exactamente en las partes de la organización que más se resistían.
“Si consigo a esa persona que ha hecho OKRs en otra organización, que está totalmente metida en ello, y le enseño cómo puede poner sus OKRs aquí –”
La frase se pierde en la transcripción, pero la implicación es clara. La adopción se extiende a través de la prueba, no de los mandatos. Un campeón entusiasta en un grupo de producto escéptico vale más que una docena de sesiones de formación.
Para el desglose completo de la entrevista, consulta nuestra entrevista completa con Long Suciu.
Herramientas mencionadas en la entrevista
Las siguientes herramientas y plataformas fueron mencionadas durante esta conversación.
Contenido relacionado
Operaciones de producto a escala sin romper equipos: entrevista con Long Suciu
Long Suciu lleva 25 años rediseñando cómo los equipos de producto e ingeniería planifican, priorizan y entregan. Explica por qué los story points suelen ser lo primero en eliminarse, cómo una cadencia de planificación trimestral de seis semanas alineó a más de 30 equipos en Gartner, y por qué las herramientas deben reforzar comportamientos en lugar de reemplazarlos.
Dashboards de Power BI que los managers de ingeniería realmente usan
Long Suciu construyó dashboards de Power BI con datos de Jira que los managers de ingeniería realmente abrían cada mañana. Explica los principios de diseño -- legibilidad, actualización diaria, visibilidad de objetivos de sprint -- que los hicieron funcionar, y cómo la transparencia de backlog llevó a las conversaciones de archivado más productivas de su carrera.
Por qué eliminar los story points es el primer paso en cualquier transformación ágil
Long Suciu explica por qué eliminar los story points -- una práctica que usa el 90% de los equipos de software -- suele ser el shock más productivo para el sistema cuando se transforma la forma en que los equipos planifican y entregan.