Je trouve que la vidéo fait l'impasse sur deux points essentiels du livre : les notions d'hypothèses de valeur et d'hypothèses de croissance, et l'importance de se fier aux bons indicateurs, liés justement à ces hypothèses. En fait, j'ai plus l'impression (pas complètement, mais un peu tout de même) que cette vidéo est drivé par Lean UX que par Lean Startup. Mais une bonne entrée en matière quand même. :)
Bonjour Jean-Pierre, Comme toujours, excellente vidéo. À mon humble avis, un MVP qui prend 6 mois pour être développé est symptomatique de quelque chose. Je ne dis pas que les décideurs sont forcément dans l'erreur, juste qu'ils devraient se poser les bonnes questions quant au produit en question et les investisseurs devraient à minima avoir conscience du risque. Car oui, plus on attend, plus le risque est élevé, et comme tu le souligne si bien: là, il ne s'agit plus d'être sûr de soi, mais bel et bien de mesurer un risque et de prendre la bonne décision au bon moment en fonction celui-ci.
Le "pivot" est très intéressant. Je ne connaissais pas ce terme, mais l'idée est très intéressante. J'ai l'impression qu'à certains endroits, on préfère se dire : "j'ai investi de l'argent, tant pis, je persévère plutôt que de perdre ce que j'ai investi". Alors oui, peut-être que ça paiera. Mais il y a également le risque d'investir encore plus, sans que le produit n'intéresse plus. En gros, on perd encore plus. Donc à un moment, il faut savoir dire "stop" et ne plus faire de frais. Mais comment éviter d'arriver dans cette situation où "j'ai déjà investi beaucoup, donc je ne veux pas perdre ce que j'ai investi" ? J'ai l'impression de dérouler la vidéo à l'envers, mais là encore, la notion d'un test très simple et à moindre coût (quitte à n'avoir qu'un bout de la chaîne pour simplement vérifier l'attrait par exemple) est très intéressante. A titre d'exemple, avec mon équipe, nous travaillons actuellement sur des APIs. Nous avons constaté que les performances n'étaient pas vraiment au RDV. Ils ont donc fait un premier travail de réécriture qui, nous l'espérions, nous permettrait de gagner 50-75% de temps de traitement. Nous sommes allés au bout (en 3 semaines) et nous n'avons constaté qu'un gain de 7%... Pas top... Si nous l'avions su plus tôt, peut-être que nous n'aurions pas insisté dans cette voie. Puis une autre idée est apparue et nous avons décidé de la tester également. Seulement cette fois-ci, nous avons décidé de ne faire un test que sur un sous-ensemble et en 1 semaine, nous avons constaté un gain d'environ 75-90%... Donc là on a pensé qu'on pouvait y aller vraiment ! Dans notre cas, il ne s'agit pas vraiment d'un test A/B en production. Mais j'ai le sentiment que l'esprit du test, même partiel, est tout de même présent et nous nous sommes bien rendus compte (moi en tout cas) lors de cette expérience, qu'avoir un retour au plus tôt pour confirmer la bonne direction était plus important que d'atteindre l'objectif qu'on s'est fixé, en pensant que c'était le bon...
Bonjour, super vidéo au passage ! Même si je trouve que le Lean Startup reste une notion qui me semble encore abstraite (peut-être est-ce lié au fait que je n'ai pas [encore] connu le monde des startups (^_^)). Hypothèses, expérimentation... Ça reprend beaucoup les étapes de la démarche scientifique, je trouve. N'est-ce pas finalement du "bon sens" revisité, mais appliqué au développement d'un produit ? D'ailleurs, j'ai remarqué que le Lean Startup, tel que décrit dans la vidéo, se concentre beaucoup sur le produit à développer, quand est-il de l'organisation ? Concernant le MVP, cela me fait penser à la boite où je travaille (une PME) qui se retrouvait dans la situation décrite à 7:32 (th-cam.com/video/gzbZoy8IYw0/w-d-xo.html) où l'équipe R&D devait réfléchir à la réécriture complète de l'application (à cause des problèmes de mise à l'échelle et de maintenance) et voulait utiliser "l'approche MVP" (sic). Et pourtant, le produit existant, avait tout de même une base solide d'utilisateurs.rices, et ceux, malgré la forte concurrence. Il y avait aussi une autre entreprise (une grosse structure) dans laquelle j'ai travaillé, qui parlait aussi de MVP, mais dans un projet d'automatisation de tests fonctionnels qui était plus à une étapes de "bêta". Dans les deux cas, elles considéraient que le MVP était une version ± v1.0. J'ai tout de même une question sur le MVP : - Peut-on quand même considérer un prototype ou une Preuve de concept (POC: Proff of Concept) comme un MVP ? Merci,
Le Lean Startup n'est pas réservé aux startups, c'est d'ailleurs tout l'enjeu de "l'intraprenariat" que développent les grosses entreprises. Ce sujet est d'ailleurs abordé par Eric Ries dans le livre. Concernant les changements sur l'organisation, là aussi Eric Ries en parle dans son livre. Je te rejoins sur le fait que la majorité des entreprises et équipes se sont appropriées le concept de MVP pour en faire autre chose... Et finalement cela va même encore plus loin : c'est même fondamentalement le développement incrémental et itératif qui est difficile à mettre en place. On a beaucoup de mal à voir comment s'en sortir sans tout faire ! Quand à un POC, on peut tout à faire le considérer comme un MVP : on formule une hypothèse sur notre capacité à utiliser telle ou telle techno, ou à implémenter telle fonctionnalité, ou à intégrer deux produits ensemble, etc. et on va faire un POC pour valider ou invalider cette hypothèse. Après, tout est question du volume d'effort qu'on met dedans et de jusqu'à quel point on oriente ce POC pour bien le focaliser sur cette validation d'hypothèse, et non pas pour construire les bases du développement.
La difficulte principale a cette approche, si l'on n'est pas en startup justement, c'est de convaincre "l'entreprise" a une mise en production precoce, et a eduquer cette resilience au changement grace aux feedbacks des usagers. Le modele waterfall a encore la main mise sur certains aspects, et la crainte du "flop" si l'on publie un produit pas assez abouti est omnipresente. Quels conseils pour reussir a amener ce mindset different ? Pour la portion de "on jete le code", dans certains cas de figures je pense interessants de garder des composantes, car elles ne repondent peut etre pas aux besoins presents, mais elles peuvent etre recyclees pour d'autres usages, qui viendraient dans le futur. Et cela aide a gerer le sentiment "d'avoir travaille pour rien" des developpeurs, pour qui du code qu'on jette est parfois source de frustration et de demotivation. Est-ce que cette notion de "recyclage", de "librairie de fonctionnalites" qui sont desactivees reste coherente ?
J'ai un a priori très négatif sur la pertinence de garder le code de l'expérience ratée. Globalement il faut viser la solution la plus simple possible et la base de code la plus petite possible : jeter du code devrait donc être vu comme la meilleure activité par excellence. Même inactif, il faudra maintenir ce code ce qui prendra du temps et de l'effort, sans parler des tests automatiques qui rallongent l'exécution de l'intégration continue, ou de la complexité induite du code rajouté par ces cas en plus et qui rendent l'ensemble de la base de code plus longue à prendre en main et plus dure à maintenir. J'irais même encore plus loin pour évoquer ce que j'ai pu vivre : d'expérience, quand on garde comme ça des "fonctionnalités inutilisées" pendant quelques temps, et que finalement on en a besoin quelques années plus tard... Et bien elles ne fonctionnent plus (car le reste du produit a évolué autour) et qui plus est cela ne correspond pas vraiment à ce que l'on cherche (car les besoins évoluent toujours). Quoi qu'il arrive, on se retrouve à le refaire, alors qu'on a quand même payé une taxe entre temps à l'avoir gardé (code en plus, complexité induite plus élevée...). Ils auraient donc fait mieux de virer tout ça dès le début... ! Et au pire du pire, si on veut retrouver le code qu'on avait écrit pour le reprendre ou du moins s'en inspirer, on peut toujours fouiller dans l'historique du logiciel de gestion de version.
Oui l'idée lean startup est de tester ses hypothèses par tous les moyens possibles (petites annonces, maquettes...) ! Cependant la notion de mvp est plus large que ce que vous décrivez. En effet un mvp doit être "viable" donc rapporter de l'argent comme le dit en entretien Éric ries : "The minimum viable product is that product which has just those features and no more that allows you to ship a product that early adopters see and, at least some of whom resonate with, pay you money for, and start to gave you feedback on." Cf venturehacks.com/articles/minimum-viable-product
Je ne suis pas sûr que cela soit contradictoire avec l'interprétation que je donne, mais vous avez raison, j'aurais peut être dû utiliser d'autres mots. Merci beaucoup pour ces compléments d'information.
Bonjour, je suis d'accord avec Julien, le MVP c'est pas juste une petite fonctionnalité mais un produit viable. Ce que tu expliques Jean-Pierre est plus pour une nouvelle fonctionnalité que tu veux tester auprès de tes utilisateurs qu'un produit, non ?
Votre présentation s'agit elle d'un vrai produit (d'une information de qualité) ou d'un MVP et donc d'une information d'évaluation de l'une de vos hypothèses, par exemple le niveau d'intérêt au sujet. :). hhh. merci pour ces clarifications.
On itère toujours ! On a reparlé de Lean Startup dans cette vidéo d'ailleurs récemment, tu l'as vu ? => th-cam.com/video/VEWiJniocDg/w-d-xo.html -- Constantin
Découvrez toute la communauté Scrum Life ! 👉 sl.run/oUq955
Je trouve que la vidéo fait l'impasse sur deux points essentiels du livre : les notions d'hypothèses de valeur et d'hypothèses de croissance, et l'importance de se fier aux bons indicateurs, liés justement à ces hypothèses. En fait, j'ai plus l'impression (pas complètement, mais un peu tout de même) que cette vidéo est drivé par Lean UX que par Lean Startup. Mais une bonne entrée en matière quand même. :)
C'est possible ! Merci des compléments.
Le MVP ! Ca alors. En voilà une info surprenante.
Merci pour cet épisode très intéressant (un de plus).
Bonjour Jean-Pierre,
Comme toujours, excellente vidéo.
À mon humble avis, un MVP qui prend 6 mois pour être développé est symptomatique de quelque chose. Je ne dis pas que les décideurs sont forcément dans l'erreur, juste qu'ils devraient se poser les bonnes questions quant au produit en question et les investisseurs devraient à minima avoir conscience du risque.
Car oui, plus on attend, plus le risque est élevé, et comme tu le souligne si bien: là, il ne s'agit plus d'être sûr de soi, mais bel et bien de mesurer un risque et de prendre la bonne décision au bon moment en fonction celui-ci.
Le "pivot" est très intéressant. Je ne connaissais pas ce terme, mais l'idée est très intéressante.
J'ai l'impression qu'à certains endroits, on préfère se dire : "j'ai investi de l'argent, tant pis, je persévère plutôt que de perdre ce que j'ai investi". Alors oui, peut-être que ça paiera. Mais il y a également le risque d'investir encore plus, sans que le produit n'intéresse plus. En gros, on perd encore plus. Donc à un moment, il faut savoir dire "stop" et ne plus faire de frais.
Mais comment éviter d'arriver dans cette situation où "j'ai déjà investi beaucoup, donc je ne veux pas perdre ce que j'ai investi" ?
J'ai l'impression de dérouler la vidéo à l'envers, mais là encore, la notion d'un test très simple et à moindre coût (quitte à n'avoir qu'un bout de la chaîne pour simplement vérifier l'attrait par exemple) est très intéressante.
A titre d'exemple, avec mon équipe, nous travaillons actuellement sur des APIs. Nous avons constaté que les performances n'étaient pas vraiment au RDV. Ils ont donc fait un premier travail de réécriture qui, nous l'espérions, nous permettrait de gagner 50-75% de temps de traitement. Nous sommes allés au bout (en 3 semaines) et nous n'avons constaté qu'un gain de 7%... Pas top... Si nous l'avions su plus tôt, peut-être que nous n'aurions pas insisté dans cette voie.
Puis une autre idée est apparue et nous avons décidé de la tester également. Seulement cette fois-ci, nous avons décidé de ne faire un test que sur un sous-ensemble et en 1 semaine, nous avons constaté un gain d'environ 75-90%... Donc là on a pensé qu'on pouvait y aller vraiment !
Dans notre cas, il ne s'agit pas vraiment d'un test A/B en production. Mais j'ai le sentiment que l'esprit du test, même partiel, est tout de même présent et nous nous sommes bien rendus compte (moi en tout cas) lors de cette expérience, qu'avoir un retour au plus tôt pour confirmer la bonne direction était plus important que d'atteindre l'objectif qu'on s'est fixé, en pensant que c'était le bon...
Une vraie petite pépite.
Très intéressant. J'ai lu les deux livres, aussi le modèle startup.
Est-ce qu'on dit des bêtises ? Qu'ajouterais-tu à la vidéo ?
Bonjour, super vidéo au passage !
Même si je trouve que le Lean Startup reste une notion qui me semble encore abstraite (peut-être est-ce lié au fait que je n'ai pas [encore] connu le monde des startups (^_^)).
Hypothèses, expérimentation... Ça reprend beaucoup les étapes de la démarche scientifique, je trouve. N'est-ce pas finalement du "bon sens" revisité, mais appliqué au développement d'un produit ?
D'ailleurs, j'ai remarqué que le Lean Startup, tel que décrit dans la vidéo, se concentre beaucoup sur le produit à développer, quand est-il de l'organisation ?
Concernant le MVP, cela me fait penser à la boite où je travaille (une PME) qui se retrouvait dans la situation décrite à 7:32 (th-cam.com/video/gzbZoy8IYw0/w-d-xo.html) où l'équipe R&D devait réfléchir à la réécriture complète de l'application (à cause des problèmes de mise à l'échelle et de maintenance) et voulait utiliser "l'approche MVP" (sic). Et pourtant, le produit existant, avait tout de même une base solide d'utilisateurs.rices, et ceux, malgré la forte concurrence.
Il y avait aussi une autre entreprise (une grosse structure) dans laquelle j'ai travaillé, qui parlait aussi de MVP, mais dans un projet d'automatisation de tests fonctionnels qui était plus à une étapes de "bêta".
Dans les deux cas, elles considéraient que le MVP était une version ± v1.0.
J'ai tout de même une question sur le MVP :
- Peut-on quand même considérer un prototype ou une Preuve de concept (POC: Proff of Concept) comme un MVP ?
Merci,
Le Lean Startup n'est pas réservé aux startups, c'est d'ailleurs tout l'enjeu de "l'intraprenariat" que développent les grosses entreprises. Ce sujet est d'ailleurs abordé par Eric Ries dans le livre.
Concernant les changements sur l'organisation, là aussi Eric Ries en parle dans son livre.
Je te rejoins sur le fait que la majorité des entreprises et équipes se sont appropriées le concept de MVP pour en faire autre chose... Et finalement cela va même encore plus loin : c'est même fondamentalement le développement incrémental et itératif qui est difficile à mettre en place. On a beaucoup de mal à voir comment s'en sortir sans tout faire !
Quand à un POC, on peut tout à faire le considérer comme un MVP : on formule une hypothèse sur notre capacité à utiliser telle ou telle techno, ou à implémenter telle fonctionnalité, ou à intégrer deux produits ensemble, etc. et on va faire un POC pour valider ou invalider cette hypothèse. Après, tout est question du volume d'effort qu'on met dedans et de jusqu'à quel point on oriente ce POC pour bien le focaliser sur cette validation d'hypothèse, et non pas pour construire les bases du développement.
La difficulte principale a cette approche, si l'on n'est pas en startup justement, c'est de convaincre "l'entreprise" a une mise en production precoce, et a eduquer cette resilience au changement grace aux feedbacks des usagers. Le modele waterfall a encore la main mise sur certains aspects, et la crainte du "flop" si l'on publie un produit pas assez abouti est omnipresente. Quels conseils pour reussir a amener ce mindset different ?
Pour la portion de "on jete le code", dans certains cas de figures je pense interessants de garder des composantes, car elles ne repondent peut etre pas aux besoins presents, mais elles peuvent etre recyclees pour d'autres usages, qui viendraient dans le futur. Et cela aide a gerer le sentiment "d'avoir travaille pour rien" des developpeurs, pour qui du code qu'on jette est parfois source de frustration et de demotivation. Est-ce que cette notion de "recyclage", de "librairie de fonctionnalites" qui sont desactivees reste coherente ?
J'ai un a priori très négatif sur la pertinence de garder le code de l'expérience ratée. Globalement il faut viser la solution la plus simple possible et la base de code la plus petite possible : jeter du code devrait donc être vu comme la meilleure activité par excellence. Même inactif, il faudra maintenir ce code ce qui prendra du temps et de l'effort, sans parler des tests automatiques qui rallongent l'exécution de l'intégration continue, ou de la complexité induite du code rajouté par ces cas en plus et qui rendent l'ensemble de la base de code plus longue à prendre en main et plus dure à maintenir.
J'irais même encore plus loin pour évoquer ce que j'ai pu vivre : d'expérience, quand on garde comme ça des "fonctionnalités inutilisées" pendant quelques temps, et que finalement on en a besoin quelques années plus tard... Et bien elles ne fonctionnent plus (car le reste du produit a évolué autour) et qui plus est cela ne correspond pas vraiment à ce que l'on cherche (car les besoins évoluent toujours). Quoi qu'il arrive, on se retrouve à le refaire, alors qu'on a quand même payé une taxe entre temps à l'avoir gardé (code en plus, complexité induite plus élevée...). Ils auraient donc fait mieux de virer tout ça dès le début... !
Et au pire du pire, si on veut retrouver le code qu'on avait écrit pour le reprendre ou du moins s'en inspirer, on peut toujours fouiller dans l'historique du logiciel de gestion de version.
Oui l'idée lean startup est de tester ses hypothèses par tous les moyens possibles (petites annonces, maquettes...) ! Cependant la notion de mvp est plus large que ce que vous décrivez. En effet un mvp doit être "viable" donc rapporter de l'argent comme le dit en entretien Éric ries : "The minimum viable product is that product which has just those features and no more that allows you to ship a product that early adopters see and, at least some of whom resonate with, pay you money for, and start to gave you feedback on."
Cf venturehacks.com/articles/minimum-viable-product
Je ne suis pas sûr que cela soit contradictoire avec l'interprétation que je donne, mais vous avez raison, j'aurais peut être dû utiliser d'autres mots. Merci beaucoup pour ces compléments d'information.
Bonjour, je suis d'accord avec Julien, le MVP c'est pas juste une petite fonctionnalité mais un produit viable. Ce que tu expliques Jean-Pierre est plus pour une nouvelle fonctionnalité que tu veux tester auprès de tes utilisateurs qu'un produit, non ?
Votre présentation s'agit elle d'un vrai produit (d'une information de qualité) ou d'un MVP et donc d'une information d'évaluation de l'une de vos hypothèses, par exemple le niveau d'intérêt au sujet. :). hhh. merci pour ces clarifications.
On itère toujours ! On a reparlé de Lean Startup dans cette vidéo d'ailleurs récemment, tu l'as vu ? => th-cam.com/video/VEWiJniocDg/w-d-xo.html
-- Constantin