Lean User Experience et Lean Analytics

1. Introduction

J’utilise pour la Digital Agency le schéma suivant pour représenter la démarche Lean Startup. Ce schéma est une extension d’un schéma original à deux boucles de Dave Landis, modifié avec Stéphane Delbecque pour y ajouter la dimension de développement analytique sous le chapeau du « Growth Hacking ». Il y a plusieurs variantes de ce dessin, celle-ci représente ma meilleure synthèse du moment, en définissant deux moments clés pour le passage d’un cercle à l’autre :

• le « «sprint zero », lorsqu’on démarre le processus de construction du MVP (cercle 1 à 2)
• la mise à disposition dans les stores (App Stores) de l’application, lorsqu’on passe des « beta testers » aux « vrais clients » (cercle 2 à 3)

La représentation sous forme de 3 cercles insiste sur le fait que chaque étape : Design Thinking, MVP agile development et Growth Hacking est itérative. Ce dessin cristallise deux parti-pris éditoriaux : 

1. le Lean Startup couvre l’ensemble des 3 phases (build – measure – learn s’applique partout)
2. le Growth Hacking commence dès que l’application est entre les mains du marché, et pas seulement lorsque le « Product-Market Fit » a été obtenu. 

Je place le « growth hacking » sous l’égide du « nail it, then scale it » : les méthodes de lean analytics, les pirate metrics et les modèles de croissance sont utiles avant et après l’obtention du Product-Market Fit. Il est possible de prendre une définition plus large pour la définition du MVP et de faire du product-market fit la transition avec une phase plus étroite du Growth hacking, mais je préfère faire du lancement la seconde transition car elle sépare deux étapes (on construit / on améliore) qui sont plus distinctives en termes de gouvernance et mode de travail (l’atteinte du Product-Market-Fit n’est pas aussi simple à caractériser).

Le billet de ce jour propose la revue de lecture de deux livres fondamentaux qui alimentent respectivement les deux premières – design thinking & minimum viable product – et la dernière étape – growth hacking – de cette démarche de Lean Startup. Ces deux livres font explicitement référence à Eric Ries et au Lean Startup, et me semblent des lectures indispensables pour bien comprendre l’ensemble de la démarche.

2. Lean UX

Le premier livre est « Lean UX : Applying Lean Principles to Improve User Experience » de Jeff Gothelf (avec Josh Seiden). C’est un livre de la collection « The Lean Startup Series » proposée par Eric Ries. Dès les premières pages, les auteurs font références à trois « fondations » pour la démarche de Lean UX (User eXperience) : Design Thinking, Product Agile Development et Lean Startup. Comme toujours, je vous propose un résumé synthétique émaillé de quelques citations, mais je vous recommande la lecture, d’autant plus que ce livre est court et contient des exemples intéressants.

