Revisión post-lanzamiento: medir lo que se lanzó y aprender de ello
Una revisión post-lanzamiento compara lo lanzado con la meta fijada antes. Aprende cuándo hacerla, qué medir, cómo hacer la retrospectiva y cerrar con acciones.
¿Qué es una revisión post-lanzamiento?
Es el cierre de un ciclo que muchos equipos dejan abierto. Se lanza, se celebra, y se pasa a lo siguiente sin saber si la funcionalidad cumplió su propósito. La revisión existe para responder dos preguntas: ¿funcionó lo que lanzamos?, y ¿qué haremos distinto la próxima vez?
Hay dos partes que conviene separar. La primera es la medición: qué pasó con los usuarios y el negocio. La segunda es la retrospectiva: qué pasó con el proceso, las decisiones y la colaboración.
¿Cuándo hacerla?
Las guías no coinciden en un plazo universal, y conviene adaptarlo al tipo de cambio. Rational PM sugiere medir al menos cuatro semanas en actualizaciones que no obligan al cliente a hacer nada: en la primera semana se mira la adopción temprana, en las semanas dos y tres el feedback y la estabilidad del uso, y en la cuarta una predicción frente a la meta. Si el lanzamiento requiere que el cliente actualice, el seguimiento puede durar meses.
Un punto práctico: no esperes al final para pensar en la revisión. Define la fecha antes del lanzamiento y ponla en el calendario del equipo.
¿Qué comparar?
Lo más importante es la meta definida antes de salir. Rational PM usa la cuarta semana para predecir si se alcanzará la meta fijada, y propone medir métricas de pegajosidad (stickiness) como la relación entre usuarios activos diarios y mensuales (DAU/MAU).
Una meta útil se parece a esta frase: “esperamos que la tasa de finalización del registro suba de X a Y en seis semanas, sin empeorar la retención”. Tiene una métrica, un cambio concreto y un plazo, y además vigila el daño en otra métrica clave.
Si no tienes una línea base, la revisión se vuelve una narración. Por eso conviene capturar los datos actuales antes de lanzar, no después.
| Qué medir | Por qué |
|---|---|
| Adopción | Cuántas personas usan la función y con qué frecuencia |
| Métrica objetivo | Si se movió en la dirección y cantidad esperadas |
| Métricas de salud | Si el cambio empeoró algo importante (retención, soporte) |
| Feedback | Qué dicen los usuarios, con números y con entrevistas |
La plantilla de Product-Led Alliance incluye adquisición, ingresos, engagement y retención entre los indicadores, y pide analizar la recepción del producto y asignar responsables y fechas a las acciones. Los objetivos y las líneas base los defines tú.
¿Cómo hacer la retrospectiva?
Rational PM propone algunas preguntas que funcionan bien en la sesión: ¿qué salió bien?, ¿los requisitos estaban claros?, ¿el calendario era razonable?, ¿los equipos de apoyo tenían lo necesario?, ¿hubo sorpresas?, ¿dónde estaban los cuellos de botella? Y, al final, ¿fue exitoso el lanzamiento?
La retrospectiva sirve para entender el proceso, no para buscar culpables. Si la conversación se vuelve una búsqueda de responsables, la gente dejará de decir la verdad en la siguiente.
¿Cómo se cierra con acciones?
Cada hallazgo debe convertirse en una acción con responsable y fecha. Una lista de “aprendizajes” sin dueños no cambia nada.
Un formato simple:
- Acción: qué vamos a cambiar.
- Responsable: una persona, no un equipo.
- Fecha: cuándo se revisará.
- Dónde queda: en el proyecto siguiente, no en un documento olvidado.
Rational PM insiste en aplicar las conclusiones al siguiente proyecto y recomienda compartir las lecciones aprendidas con el resto de la empresa. Esto último importa: una revisión que nadie más lee no reduce el costo de errores repetidos.
¿Cuándo NO conviene una revisión formal?
Si el cambio fue menor, reversible y no afectó métricas importantes, una revisión larga no se justifica. Basta con una nota de tres líneas: qué se lanzó, qué pasó y qué cambió.
También hay que tener cuidado con copiar el formato de los incidentes. La guía SRE de Google describe la revisión de incidentes con disparadores claros y un enfoque sin culpables, pero está escrita para fallos de sistemas. Adáptala a un lanzamiento de funcionalidad, no la trasplantes tal cual.
Ejemplo
Ejemplo ilustrativo: un equipo lanzó un nuevo filtro de búsqueda en una tienda en línea. La meta era reducir los clics hasta el producto en un 20 %. A las cuatro semanas, la adopción es alta, pero los clics bajaron solo un 8 %. Al revisar el feedback, encuentran que los usuarios no entienden la diferencia entre “marca” y “categoría”. La acción es clara: el equipo de diseño rediseña las etiquetas y el responsable es la diseñadora de la función, con fecha para la siguiente medición. La revisión no dijo que el filtro fracasó; dijo que había un problema concreto de comprensión.
Errores comunes
- No definir la meta antes de lanzar, y luego elegir la métrica que sí mejoró.
- No capturar la línea base, lo que impide saber si el cambio fue el responsable.
- Medir solo el éxito y no las métricas de salud que podrían empeorar.
- Hacer la retrospectiva con culpables y perder la honestidad del equipo.
- Dejar acciones sin responsable, que nadie ejecuta.
- Nunca cerrar la revisión, con una reunión sin conclusión ni documento.
Para ordenar las métricas que vas a seguir después del lanzamiento, los KPI te ayudan a decidir qué mirar, y las métricas de DesignOps sirven para medir el trabajo del propio equipo. Si el lanzamiento nació de una hipótesis, concept testing es una forma de validarla antes de invertir. Y para el proceso completo de diseño, el proceso de diseño UX muestra dónde encaja la revisión.