Lo que me enseñó trabajar con equipos de desarrollo sobre la comunicación
Los equipos de desarrollo te enseñan a ser más preciso, más honesto sobre lo que no sabes, y más respetuoso con el coste real del trabajo. Si estás dispuesto a escuchar.
Hay una cosa que me pasó al principio de mi etapa en producto, cuando venía del diseño. Escribía specs y los entregaba al equipo de desarrollo como si fueran planos de construcción. Describía lo que quería, incluía los mockups, y esperaba que el equipo construyera exactamente eso.
El equipo construía algo diferente. No por falta de capacidad. Porque mis specs dejaban demasiadas cosas sin definir, y el equipo tomaba decisiones de implementación en esos vacíos que yo nunca había pensado.
Esa fricción me enseñó más sobre comunicación que cualquier libro o curso que haya leído.
La precisión que el desarrollo exige
El código es literal. No interpreta la intención, ejecuta la instrucción. Esa característica del desarrollo tiene un efecto muy educativo en quienes trabajan con equipos técnicos: te enseña a ser preciso.
“El botón debería estar visible” no es suficiente. ¿Visible siempre? ¿Solo en determinadas condiciones? ¿Para todos los usuarios o solo para algunos? ¿Qué pasa cuando el usuario no tiene permisos para la acción que dispara el botón?
Hacer ese ejercicio de precisión sistemáticamente cambia cómo piensas el producto. Empiezas a ver los casos extremos. Empiezas a preguntarte por los estados vacíos, por los flujos de error, por los estados de carga. Todo eso lo aprende el PM que trabaja cerca del desarrollo.
La honestidad sobre la incertidumbre
Otra cosa que aprendí: el equipo de desarrollo tiene una tolerancia muy baja para la ambigüedad que suena a certeza.
Cuando el PM dice “creo que necesitamos que haga X” con la confianza de quien está dando un requisito definitivo, el equipo dedica tiempo a construir X. Si después resulta que X era solo una hipótesis que el PM tenía pero no había validado, el tiempo se ha perdido.
Los mejores equipos de desarrollo con los que he trabajado me enseñaron a ser explícito sobre mi nivel de confianza. “Esto está confirmado por usuario y hay criterios de aceptación claros” es diferente a “esto es mi mejor hipótesis ahora mismo y puede cambiar después de la próxima ronda de discovery”. Esa distinción importa para cómo el equipo aborda el trabajo.
El respeto por el coste real
La tercera lección es más difícil de articular pero quizá la más importante.
Cuando se trabaja cerca del desarrollo, se empieza a entender el coste real de las decisiones. No en abstracto (“esto es complejo técnicamente”) sino de forma concreta: esta decisión de producto que parece un detalle menor requiere cambiar la estructura de datos, lo que implica una migración, lo que implica riesgo en producción, lo que implica trabajo de validación que no estaba planificado.
Ese entendimiento cambia cómo evalúas las peticiones. Empiezas a tener una intuición, aunque sea imprecisa, de cuándo una petición de cambio de alcance tiene implicaciones técnicas que no son obvias desde afuera. Y empiezas a hacer las preguntas correctas antes de comprometerte.
No me hice técnico. Sigo sin poder escribir código con ningún nivel de competencia. Pero aprendí a respetar la complejidad del desarrollo de formas que me hacen un mejor PM que si me hubiera quedado en el lado del diseño y la definición.
Las opiniones expresadas son personales y no representan la posición de ninguna organización.