Lo que todos los gestores de productos deben saber acerca del análisis de productos

Los datos que recopilamos de los análisis de productos nos indican la forma real en que los usuarios utilizan el producto.

Sam Tardif Sam Tardif

Como gestores de productos, aprovechamos cada oportunidad que tenemos para aprender más acerca de nuestros clientes porque entendemos que sus necesidades son fundamentales para desarrollar productos útiles. Esto implica realizar entrevistas a clientes, llevar a cabo encuestas y examinar las analíticas de productos. Los datos que obtenemos de las analíticas de productos nos indican cómo utilizan los usuarios realmente el producto, no lo que quieren hacer, cómo creen que lo están utilizando ni tampoco cómo creemos nosotros que lo están haciendo.

Donde el desarrollo de software difiere y la construcción de una casa podría salir totalmente beneficiada, es en el uso de la metodología ágil. La metodología ágil permite que varios equipos puedan responder a los cambios rápidamente. Así que ¿cómo puede la metodología ágil, un método basado en una entrega frecuente y continua, existir con una planificación general y a largo plazo? ¿Es posible crear un pronóstico realista durante un periodo prolongado, sabiendo que la única constante es el cambio?

Como gestor de productos, preguntas del tipo: "¿cuánto tiempo emplean los usuarios cada día?", "¿cuáles son las acciones que más realizan?" y "¿a qué funcionalidades les cuesta más trabajo adaptarse?" tienen un gran valor a la hora de comprender a los usuarios y nos arrojan pistas sobre cómo mejorar su experiencia. En esta publicación, explicaré en qué consisten los análisis del producto y por qué deberías usarlos; cómo comprender de verdad a los usuarios y saldar la "falta de empatía" y cómo utilizar el análisis para guiarte en el desarrollo de nuevas funcionalidades.

Vamos allá.

Una introducción al análisis de productos

Para obtener una comprensión cuantitativa de lo que los usuarios están haciendo con el producto, el primer paso es incorporar el análisis. La idea es lanzar un evento para cada acción que el usuario lleve a cabo en el producto, para que puedas obtener una visión consolidada del número de usuarios que utilizan una funcionalidad y la frecuencia con que lo hacen. Por ejemplo, si quieres realizar el seguimiento del número de veces que un usuario hace clic en un botón concreto, puedes lanzar un evento llamado "clic.botón-rojo-grande". A partir de él, puedes comprobar qué funcionalidades necesitan ponerse en marcha, cuáles son las más importantes y utilizar esta información para priorizar los cambios. 

Análisis de productos | Orientador ágil de Atlassian
Consejo de experto:

Hay miles de soluciones ahí fuera que te otorgan un marco ágil para añadir eventos de análisis y hacer un seguimiento de ellos. Consulta Google Analytics o KISSmetrics como punto de partida.

En Atlassian, hemos tratado de facilitar lo máximo posible a todos los usuarios la obtención de datos y la posibilidad de realizar sus propias consultas e informes. Utilizamos algunas herramientas desarrolladas internamente para ofrecer estos servicios, pero también usarás herramientas como Google Analytics. Esto ha hecho que todos los usuarios, desde los desarrolladores hasta los gestores de productos y diseñadores, realicen preguntas sobre el uso y traten de comprender el alcance de lo que crean.

"Falta de empatía": el último tipo de deuda

Probemos con este nuevo término: "falta de empatía".

Los análisis internos del producto permiten saldar la falta de empatía de dos modos: con el feedback cualitativo recopilado a través de actividades como las pruebas de conceptos y las entrevistas a los clientes; y con los datos cuantitativos recopilados en el producto a través del análisis del producto y las encuestas de NPS.

A modo de ejemplo, Confluence lleva utilizándose muchos años y tiene funcionalidades que poco o nada tienen que ver con el análisis. Una de ellas es el panel, que es el comienzo de la mayoría de las experiencias de usuario con Confluence. En realidad, ahora estamos en proceso de revisión. Recopilamos algún feedback sobre el panel de las entrevistas a los clientes, pero no disponíamos de un análisis del producto adecuado para comprender realmente el uso desde una perspectiva cuantitativa. Teníamos muchas preguntas sin contestar, como por ejemplo:

  • ¿Cuánto uso se hace del panel? ¿Cuántas veces visitan los usuarios el panel en una sesión habitual de Confluence?
  • ¿Para qué se utiliza realmente el panel? ¿La fuente de todas las actualizaciones? ¿La fuente popular? ¿Te desplazas a un espacio?
  • ¿Qué esperan los usuarios del panel? ¿Se pueden determinar los mejores elementos a destacar en función de lo que hacen los usuarios tras visitar el panel?

