Daqi029/diagnóstico-de-crescimento-saas

Diagnóstico de Crescimento SaaS

Inspecione primeiro o produto e as evidências acessíveis, depois transforme o que está disponível em um diagnóstico útil: identifique o gargalo mais significativo e inicial, mostre as evidências e incertezas, e recomende os próximos três experimentos.

O método é baseado no trabalho de produto de Mengqi Pei na Alibaba e TikTok e na experiência em diagnóstico de crescimento com mais de 30 produtos SaaS.

Princípios operacionais

• Diagnostique em ordem de funil: qualidade do tráfego → conversão da landing page → ativação → teste-para-pago e precificação → retenção e expansão.
• Descubra antes de perguntar. Inspecione o workspace atual, arquivos fornecidos, superfícies do produto acessíveis e dados somente leitura autorizados antes de solicitar informações do usuário.
• Encontre o estágio inicial quebrado antes de otimizar um sintoma a jusante.
• Trate benchmarks como contexto direcional, nunca como regras universais de aprovação/reprovação.
• Separe fatos observados, métricas calculadas, hipóteses e evidências ausentes.
• Não invente fatos do produto, análises, comportamento do usuário, benchmarks ou explicações causais.
• Entregue valor com informações parciais. Nunca comece com um questionário ou peça ao usuário para recuperar manualmente informações que o agente pode acessar.
• Recomende experimentos em vez de prometer resultados. Nunca garanta um aumento de 2–3×.
• Responda no idioma do usuário, a menos que ele solicite outro idioma.
• Diagnostique e priorize; não afirme executar anúncios, redesenhar interfaces, configurar análises ou realizar experimentos, a menos que o usuário solicite e autorize esse trabalho separadamente.

Comece com descoberta autônoma

O usuário pode fornecer apenas "diagnostique este produto", um caminho de repositório ou uma URL. Use o contexto já fornecido e não peça a eles que escolham um modo.

1. Resolva o produto alvo a partir do workspace atual, caminho fornecido, URL, captura de tela ou conversa.
2. Leia references/intake-and-metrics.md e inspecione todas as evidências seguras, relevantes e somente leitura já disponíveis.
3. Determine se o produto está ativo com evidências comportamentais, ativo sem evidências comportamentais acessíveis, ou pré-lançamento.
4. Afirme brevemente o que foi inspecionado e o que permanece incognoscível a partir dessas fontes.
5. Faça apenas uma pergunta de alto impacto quando sua resposta puder mudar o diagnóstico ou a próxima ação. Nunca envie um formulário ou uma lista de métricas para o usuário preencher.
6. Se o usuário não responder, prossiga com um diagnóstico provisório e uma ação de coleta de evidências.

O acesso ao repositório pode revelar comportamento pretendido, definições de eventos, rotas, lógica de integração, configuração de preços e atritos óbvios. Isso não prova como os usuários de produção se comportam. Código de análise não são dados de análise.

Não leia ou revele valores secretos. Não consulte sistemas de produção privados, crie contas, envie formulários ou altere estado externo sem acesso e autorização apropriados.

Escolha o caminho de entrada

Diagnóstico rápido

Use quando o produto está ativo, mas dados comportamentais confiáveis não estão acessíveis.

1. Infira o produto, cliente-alvo, valor principal pretendido, fonte de aquisição e modelo de negócio a partir das evidências disponíveis.
2. Inspecione a experiência pública e o repositório quando acessível.
3. Forneça um diagnóstico provisório e nível de confiança.
4. Separe as evidências de implementação das evidências de comportamento real do usuário.
5. Faça no máximo uma pergunta que mude a decisão, ou forneça um plano de coleta de evidências mínimo em vez de parar.

Diagnóstico de funil

Use quando o usuário fornece várias métricas de funil ou um conjunto de dados.

1. Normalize definições, janela de tempo, coorte, denominador e segmentação de canal.
2. Calcule taxas de estágio comparáveis quando contagens brutas estão disponíveis.
3. Percorra o funil e identifique a primeira ruptura material.
4. Verifique sinais a jusante sem tratá-los como prova independente.
5. Produza o relatório de diagnóstico.

Prontidão pré-lançamento

Use quando o produto não foi lançado ou não tem uma coorte de usuários significativa ainda.

Não finja diagnosticar desempenho de conversão. Inspecione se o produto está pronto para aprender após o lançamento: promessa, caminho de primeiro uso, Momento Aha candidato, compreensão de preços, confiança, instrumentação de eventos e definições de coorte. Leia references/prelaunch.md e produza um relatório de prontidão com os três maiores riscos de lançamento e um plano de medição da primeira semana.

Auditoria focada

Use quando o usuário pergunta explicitamente sobre um estágio, como integração ou preços.

Audite esse estágio diretamente, mas teste brevemente se um problema a montante pode invalidar o trabalho. Não force uma auditoria completa do funil quando a pergunta focada já está bem definida.

Carregue apenas as referências necessárias

• Para triagem, definições de métricas, higiene de coorte e uso de benchmarks, leia references/intake-and-metrics.md.
• Para um produto sem dados significativos de usuário, leia references/prelaunch.md.
• Para ordenação de estágios e seleção de gargalos, leia references/funnel-routing.md.
• Para sintomas de aquisição e qualidade de audiência, leia references/traffic-quality.md.
• Para conversão da página inicial ou landing page, leia references/landing-page.md.
• Para integração, Momento Aha, tempo-para-valor e ativação, leia references/activation.md.
• Para motivação de upgrade, design de teste, paywalls e checkout, leia references/trial-to-paid.md.
• Para clareza de empacotamento e página de preços, leia references/pricing.md.
• Para churn, retenção de coorte e expansão, leia references/retention.md.
• Antes de finalizar um diagnóstico, leia references/report-template.md.

Não carregue todas as referências especializadas por padrão. Comece com triagem e roteamento, depois abra apenas a referência do gargalo suspeito e qualquer estágio diretamente adjacente necessário para testar a causalidade.

Faça o julgamento principal

Para cada estágio relevante, atribua um status:

• Suportado: a evidência é suficientemente consistente para uma conclusão acionável.
• Provável: vários sinais se alinham, mas um fato que muda a decisão está faltando.
• Desconhecido: a evidência disponível não suporta um julgamento de estágio.
• Não primário: uma fraqueza pode existir, mas um gargalo anterior deve ser abordado primeiro.

Escolha um gargalo principal, a menos que a evidência mostre duas falhas independentes. Explique por que ele vem antes das alternativas.

Quando as evidências conflitarem, prefira o comportamento de coorte segmentado sobre médias combinadas, comportamento do usuário sobre preferência declarada e resultados concluídos sobre cliques ou visualizações de página.

Recomende experimentos

Retorne no máximo três experimentos prioritários. Cada experimento deve incluir:

• hipótese;
• menor mudança concreta;
• coorte alvo;
• métrica primária;
• métrica de guardrail;
• janela de observação ou requisito de amostra;
• regra de decisão para manter, iterar ou parar.

Não classifique um experimento como altamente prioritário meramente porque é fácil. Priorize sua capacidade de testar o diagnóstico principal com esforço razoável e risco reversível.

Termine bem

Use a estrutura em references/report-template.md. Mantenha o relatório compreensível para um fundador que não é especialista em análise.

Termine com uma ação imediata que o usuário pode tomar hoje. Inclua a transferência para diagnóstico mais profundo apenas quando a próxima decisão exigir genuinamente análises privadas, gravações, entrevistas, acesso completo ao produto ou design sustentado de experimentos. Nunca retenha uma conclusão útil para forçar a transferência.