El ritmo de product review que sí escala

La peor revisión de producto que jamás dirigí duró cuatro horas y produjo cero decisiones.

Trece personas. Una pantalla compartida con un tablero de Jira. Actualizaciones de cada equipo. Mucho asentir con la cabeza. Dos action items al final: “hacer seguimiento” y “alinear en próximos pasos.”

Salí de esa sala y borré la invitación recurrente. Luego pasé las siguientes semanas reconstruyendo cómo revisamos el estado del producto, desde cero.

Por qué fallan la mayoría de las revisiones

El error central es mezclar estatus y decisiones en la misma reunión.

Las actualizaciones de estatus requieren atención pasiva. La toma de decisiones requiere participación activa. Ejecutar ambas en secuencia garantiza que para cuando llegues a la decisión, la mitad de la sala ya se desconectó mentalmente procesando todo el estatus. La otra mitad está apurada porque ya van cuarenta minutos sobre tiempo.

Una vez que vi esto, no pude desverlo. Casi todas las revisiones ineficaces en las que había participado tenían la misma estructura: estatus primero, decisiones cuando haya tiempo, que nunca hay.

Dos loops

La solución es ejecutar dos cadencias separadas a diferentes horizontes.

Táctica: semanal, 45 minutos máximo. Este es el loop operativo. ¿Qué se entregó? ¿Qué está bloqueado? ¿Qué está en riesgo de retrasarse esta semana? ¿Quién necesita una decisión para desbloquearse? Sin presentaciones. Sin demos. Solo las personas responsables de la entrega, poniendo sobre la mesa lo que necesita atención. Cada ítem termina con dueño y fecha o no pertenece a la reunión.

Estratégica: quincenal, 90 minutos. Este es el loop de dirección. ¿En qué estamos apostando realmente? ¿Qué tradeoffs estamos haciendo? ¿Qué nos han mostrado los usuarios que cambia cómo estamos pensando? Esta es la sala donde tienes permitido decir “creo que estamos resolviendo el problema equivocado” y hay espacio para que eso aterrice.

La separación importa. La reunión táctica no permite debates filosóficos. La reunión estratégica no se empantana en el calendario de despliegue de esta semana.

Qué cambié en cómo corren las revisiones

Ninguna demo sin contexto de usuario primero. Antes de mostrar algo, alguien tiene que decir: este es el problema que estábamos resolviendo, esto es lo que sabíamos, esto es lo que construimos. La demo es lo último, no la apertura. Cambia completamente cómo responde la gente a lo que ve.

Las preguntas abiertas viven fuera de la reunión. Hay un doc compartido para preguntas abiertas. No se plantean en la sala a menos que alguien esté preparado para tomar una decisión sobre ellas en ese momento. De lo contrario se convierten en madrigueras que devoran la sesión.

Las decisiones requieren dueño y fecha. No “lo resolveremos” o “alineemos offline.” Antes de que un ítem de decisión salga de la agenda, alguien tiene su nombre en él y una fecha para la que estará resuelto. Sin excepciones.

El patrón incómodo

Cuando empecé a aplicar la regla de dueño + fecha, algo interesante ocurrió: el volumen de ítems planteados en revisiones cayó marcadamente. No porque los problemas desaparecieran, sino porque la gente empezó a resolver cosas antes de la revisión una vez que supieron que “discutamos en la revisión” ya no significaba difundir la responsabilidad.

La reunión es para cosas que genuinamente necesitan la sala. La mayoría de las cosas no. Una buena estructura de revisión le enseña a un equipo la diferencia.