Les entreprises trouvent des moyens d'adopter l'approche Lean Startup pour aider les marchés et les clients à qui elles fournissent leurs produits. Elles veulent pouvoir récupérer un retour utilisateur le plus tôt et le plus souvent possible pour être en mesure de comprendre les besoins et d'offrir des solutions qui créent de la valeur ajoutée.
L'article Minimum Viable Products for Enterprises donne des exemples sur la façon dont les entreprises peuvent utiliser le Lean Startup pour en apprendre davantage sur les clients, sans trop d'efforts ni d'argent. Yammer est une des entreprises citées dans cet article d'InfoQ et InfoQ a rencontré Brian Murray pour discuter avec lui la manière dont Yammer utilise le Minimum Viable Product pour tester leurs hypothèses et pourquoi ils concentrent tant leur attention sur l'architecture de leurs produits.
InfoQ : J'interview maintenant Brian Murray, le directeur stratégie chez Yammer. Brian, pouvez-vous vous présentez brièvement aux lecteurs d'InfoQ ?
Brian : Bien sûr, je suis arrivé chez Yammer il y a environ trois ans maintenant et avant Yammer, j'étais consultant technique en déploiement de solutions globales, comme SAP et Siebel, pour les grandes entreprises. J'ai changé d'orientation en allant chez Yammer et j'ai eu une expérience vraiment incroyable d'apprentissage du Software as a Service, du cloud et les nouveaux moyens d'introduire la technologie. J'ai passé à peu prés la moitié de mon temps chez Yammer en avant vente, aidant les entreprises à donner du sens à cette nouvelle manière de communiquer et l'autre moitié du temps avec l'équipe produit pour contribuer à façonner l'orientation de notre produit en évanlégisant et expliquant cette nouvelle façon de créer notre produit et d'itérer rapidement.
InfoQ : En étant avec l'équipe produit, vous voulez dire que votre rôle est aussi d'être le responsable produit ?
Brian : Oui. Notre équipe produit est divisée en deux catégories - nous avons la catégorie conception qui regroupe les responsables utilisateurs, les ergonomes et les graphistes, c'est à dire ceux qui créent le look and feel de Yammer. L'autre catégorie regroupe les responsables produit, ce qui inclus toutes les personnes responsables d'amener les nouvelles fonctionnalités sur le marché et qui travaillent avec les ingénieurs, notre équipe d'analyse et l'équipe de conception. Enfin, il y a mon équipe qui est une sorte de liaison entre le marché, les clients, nos équipes interne comme les commerciaux, l'avant-vente, les équipes techniques comme les ingénieurs et les analystes. Notre travail est de s'assurer que ce que nous concevons va être bien reçu par le marché et les clients, et de prévoir et atténuer les obstacles potentiels.
InfoQ : Juste pour information, quelle est la taille de Yammer désormais ?
Brian : Yammer, c'est au total, à peu prés 450 employés.
InfoQ : Dans un article l'année dernière dans Forbes qui a été mentionné dans l'article InfoQ Minimum Viable Products for Enterprises, vous dites qu'une nouvelle approche est nécessaire pour développer et versionner les produits plus rapidement. Qu'est ce qui rend cela si important ?
Brian : Cette nouvelle approche que nous appelons Rapid Iteration - il y a beaucoup de termes différents pour la nommer - devrait être adoptée par tous les fournisseurs de technologies pour plusieurs raisons. La raison principale est qu'elle est accessible de tout de suite. Historiquement parlant, quand l'internet n'était pas aussi puissant, quand les applications étaient déployées sur site, il n'était tout simplement pas possible d'avoir un logiciel en mode SaaS. Cependant avec l'arrivée des architecture cloud, nous pouvons faire des modifications rapidement de nos produits et finalement éviter de faire trop d'hypothèses ; l'enjeu est là. Avec les méthodes de développement traditionnelles en entreprise, vous auriez 2 à 3 ans par cycle de version et vous auriez beaucoup d'hypothèses à faire sur ce qu'attendent les utilisateurs de votre technologie par rapport au moment où elle a été mise sur le marché. Avec Yammer, nous faisons de petites hypothèses et nous sommes en mesure de les tester rapidement, en quelques semaines plutôt qu'en mois ou en années et de cette façon nous pouvons orienter notre bateau et s'assurer que Yammer va dans la direction qui répond aux besoins de nos clients et que nous ne sommes pas en train de travailler sur quelque chose ou de livrer une fonctionnalité qui, au final, ne correspondrait pas à ce que nous voulions atteindre.
InfoQ : J'ai cru comprendre que Yammer utilisait l'approche Lean Startup. Pourquoi l'avoir choisi et comment l'avez-vous mise en oeuvre chez Yammer ?
Brian : Nous l'avons choisie car c'était d'ores et déjà accessible. Si vous regardez le pedigree de notre équipe fondatrice avec David Sacks et Adam Pisoni, ils ont beaucoup d'expérience dans la technologie mais principalement axée sur l'utilisateur et pas nécessairement sur l'entreprise. Du coup, ils se sont tout naturellement tourné vers le cloud, avec l'approche Lean Startup, avec les architectures mutualisées, et ils croyaient de tout coeur que ces architectures étaient intrinsèquement meilleures, plus efficaces et permettaient à l'entreprise de réagir rapidement à la montée en charge. Nous utilisons les mêmes architectures techniques et les mêmes méthodologies dans le contexte de l'entreprise - ce qui a eu des conséquences intéressantes - mais dans l'ensemble, selon nous, c'est ce qui a fait de Yammer, Yammer. C'est ce qui nous a permis d'être compétitif dès le démarrage et c'est ce qui nous a permis d'offrir une expérience et des perspectives uniques dont Microsoft tire profit désormais. Vous pouvez souvent entendre nos fondateurs dire que l'architecture c'est la destinée de l'entreprise ; nous pensons vraiment qu'à long terme la manière dont est architecturée votre technologie dicte votre durabilité et votre viabilité à long terme.
InfoQ : Les Minimum Viable Products (MVP) sont utilisés pour livrer de petites versions contenant de nouvelles fonctionnalités de Yammer. Pouvez-vous donner quelques exemples de la façon dont cela a été utilisé ?
Brian : Nous essayons presque toujours d'employer un modèle MVP dans l'ensemble de nos fonctionnalités. Cela ne veut pas dire que nous livrons des fonctionnalités bancales, mais que nous avons des hypothèses sur ce que nos utilisateurs s'attendent à avoir, ce qu'ils recherchent dans nos produits à travers les retours utilisateurs et les statistiques d'abonnements. Nous pouvons avoir une vision claire de ce que nos utilisateurs recherchent, mais plutôt que d'essayer de concevoir un ensemble de fonctionnalités d'un coup, ce qui prendrait beaucoup de temps, nous le découpons en petit morceaux. Un exemple intéressant de cela est une nouvelle fonctionnalité appelée Universal Publisher. Universal Publisher représente un changement très important dans Yammer où vous pouvez poster un seul message à plusieurs groupes en même temps. Aujourd'hui, vous ne pouvez envoyer qu'un message Yammer dans un seul groupe et nos systèmes coté serveur sont architecturés pour gérer ce cas d'utilisation. Avec Universal Publisher, nous voulons permettre l'envoi de message multi-groupes et multi-audience, mais cela signifie qu'il faut prévoir des changements importants au niveau de l'architecture de la messagerie. Plutôt que de développer notre vision complète de cette fonctionnalité, nous l'avons découpée en petits morceaux : petites évolutions ergonomiques, améliorations graduelles de l'architecture de messagerie, etc. En décomposant notre vision en petits bouts facilement gérables, nous avons moins besoins d'émettre des hypothèses et nous apprenons ce à quoi l'utilisateur réagi au fur et à mesure.
InfoQ : J'imagine que si vous regardez les groupes privés et public vous allez devoir jongler entre le respect de la vie privée d'un coté et la facilité d'utilisation de l'autre ?
Brian : Oui, et aussi comment voulez-vous indiquer visuellement qu'un message fait partie d'un groupe privé et d'un groupe public, ou comment faire comprendre à l'utilisateur final que ce qu'il affiche soit privé ou public ? Nous avons quelques idées sur ce qui pourrait fonctionner, mais nous ne pouvons pas dire avec certitude que la mise en oeuvre de telle idée est meilleure qu'une autre, du coup, c'est là qu'on utilise notre modèle MVP et que l'on itère rapidement sur l'idée jusqu'à ce que ce soit bon.
InfoQ : Appliquer des pratiques Lean Startup et mettre en oeuvre l'approche MVP dans le cadre du développement d'un produit diffère-t-il d'un contexte d'entreprise ? Si oui, comment ?
Brian : Encore une fois, dans mon expérience passée, avant de rejoindre Yammer, je déployais des technologies traditionnelles, gros ERP, CRM, et ces projets pouvait prendre un an voir plus. Une partie était consacrée à la conduite du changement et à la formation au déploiement de la nouvelle technologie pour s'assurer qu'elle soit adoptée. Avec les technologie traditionnelle vous disposez d'un "go live" prévu à une date précise autour duquel l'équipe de déploiement se concentre. Dans un environnement SaaS, où vous pouvez améliorer en permanence votre produit, le changement est lissée dans le temps. Il y a des implications majeures dans l'entreprise face à de tels changements de technologie de déploiement. Les produits que nous utilisons dans notre vie quotidienne tels que Facebook, Twitter et Zynga sont mis à jour deux fois par jour maintenant mais personne ne le remarque! Ceci est du au fait que le changement est moins important et plus progressif. Les utilisateurs ont aussi une relation directe avec l'éditeur-créateur de la technologie. Avec Yammer, nous vendons aux entreprises, nous créons une relation avec elles et les équipes lancent leur réseau Yammer et sont représentatifs de tous les utilisateurs de Yammer dans leur réseau. Lorsque nous apportons des modifications au produit, en particulier celles qui vont être visible ou peuvent modifier l'expérience utilisateur, nous devons nous assurer que nous communiquons assez bien pour que nos champions et nos équipes administratives côté client soient pleinement conscientes du changement et de ses implications. Nous voulons aussi nous assurer qu'ils ont tous à leur disposition, les supports de formation que nous avons créés, afin que cette nouvelle fonctionnalité soit adoptée de manière efficace. Cela ne veut pas dire que ces pratiques ne doivent pas être utilisés, elles doivent l'être absolument, mais dans un contexte d'entreprise, vous avez besoin d'être prudent quant au déploiement de modifications car beaucoup d'entreprises sont dépendantes de ces outils dans leurs travaux de tous les jours et vous devez vous assurer que vous n'entrainez pas trop de perturbations.
InfoQ : Oui, je comprends que ce n'est pas seulement une question de fonctionnalité, mais aussi de supports de communication supplémentaires, et tout ce qui est nécessaire pour mettre en oeuvre de nouvelles fonctionnalités dans l'organisation. Ils font partie de vos produits et livrés à votre client, n'est ce pas ?
Brian : Absolument. Une des différences par rapport au modèle traditionnel, c'est que pour des cycles de version de un à trois ans, une fois que vous obtenez la nouvelle version du logiciel, c'est une nouvelle application de façon drastique. Il y a beaucoup de changements qui ont été intégrés dans cette nouvelle version. D'autre part, avec l'approche à itération rapide, vous pouvez effectivement lisser les changements au fil du temps, plutôt que d'avoir une expérience totalement nouvelle au moment de mettre à jour votre logiciel. Cela permet une transition plus naturelle dans une expérience améliorée au fil du temps. Il s'agit de découper les grandes idées en petits morceaux, des morceaux plus facile à digérer et de les introduire d'une manière moins perturbante. En fin de compte, nous nous assurons que les fonctionnalités destinées aux attentes du marché sont valides et ramènent des abonnements, une adoption de la technologie, et des messages positifs. Avec le développement de logiciels traditionnels, vous deviez investiguer beaucoup quant à ce qui devra fonctionner et il n'y a pas de bonne façon de valider ces suppositions une fois que la nouvelle technologie est en production.
InfoQ : Tester ses hypothèses et accroître la compréhension des besoins client sont souvent la raison pour laquelle les entreprises utilisent MVP. Y a-t-il d'autres avantages à l'utilisation de l'approche Lean Startup ?
Brian : Il y a beaucoup de leçons à tirer de la façon dont nous organisons les équipes de produits et d'ingénierie. Chaque équipe qui travaille sur une fonctionnalité inclut les ingénieurs qui développent cette fonctionnalité, les designers qui conçoivent l'interface utilisateur de cette fonctionnalité et les responsables des analyses de données. Nos analystes évaluent les données d'adoptions des nouvelles fonctionnalités et ensuite travaille avec le chef de produit pour en déduire ce qui fonctionne et ce qui ne marche pas. Un avantage majeur est que les retours utilisateurs permettent à nos chefs de produits de faire de meilleures hypothèses au fil du temps parce qu'ils voient ce qui est en résonance avec notre clientèle. Ils s'améliorent en évitant les suppositions et en gardant un esprit ouvert à toutes les solutions possibles.
InfoQ : Qu'avez-vous appris en utilisant le Lean Startup ? Qu'est ce qui a marché et qu'est ce qui n'a pas marché et pourquoi ?
Brian : Nos décisions architecturales de départ ont été essentielles à notre réussite sur le long terme. Yammer est en fait une compilation d'un certain nombre de services différents. Recherche, classement, flux de messages, profils, et d'autres, qui sont tous alimentés par des services séparés. Tous ces services interagissent les uns avec les autres pour alimenter Yammer. Plutôt que d'avoir une base de code monolithique, Yammer est distribué. Cela nous permet de faire évoluer chacun de ces services de façon indépendante, afin que nous puissions améliorer un service sans trop se soucier des effets de bord que cela aura sur tout le reste. Nous avons appris qu'en découplant les services qui font marcher Yammer, nous sommes capables d'innover plus rapidement. En fait, nous avons dépensé beaucoup d'énergie en prenant certains des services les plus importants, comme celui qui alimente le flux de Yammer, et nous les avons décomposés en plus petits services. En faisant cela, nous sommes en mesure d'optimiser encore plus efficacement sans perturber les autres services ou l'expérience utilisateur en général.
InfoQ : Comment le Lean vous a-t-il aidé avec l'architecture ? Vous a-t-il rendu plus conscient de la criticité de l'architicture ?
Brian : Cela nous a aidé à réaliser qu'il y a un avantage significatif à être en mesure d'améliorer ces différents services individuellement. Le Lean a contribué à nous montrer que le découplage ou la distribution de notre base de code est toujours une bonne chose, et plus nous pouvons le faire vite, plus nous pourrons avancer et innover sur Yammer.
InfoQ : Si des sociétés voulaient se mettre au Lean Startup, quelles recommandations auriez-vous à leur faire ?
Brian : Je leur conseillerais de passer beaucoup de temps à réfléchir à leur architecture (avant de commencer à développer) et d'avoir une représentation claire des clients auxquels ils veulent vendre. Si vous vendez à l'entreprise, tenez compte des différentes réglementations du secteur, la capacité de vos clients à changer d'avis et comment vous allez créer des relations durables avec eux. Si vous pouvez planifier cela à l'avance, vous serez plus à l'aise sur le long terme. Gardez à l'esprit qu'il n'y a pas de date de fin pour un bon produit. Vous devez toujours itérer parce que les exigences de votre marché et vos clients seront toujours en train de changer. Le rythme du changement s'accélère, de sorte que votre produit (et votre entreprise) aura toujours besoin d'évoluer pour répondre à cette demande en pleine évolution. Il est important de garder cela à l'esprit et de se rendre compte que c'est tout un voyage. Cela revient à construire un produit que vos utilisateurs finaux aiment vraiment et qui les aide à mieux faire leur travail.
InfoQ : Avez-vous eu besoin d'organiser des ateliers ou autre évènement du même type pour faire comprendre le Lean Startup ?
Brian : Beaucoup de gens se sont impliqués dans cette démarche depuis un long moment, tout le monde a lu la littérature sur ce sujet. Nous utilisons ces pratiques depuis longtemps, cela a toujours été dans nos esprits. Nous ne considérons pas cela comme une option mais comme un principe de base auquel nous devons tous adhérer. Cela a vraiment été super d'avoir une équipe de fondateurs qui soit aussi attachée à cette philosophie et c'est génial de voir de plus en plus d'éditeurs de logiciels adopter ces idées aussi.
InfoQ : Y a-t-il quelque chose que vous avez personnellement appris en appliquant le Lean Startup ?
Brian : Ce qui a été vraiment intéressant pour moi dans tous ce processus - passer d'une approche traditionnelle de la technologie d'entreprise à une approche basée sur le cloud et le développement rapide - est que nous devons toujours rester intellectuellement honnête. En tant que chef de produit, être intellectuellement honnête signifie ne pas être attaché émotionellement à la fonctionnalité sur laquelle vous travaillez. Pour livrer vraiment le meilleur produit pour vos utilisateurs, vous devez être ouvert au fait que vous pourriez avoir tort et vous rendre compte que la meilleure façon de mesurer l'utilité de votre fonctionnalité est d'examiner les données recueillies au moyen de tests. Le jugement humain est imparfait et, par conséquent, nous devons toujours utiliser les données pour nous guider vers les bonnes décisions. Cela a été un apprentissage passionnant pour moi.
InfoQ : Vous restez donc ouvert à toute demande venant de vos clients ?
Brian : Oui. Considérez ceci : si vous avez des ingénieurs dont le travail est lié à un certain ensemble de fonctionnalités, ils voudront toujours que celles-ci soient prioritaires sur les autres parce qu'ils ont un lien et un besoin implicite que ces fonctionnalités soient mises en évidence ou améliorées. Mais si vous séparez l'équipe de toute zone individuelle de votre produit, vous êtes capable de prendre des décisions plus rationnelles qui ne sont pas influencés par l'émotion ou autres obscures motivations qui ne sont pas vraiment en harmonie avec le but ultime d'améliorer l'expérience de l'utilisateur final.
A propos de l'interviewé
Brian Murray est directeur de la stratégie d'entreprise chez Yammer, où il contribue à façonner la stratégie produit de l'entreprise pour répondre aux demandes des entreprises et évangéliser les tendances de SaaS, de consumérisation et de développement pilotés par les données. Brian est responsable des partenariats avec les clients des différentes industries de toutes tailles partout dans le monde, de la prévision de l'évolution du marché et de la promotion pour l'adoption de Yammer et autres applications d'entreprise en mode SaaS.
Auparavant, Brian a dirigé la conception et le développement de la méthodologie de déploiement structuré de Yammer, qui fournit un cadre et une stratégie pour les clients qui souhaitent intégrer le réseau social d'entreprise de Yammer dans leur société.
Avant de rejoindre Yammer, Brian a été consultant chez Deloitte, responsable de la conduite du changement et du déploiement de technologies dans les grandes organisations, dont Chevron, CVS Caremark et Juniper Networks. Il a une B.A. en économie d'entreprise de l'Université de Californie à Los Angeles.