Le diagnostic de
situation produit.
Ce diagnostic intervient lorsque l'effort fourni par les équipes est élevé, mais que l'adoption stagne, que la rétention ne bouge plus, ou que chaque nouvelle décision coûte plus cher que la précédente. Les signaux sont là, mais ils sont contradictoires : le produit avance, mais l'impact recule.
La pression augmente, les feuilles de route s'alourdissent et chaque décision pèse plus lourd que la précédente. C'est le moment où le système sature et où l'on perd de vue le signal au milieu du bruit.
Une pause pour
vérifier le cap.
Il s'agit d'une intervention courte (2-3 semaines) destinée à identifier pourquoi les décisions ne tiennent pas. Souvent, cela révèle un décalage entre ce que l'organisation pense faire et ce qu'elle fait réellement. L'objectif n'est pas de juger la performance, mais de mettre sur la table les tensions que personne n'osait nommer.
C'est un moyen de vérifier que vous adressez le bon problème avant de chercher à accélérer. Une pause nécessaire pour retrouver une capacité de décision saine.
Ce que ce
diagnostic n'est pas.
Pas une définition de roadmap. On ne décide pas de ce qu'on build, on comprend pourquoi on le build. Souvent, les équipes veulent une roadmap pour éviter de trancher sur la direction. Je ne donne pas cette roadmap.
Pas un design de solution. Je ne viens pas dessiner des interfaces ou concevoir des fonctionnalités.
Pas un plan de delivery. L'enjeu est stratégique et organisationnel, pas logistique.
Pas un programme de transformation. Je n'impose pas de changement de process global.
Pas un engagement de suite. Ce diagnostic n'oblige à aucune collaboration ultérieure.
Une lecture
directe du terrain.
Ce qui est confronté
Je confronte la vision affichée aux décisions réellement prises. Souvent, la vision existe sur un slide mais n'aide plus à trancher les arbitrages du quotidien. Je confronte aussi les métriques affichées aux comportements réels des utilisateurs. Souvent, il y a un écart que personne n'osait nommer.
Ce qui est mis sur la table
Je mets sur la table les décisions qui restent ouvertes depuis trop longtemps. Souvent, cela révèle un désaccord entre le fondateur et le Head of Product que personne n'osait nommer. Je mets aussi sur la table les fonctionnalités qui ne trouvent pas leur public malgré l'effort fourni. Cela crée toujours une tension : personne n'aime arrêter ce qui a coûté du temps à construire.
Ce qui peut conduire à ne pas travailler ensemble
Si la situation actuelle est le meilleur arbitrage possible compte tenu des contraintes, je le dis explicitement. Cela peut conduire à ne pas collaborer plus loin. C'est une issue valide et assumée. Si le blocage racine est ailleurs (vision floue, organisation de l'équipe, manque de données), je le nomme aussi. Cela peut créer un désaccord immédiat avec ceux qui pensaient que le problème était opérationnel.
Où cela
mène-t-il ?
Clarifier le vrai problème
Nommer enfin ce qui freine l'équipe. Souvent, les symptômes visibles (PMs débordés, priorités qui changent) masquent un problème plus profond : une vision qui n'aide plus à trancher, ou un désaccord fondamental sur la direction que personne n'osait nommer.
Mettre en pause
Décider d'arrêter certaines initiatives pour protéger la santé du produit.
Cibler l'intervention
Identifier précisément où investir l'énergie de l'équipe pour le prochain cycle.
Ne rien changer
Conclure que la situation actuelle est le meilleur arbitrage possible compte tenu des contraintes, et ne pas collaborer plus loin. C'est une issue valide et assumée.