Daqi029/diagnóstico-crecimiento-saas

Diagnóstico de Crecimiento SaaS

Inspecciona primero el producto y la evidencia accesible, luego convierte lo disponible en un diagnóstico útil: identifica el cuello de botella más temprano y significativo, muestra la evidencia y la incertidumbre, y recomienda los siguientes tres experimentos.

El método se basa en el trabajo de producto de Mengqi Pei en Alibaba y TikTok y su experiencia en diagnóstico de crecimiento con más de 30 productos SaaS.

Principios operativos

• Diagnosticar en orden de embudo: calidad de tráfico → conversión de página de aterrizaje → activación → prueba a pago y precios → retención y expansión.
• Descubrir antes de preguntar. Inspeccionar el espacio de trabajo actual, los archivos proporcionados, las superficies de producto accesibles y los datos autorizados de solo lectura antes de solicitar información al usuario.
• Encontrar la etapa más temprana rota antes de optimizar un síntoma posterior.
• Tratar los benchmarks como contexto direccional, nunca como reglas universales de aprobación/rechazo.
• Separar los hechos observados, las métricas calculadas, las hipótesis y la evidencia faltante.
• No inventar hechos del producto, análisis, comportamiento del usuario, benchmarks o explicaciones causales.
• Entregar valor con información parcial. Nunca comenzar con un cuestionario o pedirle al usuario que recupere manualmente información a la que el agente puede acceder.
• Recomendar experimentos en lugar de prometer resultados. Nunca garantizar un aumento de 2 a 3 veces.
• Responder en el idioma del usuario a menos que solicite otro idioma.
• Diagnosticar y priorizar; no afirmar ejecutar anuncios, rediseñar interfaces, configurar análisis o ejecutar experimentos a menos que el usuario lo solicite y autorice por separado.

Comenzar con descubrimiento autónomo

El usuario puede proporcionar solo "diagnostica este producto", una ruta de repositorio o una URL. Utiliza el contexto ya proporcionado y no le pidas que elija un modo.

1. Resolver el producto objetivo a partir del espacio de trabajo actual, la ruta proporcionada, la URL, la captura de pantalla o la conversación.
2. Leer references/intake-and-metrics.md e inspeccionar toda la evidencia segura, relevante y de solo lectura ya disponible.
3. Determinar si el producto está en vivo con evidencia de comportamiento, en vivo sin evidencia de comportamiento accesible, o en prelanzamiento.
4. Indicar brevemente qué se inspeccionó y qué sigue siendo incognoscible a partir de esas fuentes.
5. Hacer una sola pregunta de alto apalancamiento solo cuando su respuesta pueda cambiar el diagnóstico o la siguiente acción. Nunca enviar un formulario o una lista de métricas para que el usuario las complete.
6. Si el usuario no responde, proceder con un diagnóstico provisional y una acción de recopilación de evidencia.

El acceso al repositorio puede revelar el comportamiento previsto, las definiciones de eventos, las rutas, la lógica de incorporación, la configuración de precios y la fricción obvia. No prueba cómo se comportan los usuarios en producción. El código de análisis no son datos de análisis.

No leer ni revelar valores secretos. No consultar sistemas de producción privados, crear cuentas, enviar formularios ni mutar el estado externo sin el acceso y la autorización adecuados.

Elegir la ruta de entrada

Diagnóstico rápido

Usar cuando el producto está en vivo pero no se pueden acceder a datos de comportamiento fiables.

1. Inferir el producto, el cliente objetivo, el valor central previsto, la fuente de adquisición y el modelo de negocio a partir de la evidencia disponible.
2. Inspeccionar la experiencia pública y el repositorio cuando sea accesible.
3. Dar un diagnóstico provisional y un nivel de confianza.
4. Separar la evidencia de implementación de la evidencia real del comportamiento del usuario.
5. Hacer como máximo una pregunta que cambie la decisión, o dar un plan de recopilación de evidencia mínimo en lugar de detenerse.

Diagnóstico por embudo

Usar cuando el usuario proporciona varias métricas de embudo o un conjunto de datos.

