-
サマリー
あらすじ・解説
Si trabajas en un equipo de producto o desarrollo, seguro que alguna vez has sentido que hay una especie de trinchera entre ambos mundos. Los product managers pidiendo rapidez, los desarrolladores exigiendo calidad, las fechas de entrega tensando la relación... Vamos, un clásico.
Por eso, cuando tuve la oportunidad de entrevistar a Raul Gonzalez, CTO y asesor tecnológico, no dudé en preguntarle sobre cómo mejorar la colaboración entre producto y desarrollo. Raúl ha trabajado con startups y scale-ups ayudando a construir equipos técnicos eficientes y alineados con el negocio. Así que, si alguien sabe de esto, es él.
¿Por qué hay tantas fricciones entre producto y desarrollo?
Le pregunté directamente: ¿Dónde están las mayores tensiones entre estos dos equipos? Y su respuesta fue clara: viene de lejos.
Raúl explica que la estructura tradicional de trabajo en cascada dejó una herencia difícil de romper. Antes, producto definía los requisitos y los pasaba a desarrollo como si fueran una fábrica, sin apenas interacción. Con la llegada de Agile, en teoría, esto cambió. Pero, en la práctica, aún vemos equipos trabajando en silos, sin entenderse del todo.
También me habló de un error común: pensar que el delivery es solo cosa de desarrollo. En realidad, entregar producto es una misión de equipo, y cuando no se entiende así, empiezan los problemas.
Aquí Raúl usó una metáfora que me pareció muy acertada: en un equipo de fútbol, defender no es solo tarea de los defensas. Si el equipo entero no colabora en la defensa, tarde o temprano recibirán goles. Lo mismo pasa en los equipos de producto: si desarrollo y producto no trabajan juntos en la entrega, el resultado será un caos. Todos deben asumir la responsabilidad del éxito del producto, sin delegar completamente en el otro equipo.
Velocidad vs. Calidad: ¿Se puede tener todo?
Uno de los grandes conflictos entre producto y desarrollo es el equilibrio entre ir rápido y hacer las cosas bien.
Raúl lo dejó claro: la calidad es lo que te permite ir rápido a largo plazo. Un equipo que construye con calidad desde el principio evita problemas futuros, reduce la deuda técnica y puede moverse con más agilidad. Pero claro, eso implica tomar buenas decisiones sobre cuándo y cómo asumir deuda técnica.
Aquí soltó una comparación que me encantó: la deuda técnica es como una deuda financiera. Si la usas bien, te da un impulso; si abusas de ella, acabas ahogado.
Cómo mejorar la colaboración entre producto y desarrollo
Si tuviera que quedarme con tres ideas clave de la entrevista, serían estas:
* Construir un equipo de verdad. No basta con juntar a product managers y desarrolladores en la misma reunión. Hay que generar confianza, empatía y propósito compartido.
* Los desarrolladores deben entender negocio y los PMs tecnología. Si cada equipo solo habla su propio idioma, la comunicación se rompe. Raúl insiste en que los ingenieros deberían hablar con usuarios y los PMs deberían entender las implicaciones técnicas de sus decisiones.
* Eliminar la mentalidad de silos. Producto no es el enemigo de desarrollo y viceversa. Los mejores equipos trabajan con una visión común y desafían mutuamente sus ideas para llegar a mejores soluciones.
Raul ha sacado un playbook sobre como escalar tu equipo que es una pasada! Echale un ojo aquí!
Si alguna vez has sentido fricción entre producto y desarrollo en tu empresa, te recomiendo que veas la entrevista completa. Hay ideas súper valiosas para cualquier equipo que quiera trabajar mejor y entregar producto sin tanto drama.
🔗 Mira la entrevista completa aquí:
→ ¿Te gusta el contenido? Suscríbete a mi canal de YouTube y apoya al podcast.
→ ¿Quieres venir a hablar al podcast? Contesta a este email.
This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit www.alvaroperezbello.com