Trabajar con product managers: el trío de producto y la tensión sana
Cómo trabajar con un product manager sin traspasos ni guerras de opiniones: el trío de producto de Teresa Torres, problema y solución, y los desacuerdos.
¿Qué es el trío de producto?
Torres lo popularizó en Continuous Discovery Habits (2021). La mayoría de los tríos tiene un product manager, un diseñador y un ingeniero, pero el modelo se puede ampliar o reducir: un equipo de machine learning puede sumar un científico de datos. Lo que no cambia es la idea central: el trío lidera el descubrimiento para el trabajo que construye el resto del equipo, y no es un grupo separado del equipo de entrega (Product Talk: Product trios).
En la práctica, el trío entrevista clientes, mapea oportunidades, elige qué objetivos atacar, genera soluciones y las prueba juntos. Torres recomienda que todo el trío participe en la investigación, incluso si hay un investigador en el equipo, para que cada persona tenga contacto directo con los clientes y el aprendizaje no se quede en una sola cabeza.
¿Cómo se reparten las responsabilidades?
Un reparto común dice que el product manager define el problema y el diseñador, la solución. Torres advierte que esa división recuerda a una cascada con traspasos: definir el problema y generar soluciones forman un ciclo de ida y vuelta, y separarlos corta la retroalimentación. Su consejo es centrarse más en quién hace qué y menos en quién es dueño de qué, porque la línea entre roles es, en el mejor caso, borrosa (Product Talk: Product managers don’t own the problem).
En otro texto, Torres propone que todos sean responsables de todos los riesgos: deseabilidad, viabilidad, factibilidad, usabilidad y ética. Los ingenieros aportan más en factibilidad y los PM en viabilidad, pero nadie es dueño único de un riesgo. Torres rechaza etiquetas como «líder de factibilidad» (Product Talk: Responsibility in a product trio).
Para el diseñador, eso significa que la usabilidad no es responsabilidad exclusiva suya, y que la viabilidad no es solo tarea del PM. Lo que cambia es el tipo de conversación: en lugar de «esto no es mi área», la pregunta es «¿qué riesgo estamos dejando sin revisar?».
¿Cómo se resuelven los desacuerdos?
Una práctica razonable es no resolver por rango. Primero, explorar las perspectivas distintas: cada persona explica qué riesgo ve y por qué. Si sigue trabado, convertir la discusión en un supuesto que se pueda probar con una prueba barata, como un prototipo y cinco personas. Para encontrar una tercera opción sirve el formato «¿cómo podríamos…?», que obliga a salir de la discusión entre dos alternativas.
Eso no significa que todo se decida por consenso: alguien tiene que cerrar la decisión. Lo que cambia es que la decisión se toma con evidencia visible para todos. Una propuesta práctica es escribir en la carta del equipo cómo se toman las decisiones. No hace falta un documento largo: una página con quién propone, quién decide y cómo se prueba una duda basta para evitar que el desacuerdo se convierta en guerra de opiniones.
Si el desacuerdo es sobre qué investigar, un plan de investigación compartido, con preguntas escritas por el trío, reduce la discusión a una sola pregunta por resolver.
¿Qué tensión es sana?
Ser responsable de un riesgo que no es tu especialidad genera una incomodidad que impulsa la colaboración: según Torres, esa incomodidad lleva al diseñador a trabajar con el ingeniero las concesiones de factibilidad. Pero conviene vigilar la tensión: si los roles son rígidos, la incomodidad desaparece. Torres advierte que las responsabilidades asignadas se vuelven costumbre y los equipos olvidan salir de ellas.
Una señal sana es que el diseñador y el PM discuten sobre un flujo sin pedir permiso al jefe. Una señal preocupante es que uno de los dos dice «eso lo decide el otro» cada vez que hay un conflicto.
Ejemplo ilustrativo
Ejemplo ilustrativo: un product manager quiere lanzar en dos semanas un flujo de pago con cuatro pasos. La diseñadora cree que el paso de dirección confunde a la mitad de los usuarios. En lugar de discutir quién tiene razón, el trío propone una prueba de supuestos: cinco personas completan el flujo en prototipo con una tarea escrita. Tres se detienen en el paso de dirección. El PM ajusta el alcance: reduce el flujo a tres pasos y deja la dirección con autocompletado. El ingeniero revisa la factibilidad del autocompletado en una tarde. La decisión se toma con evidencia y nadie tuvo que ganar la discusión.
Para entender cómo se reparten el descubrimiento y la entrega, lee dual-track agile. Y si la conversación sobre estrategia es la que se atora, estrategia de producto vs. estrategia de UX aclara qué decide cada uno.
Errores comunes
- Dejar que el PM escriba requisitos y el diseñador solo haga pantallas.
- Resolver un desacuerdo porque uno tiene más rango.
- Asignar riesgos fijos: «el ingeniero siempre valida la factibilidad».
- Esperar a tener toda la información antes de hablar con el PM.
- Tomar la fricción como señal de que algo está mal, cuando puede indicar que el proceso funciona.
- Llevar el desacuerdo a una reunión grande en vez de resolverlo en el trío.
Qué puedes hacer mañana
- Escribe en una página qué decisiones toma el PM, cuáles tomas tú y cuáles se toman juntos.
- Para el próximo desacuerdo, pregunta: ¿qué prueba barata nos dice cuál opción funciona?
- Propón una sesión de quince minutos para revisar un riesgo que nadie está mirando.