La reunión de priorización que duró veinte minutos
Hace unos meses hablé con un CPO que estaba encantado con cómo había mejorado la eficiencia de su equipo. Me dio un ejemplo concreto: las sesiones de priorización trimestral, que antes les llevaban dos horas de debate intenso, ahora duraban veinte minutos. El PM llegaba con un stack rank generado a partir de los OKRs, el análisis de impacto por feature y el esfuerzo estimado de ingeniería. Todo en un doc limpio, con criterios explícitos, generado con IA. El equipo revisaba, hacía algún ajuste menor, y listo.
Le pregunté qué pasaba en esas dos horas antes. Se quedó un momento pensando. “Pues… discutíamos mucho. El PM quería priorizar una cosa, engineering quería otra, diseño tenía una opinión diferente sobre qué le importaba al usuario. A veces era frustrante.”
Le pregunté si alguna vez salían buenas ideas de esa fricción. “Sí, muchas veces. Más de las que me acordaba.”
Eso es lo que se lleva el veinte minutos.
La fricción no eran dos horas de ineficiencia. Era el mecanismo por el que cada disciplina articulaba su perspectiva, escuchaba las demás, y llegaban a una decisión que todos entendían genuinamente aunque no todos la amaran. Cuando eliminaron la fricción, eliminaron también ese mecanismo. Y lo hicieron creyendo que estaban mejorando el proceso.
Dos formas de usar IA que no son lo mismo
Antes de seguir, quiero proponer una distinción que me parece fundamental y que muy pocos equipos han hecho de forma explícita.
IA como thinking partner. Tú, solo o en pareja, usando IA para explorar ideas antes de llevarlas al equipo. Para presionar tu propia hipótesis antes de defenderla en una reunión. Para generar variantes de un concepto de diseño y ampliar tu exploración personal. Para analizar datos antes de una conversación con stakeholders. Para redactar, iterar, cuestionar tu propio trabajo. Esto es extraordinariamente poderoso. Úsalo todos los días.
IA como atajo de colaboración. Usar IA para saltarte los momentos donde el equipo necesita pensar junto. Llegar a una sesión de priorización con la respuesta ya generada. Sintetizar research de usuario con IA sin que el equipo vea las entrevistas. Preparar la retrospectiva con lo que Claude sugiere que debería mejorar el equipo. Aquí es donde se hace daño.
La clave es que la distinción no es sobre la herramienta. Es sobre el momento. La misma IA que te hace mejor individualmente puede hacerte peor colectivamente si la usas en el contexto equivocado. Y la mayoría de equipos no han hecho esa distinción de forma consciente — lo cual significa que la están dejando al criterio individual de cada persona, que es otra forma de tener adoption asymmetry pero de una dimensión diferente.
Los tres momentos que no deberían tener IA en la sala
Priorización.
En un equipo de producto con el que trabajé en fintech, el PM empezó a llegar a las sesiones de priorización con una propuesta generada con IA basada en los datos de uso del producto. Objetivamente, la propuesta era razonable. El problema es que era tan completa y tan bien argumentada que el equipo dejó de cuestionarla. El tech lead, que antes empujaba mucho en estos momentos porque veía dependencias técnicas que el PM no siempre contemplaba, dejó de hacerlo porque la propuesta ya las incluía — aunque fueran estimaciones de IA que él no había validado. La diseñadora, que solía defender los casos de usuario menos obvios en estas reuniones, asintió porque la propuesta incluía una sección de user impact que parecía sólida.
Tres meses después, estaban en medio de una feature que nadie del equipo habría priorizado si hubieran debatido de verdad. Habían optimizado para métricas que la IA sabía medir, no para el valor que el equipo sabía crear.
El valor de una sesión de priorización no es llegar a una respuesta correcta. Es que el equipo entienda por qué esa respuesta y no otra. Ese entendimiento solo se construye a través del desacuerdo y la discusión. La IA puede preparar el terreno — generar opciones, organizar criterios, calcular impactos. Pero la decisión en sí necesita la fricción humana para ser legítima.
Discovery synthesis.
Cuando un equipo revisa research de usuario, hay un momento que me gusta llamar el momento de las interpretaciones divergentes. Es cuando la investigadora dice “yo creo que estos usuarios tienen miedo a equivocarse” y el PM dice “yo lo leo diferente, creo que es impaciencia” y el diseñador dice “para mí es algo más parecido a desconfianza en el sistema.” Ninguno tiene razón todavía. Y ese desacuerdo es exactamente donde vive el insight estratégico. Lo que cada persona trae a esa interpretación — su experiencia, su perspectiva, sus asunciones sobre el usuario — es el material con el que se construye la buena estrategia de producto.
Cuando la IA sintetiza las entrevistas y da tres conclusiones limpias antes de que el equipo las haya leído, esa conversación no ocurre. La ambigüedad se colapsa prematuramente. Se obtiene una respuesta limpia a una pregunta que todavía no estaba lista para tener una respuesta limpia. Y el equipo pierde exactamente lo que hacía valiosa esa sesión.
Usa IA para transcribir, para organizar, para buscar patrones en grandes volúmenes de data. No uses IA para interpretar antes de que el equipo haya interpretado.
Retrospectivas.
Este es el más breve porque es el más simple. Una retro funciona cuando la gente dice la verdad. Cuando alguien dice “cometí un error en esa decisión y me cuesta reconocerlo.” Cuando alguien dice “hay una dinámica en el equipo que me incomoda y llevo semanas sin saber cómo sacarlo.” Cuando alguien dice “creo que estamos construyendo lo equivocado y nadie quiere escucharlo.”
Ninguna de esas frases puede pasar por un filtro de IA. Si alguien prepara su input de retro con Claude, ese input ya no es honesto — es editado, es pulido, es performativo. Es, literalmente, performative alignment en su versión más pura.
La IA no tiene cabida en una retro. Ni para preparar, ni para facilitar, ni para sintetizar. Es el único momento del proceso de producto donde la imperfección y la incomodidad son la feature, no el bug.
La regla: prepara con IA, decide sin ella
Si tuviera que condensar todo esto en un principio de diseño para equipos, sería este: usa IA para prepararte para la conversación, no para sustituirla.
Antes de una sesión de priorización, usa IA para organizar los criterios, calcular impactos, generar opciones que no habías considerado. Lleva ese material como insumo, no como conclusión. Antes de discovery synthesis, usa IA para transcribir y organizar. Lee las entrevistas tú mismo antes de ver qué dice la IA sobre ellas. Antes de una retro, usa IA para revisar métricas, para recordar qué pasó en el sprint. No para saber qué sientes ni qué debería decir el equipo.
Es la misma lógica que usa un buen abogado. Prepara el caso con toda la tecnología disponible: bases de datos jurídicas, análisis de precedentes, generación de argumentos alternativos. Pero va al juicio a argumentar en persona, porque el momento de la verdad no puede ser delegado. La preparación puede ser asistida. La decisión, no.
Cómo hacerlo sin que suene a retroceso
El pushback que escucho siempre cuando propongo esto es “¿me estás diciendo que no use IA? ¿eso no es ir hacia atrás?”
No. Estoy proponiendo exactamente lo que haría un buen product designer con un flujo de usuario. No haría el flujo más rápido en todos los pasos — diseñaría dónde poner fricción y dónde no. En un checkout, la fricción en la confirmación de pago no es un error de diseño. Es una decisión consciente para que el usuario no haga algo irreversible por accidente. La fricción protege al usuario.
En un equipo de producto, la fricción en los momentos de decisión colectiva no es ineficiencia. Es la protección contra decisiones que nadie entendió del todo, alineaciones que eran performativas, y estrategias que nadie cuestionó porque el documento se veía demasiado bien.
Un equipo que sé que lo hizo bien acordó en una retro algo muy simple. Pusieron en su Notion un doc con dos listas: momentos del proceso donde la IA está bienvenida y momentos donde no. No como política, sino como recordatorio de lo que habían decidido juntos. Tardaron veinte minutos en construirlo. Y cuando alguien llegaba a una sesión de priorización con la respuesta ya generada, cualquier persona del equipo podía señalar la lista y decir “esto es momento human-only.” Sin drama. Sin confrontación. Era simplemente el acuerdo del equipo.
Los frenos no existen para ir más lento
Hay una idea que quiero dejar antes de cerrar.
La IA te da velocidad. Y la velocidad es buena. Pero la velocidad sin fricción diseñada no es eficiencia — es un coche sin frenos. Los frenos no existen para ir más lento. Existen para poder ir rápido de forma segura.
Tu equipo necesita frenos. No porque vaya lento — sino porque va lo suficientemente rápido como para hacerse daño si nadie ha diseñado dónde parar, dónde discutir, dónde decidir juntos antes de seguir.
Saber cuándo no usar IA no es la habilidad del equipo que va con miedo a la tecnología. Es la habilidad del equipo que ha entendido para qué sirve realmente la tecnología — y para qué no.
The Human Layer es una serie que explora la infraestructura humana debajo de la adopción de IA en equipos de producto.
También encontrarás en el libro PRAXIS (www.praxisbook.com) más información acerca de los fenómenos y prácticas que estaré informando a través de esta serie.
Si esto te ha resonado, compártelo con alguien de tu equipo. Estas conversaciones funcionan mejor cuando las dos personas tienen el lenguaje.