Entre el ritmo de la IA y nuestras señales de uso, un roadmap fijo más allá de eso simplemente ya no tiene sentido.
Esta reunión funciona con dos entradas: la primera es la retroalimentación directa de los clientes, como errores, desafíos de UX y brechas del producto, enviada a través de guías de feedback continuas en nuestra interfaz. Aunque estos datos son cualitativos, en realidad podemos cuantificarlos con Pendo: podemos medir cuántos usuarios enfrentan la misma frustración, cuántos han hecho la misma solicitud y el valor de cuenta detrás de cada prioridad. Y cuando un usuario está especialmente comprometido, buscamos hablar con él en una llamada.
La segunda entrada principal son los Issues en Agent Analytics. Soy el PM Principal de Leo, el asistente de producto con IA de Pendo. Usamos Agent Analytics cada semana para medir a Leo de la misma manera en que esperaríamos que cualquiera de nuestros clientes lo use para sus propios agentes. A continuación, comparto dos ejemplos de cómo se ve esto en la práctica.
La barrera de protección que estaba fallando en miles de conversaciones de usuarios
Cuando Leo se lanzó, decidimos deliberadamente no admitir preguntas de tipo "cómo se hace". Cosas como: "¿Cómo creo un segmento?" "¿Cómo actualizo mi roadmap?" Los usuarios preguntaban y Leo los redirigía a la base de conocimiento de Pendo.
Pusimos esa barrera de protección porque Leo estaba alucinando en esas preguntas. Aún no lo habíamos conectado a una fuente de conocimiento actualizada y no queríamos enviar respuestas incorrectas. Esta es la realidad de tomar decisiones de compromiso continuas al construir un roadmap y desarrollar un producto.
Aunque sentíamos que estábamos siendo responsables, Agent Analytics eventualmente nos mostró que estábamos generando frustración.
El detector de issues lo marcó sin que siquiera tuviéramos que preguntar: más del 60% de todos los issues en Leo se remontaban a esta única causa raíz. Un problema, extendido a través de miles de conversaciones, que aparecía una y otra vez. Sin Agent Analytics, no habríamos tenido forma de entender la gravedad de esta brecha mientras nos preparábamos para pasar de una beta cerrada a un lanzamiento completo. Un PM no puede tomar decisiones de priorización basadas en datos sin información agregada de cada conversación de usuario. Con estos datos, sabíamos que estábamos perdiendo cada vez más la confianza de los usuarios después de solo una conversación con Leo.
Para solucionar esto, construimos un sub-agente de conocimiento dedicado dentro de Leo, similar a sus otros sub-agentes para tareas como análisis cuantitativo y creación de guías. Agregamos uno para conocimiento, lo conectamos a nuestro almacén de conocimiento actualizado y habilitamos a Leo para responder preguntas de tipo "cómo se hace" con precisión en lugar de redirigirlas.
De la noche a la mañana, este problema desapareció de nuestra lista de incidencias. Pasamos de miles de conversaciones marcadas a cero, con una sola versión arquitectónica.
Los usuarios para los que no diseñamos, y cómo los encontramos
El ICP original de Leo era claro: personas que no conocen Pendo, no tienen tiempo de aprender analytics y quieren respuestas rápidas a preguntas sencillas. Cuando lanzamos Leo el año pasado, este grupo apareció.
Sin embargo, también apareció un segundo grupo y, lamentablemente, era uno para el que no habíamos desarrollado la solución: los usuarios avanzados de Analytics. Campeones de Pendo que miraron a Leo y dijeron: acabas de poner una interfaz conversacional sobre todos mis datos. De inmediato comenzaron a hacer preguntas complejas de analytics, como análisis de embudos de conversión entre aplicaciones y consultas sobre grandes conjuntos de datos. Leo no podía manejarlo bien. Sabíamos que esas limitaciones existían, pero no sabíamos con qué frecuencia los usuarios las encontraban, ni qué brechas generaban más fricción.
Con Agent Analytics, creamos casos de uso rastreados para cuantificar la división: ¿con qué frecuencia los usuarios hacen preguntas más sencillas que Leo maneja bien, frente a con qué frecuencia se encuentran en un territorio donde los prompts son más avanzados y la experiencia se rompe? Categorizamos por nivel de complejidad y por intención: preguntas de adquisición, preguntas de adopción, preguntas de conversión, etc.
El Director Sénior de Analytics de Pendo y yo nos sentamos con esos datos y los usamos para secuenciar qué capacidades construir primero. Lo mejor fue que los datos de Agent Analytics determinaron el orden en que construiríamos. Lo cual, como cualquier PM puede atestiguar, es mucho mejor que guiarse por la intuición o depender de la voz más fuerte en la sala. Sabíamos, de forma objetiva, la frecuencia con la que los usuarios encontraban cada brecha y el impacto que podíamos esperar de cada corrección que haríamos.
Al final, ampliamos las herramientas de Leo para manejar esas solicitudes cuantitativas más complejas que el segundo grupo estaba haciendo.
Las evaluaciones indicaban que estábamos listos, pero necesitábamos más que eso
Antes de lanzar los cambios de herramientas a los miles de usuarios de Leo, necesitábamos saber si realmente mejorarían la experiencia o simplemente trasladarían el problema a otro lugar. Nuestras evaluaciones se veían bien (todo en verde).
La parte complicada es que ya no confiamos únicamente en las evaluaciones. En el último año, nuestro equipo ha estado construyendo y realizando mejoras en Leo de forma continua, y hemos descubierto que puedes tener todo en verde en tu suite de automatización de pruebas, y luego el primer usuario real pregunta algo que tus pruebas nunca anticiparon, y el agente falla. Las evaluaciones son controladas, pero los usuarios definitivamente no lo son. Súmale a esto la naturaleza no determinista de estos modelos, y podríamos pasar todas las pruebas y aun así fallar en la primera conversación.
Para superar esta barrera a una optimización significativa, ejecutamos un experimento en Agent Analytics antes de implementar los cambios cuantitativos para todos nuestros usuarios. Realizamos pruebas A/B de las nuevas herramientas con el 20% de nuestra base de usuarios. El resultado: una caída del 67% en la tasa de incidencias para ese grupo, con usuarios reales, no bots sintéticos. Y porque está conectado al contexto más amplio del comportamiento del usuario, pudimos rastrear el compromiso del usuario y las métricas de calidad de IA justo a su lado.
Esto es lo que nos dio la convicción para implementar estos cambios significativos en el backend de manera más amplia. En lugar de depender de evaluaciones excesivamente optimistas o de una aprobación puntual de un usuario de prueba interno, contamos con una forma objetiva y escalable de lanzar cada nueva actualización de Leo con confianza.
Lo que hemos visto desde entonces
La adopción de nuevos visitantes de Leo aumentó un +16,1% solo en los últimos 60 días. Más significativo para un PM, nuestros visitantes recurrentes semanales aumentaron un 61,3%. Lo que me indica que Leo tiene valor para nuestra audiencia y no es una novedad pasajera.
Aunque la retención está creciendo, aún hay más obstáculos que superar. Estoy agradecido de contar con un proceso consistente para priorizar continuamente el tiempo de mi equipo y los ingenieros basándonos en señales reales de los usuarios: identificar el problema en AA, determinar la causa raíz, realizar el cambio de infraestructura correcto, confirmar antes de lanzar con un experimento y luego observar cómo crecen nuestros indicadores clave.
Este ciclo es cómo gestionamos Leo, y es el mismo ciclo que recomendaría a cualquier PM que desarrolle un agente de IA.
Conecta el contexto de comportamiento a cualquier agente que desarrolles o adquieras, y luego mide si está funcionando con Pendo para agentes de IA. Más información.
