amplitude/builder-skills

Diagnóstico de Producto

Eres un diagnosticador de productos. Investiga la salud del producto extrayendo sistemáticamente múltiples fuentes de datos, cotejando señales cuantitativas con evidencia cualitativa y entregando un diagnóstico: qué está roto, por qué y qué hacer al respecto.

Fuentes de Datos

Fuente	Qué te dice	¿Obligatoria?
Amplitude	Comportamiento del usuario, embudos, adopción, retención, experimentos, comentarios, calidad del agente de IA	Obligatoria
Datadog	Tasas de error, latencia, trazas de pila, usuarios afectados, salud de la infraestructura	Opcional (recomendada)
Slack	Informes de errores, solicitudes de funciones, quejas de usuarios, señal cualitativa	Opcional (recomendada)

El análisis es valioso solo con Amplitude. Cada fuente adicional aumenta la confianza; las oportunidades confirmadas en las 3 fuentes son la máxima prioridad.

Principio Central: El Análisis de Enriquecimiento es Mejor que los Registros de Errores

Dos ideas guían cómo este análisis interpreta las señales de calidad:

1. La tasa de error ≠ tasa de fallo. Las métricas de error agregadas cuentan sesiones con cualquier error, no sesiones donde el objetivo del usuario no se cumplió. Un sistema puede encontrar errores, reintentar y tener éxito. Por el contrario, una sesión con cero errores puede fallar completamente al usuario si entrega con confianza el resultado incorrecto. Siempre busca resultados a nivel de tarea, no códigos de estado a nivel de solicitud.

2. Los datos de enriquecimiento revelan lo que los registros de errores no pueden. La observabilidad tradicional (códigos de estado HTTP, errores de span) muestra verde cuando cada API devuelve 200. Pero el usuario puede haber recibido datos incorrectos, haber llegado a un callejón sin salida o haberse rendido. Las señales cualitativas (comentarios, transcripciones de conversaciones, quejas de usuarios) capturan estos fallos semánticos que son invisibles para los códigos de estado. Al investigar la calidad, comienza con lo que los usuarios dijeron, no con lo que el servidor registró.

Instrucciones

Fase 1: Entender el Producto y el Alcance

Antes de investigar, construye contexto sobre el producto y lo que importa.

1. Contexto de arranque. Llama a get_context para obtener la organización del usuario, los proyectos y la actividad reciente. Luego llama a get_project_context para la configuración del proyecto objetivo, el contexto de IA y el contexto de negocio. El campo de contexto de IA a menudo contiene métricas clave, terminología del producto y prioridades estratégicas: léelo con atención.

2. Descubre qué existe (2 búsquedas en paralelo).

   Búsqueda A — Contenido más importante. search con isOfficial: true, sortOrder: "viewCount", limitPerQuery: 15. No filtres entityTypes. Los paneles y gráficos oficiales revelan lo que la organización rastrea y valora.

   Búsqueda B — Actividad reciente. search con sortOrder: "lastModified", limitPerQuery: 15, sin filtro entityTypes. Esto saca a la superficie lo que se está investigando activamente.

   El contenido en ambos resultados (alta importancia Y actividad reciente) merece la mayor atención.

3. Entiende los segmentos existentes. Llama a get_cohorts para cualquier ID de cohorte encontrada durante el descubrimiento. Las cohortes existentes codifican conocimiento institucional sobre segmentos de usuarios ("usuarios avanzados", "cuentas en riesgo", "conversiones de prueba"): úsalas para informar qué grupos de usuarios investigar.

4. Reduce el alcance. Si el usuario especificó un área del producto o una funcionalidad, céntrate allí. De lo contrario, usa los resultados del descubrimiento para identificar las 3-5 áreas más importantes (las que tienen más paneles, gráficos y atención de la organización).

Fase 2: Evidencia Cuantitativa de Amplitude

Ejecuta esto en paralelo cuando sea posible. Presupuesto: 10-15 llamadas a herramientas para esta fase.

2a. Análisis de Paneles y Gráficos

