Práctica 02.05 · Retención
Haz una revisión de producto periódica
Una revisión de producto no es una reunión para presentar todos los números. El equipo conecta los cambios con los resultados y elige como máximo tres decisiones siguientes.
60 minutos para la primera revisión
En lenguaje sencillo
La reunión existe para reducir la lista de tareas
Qué vas a necesitar
01
Cuándo aplicarla
El equipo publica cambios pero nunca vuelve sobre su efecto; las reuniones se convierten en un reporte de números y la lista de tareas solo crece.
En lenguaje sencillo
Qué preparar antes de la reunión
No reúnas decenas de dashboards. Trae solo los datos, los cambios y las señales reales que hacen falta para las decisiones de este periodo.
Pantalla de salud
Muestra el crash-free rate, la conversión de la primera ruta, el FTD, el D1 y el D7, las solicitudes de soporte y la respuesta a los mensajes junto al periodo anterior.
Sin un dashboard único, reúne siete números en una tabla y anota la fuente, el periodo y el responsable de cada uno.Registro de cambios
Anota los tres releases, experimentos o comunicaciones principales del periodo, con fechas y el efecto esperado.
Si no se llevó un registro, reconstruye los cambios a partir de las tareas, las versiones de la tienda y el calendario de envíos.Señales reales
Agrega tres temas recurrentes de soporte o reseñas y un ejemplo concreto de una ruta de usuario.
Pide a soporte que elija de antemano cinco solicitudes representativas, en lugar de la impresión general de que «hay más quejas».02
Haz una revisión de producto en 60 minutos
Muestra la salud del producto
Empieza con 5 a 7 indicadores a lo largo del tiempo y marca solo los cambios significativos. No comentes cada número uno por uno.
- Dónde hacerlo
- En una sola pantalla con el periodo, las fuentes y los valores anteriores.
- Cómo se ve el resultado
- Crash-free 99,6%, sin cambios; primer resultado útil +8 p.p.; D7 sin cambios; preguntas sobre el estado +40%.
Pon los cambios junto a las señales
Nombra los tres releases o comunicaciones principales con fechas y el efecto esperado. No atribuyas causalidad sin una verificación.
- Dónde hacerlo
- En la segunda columna del registro.
- Cómo se ve el resultado
- 3 de junio: onboarding acortado; 7 de junio: nueva pantalla de estado publicada; 10 de junio: cambió la ruta del push.
Agrega la voz del usuario
Muestra las preguntas recurrentes y una ruta típica. Una señal cualitativa ayuda a explicar qué se esconde detrás de la métrica.
- Dónde hacerlo
- Junto al indicador correspondiente.
- Cómo se ve el resultado
- 12 usuarios preguntan si su operación se completó, aunque no hay ningún error técnico.
Elige una conclusión principal
Formula el problema o la oportunidad en una frase. No mezcles calidad, retención y crecimiento en un tema difuso.
- Dónde hacerlo
- En un bloque visible antes de las decisiones.
- Cómo se ve el resultado
- La pantalla nueva funciona técnicamente pero no explica el estado: eso genera solicitudes y desconfianza.
Limita las decisiones a tres
Cada decisión necesita responsable, plazo y una señal para revisar en la próxima revisión. Deja explícitamente de lado el resto de las ideas.
- Dónde hacerlo
- En la última columna del registro y en la lista de tareas.
- Cómo se ve el resultado
- Agregar el estado — Ana — 21 de junio — solicitudes sobre el tema y finalización de la acción.
03
Ejemplos prácticos
Una señal se convierte en decisión
Después de la pantalla nueva los indicadores técnicos están estables, pero las preguntas sobre el estado crecieron un 40%. La conclusión: el proceso no está claro; la decisión: agregar el estado, un responsable y una revisión de las solicitudes.
Tres decisiones en lugar de veinte ideas
El equipo arregla la ruta del push, explica el estado de la operación y revisa la próxima cohorte. Las ideas restantes quedan aparcadas de forma explícita hasta la siguiente revisión.
Registro de la revisión de producto
No transcribas toda la discusión. Anota la señal, su relación con un cambio y una decisión que se pueda revisar.
| Señal | Qué cambió | Conclusión | Decisión y responsable |
|---|---|---|---|
| Crash-free estable | Release 4.3 | No hay regresión técnica | Observar · equipo móvil |
| Primer resultado útil +8 p.p. | Onboarding más corto | El cambio ayuda | Extender a Android · producto |
| D7 sin cambios | Ruta nueva activa desde hace 2 semanas | El efecto todavía no llegó | Revisar la próxima cohorte · analista |
| Preguntas sobre el estado +40% | Pantalla nueva de operación | Falta una explicación | Agregar el estado · diseño + soporte |
| Los push se abren, la acción no sube | Deep link genérico | Se pierde el contexto | Arreglar la ruta · comunicaciones |
Foco del periodo: explicar el estado de la operación. No más de tres decisiones: arreglar la ruta, actualizar el texto del estado, revisar la próxima cohorte. Todo lo demás queda fuera del plan hasta la siguiente revisión.
04
Lista de verificación de la reunión
No empieces la reunión hasta tener reunidos los datos y los cambios: el tiempo del grupo debe ir a las decisiones.
05
Cómo saber si la revisión funciona
Decisiones completadas
La siguiente reunión arranca desde los acuerdos anteriores y sus resultados reales.
Foco mantenido
No hay más de tres acciones acordadas en curso y las ideas nuevas no las desplazan sin motivo.
La experiencia mejora
Las señales elegidas de calidad, retención o confianza se mueven cuando las decisiones están hechas.
Una buena revisión de producto reduce la lista de tareas y deja al equipo con unas pocas decisiones cuyo efecto se puede comprobar.