La responsable de producto lanza una función. La función debe resolver un problema del cliente e impulsar la retención.
Dos semanas después del lanzamiento: la función reduce el abandono. Más clientes usan la función. Los clientes pasan más tiempo en la función.
Sin un panel de producto, la responsable espera seis semanas al informe mensual para ver el impacto de la función. Para entonces, los comentarios de los clientes se han enfriado. No se puede iterar.
Con un panel de producto, la responsable ve a las dos semanas: la adopción de la función es del cinco por ciento (el objetivo era el veinte por ciento a la semana dos). El problema se ve de inmediato. La responsable investiga. Descubre que la función es difícil de encontrar. Añade un mensaje de incorporación. La adopción sube al quince por ciento en la semana cuatro.
Paneles de producto: adopción e interacción con las funciones
Tasa de adopción de la función
La función se lanzó hace dos semanas. Usuarios elegibles: diez mil. Usuarios que han usado la función: quinientos. Tasa de adopción: cinco por ciento. El objetivo era el veinte por ciento en la semana cuatro. Ahora vamos por detrás. Hace falta investigar.
Interacción con la función
De los quinientos usuarios que probaron la función, cuántos la usan a diario. Doscientos. Cuántos la usan cada semana. Trescientos. Cuántos han abandonado la función. Doscientos. Tasa de interacción: cuarenta por ciento a diario, sesenta por ciento cada semana, cuarenta por ciento abandonado. El abandono es demasiado alto. La función no engancha.
Tiempo dedicado a la función
La sesión media en la función es de dos minutos. Antes de la función, el tiempo medio de sesión en la web era de diez minutos. La función aleja a los usuarios de otras funciones. Es intencionado. La función sustituyó a una función anterior o es un añadido.
Impacto en la retención
Clientes que adoptaron la función: ocho por ciento de abandono mensual. Clientes que no adoptaron la función: doce por ciento de abandono mensual. La función funciona. Mejora del abandono de cuatro puntos porcentuales. Para una base de mil clientes, son cuarenta clientes menos que se van cada mes. Cuarenta por cincuenta (valor medio del cliente) son dos mil de ingresos ahorrados al mes.
Paneles de operaciones: salud y rendimiento del sistema
Disponibilidad del sistema
La web estuvo activa el 99,95 por ciento del tiempo la semana pasada. El objetivo es el 99,99 por ciento. Estamos por debajo del objetivo. Dos caídas: una de diez minutos, otra de quince. En total, veinticinco minutos de inactividad. Qué causó las caídas. Se pueden prevenir.
Tiempo de respuesta
El tiempo medio de respuesta de la API es de doscientos milisegundos. El tiempo de respuesta P95 es de quinientos milisegundos (el 95 por ciento de las solicitudes son más rápidas, el cinco por ciento son más lentas). El P99 es de un segundo. De vez en cuando hay tiempos de respuesta lentos. Son aceptables.
Tasa de errores
El uno por ciento de las solicitudes a la API devolvió error. Subió desde el cero coma cinco por ciento de la semana pasada. La tasa de errores se duplicó. Qué cambió. Una consulta a la base de datos es más lenta. Los tiempos de respuesta aumentaron. Los clientes agotan el tiempo de espera y reintentan. Hace falta investigar.
Conjunto de conexiones a la base de datos
El conjunto tiene cien conexiones. Ahora hay cien abiertas (uso completo). No quedan conexiones disponibles. Si entra una solicitud más, queda en cola. El usuario espera. El conjunto está al límite. Hay que ampliar el conjunto o reducir el uso.
Tasa de aciertos de la caché
La caché acierta el cincuenta por ciento de las veces. El cincuenta por ciento del tráfico no necesita una consulta a la base de datos. Una tasa de fallos de caché del cincuenta por ciento es aceptable para la mayoría de las webs. Por debajo del cuarenta por ciento, la base de datos está sobrecargada. Por encima del setenta por ciento, estás usando demasiada caché.
Ejemplo real: panel de producto y operaciones de un SaaS
Métricas de producto
Nueva función de panel: lanzada en el mes uno. Usuarios elegibles: cinco mil (clientes con más de diez puntos de datos). Usuarios que crearon un panel: mil. Tasa de adopción: veinte por ciento. En el objetivo.
De los mil que crearon un panel: Activos a diario: seiscientos. Buena interacción. Activos cada semana: novecientos. La mayoría lo usa al menos una vez por semana. Abandonado: cien. Diez por ciento de abandono.
Impacto en la retención: los clientes con paneles activos tienen un dos por ciento de abandono mensual. Los clientes sin paneles tienen un cuatro por ciento de abandono mensual. El panel reduce el abandono en dos puntos. Para una base de mil clientes, son veinte clientes. Con cien dólares de valor mensual por cliente, son dos mil de ingresos ahorrados al mes. Veinticuatro mil al año.
Métricas de operaciones
Disponibilidad el mes pasado: 99,92 por ciento. Objetivo: 99,95 por ciento. No cumplimos el objetivo.
Caídas: Un incidente: diez minutos, procesamiento de pagos caído. Causa: la conmutación por error de la base de datos tardó demasiado. Un incidente: quince minutos, pico de tiempos de espera de la API. Causa: aumento de tráfico más una consulta lenta a la base de datos.
Tiempo de respuesta: Media: ciento cincuenta milisegundos. Bien. P95: trescientos milisegundos. Aceptable. P99: un segundo. Es demasiado alto. El uno por ciento de los clientes espera un segundo. Hay que optimizar.
Tasa de errores: cero coma ocho por ciento. Subió desde el cero coma cuatro por ciento de hace dos semanas. La investigación muestra: los errores de procesamiento de pagos subieron porque el proveedor de pagos tuvo una caída la semana pasada (no es culpa nuestra), los errores de la API subieron porque publicamos un cambio de código que rompió un punto de acceso (es culpa nuestra).
Base de datos: Tiempo medio de consulta: treinta milisegundos. Uso del conjunto de conexiones: ochenta por ciento. Saludable. Tasa de consultas lentas: cero coma dos por ciento. Aceptable.
Tasa de aciertos de la caché: sesenta y cinco por ciento. Saludable.
Conectar los paneles de producto y de operaciones
La adopción de las funciones depende del rendimiento del sistema. Si el sistema es lento, la adopción de funciones sufre. La nueva función de panel tiene poca adopción. Revisa el panel de operaciones. El tiempo de respuesta P99 es de un segundo. Los usuarios notan retraso al abrir el panel. Añade a la investigación: el bajo rendimiento está causando la baja adopción. Si es así, optimiza primero el rendimiento del sistema. Después vuelve a medir la adopción.
El rendimiento del sistema se mide por disponibilidad, no por el impacto de las funciones. Pero el impacto de las funciones depende de la disponibilidad. Vincula los dos paneles. Cuando empeoran las métricas de operaciones, también empeoran las de producto.
Preguntas frecuentes
¿Cada cuánto debe revisar la responsable de producto la adopción de las funciones?
Primera semana: a diario. La función acaba de lanzarse y la curva de adopción es la más pronunciada. Hay que detectar los problemas pronto. Semanas dos a cuatro: tres veces por semana. La curva de adopción se aplana. Bastan las actualizaciones semanales. Después del primer mes: cada semana. La adopción se ha estabilizado o crece de forma constante. Basta con una revisión semanal. Excepción: si la función es crítica o si la adopción inicial está por debajo del objetivo, la vigilancia diaria continúa hasta resolver el problema. Con el creador de webs de WEMASY, puedes configurarlo directamente en tu web.
¿Qué tasa de adopción de una función es aceptable por semana?
Semana uno: de cinco a quince por ciento (la gente está probando). Semana dos: de diez a treinta por ciento (se corre la voz). Mes uno: de veinte a cincuenta por ciento (tasa estable). Es distinta para cada función. Las funciones de juego pueden alcanzar un noventa por ciento de adopción. Las funciones de cumplimiento normativo quizá solo lleguen al diez por ciento. El objetivo debe basarse en el segmento de usuarios y en la importancia de la función, no en una referencia genérica. Antes de lanzar, decide: la función es para todos o solo para un segmento. Eso determina el objetivo.
¿Cómo distinguimos entre adopción e interacción?
La adopción es probar la función (la usaron al menos una vez). La interacción es usarla de forma repetida (a diario, cada semana, cada mes). Una función puede tener mucha adopción y poca interacción (todos la probaron, pocos se quedaron). Una función puede tener poca adopción y mucha interacción (pocos la probaron, pero a quienes la probaron les encantó). Las dos métricas importan. Mucha adopción y mucha interacción es éxito. Poca interacción significa que la función no resuelve un problema real. Poca adopción significa un problema de visibilidad.
¿Debe el panel de producto incluir comentarios de clientes o solo métricas?
Incluye las dos cosas. Las métricas dicen qué hacen los clientes. Los comentarios dicen por qué. Quinientos usuarios abandonaron la función (métrica). Los comentarios dicen "la función es difícil de encontrar" o "la función no resuelve mi problema" (el porqué). Las métricas sin comentarios están incompletas. Añade una sección de comentarios con los tres motivos principales de abandono según los tickets de soporte y las encuestas. Aplicación: añade un campo de comentarios a la función. Cada semana: lee los veinte comentarios principales de usuarios y clasifícalos en temas. Informa de los temas en el panel.
¿Cómo fijamos objetivos de disponibilidad y de tiempo de respuesta?
Basa los objetivos en el impacto en el cliente y en los estándares del sector. Para el pago de una tienda online: disponibilidad del 99,9 por ciento, tiempo de respuesta inferior a dos segundos. Para una web de marketing: disponibilidad del 99 por ciento, tiempo de respuesta inferior a tres segundos. Para herramientas internas: disponibilidad del 95 por ciento, tiempo de respuesta inferior a cinco segundos. Cuanto más crítico es el servicio, más exigente es el objetivo. Al fijar un objetivo, sabe qué nivel de inversión requiere. Una disponibilidad del 99,99 por ciento (cuatro nueves) cuesta de tres a cuatro veces más que una del 99 por ciento (dos nueves). Asegúrate de que el objetivo compensa el coste.
¿Debe el panel de operaciones lanzar alertas o solo mostrar el estado?
Las dos cosas. El panel muestra el estado actual. Las alertas saltan cuando se superan los umbrales. Si la tasa de errores supera el uno por ciento durante cinco minutos, salta una alerta. La alerta llega al ingeniero de guardia, que investiga. El panel es para vigilar en horario normal. La alerta es para fuera de horario o situaciones críticas. Ninguna de las dos basta por sí sola. Un panel sin alertas significa que los problemas se descubren en horario laboral. Una alerta sin panel significa que el equipo no ve un deterioro lento hasta que salta la alerta. Usa las dos juntas.