Todas las empresas de hoy adoran los grandes datos, y casi todas las empresas definitivamente tendrán un departamento de analistas de ciencia de datos. Sin embargo, no existe una comprensión clara en la industria sobre quién es un analista de productos y cómo difiere de un científico de datos o investigador de UX que se enfoca en métodos cuantitativos.
Cada vez más, hay una división de analistas de productos que:
- establecer objetivos y métricas, determinar el vector de desarrollo del producto
- investigar la naturaleza de los fenómenos, identificar relaciones causales
- construir algoritmos predictivos
Por ejemplo, una estructura similar en Indeed es similar :
En este artículo, quiero resumir un poco de especialistas que se dedican exclusivamente al aprendizaje automático y hablar sobre la visión del papel de la analítica de productos en Wrike y sobre las tareas que nuestro equipo de productos tiene que trabajar a diario.
Cualitativa versus Cuantitativa
Como regla general, los desarrolladores y los piemas adoran los números: los datos cuantitativos ayudan a capturar con precisión el estado actual, mostrar la dinámica y evaluar las perspectivas del mercado. A menudo se olvida que los números en sí mismos no brindan la oportunidad de dar una respuesta sobre la motivación de las personas, sobre la causa raíz de su elección y otras acciones.
Cualitativo antes que cuantitativo: cómo los métodos cualitativos respaldan una mejor ciencia de datos
Por lo tanto, en Wirke, no establecemos una división clara entre analistas que organizan investigaciones cualitativas y cuantitativas. Por el contrario, en nuestra opinión, en un equipo pequeño (somos aproximadamente 10 de nosotros), necesitamos poder combinar estas habilidades tanto como sea posible, utilizando métodos cuantitativos para desarrollar las ideas de análisis cualitativo , que a menudo se lleva a cabo conjuntamente con el gerente y diseñador del producto.
De hecho, cuando se trata de investigación, tenemos dos expectativas del analista. Debe ser capaz de:
- encuentre puntos de crecimiento de productos prometedores
- validar el problema formulándolo y escalando
A continuación, hablaremos más sobre estas dos expectativas y mostraremos cómo el analista desempeña el papel de conexión entre la comprensión empresarial del problema y los métodos cuantitativos que los ayudan a escalar y validar.
1. Encuentra puntos de crecimiento del producto
Un analista es una persona que encuentra puntos prometedores de crecimiento de productos al ampliar problemas y tareas.
El primer paso para comprender cualquier tarea para un analista de producto es determinar a qué clase de problemas pertenece. Generalmente se distinguen tres tipos de investigación:
- Descubrimiento de problemas : cuando no sabemos qué problemas tienen los usuarios fuera de la funcionalidad de un producto en particular. Esta suele ser la etapa de la entrevista.
- Validación de problemas : cuando parece que sabemos que hay ciertas tareas, pero queremos verificar que una gran cantidad de usuarios las tengan. Esta es la etapa de varias encuestas.
- Validación de una solución (validación de la solución): cuando verificamos soluciones ya específicas que hemos creado o prototipado. Etapa de creación de prototipos o pruebas beta.
El analista participa en las tres etapas de la investigación, sin embargo, el enfoque principal en el trabajo generalmente recae en la validación de problemas y soluciones. Supongamos que un gerente de producto, junto con un analista y un comercializador, realizó veinte entrevistas con diferentes clientes. ¿Cómo entendemos que se puede confiar en estas conclusiones y que los problemas que se han expresado son relevantes para todos los usuarios? ¿Cómo asegurar la objetividad del potencial de desarrollo encontrado evaluando la escala? En otras palabras, ¿cómo verificamos que lo que encontramos en la entrevista es realmente un punto de crecimiento potencial para el producto?
Es aquí donde resulta maximizar el uso de herramientas y el conocimiento de trabajar con datos que conectan la investigación cualitativa y cuantitativa. Para comprender la escala y encontrar la forma más correcta de determinarla, esta es la competencia clave de un analista de producto. Este es solo un pequeño ejemplo en el que el enfoque analítico nos permitió cambiar nuestro proceso de recopilación de dolores de los clientes y, de lo contrario, abordar su validación por parte del equipo del producto.
Reconocer y analizar conversaciones.
Wrike tiene una división de gerentes de cuentas (gerentes de éxito de clientes ) cuya tarea principal es apoyar a los clientes no con el propósito de ventas, sino para mejorar su experiencia en el uso del producto. Llaman a los clientes por video, discuten sus dolores actuales, cuentan las mejores prácticas, sugieren rondas de trabajo e informan sobre el estado de desarrollo de nuevas funciones. Todas estas conversaciones se grabaron durante mucho tiempo y prácticamente no fueron utilizadas por la organización alimentaria: los piemas prefirieron comunicarse personalmente con los gerentes de cuentas para tener una idea general de los dolores de los clientes. Esto podría agregar un elemento de "teléfono roto" y no siempre revelaba el contexto en el que el usuario se enfrentaba a este problema.
Uno de los proyectos de iniciativa de análisis de productos fue el desarrollo de la canalización, que convirtió la conversación en un formato de texto comprensible. Utilizando la API de Google Speech, así como varios modelos adicionales de puntuación, pudimos tener una idea rápida del alcance de algunos problemas y requisitos de funcionalidad basados en muchas conversaciones de gerentes con clientes, en lugar de entrevistas individuales . Gracias a esta fuente simple, fue posible llevar a cabo una búsqueda a gran escala de palabras clave relacionadas con algunas funciones o problemas, evaluar la naturaleza de los usuarios que requerían una solución particular y también comprender el contexto en el que surgía con mayor frecuencia. Ahora también estamos probando un modelo de análisis sentimental que nos ayuda a detectar automáticamente el nivel promedio de satisfacción con partes individuales de un producto y notifica al equipo del producto al respecto.
Un analista es una persona que puede formular un problema en el nivel adecuado de abstracción, medirlo y verificar su importancia, ofrecer recomendaciones para la acción.
Independientemente de la etapa del estudio, existen diferentes niveles de hipótesis (las discutiremos en detalle a continuación) que ayudan a evaluar la interacción del usuario con el producto y a construir planes de desarrollo adicionales. Aquí, a menudo surge la tarea de evaluar correctamente el nivel necesario de hipótesis y seleccionar una herramienta para recopilar información o su validación. De hecho, el proceso es el siguiente:
- Formulación de hipótesis , por ejemplo: "es importante que los usuarios-administradores de una determinada cohorte puedan facturar basándose en un informe semanal".
- Recopilar estadísticas de uso , una tarea analítica clásica, es comprender si los números son capaces de responder a las hipótesis formuladas anteriormente.
- Recopilación de comentarios : realizar investigaciones a través de marketing, listas de correo o mediante herramientas de comentarios internos
- Análisis y validación de resultados : comprobación de resultados en una estadística. relevancia
Detengámonos en el tercer párrafo, ya que a menudo es él quien distingue a un analista de productos de una persona que conoce bien las estadísticas.
Recolección de comentarios
Muchas compañías creen que después de configurar un sistema de registro, fijar servicios analíticos como Google Analytics a su producto, la preparación de una plataforma para análisis termina aquí. Sin embargo, desafortunadamente, con este enfoque, se olvida el elemento más importante: la necesidad de retroalimentación del usuario, la capacidad de preguntarle en el momento adecuado sobre sus tareas y las dificultades que enfrenta.
Por lo tanto, es fundamental que el equipo tenga herramientas suficientes para interrogar discretamente a los usuarios y recopilar comentarios de ellos, no solo a través de algún tipo de encuesta de marketing, sino también a través de un mecanismo interno.
Utilizamos la herramienta interna QFF (formulario de comentarios cualitativos) para formular y validar hipótesis y considerar posibles escenarios de experiencia del usuario como una pirámide de tres etapas (producto → característica → interacción):
- Nivel de producto
- Nivel de funcionalidad
- Nivel de interacción específico
Detengámonos en cada uno de ellos con un poco más de detalle y muestremos qué métricas usamos para comprender sus problemas.
1. Nivel de producto
Aquí, es importante que comprendamos las partes más amplias y multifuncionales del embudo de experiencia del usuario. Este es el deseo de encontrar respuestas a las preguntas más globales, ya sea la satisfacción con el producto en su conjunto o con el conjunto de funcionalidades para resolver una sola tarea (por ejemplo, coordinar vacaciones puede requerir la interacción de la funcionalidad de calendario, estados de tareas, algoritmos de programación, etc.).
No hay métricas claramente reguladas que deban aplicarse en tales situaciones; siempre hay matices. Sin embargo, como regla general, en este nivel de abstracción, estamos hablando de métricas NPS (puntaje de promotor neto) o SUS (escala de usabilidad del sistema). Las métricas no son indiscutibles, pero, por lo general, son los estándares de la industria y ayudan a orientarse para establecer objetivos en la escala de varios trimestres.
2. Nivel de funcionalidad
En este nivel, hacemos preguntas más específicas que se relacionan directamente con un funcional específico. A partir del ejemplo anterior, ya podemos ver por separado no el problema de "coordinar vacaciones" en general, sino tomar solo una parte específica del producto, por ejemplo, calendarios. ¿Qué tan cómodos son para la percepción? ¿Por qué la gente los usa?
Dependiendo de la etapa de nuestra investigación, no solo las preguntas pueden diferir, sino también los indicadores que recopilamos de nuestros usuarios. El más simple es el nivel de satisfacción, que se puede leer de una tarea a otra utilizando diferentes escalas (tres emoticones o escala Likert), CES (puntaje de esfuerzo del cliente): cuán difícil o fácil es para el usuario implementar algunas tareas.
3. Nivel de interacción
La tarea de este nivel es evaluar la iteración específica que el usuario realizó con el producto (por ejemplo, hizo clic en un botón). Al mismo tiempo, es importante que el resultado de esta interacción sea una determinada acción o solución que no podamos medir o controlar. Como regla general, aquí estamos hablando de niveles de satisfacción y la adopción de ciertas decisiones posteriores: por ejemplo, ¿entendió el gerente, mirando el calendario, cuándo el empleado está de vacaciones? ¿El formato de exportación de datos es adecuado para el usuario? Dado que todas las acciones adicionales se producen solo en la cabeza del usuario o fuera de nuestro producto, no tenemos ningún otro método para evaluar la iteración.
De hecho, el nivel de evaluación de la interacción es un intento de evaluar la métrica CSAT (satisfacción del cliente), que a menudo se usa en soporte y otros servicios en los que necesita calificar un evento específico. Al mismo tiempo, las métricas como CES también se pueden usar aquí, pero en una formulación más "local".
Análisis y validación de resultados.
Después de haber resuelto las hipótesis, formulado preguntas y realizado nuestras encuestas de validación al nivel apropiado de experiencia del usuario con el producto, surge una tarea que nuevamente requiere un talento especial del analista, esta vez en el campo de las estadísticas y las pruebas de hipótesis.
De hecho, después de cada encuesta, el analista debe asegurarse con qué grado de confianza puede confiar en los resultados, incluidos los resultados de su trabajo. ¿El factor de trabajo en una gran empresa influye en la respuesta? ¿Y el puesto del empleado?
Todas estas hipótesis se verifican cuidadosamente utilizando las herramientas necesarias: como realizar correctamente una prueba A / B, son exactamente los enfoques que se aplican en cada situación particular los que dependen directamente del analista. Como regla general, el análisis de regresión a menudo se puede usar, sin embargo, no es la única solución universal, ya que Tiene sus propios campos de aplicación e interpretación. Los métodos específicos siempre quedan a discreción del analista.
En lugar de una conclusión
Arriba, revelamos solo dos casos principales en el trabajo del analista, y al mismo tiempo no hablamos intencionalmente sobre todas las etapas de su trabajo: una descripción detallada de todos los tipos de investigación, la formulación de hipótesis y la recopilación correcta de datos vale la pena artículos separados. Sin embargo, creemos que incluso una formulación de expectativas de tan alto nivel de los análisis y la fijación de métodos clave de su trabajo fortalecerán significativamente a cualquier equipo de productos y ayudarán a hacer mejores productos.
La capacidad de encontrar puntos de crecimiento en los datos (no importa cuán desestructurado pueda ser), formularlos correctamente en hipótesis, escalar y validar para todos los usuarios actuales y futuros: estas son las cualidades que distinguen a nuestros analistas de productos. Por lo tanto, sabemos con certeza que dichos requisitos brindan los resultados más tangibles y no permiten que entren en la rutina operativa, por lo que recomendamos estos principios a otros equipos.
Y si desea hablar sobre análisis cuantitativo, big data y cosas de infraestructura que admiten todos los análisis en Wrike, visítenos en una reunión en la oficina de San Petersburgo . Bueno, o simplemente ve a visitar.