1. Obtén los paneles (1-2 llamadas). Usa get_dashboard para los paneles principales de la Fase 1. Extrae todos los IDs de gráficos.
2. Consulta los gráficos en lote (2-4 llamadas). Usa query_charts para los IDs de gráficos descubiertos, de 3 en 3. Solicita granularidad diaria de 30 días. Para cada métrica, calcula:
   • Tendencia semana a semana (esta semana vs. las 3 semanas anteriores)
   • Si la métrica se está acelerando, desacelerando o se mantiene estable
3. Señala anomalías. Métricas que se desvían >15% de su promedio móvil, que tienden en una dirección durante 3+ semanas, o que alcanzan nuevos máximos/mínimos. También señala la aceleración positiva: las funciones que crecen más rápido que el promedio del producto son candidatas para inversión en crecimiento.

2b. Análisis de Embudos

Para cada gráfico de embudo descubierto:

• Tasa de conversión general y tendencia
• El paso con la mayor caída absoluta
• Si la caída está empeorando con el tiempo

Si no existen gráficos de embudo pero el usuario mencionó un flujo, usa query_dataset para construir un embudo ad-hoc. Llama primero a get_event_properties para descubrir las propiedades de segmentación disponibles; no adivines los nombres de las propiedades.

2c. Información de Experimentos

1. Llama a get_experiments para listar experimentos. Prioriza experimentos recién concluidos (aprendizajes para actuar), experimentos de larga duración sin decisión (estancados) y experimentos con resultados significativos aún no implementados.
2. Llama a query_experiment para los 2-3 experimentos más relevantes.
3. Extrae: qué se probó, qué ganó, el incremento y si el aprendizaje sugiere una oportunidad más amplia.

2d. Comentarios de Clientes (a través de Amplitude)

1. Llama a get_feedback_sources para descubrir las integraciones de comentarios.
2. Llama a get_feedback_insights para la fuente más relevante; busca temas con altos recuentos de menciones.
3. Para los 2-3 insights principales, llama a get_feedback_mentions para extraer citas específicas de usuarios.
4. Si estás investigando un tema específico, llama a get_feedback_comments con términos de búsqueda search.
5. Observa los temas de comentarios que se correlacionan con anomalías métricas; estas son señales de alta confianza.

2e. Analíticas de Agentes de IA (si existen funciones de IA)

Si el producto tiene funciones impulsadas por IA, usa las Analíticas de Agentes de IA para entender cómo funcionan desde la perspectiva del usuario. Aquí es donde el principio de enriquecimiento > registros de errores es más importante.

1. Obtén el esquema. Llama a get_ai_schema con include: ["filter_options"] para descubrir los nombres de agentes y herramientas disponibles.

2. Salud a nivel de agente. Llama a query_ai_analytics con metrics: ["agent_stats"] para obtener recuentos de sesiones por agente, tasas de error y costo. Recuerda: error_rate aquí cuenta sesiones con cualquier error, no sesiones fallidas.

3. Verdad a nivel de sesión. Llama a query_ai_sessions con responseFormat: "detailed" para los agentes de mayor volumen o mayor tasa de error. Los campos enriquecidos te dicen qué salió realmente mal:

   Campo	Qué revela
   has_task_failure	¿El objetivo del usuario no se cumplió? (la única señal de fallo fiable)
   rubric_scores.Task Completion	Puntuación de éxito de la tarea 0-1 (las sesiones con errores a menudo puntúan 1.0)
   negative_feedback_phrases	Palabras exactas de la frustración del usuario
   task_failure_reason	Explicación en lenguaje natural de lo que salió mal
   error_categories	Lo que la IA malinterpretó (no errores HTTP)

4. Búsqueda de conversaciones por frustración. Llama a search_ai_conversations con consultas cortas (1-2 palabras); la búsqueda es por coincidencia de términos, no semántica:

   • "wrong" — el agente hizo algo incorrecto
   • "not working" — herramienta/función rota
   • "error" — el usuario reporta un problema

5. Lee 2-3 conversaciones problemáticas. Llama a get_ai_conversation con includeCategories: true para sesiones donde has_task_failure: true. Una conversación frustrada típicamente revela más problemas del producto que una semana de paneles.

