Tombez amoureux du problème, pas de la solution

Un prototype peut être prêt avant votre premier rendez-vous avec un client. C'est utile. Cela permet aussi de passer une semaine à construire quelque chose que personne n'a demandé.

Le piège, c'est que l'écran fonctionne. Le formulaire envoie les données, le tableau de bord affiche des chiffres et la démonstration convainc. Chaque détail terminé donne une raison de défendre le produit. Il reste à savoir s'il mérite d'exister.

Le livre d'Uri Levine, Fall in love with the problem, not the solution, nomme cette discipline. J'en retiens une règle pratique. Avant de choisir quoi construire, cherchez quel travail une personne essaie de terminer et ce qui l'en empêche.

Demandez à voir le dernier cas

"Utiliseriez-vous un système pour organiser vos commandes ?" est une question confortable. La personne peut répondre oui sans rien changer à ses habitudes.

Je préfère lui demander de montrer la dernière commande difficile à traiter. Quel message est arrivé en premier ? Où a-t-elle noté le prix ? Comment a-t-elle repéré une information manquante ? Combien de temps a-t-elle attendu avant de pouvoir continuer ?

Imaginez un distributeur qui reçoit ses commandes sur WhatsApp et les recopie dans un tableur. La première idée serait de créer un portail. En observant le travail, vous pourriez découvrir que la copie prend peu de temps. Les commandes attendent surtout la validation des remises, confiée à une seule personne.

Dans cet exemple fictif, le portail peut organiser les demandes sans réduire le délai. La file d'attente a changé d'adresse.

Décrivez le problème sans citer de technologie

Une description utile serait "la personne qui traite la commande attend une validation avant de confirmer la livraison". On peut alors chercher qui valide, à quel moment et quelles commandes pourraient avancer seules.

"Il nous faut un agent IA" choisit déjà une réponse. Cela n'explique pas pourquoi une commande reste bloquée.

Avant de dessiner l'interface, notez :

• Qui fait le travail et dans quelle situation.
• Les outils utilisés aujourd'hui, y compris les messages et le papier.
• Les étapes qui imposent une attente ou une reprise.
• Le changement observable qui justifierait un nouveau processus.

Cherchez des exemples récents. Parler du travail d'hier apporte souvent plus qu'une prévision sur ce que quelqu'un ferait l'année prochaine.

Testez le changement dans le travail

Pour le distributeur, un premier essai pourrait porter sur une règle de remise pour les commandes courantes. Pendant une période convenue, une personne applique la règle à la main et relève les exceptions. Aucun logiciel n'est nécessaire pour vérifier si la validation causait le principal retard.

Décidez avant l'essai de ce que vous observerez. Par exemple, réduire le délai entre la réception d'une commande complète et sa confirmation, sans augmenter les corrections ultérieures. C'est une mesure proposée pour le test, pas un résultat promis.

Notez aussi ce qui invaliderait l'idée. Si les commandes restent bloquées par un manque de stock, le diagnostic était incomplet. L'apprendre avant le développement est un résultat utile.

Un prototype devient pertinent lorsqu'il répond à une question précise. L'équipe peut-elle saisir une commande sans aide ? La personne qui valide dispose-t-elle du contexte nécessaire ? Si le test se termine par "c'est joli", il manquait une question.

Distinguez intérêt et engagement

Complimenter une démonstration coûte peu. Réserver du temps pour un pilote, fournir des données adaptées et changer une habitude demandent davantage. Ces engagements indiquent mieux la priorité du problème.

Un pilote accepté ne prouve pourtant pas l'existence d'un marché. Observez l'usage après la première semaine. La personne revient-elle quand vous cessez de la relancer ? À quoi renoncerait-elle pour continuer à utiliser le produit ?

Un problème peut aussi être réel et trop petit pour faire vivre une entreprise. Gagner quelques minutes peut être utile sans justifier un abonnement, un déploiement et un outil supplémentaire à administrer.

Décidez de ce qui vous ferait arrêter

Avant le prochain cycle de développement, écrivez une condition pour continuer et une autre pour arrêter. Partagez-les avec les personnes qui construisent le produit.

Cet accord compte encore davantage quand du code fonctionne déjà. Le temps investi pèse dans la discussion, mais il ne rend pas obligatoire une semaine de travail supplémentaire.

Avant de demander une fonctionnalité de plus, revenez au dernier cas réel. Cherchez ce qui est resté bloqué, qui a dû intervenir et si le changement proposé aurait aidé à ce moment-là. Appuyez la décision sur ce cas.