On a livré une feature en 24h - pas parce qu'on a rushé

On a livré une feature en 24h sur une marketplace client. 24h.

Pas parce qu'on a rushé. Parce qu'on a résisté à l'envie d'en faire trop.

Le contexte : une marketplace qui existe et tourne depuis plusieurs mois. Pas question de tout chambouler pour tester un nouvel angle. Le produit a ses utilisateurs, ses workflows, sa stabilité - c'est le résultat de mois de travail. On ne touche pas à ça à la légère.

L'idée qu'on voulait tester : permettre aux marques de trouver des animateurs de live shopping directement depuis la plateforme.

Le réflexe classique qu'on a évité

Le réflexe classique aurait été de spécifier la feature "proprement" : système de matching algorithmic, profils détaillés avec portfolio, système de notation, messagerie intégrée, filtres avancés par niche et disponibilité, calendrier de réservation...

On a livré aucune de ces choses.

On a posé une brique. La plus petite possible pour que le besoin soit testable en conditions réelles.

Parce que sur un produit qui existe déjà, le pire truc que tu puisses faire c'est casser ce qui marche pour valider ce qui est encore incertain.

Ce que "MVP d'une feature" signifie vraiment

Un MVP de feature, ce n'est pas une version au rabais. C'est un pari minimum sur ce que les utilisateurs vont réellement utiliser.

La différence est importante. Une version au rabais, c'est une feature complète mais mal faite. Un MVP, c'est une question posée à la réalité : est-ce que ce besoin existe vraiment, et sous quelle forme ?

Dans ce cas précis, la question était simple : les marques présentes sur la plateforme ont-elles un vrai besoin de trouver des animateurs live ? Si oui, comment s'y prennent-elles naturellement ?

On ne peut pas répondre à cette question avec des specs. On peut y répondre avec 24h de développement et quelques semaines d'observation.

Trois principes qu'on a appliqués

1. Isoler la brique, ne pas refondre l'existant

Le live shopping est un nouvel angle d'attaque sur une marketplace qui tourne. Ça ne justifie pas de réarchitecturer quoi que ce soit. On greffe proprement sur ce qui existe, on observe le comportement.

Techniquement, ça veut dire : pas de nouveau modèle de données complexe, pas de nouveaux services, pas de nouvelle logique transversale. Une surface minimale, connectée à l'existant, déployable sans risque pour le reste.

Le live shopping ne doit pas menacer la marketplace. Il doit y coexister discrètement jusqu'à ce qu'on sache s'il mérite plus d'attention.

2. Livrer pour apprendre, pas pour impressionner

Les retours terrain dans les prochaines semaines valent plus que trois mois de specs.

On ne sait pas encore comment les marques vont s'approprier la feature. Est-ce qu'elles vont chercher des animateurs par type de contenu ? Par audience ? Par disponibilité ? Par tarif ? Par expérience métier ?

On a des hypothèses. Mais les utilisateurs ont rarement le comportement qu'on anticipe. C'est exactement pour ça que la feature est en production maintenant plutôt que dans trois mois après une phase de design exhaustive.

La prod est le seul environnement où ces questions trouvent une vraie réponse.

3. L'itération n'est pas un aveu d'échec

C'est le plan depuis le début.

La v1 n'est pas incomplète - elle est honnête sur ce qu'on sait à ce stade. La prochaine version de cette feature sera écrite par les utilisateurs, pas par l'équipe produit. Les patterns d'usage, les frictions, les workarounds que les marques vont inventer - c'est ça qui dessine la v2.

Une feature pensée en silo pendant trois mois, c'est trois mois de paris sur le comportement utilisateur. Une feature livrée en 24h et observée pendant trois mois, c'est trois mois de données réelles.

Pourquoi c'est plus difficile qu'il n'y paraît

Résister à l'envie d'en faire trop demande une discipline réelle, côté technique comme côté produit.

Côté produit : accepter de livrer quelque chose qui ne correspond pas à la vision complète. C'est inconfortable. On a envie que la feature soit "propre", "complète", "impressionnante". Livrer une brique minimale, c'est s'exposer à l'impression d'avoir fait un travail à moitié.

Côté technique : définir ce qui constitue "la brique minimale" sans compromettre la qualité du code. Un MVP mal architecturé devient rapidement un frein aux itérations suivantes. La contrainte de temps ne justifie pas la dette technique - elle demande des choix plus précis, pas des raccourcis.

La 24h dont je parle, c'est 24h de développement concentré, pas 24h d'improvisation. La feature est propre, testable, et extensible. Elle est juste petite.

Ce que j'applique systématiquement sur ce type de mission

Quand j'interviens en tant que CTO sur un produit existant qui veut tester un nouvel angle, la question de départ est toujours la même : quelle est la brique la plus petite qui permet de valider l'hypothèse centrale ?

Pas la feature complète. Pas la feature "correcte". La brique qui répond à la question.

C'est ça, la vraie discipline du product management sur un produit en production : protéger ce qui marche, tester ce qui est incertain, et ne pas confondre les deux.