Produits exceptionnels : Discovery vs. Delivery

La plupart d'entre nous travaillent sur des problèmes assez difficiles et on a généralement besoin de systèmes plutôt complexes pour les résoudre.

De nombreuses équipes font face à deux grands défis :

Tout d'abord, il faut découvrir à quoi devrait ressembler la solution pour le client (Discovery). Cela signifie à la fois déterminer s'il existe vraiment des clients qui ont besoin de cette solution (demande), et trouver une solution qui fonctionne pour les clients et pour ta propre entreprise. Encore plus difficile : trouver une seule solution qui fonctionne pour de nombreux clients et pas seulement pour quelques clients spécifiques. Pour y parvenir, nous devons apprendre rapidement.

Deuxièmement, il faut s'assurer de livrer une implémentation robuste et évolutive sur laquelle nos clients peuvent compter (Delivery). L'équipe devrait avoir confiance dans la Release. Même si on ne peut probablement jamais avoir 100 % de confiance en quelque chose, on ne devrait pas non plus avoir à prier pour que tout se passe bien quand on release quelque chose.

Il faut donc à la fois apprendre rapidement et avoir confiance dans ses releases.

Est-ce que ça peut fonctionner ?

Il est compréhensible que beaucoup de gens pensent que ces deux objectifs différents sont contradictoires. Nous devons essayer de livrer rapidement quelque chose afin de découvrir ce qui fonctionne et ce qui ne fonctionne pas. Cependant, nous ne voulons pas non plus livrer quelque chose qui n'est pas encore abouti, et risquer ainsi de nuire à nos clients et à notre marque.

J'ai discuté avec de nombreuses équipes produit et on m'a souvent interpellé parce que, d'un côté, j'encourage une équipe à livrer plus agressivement et à recueillir les retours des clients, et de l'autre, j'exige d'eux qu'ils ne fassent aucun compromis en matière de fiabilité, de performance et de sécurité du logiciel.

Le Produit Minimum Viable

Pour de nombreuses équipes, le concept d'un Minimum Viable Product (MVP) n'est pas simple. D'un côté, on est motivé à offrir rapidement quelque chose au client et à obtenir du feedback, mais de l'autre, on a vite le sentiment que ce fameux « produit » pourrait être une honte – et comment pourrait-on oser présenter une telle chose au public ?

Apprentissage rapide et releases solides

Je souhaite expliquer ici comment les bonnes équipes peuvent réussir à concilier ces deux objectifs – un apprentissage rapide et des releases solides.

Fondamentalement, je pense que pour la plupart des équipes, le deuxième objectif – livrer un logiciel de qualité – est plus facile à atteindre que d'expérimenter rapidement et d'acquérir de nouvelles connaissances. Le Continuous Delivery, c'est-à-dire la livraison continue, est une bonne méthode que j'ai pu observer chez les équipes qui ont compris l'importance de nombreux petits changements incrémentaux dans un système complexe.

Qu'est-ce qu'un produit au juste ?

La raison de cette confusion est notamment le fait qu'on ne sait souvent pas exactement ce que signifie parler de « produit », de « qualité produit », de « live in production », etc. J'essaie toujours d'utiliser le terme « produit » pour un produit qui est dans un état où il est réellement commercialisable. Il est évolutif et offre une certaine performance. Il dispose d'une solide suite de tests de régression. Il est conçu de manière à pouvoir collecter les analyses nécessaires. Selon les besoins, il a été soit internationalisé, soit localisé. Il est facile à maintenir. Il correspond à la promesse de marque. Et le plus important est le fait que l'équipe peut publier le produit en toute bonne conscience.

Ce n'est pas simple et cela prend la majeure partie du temps de développement. C'est pourquoi nous nous efforçons de ne pas gaspiller tous ces efforts.

Effectuer ces travaux alors que le product manager lui-même n'est pas certain que les clients veulent ou ont besoin de la solution est une recette absolument sûre pour le gaspillage.

La Product Discovery

L'objectif de la Product Discovery est donc de rassembler des preuves que tous les efforts des développeurs pour créer un logiciel de haute qualité ne seront pas vains.

C'est pourquoi il existe tant de techniques différentes pour la Product Discovery. Nous avons des techniques pour mieux comprendre nos utilisateurs et clients, et pour valider nos idées produit de manière qualitative et quantitative. Et la plupart de ces techniques ne prennent même pas de temps aux développeurs (c'est important, car nous savons combien de temps et d'efforts sont nécessaires pour produire une bonne qualité).

Une Product Discovery efficace consiste avant tout à obtenir un accès aux clients, et pas simplement à réaliser nos expériences pour de nouveaux produits le plus rapidement possible.

Si tu es une toute jeune startup sans clients, ce n'est évidemment pas vraiment un sujet (et il est peut-être même trop tôt pour un logiciel de qualité production).

Mais la plupart d'entre nous avons de vrais clients et de vrais revenus, et nous devons donc y réfléchir. J'ai déjà écrit sur les techniques les plus importantes pour expérimenter rapidement et de manière responsable avec la Product Discovery dans les entreprises établies.

Beaucoup de ces techniques consistent à convaincre certains de nos clients ou clients potentiels de tester nos nouvelles idées produit (de quelque manière que ce soit). Un programme de développement client est particulièrement adapté pour cela, car ces personnes se sont portées volontaires pour jouer le rôle de cobaye. Nous pouvons leur parler ou simplement les observer pendant qu'ils essaient nos idées produit, ou encore les laisser tester nos prototypes pendant un moment et voir ce qui en ressort.

Conclusion : Discovery vs. Delivery

Si vous voulez vraiment découvrir des produits exceptionnels, il est extrêmement important de tester vos idées tôt et souvent auprès de vrais utilisateurs et clients. Si vous voulez livrer des produits exceptionnels, vous devriez utiliser les meilleures méthodes de développement et essayer de ne pas ignorer les préoccupations des ingénieurs.

Lorsque nous voulons avancer rapidement et découvrir de nouvelles idées, nous utilisons des méthodes de Discovery et impliquons les clients. Dès que nous avons identifié quelle solution nous devrions développer, nous laissons les développeurs créer un logiciel de qualité production, car ils peuvent alors le livrer avec une conviction totale.

Ce texte est tiré du blog de Marty Cagan et a été traduit par nos soins.