Son preguntas bastante fundamentales para las que necesitamos respuestas antes de embarcarnos en un cambio en una de las páginas más visitadas en Confluence. Si no dispones de análisis de tu producto o incluso tienes una funcionalidad específica que vas a cambiar, entonces, estás en la misma situación y debes tener mucha precaución a la hora de tomar cualquier decisión. Es hora de saldar la falta de empatía.

En nuestra prueba de panel, hemos aprendido que una de las acciones más comunes llevada a cabo es ver las "páginas favoritas". Ha sido un importante hallazgo que no estaba incluido en nuestra hipótesis inicial y que nos lleva a la conclusión principal: salda tu falta de empatía tan pronto como sea posible. Si no cuentas con un análisis de tu producto, añádelo enseguida y empieza a utilizar los datos para tomar decisiones informadas sobre tu producto. De lo contrario, estás tomando decisiones importantes a ciegas. Y, recuerda: los análisis no mienten. Muestran exactamente lo que los usuarios están haciendo con el producto, pero indaga un poco más y utiliza el análisis para comprender lo que los usuarios quieren realmente.

Probar el futuro antes de que llegue

Mientras que añadir el análisis del producto puede ser útil para entender cómo los usuarios utilizan las funcionalidades existentes, estos son de suma importancia para probar nuevas funcionalidades y experiencias. Si tienes un objetivo claro acerca de cuántas veces se va a usar la funcionalidad, disponer del análisis del producto te ayudará a adoptar el antiguo mantra de metodología ágil de fallo rápido e iteración hasta que lo consigas.

El proceso que se suele utilizar podría ser el siguiente:

  • Define una hipótesis clara para un cambio en el producto, por ejemplo: "Al aumentar el tamaño del cuadro de comentarios, esperamos incrementar en un 5 % los comentarios".
  • Crear la implementación más económica posible de este cambio, cargada con los eventos de análisis necesarios, lo que nos permitirá probar nuestra hipótesis.
  • Desplegar el cambio en un subconjunto de clientes en una prueba A/B.
  • Quedarnos de brazos cruzados a le espera de los resultados.
  • Hacer un desglose de los resultados, con la ayuda de un analista en el caso de los cambios más complejos, y decidir si el cambio se ha realizado con éxito.

Para nuestro panel, hemos optado por diseñar tres paneles de los que se ha hablado mucho, donde cada uno de ellos promueve un caso de uso distinto y un conjunto de comportamientos. Los pusimos en marcha en este proceso (aunque nuestra hipótesis era algo más complicada) y funcionó realmente bien para nosotros. Pero hay algunos problemas de los que hemos aprendido, en ocasiones por las malas, y sobre los que querrás reflexionar antes de probar nuevas funcionalidades de este modo.

Antipatrones ante los que estar alerta:
  • No hay nada peor que llegar al final de un experimento y darse cuenta de que no tienes todos los eventos que necesitas... Trata de hacer un análisis antes de realizar el experimento con algunos datos de relleno, enseguida verás los fallos en lo que estás registrando.
  • Proponer una hipótesis puede llevar mucho tiempo pero debes garantizar que tienes una y que puedes aprobarla o refutarla con el análisis del producto antes de su lanzamiento. Hacer un análisis con datos de relleno antes del lanzamiento también te ayudará a realizar la prueba.
  • Asegúrate de realizar las pruebas en un número suficiente de usuarios y durante un largo período. Tienes que asegurarte de que tus resultados son significativos desde un punto de vista estadístico.
  • Estar preparado para desechar malas ideas. Como hemos mencionado, el objetivo es probar las funcionalidades de la forma más económica posible y realizar estas pruebas con la máxima rapidez. El fracaso rápido es la clave del éxito. 

Además, no olvides escuchar a los usuarios.

Como mencioné anteriormente, es fantástico estar bien informados con datos, pero estar totalmente orientados a los datos puede, a veces, cegarte respecto a la experiencia general que estás creando para los usuarios. Depender totalmente de los datos puede, además, resultar algo abrumador a la hora de tomar una decisión cuando no se tienen todos los datos necesarios.

Análisis de productos ágiles | Orientador ágil de Atlassian

El análisis del producto expone la cruda realidad de cómo la gente utiliza el producto o incluso una funcionalidad en concreto, pero puede ser únicamente unidimensional. Combinar lo que crees que sabes a partir de los datos de análisis del producto con el feedback cualitativo de las entrevistas a los clientes, los talleres de pruebas de concepto y el debate de intercambio de ideas te darán una visión más completa de lo que sucede para que puedas crear el mejor producto posible.

Up Next
Equipos