Ai-je vraiment « terminé » ?

C’est sur cette notion sur laquelle Kniberg nous invite à nous pencher en premier. Quand est-on « done » ?

• Quand le code est commité ?
• Quand le produit est testé ?
• Quand il est déployé en production ?

Dans ce cheminement, c’est l’utilisateur qui est perdu de vue. Même le déploiement en production ne suffit pas, ni même son utilisation par de véritables utilisateurs ? Car à ce niveau qu’est-il vraiment advenu ? Comment le savons-nous ? Le 0% defect peut-être plus qu’une douce illusion : un manque de feedback ! Ce qu’il nous faut, c’est mesurer la pertinence de notre solution.

Où l’on reparle de valeur

La valeur de la solution que nous fournissons à nos utilisateurs n’est pas une mesure absolue, mais la différence par rapport à l’ancienne solution. La valeur n’est d’ailleurs pas la seule valeur, la souffrance soulagée en est une tout assi pertinente. Et Kniberg nous propose de rapprocher ce niveau de souffrance au niveau de gain : est-il positif ? C’est l’ensemble du tableau qu’il faut regarder.

Pour le prouver, nous avons aussi besoin de mesures. Par exemple, les recommandations, qui montrent que le produit est désirable et non que l’on est coincé avec.

Un produit commence avec une grande idée

Mais au-delà de cette idée, ou plutôt en chemin, nous avons toute sorte de risques.

• Des risques techniques : avons-nous la technologie pour réaliser notre produit, la maîtrisons-nous ?
• Des risques sociaux : pourrons-nous faire travailler ces personnes ensemble.
• Des risques de coût et de planification : pourrons-nous sortir le produire à temps et aurons-nous les fonds pour le faire ?
• Mais surtout, surtout : des risques business ! Notre produit doit être pertinent, donc désirable.

Henrik Kniberg nous rappelle ainsi 3 exemples de produits qui ont échoué à l’épreuve de la pertinence, pourtant tous issus de Google !

Suis-je en train de construire le mauvais produit ? C’est là la question clé à laquelle le Lean Startup nous invite à répondre afin de vérifier nos hypothèses par le biais de MVP et d’expérimentations.

C’est l’exemple de Dropbox que j’utilise moi-même souvent (et cité dans le livre d’Eric Ries que Kniberg reprend : ici le MVP est une vidéo ! Une vidéo totalement « fake » bien sûr, mais qui a permis de tester le marché à pas cher !

Une technique alternative est le « paper prototyping ».

De l’idée à la mesure

La « pirate metric ». Pourquoi « pirate », car le cri du pirate à l’abordage, c’est AARRR !!

• Acquisition : Les clients viennent-ils ?
• Activation : Utilisent-ils le produit
• Rétention : Reviennent-ils ?
• Référent : Nous recommandent-ils à leurs semblables ?
• Revenu : Paient-ils ?

Le tout en forme de « funnel ».

Après le big bang

Par rapport à ceci, le big bang apparait une approche très risquée : on accumule les coûts en différent l’acquisition de valeur (si jamais elle arrive). Le chaos manifesto 2013 nous explique même que limiter la taille et la complexité est le principal facteur clé de succès. Autant pour ceux qui clament qu’il faut faire de l’agilité à plus grande échelle… Pensez plutôt à descaler, à faire de plus petites choses, de plus petits projets… ou de petites releases. Petites releases qui signifient déploiement en production réellement aisé.

A contrario, l’approche « big bang » nous conduit à faire de grosses releases, donc des releases difficiles. Et comme celles-ci sont difficiles, on s’efforcera d’en faire le moins souvent possible… Pour sortir de ce cercle vicieux, il faut faire de la release une routine. Comme on l’a fait il y a 15 ans pour l’intégration

Si quelque chose est difficile, faites-le souvent.

Où l’on (re)parle de la rapidité d’apprentissage

Déployer plus souvent, c’est avoir un feedback plus rapide de ses utilisateurs : c’est apprendre plus rapidement ! Apprendre plus rapidement cous permet de délivrer ce qui a le plus de valeur en premier, et ainsi de « dépasser la courbe d’investissement » tôt dans le cycle, et ceci en sélectionnant nos fonctionnalités de manière plus pertinente.

Nous le savions déjà, ce n’est pas l’occupation que nous devons optimiser, ni même « l’output », ce que nous délivrons, non c’est la valeur que nous délivrons que nous devons optimiser. Et cela ne peut se faire qu’en apprenant de nos utilisateurs. Henrik Kniberg trouve une manière très élégante d’exprimer cela :

Être focalisé sur la réduction de la distance plutôt que sur l’augmentation de la vitesse.

Spotify again

C’est avec Spotify, bien sûr, que l’orateur choisit d’illustrer tout son fil conducteur.

On part d’une idée. C’est le « think it » de Spotify. Pour toucher terre, il faut l’associer à un « narrative » et déterminer les métriques qui nous guideront.

Le « build it » qui suit s’inspire directement du Lean Startup, car c’est d’un MVP qu’il est question.

Le « ship it » met ce MVP entre les mains de l’utilisateur, pour en recueillir le feedback et en tirer les enseignements. On passe du « guessing » aux enseignements.

De ces enseignements, on tire les ajustements ou les changements de direction à opérer. C’est le « tweak it ».

Plus que savoir, c’est s’assurer que le produit fonctionne : en comprenant le problème, en apprenant de nos utilisateurs. Puis en itérant jusqu’à ce que le problème soit résolu.