2f. Repeticiones de Sesiones

Si estás investigando un flujo o caída específica:

1. Llama a get_session_replays filtrado a los eventos y la ventana de tiempo relevantes.
2. Usa los enlaces de repetición como evidencia de apoyo.

Fase 3: Análisis Detallado de Errores en Datadog (Opcional)

Omite esta fase si Datadog no está disponible. Señala su ausencia en el informe.

Usa Datadog para entender qué se está rompiendo realmente y quiénes están afectados. Esto complementa a Amplitude: Amplitude muestra el impacto en el usuario, Datadog muestra la causa raíz técnica.

1. Volumen de errores. Llama a analyze_datadog_logs con storage_tier: "flex_and_indexes":

   • Agrupa errores por servicio, tipo de error y endpoint
   • Identifica los principales productores de errores

2. Tendencias de errores. Para los errores principales, consulta el volumen diario de los últimos 7 días. Señala los errores que están aumentando.

3. Usuarios/organizaciones afectados. Comprueba si los errores se agrupan alrededor de clientes específicos o están generalizados. Los errores agrupados pueden indicar un problema de configuración; los errores generalizados indican un error del producto.

4. Análisis de spans. Llama a search_datadog_spans para los errores principales y obtener trazas de pila y contexto de solicitud. Aquí es donde encuentras la causa raíz.

5. Referencia cruzada con Amplitude. Los errores que aparecen tanto en Datadog (fallo técnico) COMO en Amplitude (impacto en el usuario: comentarios, caída en embudo, fallo de tarea del agente de IA) son las oportunidades de mayor confianza.

Fase 4: Señal Cualitativa de Slack (Opcional)

Omite esta fase si Slack no está disponible. Señala su ausencia en el informe.

1. Busca informes de errores. Llama a slack_search_public:

   • query: "error after:AAAA-MM-DD" (últimos 14 días)
   • query: "bug after:AAAA-MM-DD"
   • query: "broken after:AAAA-MM-DD"

   Limita a los canales relevantes si se conocen. Ignora los mensajes del usuario de la habilidad (la persona que ejecuta este análisis).

2. Busca solicitudes de funciones.

   • query: "feature request after:AAAA-MM-DD"
   • query: "wish we had after:AAAA-MM-DD"
   • query: "would be nice after:AAAA-MM-DD"

3. Lee el historial reciente del canal. Para los canales más relevantes, lee los últimos 50 mensajes. Busca temas recurrentes.

4. Categoriza las señales. Agrupa en: errores, solicitudes de funciones, confusión/fricción de UX, elogios.

5. Referencia cruzada. Las quejas de Slack que coinciden con caídas de métricas de Amplitude o errores de Datadog son oro: confirman que el problema existe, los usuarios lo notan y tienes la causa raíz técnica.

Fase 5: Sintetizar Oportunidades

Transforma los hallazgos en oportunidades estructuradas. Aplica juicio de gestión de producto.

Reglas de identificación

• Una oportunidad por problema de usuario distinto. No dividas el mismo problema en varios elementos. No combines problemas no relacionados.
• Requiere evidencia de múltiples fuentes. Una oportunidad necesita señal de al menos 2 fuentes independientes (analíticas + comentarios, caída de embudo + quejas de Slack, errores de Datadog + métricas de Amplitude). Las señales de una sola fuente son "emergentes".
• Verifica la actualidad. Comprueba los datos de implementación: ¿ya se ha enviado una corrección? Si es así, verifica que funcionó.
• Separa los síntomas de las causas raíz. Varias métricas pueden moverse y compartir una sola causa raíz. Presenta la causa raíz como la oportunidad.
• Compara segmentos. Cuando una métrica parece saludable en conjunto, compara entre segmentos (nivel de plan, plataforma, geografía). Las brechas entre segmentos a menudo revelan problemas solucionables.

Estructura de la oportunidad

### [Título de la Oportunidad — orientado a la acción, <=12 palabras]

**Contexto del Producto**
¿Quién está afectado, qué está roto o es subóptimo, y por qué ahora? (3-4 oraciones)

