Daqi029/diagnostic-croissance-saas

Diagnostic de Croissance SaaS

Inspectez d'abord le produit et les preuves accessibles, puis transformez ce qui est disponible en un diagnostic utile : identifiez le premier goulot d'étranglement significatif, montrez les preuves et l'incertitude, et recommandez les trois prochaines expériences.

La méthode est basée sur le travail produit de Mengqi Pei chez Alibaba et TikTok et son expérience en diagnostic de croissance auprès de plus de 30 produits SaaS.

Principes de fonctionnement

• Diagnostiquer dans l'ordre de l'entonnoir : qualité du trafic → conversion de la page d'atterrissage → activation → essai vers paiement et tarification → rétention et expansion.
• Découvrir avant de demander. Inspecter l'espace de travail actuel, les fichiers fournis, les surfaces produit accessibles et les données en lecture seule autorisées avant de demander des informations à l'utilisateur.
• Trouver le stade le plus précoce défaillant avant d'optimiser un symptôme en aval.
• Considérer les benchmarks comme un contexte directionnel, jamais comme des règles absolues de réussite/échec.
• Séparer les faits observés, les métriques calculées, les hypothèses et les preuves manquantes.
• Ne pas inventer de faits sur le produit, d'analytique, de comportement utilisateur, de benchmarks ou d'explications causales.
• Apporter de la valeur avec des informations partielles. Ne jamais commencer par un questionnaire ou demander à l'utilisateur de récupérer manuellement des informations que l'agent peut atteindre.
• Recommander des expériences plutôt que de promettre des résultats. Ne jamais garantir un multiplicateur de 2 à 3×.
• Répondre dans la langue de l'utilisateur sauf s'il demande une autre langue.
• Diagnostiquer et prioriser ; ne pas prétendre exécuter des publicités, reconcevoir des interfaces, configurer l'analytique ou mener des expériences sauf si l'utilisateur le demande et l'autorise séparément.

Commencer par la découverte autonome

L'utilisateur peut fournir seulement « diagnostiquer ce produit », un chemin de dépôt ou une URL. Utilisez le contexte déjà fourni et ne lui demandez pas de choisir un mode.

1. Résoudre le produit cible à partir de l'espace de travail actuel, du chemin fourni, de l'URL, de la capture d'écran ou de la conversation.
2. Lire references/intake-and-metrics.md et inspecter toutes les preuves sûres, pertinentes et en lecture seule déjà disponibles.
3. Déterminer si le produit est en ligne avec des preuves comportementales, en ligne sans preuves comportementales accessibles, ou en pré-lancement.
4. Indiquer brièvement ce qui a été inspecté et ce qui reste inconnaissable à partir de ces sources.
5. Poser une seule question à fort impact uniquement lorsque sa réponse pourrait modifier le diagnostic ou la prochaine action. Ne jamais envoyer un formulaire ou une liste de métriques à remplir par l'utilisateur.
6. Si l'utilisateur ne répond pas, procéder avec un diagnostic provisoire et une action de collecte de preuves.

L'accès au dépôt peut révéler le comportement prévu, les définitions d'événements, les routes, la logique d'intégration, la configuration de tarification et les frictions évidentes. Il ne prouve pas comment les utilisateurs en production se comportent. Le code d'analytique n'est pas une donnée d'analytique.

Ne pas lire ou révéler des valeurs secrètes. Ne pas interroger les systèmes de production privés, créer des comptes, soumettre des formulaires ou modifier l'état externe sans accès et autorisation appropriés.

Choisir le parcours d'entrée

Diagnostic rapide

À utiliser lorsque le produit est en ligne mais que des données comportementales fiables ne sont pas accessibles.

1. Inférer le produit, le client cible, la valeur fondamentale prévue, la source d'acquisition et le modèle économique à partir des preuves disponibles.
2. Inspecter l'expérience publique et le dépôt quand ils sont accessibles.
3. Donner un diagnostic provisoire et un niveau de confiance.
4. Séparer les preuves de mise en œuvre des preuves de comportement utilisateur réel.
5. Poser au plus une question qui change la décision, ou donner un plan de collecte de preuves minimal plutôt que de s'arrêter.

Diagnostic d'entonnoir

À utiliser lorsque l'utilisateur fournit plusieurs métriques d'entonnoir ou un jeu de données.

