# Haz una revisión de producto periódica

- **URL canónica:** https://playbook.affpartners.io/es/apps/practices/retention-review/
- **Versión Markdown:** https://playbook.affpartners.io/es/apps/practices/retention-review/index.md
- **Módulo:** Retención
- **Tiempo:** 60 minutos para la primera revisión

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.

## Resultado

Un registro de revisión de una página con la salud del producto, tres cambios del periodo, una conclusión clave y hasta tres decisiones con responsable.

## La reunión existe para reducir la lista de tareas

En un mismo periodo el equipo puede publicar un release, cambiar el onboarding y lanzar mensajes. La revisión responde: qué pasó con la experiencia del usuario, qué cambio pudo causarlo y qué revisamos después. El resultado son decisiones, no una pila de diapositivas.

## Qué vas a necesitar

- **Participantes:** El product manager, un analista o responsable de datos, un representante técnico, soporte y un especialista de comunicaciones.
- **Una pantalla:** De 5 a 7 indicadores de calidad, primera ruta útil, retención, solicitudes de soporte y comunicaciones a lo largo del tiempo.
- **Ritmo:** Semanal para un producto que cambia rápido o mensual para uno estable; siempre el mismo periodo de comparación.

## Términos en lenguaje sencillo

- **Retention — La proporción de usuarios que vuelven:** Definición: Muestra cuántas personas vuelven a abrir la app pasado un periodo determinado desde la instalación o el registro. Ejemplo: Si 18 de 100 usuarios nuevos vuelven a los siete días, el retention D7 es del 18%.
- **D1 / D7 / D30 — Regreso a los 1, 7 o 30 días:** Definición: La D viene de day, día. La métrica muestra qué proporción de un grupo de usuarios nuevos volvió después del número de días elegido. Ejemplo: D7 = 18% significa que 18 de cada 100 usuarios nuevos volvieron a los siete días.
- **Crash-free rate — La proporción de usuarios sin cierres inesperados de la app:** Definición: Cuanto más cerca del 100%, menos usuarios sufrieron un cierre inesperado de la app durante el periodo elegido. Ejemplo: Un 99,5% de usuarios crash-free significa que el 0,5% sufrió al menos un cierre inesperado.
- **FTD — El primer depósito de un usuario:** Definición: La primera vez que un usuario registrado fondea su cuenta. Es el resultado de toda la ruta, no un botón suelto que haya que promocionar con más insistencia. Ejemplo: Si 100 personas completan el registro y 24 hacen un primer depósito, la conversión a FTD es del 24%.
- **Conversion — La proporción de personas que pasan al siguiente paso:** Definición: Muestra cuántas de las personas que empezaron un paso lo completaron o llegaron al siguiente. Ejemplo: 80 registros completados de 100 iniciados: 80 ÷ 100 × 100% = 80% de conversión.

## 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.

## 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**
  - **Fuente:** 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.
  - **Si no hay acceso:** 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**
  - **Fuente:** Anota los tres releases, experimentos o comunicaciones principales del periodo, con fechas y el efecto esperado.
  - **Si no hay acceso:** 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**
  - **Fuente:** Agrega tres temas recurrentes de soporte o reseñas y un ejemplo concreto de una ruta de usuario.
  - **Si no hay acceso:** Pide a soporte que elija de antemano cinco solicitudes representativas, en lugar de la impresión general de que «hay más quejas».

## Haz una revisión de producto en 60 minutos

1. **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.
   - **Ejemplo:** Crash-free 99,6%, sin cambios; primer resultado útil +8 p.p.; D7 sin cambios; preguntas sobre el estado +40%.
2. **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.
   - **Ejemplo:** 3 de junio: onboarding acortado; 7 de junio: nueva pantalla de estado publicada; 10 de junio: cambió la ruta del push.
3. **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.
   - **Ejemplo:** 12 usuarios preguntan si su operación se completó, aunque no hay ningún error técnico.
4. **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.
   - **Ejemplo:** La pantalla nueva funciona técnicamente pero no explica el estado: eso genera solicitudes y desconfianza.
5. **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.
   - **Ejemplo:** Agregar el estado — Ana — 21 de junio — solicitudes sobre el tema y finalización de la acción.

## 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.

## Artefacto final: 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.

## 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.

- [ ] Una sola pantalla muestra de 5 a 7 indicadores con su tendencia y un único periodo.
- [ ] Están nombrados los tres cambios principales del periodo y su efecto esperado.
- [ ] Soporte trajo temas recurrentes y ejemplos concretos.
- [ ] Hay una conclusión principal formulada, sin causalidad no confirmada.
- [ ] Se toman como máximo tres decisiones, cada una con responsable, plazo y métrica de revisión.

## 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.

## Regla principal

Una buena revisión de producto reduce la lista de tareas y deja al equipo con unas pocas decisiones cuyo efecto se puede comprobar.

## Crece con GameChange Partners

[Explorar el programa de afiliados ↗](https://gamechange.partners/es?utm_source=academy&utm_medium=referral&utm_campaign=gcpacademy)

---

- [Versión HTML](https://playbook.affpartners.io/es/apps/practices/retention-review/)
- [Todas las prácticas](https://playbook.affpartners.io/es/apps/)