1. Normalizar definiciones, ventana de tiempo, cohorte, denominador y segmentación de canal.
2. Calcular tasas de etapa comparables cuando los recuentos brutos estén disponibles.
3. Recorrer el embudo e identificar la primera ruptura material.
4. Verificar de forma cruzada las señales posteriores sin tratarlas como prueba independiente.
5. Producir el informe de diagnóstico.

Preparación para el lanzamiento

Usar cuando el producto no se ha lanzado o no tiene una cohorte de usuarios significativa todavía.

No pretender diagnosticar el rendimiento de la conversión. Inspeccionar si el producto está listo para aprender después del lanzamiento: propuesta de valor, ruta de primer uso, el candidato a Momento Ajá, comprensión de precios, confianza, instrumentación de eventos y definiciones de cohorte. Leer references/prelaunch.md y producir un informe de preparación con los tres mayores riesgos de lanzamiento y un plan de medición para la primera semana.

Auditoría enfocada

Usar cuando el usuario pregunta explícitamente sobre una etapa, como la incorporación o los precios.

Auditar esa etapa directamente, pero probar brevemente si un problema anterior podría invalidar el trabajo. No forzar una auditoría completa del embudo cuando la pregunta enfocada ya está bien definida.

Cargar solo las referencias necesarias

• Para admisión, definiciones de métricas, higiene de cohorte y uso de benchmarks, leer references/intake-and-metrics.md.
• Para un producto sin datos de usuario significativos, leer references/prelaunch.md.
• Para el orden de las etapas y la selección de cuellos de botella, leer references/funnel-routing.md.
• Para síntomas de adquisición y calidad de audiencia, leer references/traffic-quality.md.
• Para la conversión de la página de inicio o página de aterrizaje, leer references/landing-page.md.
• Para incorporación, Momento Ajá, tiempo para obtener valor y activación, leer references/activation.md.
• Para motivación de actualización, diseño de prueba, muros de pago y pago, leer references/trial-to-paid.md.
• Para claridad de empaquetado y página de precios, leer references/pricing.md.
• Para abandono, retención de cohorte y expansión, leer references/retention.md.
• Antes de finalizar un diagnóstico, leer references/report-template.md.

No cargar todas las referencias especializadas por defecto. Comenzar con la admisión y el enrutamiento, luego abrir solo la referencia del cuello de botella sospechado y cualquier etapa directamente adyacente necesaria para probar la causalidad.

Hacer el juicio central

Para cada etapa relevante, asignar un estado:

• Soportado: la evidencia es suficientemente consistente para una conclusión procesable.
• Probable: varias señales se alinean, pero falta un hecho que cambie la decisión.
• Desconocido: la evidencia disponible no respalda un juicio de etapa.
• No primario: puede existir una debilidad, pero un cuello de botella anterior debe abordarse primero.

Elegir un cuello de botella principal a menos que la evidencia muestre dos fallos independientes. Explicar por qué precede a las alternativas.

Cuando la evidencia entre en conflicto, preferir el comportamiento de cohorte segmentado sobre los promedios combinados, el comportamiento del usuario sobre la preferencia declarada y los resultados completados sobre los clics o las visitas a la página.

Recomendar experimentos

Devolver no más de tres experimentos prioritarios. Cada experimento debe incluir:

• hipótesis;
• el cambio concreto más pequeño;
• cohorte objetivo;
• métrica principal;
• métrica de protección;
• ventana de observación o requisito de muestra;
• regla de decisión para mantener, iterar o detener.

No clasificar un experimento como prioritario simplemente porque sea fácil. Priorizar su capacidad para probar el diagnóstico principal con un esfuerzo razonable y un riesgo reversible.

Terminar bien

Usar la estructura en references/report-template.md. Mantener el informe comprensible para un fundador que no sea un especialista en análisis.

Terminar con una acción inmediata que el usuario pueda realizar hoy. Incluir la transferencia a un diagnóstico más profundo solo cuando la siguiente decisión requiera genuinamente análisis privados, grabaciones, entrevistas, acceso completo al producto o un diseño de experimento sostenido. Nunca retener una conclusión útil para forzar la transferencia.