Los Product Managers toman decisiones constantemente: qué característica priorizar, dónde abandonan los usuarios un recorrido, si una versión tiene una activación mejorada o qué segmento de clientes utiliza más una característica en particular.
Algunas respuestas ya están en un dashboard; otras necesitan un periodo, un segmento o una combinación de registros diferente. La petición de análisis debe concretar esas decisiones antes de poder interpretar el resultado.
SQL para directores de producto
Aprender SQL permite a los Product Managers consultar información almacenada en una base de datos, validar hipótesis y responder preguntas básicas sobre sus productos sin tener que esperar siempre al equipo de datos.
Un manejo práctico de SQL permite realizar investigaciones habituales y revisar con el equipo de Datos cómo se ha producido un análisis.
¿Qué es SQL?
SQL significa lenguaje de consulta estructurado. Es un lenguaje utilizado para consultar y trabajar con información almacenada en bases de datos relacionales. Estas bases de datos organizan la información en tablas formadas por filas y columnas. Una tabla de usuarios, por ejemplo, podría contener una fila para cada persona registrada y columnas como:
- ID de usuario.
- Fecha de registro.
- País.
- Plan de suscripción.
- Estado de la cuenta.
Otra tabla puede contener eventos generados dentro del producto, como inicios de sesión, visitas a páginas, activaciones de funciones o compras. SQL nos permite seleccionar, filtrar, ordenar, agrupar y conectar esta información para responder preguntas específicas.
¿Por qué un Product Manager debería aprender SQL?
SQL puede acortar la distancia entre una pregunta sobre un producto y su respuesta. Para una funcionalidad lanzada la semana pasada, el equipo podría contar los usuarios únicos que activaron su evento de uso durante los siete días siguientes. Hace falta acordar el evento, los criterios de elegibilidad y si toda la cohorte ha tenido una semana completa para utilizarla.
Con una consulta relativamente simple, usted mismo podría realizar una investigación inicial. Esta autonomía no reemplaza el trabajo de los equipos de Datos. Los análisis complejos, los modelos estadísticos y las definiciones de métricas rigurosas aún requieren conocimientos especializados. Sin embargo, SQL permite a los Product Managers responder preguntas exploratorias y participar en conversaciones sobre datos con mucho más contexto.
También puede ayudarle a identificar problemas, validar resultados y comprender cómo se registra la actividad del producto.
Los componentes básicos de SQL
Una consulta puede parecer complicada al principio, pero gran parte del SQL que necesita un Product Manager se puede crear combinando algunos elementos fundamentales.
SELECCIONAR: elige la información
SELECT especifica qué columnas desea recuperar.
Si una tabla contiene docenas de campos, por ejemplo, puede seleccionar solo el nombre del usuario y el plan de suscripción. Esto evita que la consulta devuelva información innecesaria y hace que los resultados sean más fáciles de interpretar.
DESDE: identificar la fuente
FROM especifica la tabla que desea consultar.
Una base de datos puede contener tablas separadas para usuarios, suscripciones, pagos, pedidos, sesiones y eventos. Antes de escribir una consulta, debe comprender dónde se almacena la información relevante.
DÓNDE: filtrar los resultados
WHERE le permite definir condiciones.
Puedes usarlo para recuperar solo usuarios de un país en particular, cuentas con un plan específico o eventos generados dentro de un período en particular. Un filtro define la población o el periodo analizado. Excluir un mercado, las cuentas de prueba o los periodos de observación incompletos cambia lo que describe el resultado.
GRUPO POR: comparar grupos
GROUP BY organiza los datos según una o más características.
Por ejemplo, puede agrupar usuarios por país, plan de suscripción, canal de adquisición o versión de la aplicación. Luego podrá calcular una métrica para cada grupo y comparar los resultados. Esto podría revelar si una función tiene una mayor adopción entre los clientes de pago o si la activación difiere entre los mercados.
Funciones agregadas: resumir información
Las funciones agregadas realizan cálculos en un conjunto de registros. Algunos de los más utilizados son:
COUNTpara contar registros.SUMpara agregar valores.AVGpara calcular un promedio.MINpara encontrar el valor más bajo.MAXpara encontrar el valor más alto.
Estas funciones convierten miles de filas individuales en métricas que pueden interpretarse y utilizarse en la toma de decisiones.
UNIRSE: conectar diferentes tablas
La información necesaria para responder una pregunta no siempre está contenida en una única tabla.
La información básica del usuario puede almacenarse en una tabla, mientras que su actividad dentro del producto se almacena en otra. JOIN conecta ambas tablas usando un campo compartido, como el ID de usuario.
Combinar tablas permite asociar un segmento de cliente a un evento o pedido. También hay que comprobar la relación: varias filas coincidentes pueden multiplicar los registros e inflar un recuento.
Preguntas sobre productos que puedes responder con SQL
Estos conceptos básicos son suficientes para investigar muchas preguntas comunes sobre productos:
- ¿Cuántos usuarios interactúan con una función en particular?
- ¿Qué porcentaje de usuarios completan el proceso de incorporación?
- ¿En qué etapa del embudo abandonan la mayoría de los usuarios?
- ¿Cómo ha cambiado una métrica en las últimas semanas?
- ¿Qué segmento de clientes tiene la mayor adopción?
- ¿Mejoró la activación después de un cambio de producto?
- ¿Cuántos usuarios regresan después de una semana?
- ¿La caída en una métrica afecta a todo el producto o solo a un mercado?
El desafío no es simplemente escribir la consulta. Antes de abrir una herramienta de datos, debes convertir una preocupación general en una pregunta mensurable. “¿Está funcionando bien la nueva característica?” es demasiado ambiguo.
“¿Qué porcentaje de usuarios activos interactuaron con la función al menos una vez durante los últimos siete días?” define una población, una acción y un período. Esa pregunta se puede traducir en una consulta SQL.
De una pregunta sobre un producto a una decisión
El proceso siempre debe comenzar con una pregunta sobre el producto, no con los datos que estén disponibles. Primero, define lo que quieres entender. Luego convierta esa preocupación en una pregunta medible, escriba la consulta SQL, revise el resultado y decida qué significa para el producto.
Un flujo de trabajo simple se ve así:
- Comience con una pregunta sobre el producto.
- Conviértela en una pregunta mensurable.
- Escribe la consulta SQL.
- interpretar y validar el resultado.
- Utilice la información para tomar una decisión.
SQL proporciona datos, pero no explica automáticamente por qué sucedió algo. Si la adopción de funciones disminuye, aún deberá investigar las posibles causas, revisar los cambios recientes y quizás combinar el análisis cuantitativo con la investigación cualitativa.
No confíes ciegamente en los resultados
Una consulta puede ejecutarse correctamente y aun así proporcionar una respuesta incorrecta. Es posible que esté contando eventos duplicados, incluidos usuarios internos o interpretando una fecha incorrectamente. El mismo concepto de negocio también puede tener diferentes definiciones en toda la organización.
Por ejemplo, un "usuario activo" podría significar alguien que inició sesión, alguien que completó una acción específica o alguien que usó el producto en cualquier momento durante los últimos 30 días.
Antes de utilizar un resultado para tomar una decisión, verifique:
- Qué representa cada tabla y columna.
- Cómo se registran los eventos.
- Si los datos contienen valores nulos o duplicados.
- Qué período se está analizando.
- Qué usuarios deben incluirse o excluirse.
- Si la métrica coincide con la definición utilizada por la empresa.
Conviene revisar la definición con quienes utilizan el informe, especialmente si distintos equipos emplean la misma etiqueta para poblaciones diferentes.
Aplicar SQL a una investigación de producto
Las consultas habituales pueden convivir con el trabajo con Datos e Ingeniería. Conviene acordar qué conjuntos de datos se pueden analizar directamente y cuándo un cálculo desconocido necesita una revisión especializada. Un primer ejercicio útil es una pregunta sobre un recorrido conocido. Conviene identificar las tablas, examinar algunos registros y comparar el resultado con un informe de referencia antes de ampliar el análisis.
Con SELECT, WHERE, GROUP BY, algunas funciones agregadas y una comprensión básica de JOIN, puede responder una cantidad significativa de las preguntas que aparecen durante el desarrollo del producto.
La definición de la métrica debe acompañar a la consulta, con su población, periodo y exclusiones conocidas. Quien la retome debe poder reproducir el cálculo y valorar si sirve para una nueva decisión.
