Cet article est une traduction du podcast « Experimentation is Product Management » publié sur le site « This is Product Management » le 4 Avril 2015.
Les phrases ont parfois été éditées (raccourcies/reformulées) pour plus de lisibilité.
Livres mentionnés
Value Proposition Design par Alexander Osterwalder
Lean Startup par Eric Ries
Mike Fishbein – Dans cet épisode, nous parlerons d’un des sujets les plus brûlants de la gestion de produit aujourd’hui, l’expérimentation. Je vais discuter avec Tristan Kromer de GrasshopperHerder. C’est un célèbre consultant et je suis très intéressé de connaître son avis sur ce que l’expérimentation peut apporter aux chefs de produit mais également de comprendre quelles sont ses limites. Lisez la suite pour le découvrir.
Tristan Kromer – Je m’appelle Tristan Kromer. Je suis coach de la méthode Lean. Je passe environ soixante à soixante-dix pour cent de mon temps à travailler avec des organisations d’à peu près toutes les tailles mais généralement des entreprises privées ou publiques, cherchant à augmenter l’innovation au sein de leur écosystème.
Je donne environ trente-quarante pour cent de mon temps en tant que bénévole pour le Lean Startup Circle une organisation communautaire qui mène le concept de tutorat entre pairs au sein des communautés de la Lean Startup. Nous intervenons dans quatre-vingt villes dans le monde voire plus. Notre objectif est d’échanger des informations, des connaissances entre praticiens du Lean Startup. Nous apprenons donc des gens qui effectuent des expérimentations à Tokyo, au Pakistan, à Moscou. Nous recueillons ces histoires et nous nous assurons en tant qu’entrepreneurs d’avoir accès aux meilleurs outils, conseils et astuces du monde entier pour que les gens en apprennent de plus en plus sur ce type de méthodologies encore nouvelles d’expérimentation et de développement par hypothèse.
L’expérimentation est à mi-chemin de la méthode scientifique vers laquelle nous tendons. Mais c’est en quelque sorte un peu une illusion de la gestion de produit. A l’heure actuelle, je pense que la gestion de produit c’est vraiment de l’expérimentation c’est à dire que votre métier en tant que chef de produit est d’expérimenter votre voie vers le succès, d’interpréter les indicateurs pour comprendre ce qui est le plus important pour votre produit et d’essayer ensuite, désespérément, de les influencer de toutes les façons possibles.
Il y a une certitude légèrement gênante lorsque les gens emploient le mot expérimentation qui voudrait que le résultat soit toujours vrai ou faux. Et ce n’est pas très scientifique. Je pense qu’il y a un peu trop de fausses certitudes autour de ce terme en gestion de produit.
Mike Fishbein – Tristan fait une affirmation directe. L’expérimentation n’est qu’à mi chemin de la méthode scientifique. Tristan aborde un point intéressant en disant que les résultats des expérimentations ne sont pas noirs ou blancs. Ils peuvent renseigner un autre cycle d’expérimentations mais ne résoudront pas toutes les questions de gestion de produit à partir de rien. Je souhaite qu’il nous parle de son expérience avant de se plonger plus profondément dans tout cela.
Tristan Kromer – J’ai passé la première partie de ma carrière dans l’industrie de la musique, dix ans en tant que musicien, producteur, commercial, comme quelqu’un essayant désespérément de gagner sa vie en produisant des types variés de contenus créatifs.
De là j’ai suivi la voie du marketing vers la sécurité informatique ce qui était un changement singulier mais remarquablement similaire de bien des manières. J’ai poursuivi mon chemin du marketing à la gestion de produit puis à la gestion d’une unité opérationnelle et à l’exploitation.
J’ ai passé cinq ans à l’étranger à travailler pour des entreprises de sécurité informatique au Vietnam, en Allemagne, en Suisse, à Taïwan. Et je suis retourné aux Etats-Unis où je me suis impliqué dans le mouvement des startups et le mouvement du Lean Startup au début de la crise financière et depuis j’en suis amoureux.
Cela m’a en quelque sorte plus rapproché de mes racines de l’industrie de la musique avec toutes ces rock stars déjantées qui courent dans tous les sens en essayant de créer des choses ridicules que les gens peuvent parfois vouloir mais auxquelles les gens n’accordent parfois aucun intérêt.
Mike Fishbein – Tristan a donc emprunté un chemin détourné vers la gestion de produit, chemin vu comme une accumulation d’expériences qui, d’une manière ou d’une autre, mènent à construire des produits. Plus tôt, nous avons parlé du fait que l’expérimentation tient plus de la navigation. Je me demande ce qu’il entendait par là. Quelles sont les limites des données? Puis-je demander non seulement quoi et comment mais aussi pourquoi?
Tristan Kromer –Le débat qui oppose le qualitatif au quantitatif est un faux débat. Ce qui est vraiment important c’est de déterminer quelle est la bonne question à se poser, que cherchons-nous réellement à apprendre? Et en se basant sur ce que nous cherchons à apprendre, il y a une variété de méthodes différentes d’expérimentation que nous pouvons exploiter.
Certaines sont quantitatives, certaines sont qualitatives. Mais essayer de dire que le qualitatif est toujours meilleur ou que le quantitatif est toujours meilleur est une erreur. Le qualitatif vous apporte un type différent d’information. Parfois vous n’avez pas d’information quantitatives. Et si vous restez focalisé sur l’idée que le quantitatif est toujours meilleur, que vous devriez toujours avoir des données quantitatives, alors vous finirez par forcer vos données qualitatives dans ce moule quantitatif d’une façon qui n’a aucun sens.
Comme lorsque vous montez une startup en BtoB. Vous montez votre startup en BtoB vous avez des cycles de vente entre trois et douze mois et vous allez maintenant essayer de forcer cela dans un cadre quantitatif. Cela devient très complexe. Que s’est-il passé au cours de ces réunions? Avez-vous rencontré les techniciens, pouvons-nous dire de façon quantitative le pourcentage des réunions qui a débouché sur un achat de la part du client?
Ce n’est vraiment pas ce que nous devrions demander. Nous devrions demander à quel point leur problème est pointu, ont-ils mentionné l’impact, quel était votre sentiment face à cela, étaient-ils prêts à vous présenter à des gens? Il y a trop de composantes différentes et changeantes qui n’entrent pas bien dans un cadre quantitatif et ne le réduire qu’à cela retire sa valeur à la donnée.
Mais surtout, nous essayons parfois d’utiliser à la fois des données qualitatives et quantitatives comme par exemple en menant beaucoup de petites expériences, peut-être plusieurs petites expériences quantitatives sur un petit échantillon.
Et nous essayons d’obtenir une lecture différente de toutes ces petites expériences qui peuvent nous aider à cerner ce qu’est réellement l’expérience utilisateur.
Avoir tous ces différents types d’information peut mener vers de nouvelles idées, non seulement sur ce que fait le client en termes quantitatifs mais pourquoi fait-il cela ce qui est plus qualitatif.
Vous savez, c’est effectuer un suivi et demander, pourquoi avez-vous appuyé sur ce bouton, pourquoi avez-vous essayé d’ajouter des hash tags dans votre ligne d’objet, que pensiez-vous obtenir? Et c’est vraiment l’information qui stimulera votre prochaine idée, votre prochaine grande idée pour faire avancer le produit.
Mike Fishbein- Tristan affirme qu’un mélange de différentes formes de données en expérimentation peut aider les chefs de produits à naviguer d’expérimentation en expérimentation. Cela semble génial d’un point de vue général mais comment cela se passe-t-il au jour le jour? L’une des erreurs les plus communes que je vois ce sont les chefs de produit qui commandent un ensemble d’expériences et qui invalident leur hypothèse dès le début. Soit ils posent des questions orientées soit ils font d’autres types d’erreur afin de prouver une idée préconçue.
Tristan Kromer –Il y a ce truc avec les hypothèses où les gens essaient d’obtenir ce format comme « nous pensons que les clients veulent cette fonction » ou quelque chose de ce genre. Personnellement je trouve cela extraordinairement irritant, n’importe quelle phrase qui commence par les mots « je crois » ou « nous croyons », s’il s’agit de notre hypothèse je peux tester cette hypothèse en demandant « croyez-vous cela », et savoir si votre hypothèse est juste. Votre hypothèse devrait suivre la structure si ceci alors cela. Il faut que ce soit une sorte de cause ou de relation.
Si nous mettons cette page d’accueil certaines personnes s’inscriront, ce n’est pas une hypothèse, l’hypothèse est une phrase colossale. Et elle devrait être extraordinairement spécifique, elle ne devrait pas être du type, « si je montre mon offre de valeur alors ils s’inscriront« , cela devrait plutôt être « qui sont les gens?« .
Si je montre à des personnes norvégiennes qui courent trois fois par semaine même au cœur de l’hiver, ma page de renvoi pour des chaussures de neige qui ont une plus grande adhérence dans la neige, alors ils s’engageront. L’indicateur que je mesurerai ensuite est le pourcentage de personnes qui s’engagent et j’aurai une condition d’échec.
Qu’est-ce qui me convaincrait que notre hypothèse est fausse? Et bien si seulement cinq pour cent de ces gens s’engage alors clairement, les coureurs norvégiens n’ont pas de problème de glissade et de patinage dans la neige. Donc peut-être que mes chaussures sont superflues de ce point de vue. Mais ce sont les conditions. Cela ne peut pas être cette géante inadéquation de quelques personnes s’engageront à un moment donné. Ce n’est pas suffisamment rigoureux.
Un faux positif c’est lorsque vous concevez une expérimentation afin de vous prouver quelque chose comme par exemple « oui les gens veulent mes chaussures de neige » et ensuite vous concevez l’expérience de telle façon que cela influence la personne interrogée à répondre « oui vos chaussures sont géniales, je veux les acheter! ». Et l’on sort de la conversation ou de l’expérimentation ou de la page de renvoi en se disant « wow, les gens veulent vraiment mon truc! » mais ce n’est pas vrai en réalité.
Nous avons donc une fausse croyance que notre hypothèse est exacte. Le plus souvent cela arrive en Lean Startup lors d’interviews avec les clients, de parler aux gens et de leur poser la question hypothétique « aimeriez-vous acheter mon produit? » Et la solution à cette erreur la plus commune est très simple, vous ne demandez pas aux gens s’ils veulent votre produit, vous leur demandez de vous donner de l’argent. S’ils vous donnent de l’argent alors ce n’est pas un faux positif puisqu’ils vous paient réellement pour le produit.
Mais poser des questions hypothétiques sur le futur, c’est un moyen sûr d’obtenir un faux positif lors d’interviews clients ou de sondages, typiquement une technique effroyable de recherche.
Il y a de nombreuses autres méthodes, comme ne pas réellement demander un niveau de prix suffisant, c’est une autre façon typique d’obtenir des faux positifs. Par exemple j’ai mis en place une page de renvoi et les gens étaient prêts à me donner leur adresse e-mail en échange de la promesse d’être un jour capables d’acheter ce produit quasiment gratuitement. Qui ne veut pas des choses gratuites? Les gens donnent leur adresse e-mail pour rien aujourd’hui donc ce n’est pas très bon signe. Ne pas fixer un prix suffisamment haut est donc un autre moyen sûr de se tromper.
Mike Fishbein – Tristan a fourni un cadre sûr aux chefs de produit pour formuler des hypothèses valides. Cela m’a amené à penser, quelles sont les autres fausses idées qu’il rencontre souvent?
Tristan Kromer – Le Lean est bon marché, le Lean n’est qu’un moyen d’économiser de l’argent…je crois que beaucoup de gens confondent encore le Lean Startup avec la production Lean et bien que les principes autour soient vraiment très similaires, il y a une différence de taille.
La production Lean par exemple concerne la production, comment pouvons-nous produire un bien spécifique ou un produit spécifique? Nous savons quel est le produit. Nous n’avons donc qu’à minimiser le gaspillage au cours de la production de ce bien, diminuons les niveaux de stock, éliminons les étapes superflues et ainsi de suite pour toutes les activités qui n’apportent aucune valeur.
Et dans le Lean Startup, ce que nous essayons de produire c’est de la connaissance. Nous essayons de produire un modèle d’entreprise. Et ce ne sont que des morceaux de savoir sur notre catégorie de clients, sur notre proposition de valeur, sur nos revenus.
De nombreuses activités en Lean Startup semblent inefficaces. Comme par exemple, « produisons le produit manuellement ». Faisons maintenant des tests magicien d’oz, nous avons tout un tas de stagiaires qui génèrent manuellement les données pour le client de l’autre côté. Cela semble incroyablement inefficace du point de vue de la fabrication ou de la production mais c’est incroyablement efficace en termes de compréhension de ce qui a de la valeur pour le consommateur. C’est donc ce que nous essayons de faire. Nous essayons d’éliminer toute activité qui ne produit pas de savoir.
Mike Fishbein – Quelque chose me perturbe depuis que tout le mouvement du Lean a démarré. C’est l’écart entre l’expérimentation et le marché traditionnel de la recherche. Particulièrement, où intervient le rôle de la signification statistique? Évidemment l’objectif de l’expérimentation est de générer des retours rapidement. Mais plus nous voulons que les retours soient significatifs statistiquement plus nous passerons de temps à le découvrir par définition. Comment les chefs de produit équilibrent-ils cela?
Tristan Kromer –Il y a trop de données, il n’y a pas assez de données. La signification statistique n’est pertinente que lorsque vous faites des tests qualitatifs et que vous avez vraiment une cohérence…
Prenons un exemple, faisons le test de la page de renvoi. Un test de page de renvoi où l’on met en avant une proposition de valeur sur une page de renvoi et l’on surveille le nombre de personnes qui s’inscrivent, quel pourcentage de personnes vont s’inscrire. Si j’envoie cent personnes sur cette page, combien vont s’inscrire? La signification statistique est importante si vous faites un test A/B et que vous avez la version A qui a un taux de conversion de dix pourcent et la version B dont le taux de conversion est de douze pourcent. Nous devons connaitre la taille de l’échantillon pour déterminer si ces douze pourcent surpassent vraiment les dix pourcent.
Donc comme pour les sondages présidentiels où McCain bat Obama cinquante-et-un à quarante-neuf pourcent mais où il est indiqué en petits caractères dans le bas de ce sondage plus ou moins quatre pourcent. Plus ou moins quatre pourcent c’est votre marge d’erreur et cela vous dit essentiellement que nous ne savons pas où se trouve la réponse. Vous savez, McCain gagne avec cinquante-et-un pourcent mais c’est plus ou moins quatre pourcent cela signifie donc qu’il pourrait être à cinquante-cinq pourcent ou il pourrait être aussi bas que quarante-huit pourcent, oh attendez non, quarante-six pourcent.
Donc qu’est-ce que c’est que trop de données? Si vous meniez un test A/B et que la version A convainc à dix pourcent et que la version B convainc à quatre-vingt-dix pourcent, vous n’avez pas besoin d’une taille d’échantillon de deux mille personnes. Vous savez la taille d’échantillon de deux-mille personnes me donnerait une marge d’erreur de quoi, plus ou moins un ou deux pourcent. C’est bien au-delà de la marge d’erreur. J’aurais pu arrêter ce test après les cent premières personnes et dire manifestement la version B est meilleure. Il y a trop de données. Rendu là, c’est du gâchis d’envoyer plus de gens sur cette page de renvoi car vous avez déjà votre réponse. Trop peu de données c’est lorsque vous n’en avez pas assez, lorsque votre version A et votre version B sont trop proches l’une de l’autre et que vous ne pouvez pas vraiment les différencier. C’est vraiment à cela que ça tient.
J’aime toujours poser ce qu’on pourrait appeler une condition d’arrêt précoce. Vous placez une limite raisonnable bien avant d’envoyer les dix-mille personnes sur cette page pour voir s’il y a une bonne raison de s’arrêter. Et très souvent il y en a une, très souvent vous aurez ces tests A/B où vous attendez un taux de conversion de plus de cinq pourcent et après y avoir envoyé une centaine de personnes, vous voyez que vous avez un taux de conversion de zéro pourcent. Sommes-nous en dehors de la marge d’erreur? Je ne sais pas mais il est très probable que nous ayons oublié d’installer une analyse sur cette page, nous avons probablement oublié le logiciel de veille, c’est probablement ce qui ne va pas, c’est probablement pour cela que vous avez un taux de conversion de zéro pourcent. Revenons donc un peu en arrière et arrêtons l’expérience et enquêtons un peu plus avant d’amener dix-mille personnes dessus. Mais je pense que cela vaut également pour les données quantitatives. Si vous parlez à vingt personnes et que votre catégorie de clients est tellement restreinte qu’après avoir parlé à vingt personnes vous puissiez dire « non, c’est clairement la bonne catégorie de clients », il n’y a aucune raison pour vous d’aller parler arbitrairement à cent personnes supplémentaires. Il y a une grande différence entre des tests conçus pour générer des idées comme les entretiens avec les clients et les véritables expérimentations conçues pour réfuter une hypothèse.
De même qu’un smoke test, une page de renvoi est conçue pour réfuter une proposition de valeur, une hypothèse.
Les entretiens de développement clientèle (customer development) ne sont pas une bonne manière de réfuter une hypothèse, selon moi. Mais c’est une très bonne façon de générer une hypothèse. Parler à dix personnes et commencer à comprendre, ces cinq personnes étaient intéressées, ces cinq personnes ne l’étaient pas. Qu’est-ce que ces cinq personnes qui étaient intéressées ont en commun? Est-ce parce qu’elles sont toutes très grandes, est-ce parce qu’elles ont de très grosses têtes? Ils ont donc besoin d’une taille de chapeau extra large. Qu’ont-ils en commun? Sont-ils tous en BtoB? Ces entreprises sont-elles toutes des SAS? Sont-ils tous des développeurs? Sont-ils tous des designers? Nous recherchons ces modèles qui permettent de générer ces hypothèses spécifiques que vous pouvez ensuite aller tester sur votre page de renvoi.
Mike Fishbein – Il semble donc que la réponse de Tristan en soit une que j’ai déjà entendue auparavant. La signification statistique devrait essentiellement être prise en considération lorsqu’il y a un choix entre A ou B. Mais s’il ne s’agit que d’apprendre si une solution spécifique devrait seulement exister, poursuivre une petite expérimentation qui étaye un modèle cohérent pourrait vous aider à en apprendre beaucoup rapidement. Comment ceci et d’autres aspects de l’expérimentation divergent entre startups et entreprises?
Tristan Kromer –Et bien, il y a bien entendu différentes tactiques qui s’appliquent. En tant que grande entreprise vous ne souhaitez pas forcément lancer une page sur Kickstarter, n’est-ce pas? Pour commencer, vous ne voulez pas décevoir les gens et endommager votre marque en promettant quelque chose que vous ne distribuerez peut-être pas. C’est donc toujours un danger, les grandes entreprises ne mènent généralement pas de smoke test ou de test de page de renvoi uniquement pour vérifier s’ils fabriqueront un produit. Mais certaines d’entre elles commencent, elles doivent seulement adapter ces tactiques à leur environnement.
Donc des entreprises comme Intuit et Swisscom effectuent des tests de page de renvoi, Sandisk également, ainsi que Sony qui a mené une campagne Kickstarter pour une montre qu’ils produisaient mais ils ont fait tous ces tests indépendamment de la marque. Ils ont donc retiré leur marque et ont créé une fausse marque pour tester si quelqu’un voulait ce produit. Et cela, leur a tout d’abord permis de protéger leur marque de nombreux dégâts s’ils avaient décidé de ne pas fabriquer ce produit ou d’éviter de décevoir les gens mais cela a également limité la possibilité d’un biais. Si Sony fabrique une montre, elle va probablement obtenir beaucoup plus d’attention beaucoup plus d’engagements que si une quelconque entreprise anonyme l’avait faite. Et ils auraient donc obtenu le signal erroné que les gens sont intéressés par la montre alors que les gens sont en fait intéressés par une montre Sony.
Mike Fishbein – Poussons ce concept plus loin. Les chefs de produit des entreprises doivent adapter les expérimentations à leur environnement particulier. Mais contrairement aux startups, ils doivent travailler avec plusieurs services. Un défi courant pour ces chefs de produit est de se coordonner avec la R&D. Comment l’expérimentation peut-elle les aider à construire réputation et confiance afin que leur vision du produit ne soit pas perçue comme insignifiante et comme une charge de travail.
Tristan Kromer –Un ingénieur qui comprend Scrum, qui comprend Agile, qui comprend les principes du développement par tests peut croire à l’idée d’un développement par hypothèses, n’est-ce pas? Oui si vous lisez le manifeste Agile, fondamentalement cela ressemble au Lean, c’est quasiment identique. Ne produisons pas de code qui n’a pas de valeur. Assurons-nous que cela fonctionne et que cela offre de la valeur au client. Assurons-nous que le client veut cette chose avant de la construire.
Clairement, je pense que mener des expérimentations est une façon beaucoup plus légitime pour faire avancer le produit. Il ne s’agit pas que de l’instinct du chef de produit et d’un ordre de la hiérarchie concernant ce que nous devons construire en tant qu’ingénieurs. Je n’aime certainement pas construire des choses de façon aléatoire tout cela parce que mon bienveillant dirigeant a eu le dessus. Mais honnêtement je pense que la meilleure chose pour gagner bienveillance et réputation auprès des ingénieurs c’est de comprendre au moins la base.
En tant que chef de produit, nous devons avoir un niveau basique de connaissances sur l’écriture d’un code. Ce que je veux dire c’est que si vous ne savez pas ouvrir votre terminal et au minimum installer Rails (Ruby on Rails), je pense que vous faites une erreur. Vous n’avez pas besoin d’être excellent mais vous avez besoin d’être au moins familier avec la nature des défis rencontrés. Pour les mêmes raisons je pense qu’en tant que bon chef de produit, si vous travaillez avec des designers et des pairs vous devez avoir ne serait-ce qu’une vague compréhension des défis rencontrés à ce poste. Vous n’avez pas besoin d’être le meilleur pour la mise en œuvre de tests d’utilisation mais vous devez comprendre ce qu’est un test d’utilisation et les avoir au moins expérimentés car ce sont le type d’expérimentation que nous parlons de mettre en œuvre.
Mike Fishbein – Tristan explique la structure d’expérimentations pertinentes et comment les chefs de produit peuvent se fier aux expérimentations pour générer des données justifiables autour des directions données au produit. La prochaine étape est le benchmark. Voyons comment Tristan raisonne sur la prochaine série de questions que nous avons posées à tous ceux que nous avons interrogés.
Tristan Kromer –Comment est-ce que j’utilise ma propre théorie? Dans mon entreprise où nous ne sommes que trois personnes, nous essayons toujours d’utiliser ce type de méthodes expérimentales et bien qu’il soit très facile de s’écarter du droit chemin et de dire « non, non, non je sais vraiment ce que je fais, construisons simplement cette chose », dans mon entreprise actuelle, quand je travaillais chez LUXr ou avant cela, nous essayions toujours de nous défier les uns les autres à appliquer ces principes, à dire « attendez une minute, sommes-nous vraiment sûrs, comment avons-nous testé cela? » Et nous essayions d’établir les objectifs d’apprentissage, les priorités majeures qui feraient avancer notre business.
Et comment pouvons-nous établir si oui ou non notre activité a de la valeur? Cela implique donc de faire des entretiens de découverte du client ce que nous faisons de façon constante, avec les nouveaux clients, les anciens clients, nous regardons en arrière et observons notre taux de rétention et nous suivons des indicateurs pour à peu près tout ce que je fais, même lorsque je vais à l’extérieur pour animer une conférence ou un atelier, nous envoyons un certificat, nous envoyons ou nous effectuons un sondage sur le taux de recommandation net. Nous envoyons également un lien pour télécharger le diaporama et nous regardons le pourcentage de participants qui vont vraiment télécharger le diaporama. Même pour quelque chose d’aussi simple que cela, nous faisons le régulièrement et il en est de même pour le Lean Startup Circle.
Je vous rappelle que le Lean Startup Circle est une organisation à but non lucratif pour laquelle je travaille, nous essayons de mesurer tout ce que nous pouvons. Nous essayons de mesurer le pourcentage de bénévoles qui reviennent de façon mensuelle. Nous essayons de mesurer le nombre d’expériences que nous sommes parvenus à effectuer, quelle est notre rapidité. Et nous savons lorsque nous traversons un mois sans effectuer d’expérimentations que c’est mauvais signe, qu’il y a un problème fondamental et que nous devons nous réunir et déterminer ce qui ne s’est pas bien passé. Est-ce parce que nous étions vraiment uniquement en mode réalisation et que nous avions des choses cruciales et urgentes à faire qui ne pouvaient pas être repoussées ou est-ce parce que nous étions juste paresseux et que nous ne nous sommes pas lancé de défis les uns aux autres?
Tristan Kromer – Comment ai-je utilisé les retour clients dans ma propre entreprise? Et bien, parfois de façon très décevante. Vous savez, il y a quelque chose qui me passionne et qui m’intéresse beaucoup, c’est comment nous pouvons appliquer le Lean aux ventes en BtoB. Je ne suis pas commercial, je pense juste que c’est vraiment intéressant, que c’est un défi intéressant car vous avez cette chose compliquée que l’on appelle processus de vente de l’entreprise qui implique généralement de multiples parties prenantes au sein de l’entreprise. Et ce n’est pas un entonnoir de vente clair et linéaire avec toutes ces petites choses que vous pouvez mesurer. C’est un problème complexe. Cela m’intéressait donc beaucoup d’étudier cela et d’écrire plus sur le sujet et j’ai travaillé avec Sean Murphy sur la façon dont nous pouvons faire avancer le sujet et augmenter nos propres connaissances mais aussi les connaissance de tout l’écosystème.
Et je suis triste de dire qu’il y a très peu de personnes qui s’y intéressent. Vous savez nous avons créé ces posts sur nos blogs, nous avons suivi les indicateurs pour voir combien de personnes sont prêtes à télécharger quelque chose ou à s’inscrire à nos mails sur le sujet et les chiffres n’y sont tout simplement pas. Je peux donc continuer à étudier le sujet en tant que hobby et pour son intérêt scientifique mais il n’y a pas assez de demande je ne suis donc pas prêt d’organiser une tournée mondiale ou des ateliers sur la vente Lean en BtoB Nous recherchons donc constamment ce type de retours. Et encore une fois, c’est un grand défi de s’y tenir quand vous avez des cofondateurs, quand vous avez le Lean Startup Circle, je peux vous appeler et vous demander de choisir un bout de mon MVP et de me citer dix choses que je construis et dont je n’ai pas vraiment besoin. C’est pour cela que nous avons besoin des autres, afin de rester honnêtes.
Tristan Kromer – Quel livre je lis en ce moment? Je lis le nouveau livre d’Osterwilder, Value proposition design mais honnêtement je lis surtout de la science fiction. Je lis trop de livres sur les affaires et parfois ils ne font que m’endormir donc quand je lis j’aime lire un roman de science fiction bien nase.
Tristan Kromer – Quel est votre cauchemar récurrent en gestion de produit? Le cauchemar récurrent c’est toujours cette chose dont vous êtes absolument certain qu’elle est nécessaire et vous êtes absolument sûr que c’est vrai et vous la construisez et il s’avère que personne n’en veut. C’est un cauchemar permanent. Que vous soyez le fondateur d’une entreprise ou que vous ne soyez qu’un chef de produit travaillant pour quelqu’un d’autre. C’est la chose que vous ne voulez jamais voir arriver.
Bon sang j’ai du mal avec cette question car tous les véritables cauchemars selon moi viennent de l’industrie de la musique. Comme les fois où l’on faisait un concert pour zéro personnes littéralement. Une fois, j’ai passé douze heures dans un van avec trois autres gars qui ne sentaient pas particulièrement bon. Nous avons conduis jusqu’au New Hampshire pour faire un concert et il y avait une tempête de neige. Et les gens ne sortent généralement pas dans le blizzard pour écouter de la musique. C’est juste quelque chose qui ne se fait pas. Nous n’allions donc littéralement jouer le spectacle devant personne. Au moment où nous sommes montés sur scène, tous les autres groupes étaient partis. Ils avaient joué leur partie, nous avions poliment applaudi et ils étaient partis. Et même les barmans et les videurs ont pris une pause cigarette à ce moment là car la tempête s’était calmée et on nous a littéralement laissés jouer pour une salle vide. Et c’est un peu mon cauchemar en tant que chef de produit de vivre ce même genre d’expérience. Maintenant pour la défense de ce concert, j’ai été payé quarante dollars.
Mais dernièrement, c’est ce manque de connexion avec le client, mon cauchemar. C’est le manque de capacité à regarder en arrière à la fin de la journée et de se dire « j’ai changé quelque chose pour quelqu’un. » Je m’en fiche de toucher dix millions de personnes mais je veux au moins améliorer la vie d’une personne et je veux les entendre dire que j’ai vraiment bien fait ce travail. C’était tellement facile dans l’industrie de la musique parce que nous pouvions le voir. Je pouvais voir si quelqu’un s’amusait. Je pouvais voir s’ils balançaient les hanches. Et c’est si difficile en technologie, nous sommes tellement éloignés du client et nous nous laissons tellement piéger par ces indicateurs clé de performance et ces mesures que nous n’avons pas réellement de connexion avec le client et nous ne le comprenons pas vraiment afin de comprendre la valeur que nous créons réellement.
Donc honnêtement, c’est un peu mon cauchemar, que les gens l’utilisent ou pas, c’est de manquer la signification de ce que nous faisons. C’est de manquer la connexion humaine qui à la fin me fait savoir que j’ai une mission dans ce monde et que ce que je fais est bien et que je pourrais optimiser ce bouton et que je pourrais faire en sorte que plus de monde clique sur ce bouton. A la fin de la journée, si les gens ne sont pas heureux lorsqu’ils cliquent sur ce bouton et que ce bouton ne fournit pas de valeur, je ne veux pas faire cela. Je ne veux pas travailler pour une entreprise où je ne comprenne pas qui sont mes clients. Je ne veux pas travailler pour une entreprise où nous ne faisons que pousser les gens à cliquer sur des boutons juste pour les faire cliquer sur des boutons. Je veux changer la vie de quelqu’un d’une façon qui ait du sens. C’est mon seul véritable cauchemar. Je crois que c’est seulement de pas faire quelque chose qui serve à quelque chose.
Mike Fishbein – Et bien, c’était intense. J’adore ça. Voyons si Tristan a d’autres sages conseils à partager avec nous.
Tristan Kromer –Je pense que ce que tout le monde devrait comprendre à propos du Lean c’est que cela débute par l’ignorance. Il n’y pas de règle gravée dans le marbre qui dise que tout le monde devrait commencer à créer sa startup, ce n’est pas le cas vous savez. Si vous pensez tout savoir sur le futur et bien félicitations à vous, allez construire ce truc et passez un an à le construire. Certaines personnes réussissent de cette façon là, c’est incontestable. Cela fonctionne parfois, construisez-le et vous verrez.
Mais le Lean commence initialement par une condition d’ignorance et vous devez avoir une certaine dose d’humilité et de conscience de vos propres défauts et faiblesses afin que cela fonctionne. Et cela vaut également pour votre équipe. Alors commencez par là. C’est très difficile d’être un entrepreneur, c’est très douloureux et je pense que le Lean Startup est très difficile car nous demandons aux gens d’aller se cogner la tête contre le mur vingt fois par jour.
Menez vingt expérimentations, échouez rapidement, quelle maxime stupide; échouez rapidement, c’est tellement douloureux comme s’ils allaient continuer à se cogner la tête vingt fois de suite, à quel point c’est écrasant pour le moral de votre équipe si vous faites échouer vingt expérimentations à la suite. Soyez seulement conscient que cela commence avec une condition d’ignorance et que le progrès est synonyme d’apprentissage.
Pas d’échec, l’échec n’est pas un progrès, l’apprentissage en est un. Donc si nous menons une expérience et que notre hypothèse est fausse, nous apprenons toujours quelque chose et nous avançons. Si nous commençons par l’ignorance et que nous avançons en apprenant, c’est le cœur du Lean. Et si cela ne vous effraie pas, que vous n’avez pas d’obstacles à contourner et que vous pouvez les renverser grâce à votre expérimentation, c’est fantastique, allez y. Mais si vous pensez ne pas savoir quelque chose, alors votre travail est d’expérimenter et de trouver cette chose, c’est de répondre à cette question.
Où est-ce que les gens peuvent en savoir plus sur moi et ce que je fais? Donc je blogue régulièrement ou à peu près régulièrement sur grasshoperherder.com, vous pouvez me twitter sur TriKro et c’est également mon nom de domaine. Si vous êtes un entrepreneur à un stade précoce j’ai des horaires d’ouverture de bureau, donc venez et je serai plus qu’heureux de vous aider bénévolement.