Construir equipos de producto que funcionen
por Cristina Sánchez
Buenas! En la newsletter te vas a encontrar:
Un articulo necesario sobre equipos de producto. El año pasado acabe certificándome como Coach de Equipos porque después de 4 años de consultoría de producto, seguía viendo que las cosas no salían por la dependencias y la comunicación
He organizado dos eventos en Enero
Recomendación de una formación práctica: De la ambición al problema real
Os presento a Cristina Sánchez
Más de 20 años de experiencia liderando equipos multidisciplinares en sectores como banca, inmobiliaria, automoción, telecomunicaciones y tecnología.
Como Senior Product Manager ha gestionado productos para clientes como Kymco, Testa Homes, Charging Together y Evo Bank, incluyendo iniciativas internas de IA como IDEVoz para desarrollo de apps por voz y generación de código.
Y me hace mucha ilusión que publique aquí porque ha sido una de las pesonas que ha cambiado de rol este año gracias al servicio de recruting de Be Product y se une a Panel :)
Os dejo con su articulo:
Construir equipos de producto que funcionen
El producto no nace del backlog, nace del equipo
Llevo más de 20 años trabajando con equipos en desarrollo de software y gestión de productos, y si algo he aprendido es que un gran producto no nace de un gran backlog, sino de un gran equipo. Así de simple, y así de complicado.
De Ejecutores a Artífices del Cambio
Cuando hablo de equipos de producto, no me refiero a un grupo de desarrolladores, testers y diseñadores que van marcando tareas como “Done” en un tablero. Me refiero a personas que en cada iteración se paran y se preguntan: ¿podemos hacerlo mejor?
La diferencia es enorme.
Un equipo ejecutor completa historias de usuario. Punto. Un equipo con espíritu de mejora continua cuestiona, propone, experimenta y evoluciona el producto en cada sprint. No se quedan solo en el “qué”, van al “cómo” y, lo más importante, al “para qué”.
Hay una frase que odio: “Dime qué tengo que hacer y yo lo hago.” Cuando alguien dice eso, sé que algo falla. No quiero ejecutores. Quiero gente que entienda qué problema resolvemos y para quién.
La Mejora Continua
Los mejores equipos con los que he trabajado son aquellos donde cada retrospectiva es una oportunidad real de cambio, no ese ritual donde repites los mismos problemas sprint tras sprint. Donde cada refinamiento se convierte en un debate de verdad sobre el valor que aportamos, no solo en estimar story points. Donde cada Sprint Review no es solo un “mira lo que hicimos”, sino un “mira lo que aprendimos”.
En muchos de estos equipos he trabajado con Scrum, y cada evento aporta algo al equipo:
Sprint Planning: alineación y compromiso compartido sobre qué vamos a conseguir.
Daily: sincronización real, no reporte de estado. Detectar bloqueos antes de que se enquisten.
Sprint Review: feedback del usuario y stakeholders. Ver si lo que entregamos tiene valor de verdad.
Retrospectiva: el espacio para inspeccionar cómo trabajamos y adaptar para mejorar.
Si no trabajas con Scrum, da igual. Lo importante es tener un espacio donde el equipo pueda pararse, mirar cómo está funcionando, y ajustar.
Para mí, la mejora continua no es una métrica, es una mentalidad.
¿Qué tienen en común estos equipos?
Ownership Compartido: Cada miembro siente el producto como suyo. No hay “mi código” o “tu diseño”, hay “nuestro producto”.
Curiosidad: Preguntan “¿por qué siempre se ha hecho así?”
Colaboración Real: Se ayudan a superar impedimentos, no como quien espera que le toque, sino como quien disfruta de un café.
Seguridad Psicológica: Pueden fallar porque saben que el error es parte del aprendizaje.
Visión Compartida: Entienden el contexto de negocio y toman mejores decisiones. Preguntan lo relevante. Proponen alternativas. A veces te dicen que tu idea no tiene sentido. Y tienen razón.
Cómo cambia tu trabajo cuando el equipo funciona
Recuerdo un equipo que, cuando empezó a funcionar de verdad, dejé de tener que explicar el porqué de cada historia. Llegaban al refinamiento habiendo leído el contexto y preguntaban cosas que antes ni se planteaban.
Desaparecieron los “esto no estaba en la historia”. Los “no sabía que era urgente”. Los Slacks a las 6 de la tarde.
Gastas menos tiempo apagando fuegos y más en lo que de verdad importa: entender qué necesita el usuario, mirar los datos, pensar en el siguiente paso.
Y no es solo sensación. Se mide. En un equipo, organizábamos nuestras propias reuniones de arquitectura. Propusimos modularizar la aplicación. Resultado: reducción de bugs en producción de un 20%. Tiempos de compilación que pasaron de 30 minutos a 3 minutos por módulo.
En otro, “facilidad de release” salió en rojo en un health check. Ese resultado desencadenó mejoras en el pipeline de iOS que llevaban meses sin priorizarse.
Cuando el equipo funciona, la calidad sube sin que nadie tenga que pedirla.
El equipo que no puede funcionar
Lo he vivido. Equipo inestable. Alta rotación, gente repartida entre tres proyectos. Sin foco. Sin foro común.
Reuniones de 20 personas donde la mitad no tenía poder de decisión. Sin guión. Sin saber quién tenía la autoridad para decidir. Varios equipos mezclados hablando de temas que no les afectaban.
El resultado: nadie se sentía dueño de nada. Todo el mundo esperaba que otro decidiera.
Cuando por fin conseguimos equilibrarlo —100% de dedicación, un solo objetivo, reuniones con las personas justas— todo cambió. Cerramos tres productos que llevaban meses abiertos. Priorizamos de verdad. Dejamos de correr en círculos.
Un equipo fragmentado no es un equipo. Es un grupo de gente haciendo malabares.
De gestionar tareas a cultivar equipos
En mis primeros años, creía que mi trabajo era tener el backlog perfecto. Detallar historias perfectas. Me equivocaba.
El verdadero trabajo es quitar obstáculos para que el equipo funcione. Y eso se logra con confianza, facilitando conversaciones difíciles, y a veces simplemente escuchando.
En una sesión de motivadores, alguien que parecía poco involucrado dijo que “Objetivo” era su prioridad. El onboarding no había sido claro sobre la misión del equipo. Una conversación, documentación actualizada, y esa persona cambió por completo.
Transformar ejecutores en artífices del cambio no es fácil. Lleva tiempo. Requiere paciencia. Pero cuando lo consigues, la entrega mejora, los bugs disminuyen, y los stakeholders empiezan a notar la diferencia.
El problema es que “cultura de equipo” suena abstracto. ¿Cómo sabes si vas bien? ¿Cómo detectas qué falla antes de que explote?
Yo uso dos herramientas que me ayudan a tener conversaciones reales, no humo:
El Semáforo de Spotify
Una herramienta simple para evaluar cómo se siente el equipo respecto a diferentes áreas: valor de la entrega, facilidad de release, diversión, salud del código, aprendizaje, misión, autonomía, velocidad, procesos, soporte y trabajo en equipo.
Con emojis de colores (verde, amarillo, rojo), el equipo vota y genera conversaciones concretas sobre qué mejorar.
Moving Motivators
Soy fan de Management 3.0 y esta dinámica nos revela qué motiva a cada persona. Se ordenan 10 tarjetas según importancia: Aceptación, Curiosidad, Libertad, Honor, Maestría, Orden, Objetivo, Poder, Relaciones y Status.
El modelo CHAMPFROGS rompe suposiciones. Descubres que lo que más valora alguien no es lo que asumías.
Conclusión
Construir equipos de producto que funcionen lleva tiempo, conversaciones incómodas, y mucha paciencia.
Pero si algo tengo claro después de 20 años es esto: puedes tener el backlog más refinado del mundo, las historias mejor escritas, los criterios de aceptación perfectos. Si el equipo no funciona, no sirve de nada.
Invierte en el equipo. El producto vendrá solo.
¿Cuál ha sido tu experiencia con equipos que funcionaban de verdad?
Muy TOP!