D'une idée à un problème que l'on peut résoudre

La plupart des idées arrivent formulées comme une solution : « je veux un système qui répond aux clients ». C'est une formulation naturelle, et c'est aussi la principale raison pour laquelle les projets s'enlisent au troisième mois. Une solution sans problème défini est une cible mouvante : chacun autour de la table imagine autre chose, et rien ne permet de trancher un désaccord.

Trois questions qui exigent une réponse écrite

Qui, et à quel moment de la journée. Pas « les clients », mais une conseillère qui ouvre un ticket et passe huit minutes à fouiller des documents. Plus la description est précise, plus il devient clair ce que le système doit faire — et surtout ce qu'il ne doit pas faire.

Quelle est la solution actuelle. Tout problème a déjà une solution, même mauvaise : un tableur, une question dans un groupe, le collègue expérimenté que tout le monde sollicite. C'est votre véritable point de comparaison.

À quoi ressemble le succès chiffré. Temps de traitement, part des demandes closes sans intervention humaine, minutes économisées par semaine. Si aucune mesure ne peut être formulée, l'idée reste une intuition — ce n'est pas grave, mais alors l'étape suivante est d'enquêter, pas de développer.

Un document d'une page

Avant la première ligne de code : la personne et le moment, la solution actuelle et sa faiblesse, la mesure de succès, trois exemples réels d'entrée et de sortie attendue, et la liste de ce qui ne sera pas dans la première version.

Les trois exemples sont l'essentiel : ils transforment un débat abstrait en discussion sur un cas concret. S'ils sont difficiles à écrire, c'est le constat lui-même : il n'y a pas encore d'accord sur ce que le système doit renvoyer.