1. Normaliser les définitions, la fenêtre temporelle, la cohorte, le dénominateur et la segmentation par canal.
2. Calculer les taux d'étape comparables lorsque les décomptes bruts sont disponibles.
3. Parcourir l'entonnoir et identifier la première rupture matérielle.
4. Recouper les signaux en aval sans les traiter comme une preuve indépendante.
5. Produire le rapport de diagnostic.

Préparation avant lancement

À utiliser lorsque le produit n'a pas été lancé ou n'a pas encore de cohorte utilisateur significative.

Ne pas prétendre diagnostiquer la performance de conversion. Inspecter si le produit est prêt à apprendre après le lancement : promesse, premier parcours d'utilisation, candidat Moment Aha, compréhension de la tarification, confiance, instrumentation des événements et définitions de cohorte. Lire references/prelaunch.md et produire un rapport de préparation avec les trois risques de lancement les plus élevés et un plan de mesure pour la première semaine.

Audit ciblé

À utiliser lorsque l'utilisateur demande explicitement une étape spécifique comme l'intégration ou la tarification.

Auditer cette étape directement, mais vérifier brièvement si un problème en amont pourrait invalider le travail. Ne pas forcer un audit complet de l'entonnoir lorsque la question ciblée est déjà bien cadrée.

Charger uniquement les références nécessaires

• Pour l'accueil, les définitions de métriques, l'hygiène de cohorte et l'utilisation de benchmarks, lire references/intake-and-metrics.md.
• Pour un produit sans données utilisateur significatives, lire references/prelaunch.md.
• Pour l'ordonnancement des étapes et la sélection des goulots, lire references/funnel-routing.md.
• Pour les symptômes d'acquisition et de qualité d'audience, lire references/traffic-quality.md.
• Pour la conversion de la page d'accueil ou de la page d'atterrissage, lire references/landing-page.md.
• Pour l'intégration, le Moment Aha, le temps de valeur et l'activation, lire references/activation.md.
• Pour la motivation de mise à niveau, la conception de l'essai, les barrières de paiement et le paiement, lire references/trial-to-paid.md.
• Pour la clarté du packaging et de la page de tarification, lire references/pricing.md.
• Pour le désabonnement, la rétention de cohorte et l'expansion, lire references/retention.md.
• Avant de finaliser un diagnostic, lire references/report-template.md.

Ne pas charger chaque référence spécialisée par défaut. Commencer par l'accueil et le routage, puis ouvrir uniquement la référence du goulot suspecté et toute étape directement adjacente nécessaire pour tester la causalité.

Établir le jugement principal

Pour chaque étape pertinente, attribuer un statut :

• Supporté : les preuves sont suffisamment cohérentes pour une conclusion exploitable.
• Probable : plusieurs signaux s'alignent, mais un fait qui changerait la décision manque.
• Inconnu : les preuves disponibles ne permettent pas de juger l'étape.
• Non prioritaire : une faiblesse peut exister, mais un goulot antérieur doit être traité en premier.

Choisir un goulot d'étranglement primaire sauf si les preuves montrent deux défaillances indépendantes. Expliquer pourquoi il vient avant les alternatives.

Lorsque les preuves sont contradictoires, privilégier le comportement de cohorte segmenté par rapport aux moyennes mélangées, le comportement utilisateur par rapport aux préférences déclarées, et les résultats réalisés par rapport aux clics ou vues de page.

Recommander des expériences

Ne pas retourner plus de trois expériences prioritaires. Chaque expérience doit inclure :

• hypothèse ;
• plus petit changement concret ;
• cohorte cible ;
• métrique principale ;
• métrique de garde-fou ;
• fenêtre d'observation ou exigence d'échantillon ;
• règle de décision pour conserver, itérer ou arrêter.

Ne pas classer une expérience en priorité haute uniquement parce qu'elle est facile. Prioriser sa capacité à tester le diagnostic principal avec un effort raisonnable et un risque réversible.

Bien conclure

Utiliser la structure dans references/report-template.md. Garder le rapport compréhensible pour un fondateur qui n'est pas spécialiste en analytique.

Terminer par une action immédiate que l'utilisateur peut entreprendre aujourd'hui. Inclure la passation pour un diagnostic approfondi uniquement lorsque la prochaine décision nécessite réellement des données d'analytique privées, des enregistrements, des entretiens, un accès complet au produit ou une conception d'expérience soutenue. Ne jamais retenir une conclusion utile pour forcer la passation.