• Le Design Thinking, la première composante de lean UX, s’appuie sur l’observation des clients : « innovation powered by...direct observation of what people want and need in their lives and what they like or dislike ». Le design thinking a une applicabilité beaucoup plus grande que le développement de produits numérique, c’est un outil fondamental pour le développement de toute proposition de valeur, dans tous les secteurs d’activité, qui devrait, à mon avis, être enseigné dans tous les MBA (« every aspect of a business can be approached with design »). On trouve dans le design thinking deux caractéristiques transverses de l’ensemble du lean startup : build-measure-learn (des cette première phase, on construit des prototypes qui matérialisent des hypothèses – « There is more value in creating the first version of an idea than spending half a day debating its merits in a conference room ») et la confrontation régulière aux futurs utilisateurs (« A critical best practice in Lean UX is building a regular cadence of customer »). Il faut équilibrer les deux : l’approche analytique et l’approche qualitative : « It’s not all numbers! It’s worth noting that there’s been a lot of backlash in the design world against measurement-driven design ».  Une des autres idées clé du livre est l’importance du focus (« Lean UX is an exercise in ruthless prioritization »). Une fois définies les différentes personas, il faut choisir le moins possible et se concentrer sur quelques « unique value propositions ».
  
  
• Puisque Lean UX s’appuie sur les méthodes agiles pour le développement de produit, ce livre contient un résumé des principaux principes du développement agile ainsi que quelques conseils. Par exemple, on retrouve le résumé(reformulé) suivant du « agile manifesto » : (1) priorité aux personnes et aux interactions sur les processus et les outils (2) priorité à un logiciel qui tourne plutôt qu’une caractérisation complète de ce qu’il doit faire (3) collaborer avec les clients plutôt que de contractualiser un projet (4) s’adapter à ce qui change plutôt que suivre un plan. On retrouve également les traits classiques de l’approche agile : « small, dedicated, colocated teams », « small batch size », etc. Je cite : « This is the day-to-day rhythm of Lean UX: a team working collaboratively, iteratively, and in parallel, with few handoffs, minimal deliverables, and a focus on working software and market feedback ». Comme toujours, la co-localisation est la meilleure façon de travailler mais le livre aborde également le sujet de « la collaboration avec des équipes géographiquement distribuées » (par exemple : « Each conference room had a Mac in it with a location-specific Skype account (i.e., it wasn’t a specific individual’s account, it was that office’s account). The two offices connected to each other via their office Skype accounts so that we could see each other as a group »). On trouve également une référence au « sprint zéro » que je mentionnais en introduction :  « They use a technique called Cycle 0 (you may have heard it called “Sprint Zero” or “Staggered Sprints” as well ». Comme ce livre pose les fondations pour la collaboration entre designers et développeurs, il contient des définitions très intéressantes, comme celle qu’il propose pour les user stories : « The smallest unit of work expressed as a benefit to the end user. Typical user stories are written using the following syntax: As a [user type] I want to [accomplish something] So that [some benefit happens] » (cf. un peu plus loin la discussion sur outcome-vs-feature)
  
  
• Un des principes clés de cette approche est la notion d’équipe cross-fonctionnelle (pas de surprise, c’est une des idées fondamentales partagées par la plupart des livres auxquels je fais référence dans ce blog, et une des fondations de l’Entreprise 3.0), c’est-à-dire des équipes qui embarquent le développement, le design, la conception produit, le marketing et l’assurance qualité. La véritable collaboration entre designer et développeurs est une des clés de la réussite, et il est facile de se tromper : « Many teams have missed this critical point and have instead created workflows in which designers and developers communicate by handoff, creating a kind of mini-waterfall proces ». Il faut au contraire une véritable collaboration (au sens de « travailler ensemble sur la même chose » entre les membres de l’équipe pour produire le « shared understanding », au sens lean/kaizen du terme : « Shared understanding is the collective knowledge of the team that builds up over time as the team works together. It’s a rich understanding of the space, the product, and the customers ». Les auteurs insistent : « Without that collaboration, you don’t build shared understanding, so you end up relying heavily on documentation and handoffs for communication ». Tout cela doit se faire dans une équipe autonome, qui n’est pas soumis à un flux de contrôle trop important : « Management check-ins are one of the biggest obstacles to maintaining team momentum », ce qui conduit naturellement à l’utilisation du visual management et du « management by walking around ». Je termine          avec une dernière citation : « Lean UX requires cross-functional collaboration. By creating interaction between product managers, developers, QA engineers, designers, and marketers, you put everyone on the same page ».
  
  
• Le deuxième principe fondamental de l’approche Lean UX (et Lean Startup) est de définir le progrès (ou le succès) à partir de la satisfaction client, et donc de l’expérience, et non pas à partir de ce qui est produit : « progress is defined by outcome, not outputs ». C’est pour moi le pivot de la « transformation numérique », lorsque le succès est définit par la satisfaction des utilisateurs, pas la liste des features qui ont été livrés. "Our goal is not to create a deliverable, it’s to change something in the world — to create an outcome. We start with assumptions instead of requirements. We create and test hypotheses. We measure to see whether we’ve achieved our desired outcomes »
  
  
• Pour éviter la douche froide à la sortie, il faut donc inclure la boucle d’apprentissage à partir des feedbacks clients le plus tôt possible, et à toutes les étapes du processus de développement Lean Startup, depuis le Design Thinking jusqu’au Growth Hacking. Les auteurs insistent sur l’utilisation de tous les canaux de communication pour écouter les clients «Customers can provide feedback through many channels », selon les principes de ce que nous avons appelé le « Customer Feedback Learning Loop » (CFLL). Nous allons y revenir avec le livre suivant. Il faut aller voir les clients sur place (ce que les auteurs appellent GOOB : Get out of the Building) : « It’s the realization that meeting-room debates about user needs won’t be settled conclusively within your office ».

 3. Lean Analytics

Le deuxième livre est « Lean Analytics : Use Data to Build a Better Startup Faster » de Alistair Croll et Benjamin Yoskovitz. C’est également un livre de la collection « The Lean Startup Series ». Ce livre est très riche, plus long que le précédent, et contient beaucoup de chiffres utile. Il commence par un principe qui n’est pas sans rappeler Ash Maurya : « don’t sell what you can make, make what you can sell ». C’est un ouvrage de référence pour développer la dimension analytique d’une démarche Lean Startup, puisqu’il contient à la fois des conseils pour choisir ses métriques et des ordres de grandeur de comparaison qui sont très utiles pour commencer (« There’s lots of information in this book. We interviewed over a hundred founders, investors, intrapreneurs, and innovators, many of whom shared their stories with us, and we’ve included more than 30 case studies »). Le résumé qui suit est plus incomplet qu’à l’habitude, il s’agit vraiment d’une incitation à la lecture.

• L’innovation est une démarche complexe, qui demande beaucoup de travail (« Innovation is hard work — harder than most people realize »), même si la technologie rend le passage à l’acte facile (« It’s vanishingly cheap to create the first version of something. Clouds are free. Social media is free. Competitive research is free. Even billing and transactions are free »). On retrouve ici les conseils de Oussama Amar aux jeunes entrepreneurs. Il n’est jamais trop tard pour bien faire (build-measure-learn) mais il vaut mieux commencer une démarche lean startup dès le départ : « Many startup founders discover Lean Startup at a specific point in their growth: they’ve built a product and it has a bit of traction, but not enough to be exciting ». Comme exprimé précédemment, l’utilisation de l’approche analytique ne remplace pas l’intuition et la vision, mais c’est un outil pour corriger ses propres erreurs : «  Lean Analytics isn’t about eliminating your gut, it’s about proving your gut right or wrong ».
  
  
• La première métrique qui doit être le centre de l’attention est celle de l’usage, et plus précisément le « Monthly Average Users » (MAU). Je cite ce paragraphe car il contient l’essentiel :  « The real metric of interest — the actionable one — is “percent of users who are active.” This is a critical metric because it tells us about the level of engagement your users have with your product. When you change something about the product, this metric should change, and if you change it in a good way, it should go up. That means you can experiment, learn, and iterate with it ». Le reste du livre donne beaucoup de détail sur la mesure des MAU, qu’il s’agisse de SaaS, de e-commerce ou d’applications mobiles.
  
  
• L’approche analytique est au cœur de la démarche Lean Startup (build-measure-learn) puis qu’il s’agit précisément d’apprendre à partir des nombres. Au delà du MAU, les auteurs introduisent plusieurs métriques dans la lignée des « pirate metrics ». On retrouve l’acquisition, l’activation (« The percentage of people who download the app, actually launch it, and create an account »), la rétention (et son opposé, le churn) et la viralité. Le churn reçoit une grande attention, en particulier dans le domaine du SaaS, ce qui est parfaitement judicieux selon ma propre expérience. On retrouve très vite la référence au Growth Hacking : « Growth hacking is an increasingly popular term for data-driven guerilla marketing. It relies on a deep understanding of how parts of the business are related, and how tweaks to one aspect of a customer’s experience impact other ». On retrouve également les conseils de la catégorie « nail it, then scale it » comme celui-ci : « There’s a risk that you build virality and word of mouth at the expense of engagement ». Je souligne également le point suivant qui justifie la décomposition en trois cercles que j’ai proposé en introduction : « Growth hacking combines many of the disciplines we’ve looked at in the book: finding a business model, identifying the most important metric for your current stage, and constantly learning and optimizing that metric to create a better future for your organization ».
  
  
• Comme l’avait déjà remarqué Ash Maurya, la mesure doit être combinée avec le contact direct avec les utilisateurs : « Customer development is focused on collecting continuous feedback that will have a material impact on the direction of a product and business, every step of the way ». Le livre contient de nombreuse anecdotes à ce sujet, telle que : « Then co-founder and CEO Kyle Seaman did something critical: he picked up the phone. Kyle spoke with dozens of parents. He started calling parents who had signed up, but who weren’t active ». Pas besoin de voir trop grand : « We suggest that you speak with 15 prospective customers to start. After the first handful of interviews, you’ll likely see patterns emerging already ». Mais, également comme Ash Maurya, les auteurs nous préviennent de la difficulté : « For one thing, user feedback suffers from horrible sampling bias. Few people provide feedback when they have a predictable, tepid experience. They reach out when they’re ecstatic or furious. If they’re feeling aggrieved, you’ll hear from them ».
  
  
• La méthode préférée pour réussir une innovation est de construire une petite communauté d’utilisateurs et de la satisfaire au point d’en faire des ambassadeurs : « After all, if you can’t convince a hundred users to stick around today, you’re unlikely to convince a million to do so later ». On retrouve ici les propos de Guy Kawasaki, et on peut évidemment faire le lien avec le principe « nail it then scale it » de Nathan Furr préalablement évoqué, « Your top priority is to build a core set of features that gets used regularly and successfully, even by a small group of initial users » ; « There’s no question that growth is important. But focusing on growth too soon is bad ». Je vous recommande l’exemple de Reddit sur l’utilisation de sa communauté : « Reddit has an engaged, passionate community, and it’s perfectly designed to collect feedback ».
  
  
• Ce livre est un trésor en terme d’exemples chiffrés et d’ordre de grandeur pour comprendre ses propres résultats. Voici un exemple frappant : « Joel shared some numbers with us: 20% of visitors create an account (acquisition). 64% of people who sign up become “active” (which the founders define as posting one status update using Buffer). 60% of people who sign up come back in the first month (engagement/stickiness). 20% of people who sign up come back (are still active) after six months (engagement/stickiness) ». Les auteurs proposent de travailler « one core metric at a time » : « The core idea behind Lean Analytics is this: by knowing the kind of business you are, and the stage you’re at, you can track and optimize the One Metric That Matters to your startup right now ». Cette notion d’étape et de contexte métier est essentielle pour apprécier les métriques que l’on suit : « You need to know what sport you’re playing. Online metrics are in flux, which makes it hard to find a realistic baseline. Only a few years ago, for example, typical e-commerce conversion rates were in the 1–3% range. The best-in-class online retailers got a 7–15% conversion rate, because they had offline mindshare or had worked hard ». Les auteurs donnent également des chiffres sur ce à quoi il faut s’attendre en terme de génération de contenus par les utilisateurs : « By our estimates, expect 25% of your visitors to lurk, 60–70% of your visitors to do things that are easy and central to the purpose of your product or service, and 5–15% of your users to engage and create content for you. 
  
  
  
  
  
  
  
• En particulier, ce livre est indispensable pour construire des applications mobiles. On trouve le même genre d’ordre de grandeur particulièrement utile : « For mobile applications, 30% of the people who download the app use it each month. 10% of registered users will use the service or mobile app every day. The maximum number of concurrent users will be 10% of the number of daily users ». Je reproduit ici l’illustration trouvée dans l’article de Peter Farago sur l’engagement et a loyauté par type d’application, parce que ce graphique me semble très utile pour évaluer le comportement des utilisateurs d’une nouvelle application. Les explications sur la viralité des applications mobiles sont également utiles : « Recall that virality is actually two metrics: how many new users each existing user successfully invites (your viral coefficient) and the time it takes her to do so (your viral cycle time). ». Ces conseils sont déclinés dans le cas du modèle freemium, pour lequel les auteurs conseillent de s’assurer que la valeur d’usage augmente avec le temps. Un autre exemple de statistique utile : « An October 2012 study by mobile analytics firm Flurry showed that across more than 200,000 applications, only 54% of users were still around at the end of the first month, only 43% were around at the end of the second, and only 35% were using the application by the end of the third ».
  
  
• Pour finir, ce livre donne des multiples équipes pour des équipes qui veulent mettre en place une démarche lean startup, et en particulier une démarche d’« intrapreneurs ». Je suis particulièrement en phase avec l’idée de la « minimum viable vision » (l’ensemble des UVP) : « A minimum viable vision (MVV) is one that captivates. It scales. It has potential. It’s audacious and compelling ». Il y fort logiquement une très grande cohérence avec Running Lean : « Find Problems, Don’t Test Demand Once you start doing customer development, remember that you’re testing problems and solutions — not existing demand ». Je vous recommande également très chaleureusement les 14 règles librement adaptées de Kelly Johnson. Je termine ici avec mes 5 préférées : (1) exiger l’accès à de vrais clients (2) construire une petite équipe agile … si ce n’est pas possible, vous n’avez pas les conditions de réussite (3) tester vos propres produits et passez du temps en face-à-face avec vos utilisateurs (4) protégez l’équipes des pessimistes et des agressions externes (5) faite du client un acteur majeur du processus d’innovation et transformez vos tests en marketing.