Cinq temps, et ce qu'on décide à chacun.

J'écris trois choses avant tout le reste : le problème tel que l'utilisateur le vit, ce qu'on cherche à obtenir, et comment on saura qu'on l'a obtenu. Tant que la troisième ligne est vide, le sujet n'entre pas en sprint — et je le dis, même quand la demande vient du dirigeant.

C'est la conversation la plus inconfortable du cycle et celle qui économise le plus de jours-homme. Une équipe qui construit sans critère de réussite ne peut ni réussir, ni s'arrêter.

Marché, concurrence, entretiens utilisateurs, enregistrements de session, tickets support, données existantes. Je ne cherche pas à confirmer l'idée : je cherche ce qui l'invalide, tant que ça coûte encore une semaine et pas un trimestre.

Les tickets support sont ma source préférée. Ils ne coûtent rien, ils existent déjà, et ils disent exactement où le produit oblige les gens à demander de l'aide. Sur un projet SaaS, trente et un tickets hebdomadaires portaient sur la même question : c'était un problème de vocabulaire, pas de fonctionnalité.

Trois critères, écrits avant de connaître les candidats — sinon ce n'est plus un critère, c'est une justification. L'impact estimé sur la métrique de la période. L'effort, tel que l'équipe l'estime elle-même et non tel que je l'espère. Le coût du retard : ce qu'on perd chaque semaine à ne pas le faire.

Le troisième est le plus discriminant et le plus souvent oublié. C'est lui qui départage deux options d'égale valeur, et c'est le seul argument qui fonctionne devant une direction : il transforme une préférence en calcul.

Une roadmap sert autant à refuser qu'à promettre. Je tiens la liste des options écartées avec le motif du refus — elle vaut autant que la liste de ce qu'on fait, et elle évite de rouvrir six fois la même discussion.

J'arrive avec un problème cadré, pas avec une solution. Un PM qui apporte la maquette toute faite obtient de l'exécution ; il n'obtient jamais d'engagement, et il se prive de la meilleure idée de la pièce.

Concrètement : les critères d'acceptation s'écrivent avec l'équipe, pas avant elle. L'instrumentation est prévue avant la mise en production — une fonctionnalité qu'on ne peut pas mesurer n'est pas terminée. Et je protège le temps de recherche du designer devant la direction, parce que c'est mon travail, pas le sien.

Je code du front-end. Cela ne me sert plus à produire : cela me sert à comprendre une estimation, à en discuter sans arrogance, et à savoir quand « c'est compliqué » veut dire « c'est cher » ou « je n'ai pas envie ». La différence compte.

Relevé à trente, soixante et quatre-vingt-dix jours. Ce que je porte devant un comité, ce n'est pas ce qu'on a livré : c'est ce qui a bougé, y compris quand rien n'a bougé. Quand mon avis et les données s'opposent, les données gagnent — y compris quand la version que je préfère perd le test.

Chaque cycle se termine par une revue d'apprentissage écrite : ce qui a marché, ce qui n'a pas marché, et ce qu'on en retire pour la décision suivante. C'est la seule partie du processus que je refuse de sauter, parce que c'est la seule qui compose dans le temps.