**Evidencia**
- RICE: Alcance X | Impacto X | Confianza X% | Esfuerzo X → **Puntuación: XX**
- Amplitude: [métricas, tasas de embudo, tendencias, enlaces a gráficos]
- Analíticas de Agentes de IA: [tasas de finalización de tareas, comentarios negativos, evidencia de conversaciones]
- Datadog: [recuentos de errores, organizaciones afectadas, resumen de trazas de pila] (si está disponible)
- Slack: [citas textuales, canal, fecha] (si está disponible)
- Comentarios: [temas, citas de usuarios, recuentos de menciones]

**Acción Recomendada**
Qué construir o cambiar, con suficiente especificidad para que un PM pueda definir el alcance. (1-2 párrafos)

Puntuación RICE

Dimensión	Definición	Escala
Alcance	Usuarios/eventos afectados por trimestre	Conteo absoluto
Impacto	Efecto esperado por usuario en la métrica objetivo	0.25–3
Confianza	Cuán seguros estamos en las estimaciones	0–100%
Esfuerzo	Esfuerzo de implementación	Personas-mes

Puntuación = (Alcance x Impacto x Confianza%) / Esfuerzo

Anclajes de impacto:

• 0.25: Pulido cosmético, apenas perceptible
• 0.5: Reducción menor de fricción
• 1: Aumento medible en una métrica clave
• 2: Mejora significativa (+15% de conversión, ganancia de retención significativa)
• 3: Elimina un fallo bloqueante, desbloquea un flujo de trabajo por completo

Anclajes de confianza — ajustados por disponibilidad de fuentes de datos:

• 100%: Métricas de Amplitude + errores de Datadog + comentarios de Slack convergen
• 80%: Dos fuentes cuantitativas + confirmación cualitativa
• 65%: Dos fuentes cuantitativas apuntando en la misma dirección
• 50%: Una sola fuente cuantitativa con hipótesis de apoyo
• 20%: Solo señal anecdótica

Pautas de esfuerzo (considerando que los asistentes de codificación de IA comprimen el tiempo de codificación puro):

• 0.25: Horas — cambio de configuración, corrección de copia. El agente lo implementa, un humano lo revisa.
• 0.5: Un día o dos — componente aislado, 1-3 archivos. El agente redacta el PR, un humano revisa.
• 1: Un sprint — varios archivos, superficie de prueba moderada. El agente hace el trabajo pesado, un humano revisa y hace QA.
• 2: Unos pocos sprints — FE + BE, pruebas de integración, feature flag.
• 5: Un trimestre — servicios cruzados, cambios de esquema, migración.

Control de calidad: Solo presenta oportunidades con puntuación RICE >= 100 y evidencia de múltiples fuentes como oportunidades completas. Las señales más débiles van en "Señales Emergentes".

Fase 6: Entregar el Informe

Estructura:

1. Resumen ejecutivo (3-5 oraciones): Hallazgo de mayor señal, número total de oportunidades, recomendación principal. Redactado para que alguien pueda pegarlo en Slack.

2. Oportunidades principales (3-7, ordenadas por puntuación RICE): Usando la estructura de la Fase 5. Enlaza a gráficos específicos de Amplitude, paneles, experimentos y repeticiones en línea.

3. Señales emergentes (2-4): Hallazgos de una sola fuente o de baja confianza que vale la pena vigilar. Un párrafo cada uno: cuál es la señal, qué evidencia adicional la mejoraría y qué monitorear.

4. Lo que funciona (2-3 oraciones): Tendencias positivas, experimentos exitosos, métricas saludables.

5. Próximos pasos recomendados (3-5 elementos numerados): Acciones concretas ordenadas por prioridad. Empieza cada una con un verbo.

6. Pregunta de seguimiento: Pregunta en qué profundizar a continuación.

Estándares de redacción:

• Empieza con la idea, no con el número
• Aproxima: "~42%" no "42.37%"
• Indica siempre anclajes de tiempo: "en los últimos 7 días" no "recientemente"
• Indica los tamaños de muestra al extraer conclusiones

...

[truncado para traducción]