STEPH CRUCHON : Bonjour à tous, c’est donc notre dernier talk de la journée et je suis heureux et fier d’accueillir Jake Knapp. Inventeur du design sprint, le livre best best-seller du New York Times. Jake a passé dix ans chez Google où il a conçu des produits comme google hangout (Google Meet), il a également créé des produits comme gmail et il a fait partie de Google ventures (GV). Et dans le cadre de Google Ventures, il a créé un processus qui s’appelle le design sprint.

J’en parlais juste avant et il est bien sûr l’auteur de notre bible – Sprint, How to solve big problems and test new ideas in just 5 days, le livre bleu que tout le monde a déjà vu. Et c’est l’un des livres les plus influents dans le domaine de UX.

Jake Knapp a coaché des équipes dans des organisations comme Slack, Lego, Ideo, Harvard, Nasa et je suis tellement jaloux qu’il a été invité au MIT et à la Harvard Business School. Et il est actuellement parmi les plus grands designers du monde… et cette blague ne vieillit pas, n’est-ce pas ?

Alors, je vous prie d’accueillir mon ami Jake Knapp, de Seattle, États-Unis.

JAKE KNAPP : merci beaucoup Steph. Je vais partager mon écran et juste pour briser l’illusion que je sais ce que je fais ici. Vous devez me regarder partager lentement mon écran.

Je vous remercie tous de vous être levés tôt, d’avoir veillé tard ou d’être sur votre ordinateur à une heure normale, selon le fuseau horaire dans lequel vous vous trouvez. J’apprécie et je suis vraiment heureux d’être ici. Même si j’espérais que ce soit en Suisse. Quand nous avons commencé à en parler, je m’imaginais vraiment être en Suisse en août, en ce moment même, mais vous savez, c’est toujours aussi charmant, alors je voudrais vous parler du design sprint et de la façon dont vous pouvez l’utiliser comme une sorte de recette d’innovation. Mais je sais aussi que vous étiez peut-être assis devant votre ordinateur toute la journée. 

Je veux donc d’abord vous donner l’occasion de faire quelque chose de différent, une petite pause dansante. 

Je pense que les pauses sont importantes pendant la quarantaine, donc je suis 100% sérieux, je vais mettre de la musique, Steph et Julien vont la diffuser en streaming et vous l’entendrez et je vais danser et j’espère que les gens qui sont sur zoom vont danser. Nous devrions tous danser pendant 60 secondes, juste pour se remuer un peu, donc si vous êtes tous prêts.

Allons-y ! Au fait, je ne suis pas un bon danseur, je n’ai commencé à danser dans l’intimité de ma maison que depuis la quarantaine. Donc vous ne pouvez pas vous mettre dans l’embarras.

Merci pour ceux qui ont dansé ! 

Donc, un petit avertissement avant que je ne me lance dans la discussion, c’est un pitch de vente pour le design sprint.

Je vais juste être franc à ce sujet, je vais essayer de vous convaincre de faire des design sprints. Je ne vais pas m’excuser pour ça, c’est juste comme ça que je fonctionne. Mais avant de te proposer de faire des design sprint, je veux parler de petit déjeuner.

C’est moi dans ma cuisine et je peux voir mon chien. Ici, c’est moi dans ma cuisine et je ne suis pas un bon cuisinier, d’accord ? Je ne le suis pas, je vais être honnête avec vous, la seule chose que je sais faire c’est des œufs brouillés et je ne les fais pas très bien.

Une partie de ma philosophie dans la cuisine est de faire les choses le plus vite possible, de sortir de là, donc je n’utilise pas beaucoup d’ustensiles supplémentaires. Pour les œufs brouillés, je casse les œufs directement dans la poêle et je les mélange avec la spatule, parce que vous savez que vous économisez sur le nettoyage après coup, et ces œufs sont un peu dégoûtants. Mais c’est comme ça que je le fais, d’accord. La façon dont je le fais – est un problème. Et j’y reviendrai.



Avant, je vais vous raconter le reste de cette histoire d’œufs brouillés. Cela me rappelle tout ce sujet de problèmes et j’ai des problèmes, des problèmes personnels, des problèmes d’œufs brouillés, des problèmes de produits aussi, j’ai des problèmes pour construire des produits depuis longtemps parce que je construis des produits depuis longtemps. J’ai toujours été intéressé par la création de produits et ce, depuis mon enfance.

Si nous retournons dans le temps jusqu’en 1989, quand j’avais peut-être 11 ou 12 ans. C’est une photo de moi travaillant sur un ordinateur à cette époque, et j’utilisais ce programme appelé hypercard pour faire des jeux vidéo. Il y a un jeu vidéo que j’ai fait quand j’étais enfant, je déplaçais la souris dans le labyrinthe et c’était génial.

Mes seuls clients à cette époque étaient mes amis et je travaillais seul, donc je n’avais pas besoin de négocier avec les autres si je pouvais trouver comment le faire, je pouvais le faire et si mes amis aimaient le jeu, alors c’était un succès. C’était donc parfait, pas de problème à ce moment-là.

Environ 10 ans plus tard, je commençais à être plus adulte, j’ai obtenu mon premier emploi dans une entreprise, J’ai travaillé pour Oakley, la société de lunettes de soleil, et mon travail consistait à réaliser des gifs animés. C’était des publicités de ce genre à l’époque. Vous n’alliez pas sur Google, vous alliez sur Yahoo et il y avait des bannières publicitaires, des gifs animés, alors je faisais ces publicités gif animées pour les lunettes de soleil .C’était un peu bizarre parce que en gros mon travail: je trouvais un tas d’idées différentes pour différentes publicités. Mon patron venait à mon bureau, s’asseyait sur mon bureau, remontait la manche de sa chemise, mettait son bras juste à côté de mon visage et me demandait de regarder les publicités que j’avais faites et il me disait : si les poils de mon bras s’hérissent, alors on va les utiliser. Et donc je passais en revue toutes les idées que j’avais et il me disait non, non, non. Et puis oui… c’était bizarre, non ? C’étais bizarre, mais avec le temps, j’ai commencé à comprendre ce qui lui plaisait, et j’ai compris, mais vous savez, c’était vraiment bizarre.

C’était en quelque sorte mon premier contact avec  la création de produits.

Quelques années plus tard, j’ai trouvé un emploi chez Microsoft et j’ai rencontré les mêmes problèmes qu’avec ce boss bizarre. En fait, mes boss directs étaient plutôt bons, mais il y avait un autre problème, comme celui du manager qui micromanage ce sur ce sur quoi vous travaillez.

C’est comme si vous pensiez que vous aviez un plan bien défini au sein de votre équipe ou en tant qu’individu, et puis une personne entre, et c’est un grand patron. Vous savez, parce que l’organisation est vraiment grande, il y a un super grand patron d’un autre département ou d’un autre organisme qui arrive et qui change les choses, et c’était vraiment frustrant.

Il est également difficile de travailler dans un groupe de personnes. Avant, je ne travaillais que seul, et maintenant, quand on travaille avec des gens, on parle beaucoup. Tant de discussions et je ne sais pas si vous avez déjà été dans les réunions qui se déroulent comme ça, mais c’était toutes les réunions comme ça. C’était juste des allers-retours, des gens qui se lancent dans des brainstormings, des gens qui se disputent et c’est frustrant. C’est tellement frustrant, c’est difficile de faire avancer les choses.

Mais malgré tout cela, je dois dire que j’ai eu de la chance d’avoir une bonne équipe ; nous avons travaillé sur un projet vraiment cool appelé l’Encyclopédie Encarta. Il s’agissait d’une encyclopédie sur cd-rom que Microsoft avait réalisée tout au long des années 1990. C’était un vrai succès et vous savez que c’est ce sur quoi nous travaillions, c’était cool la façon dont nous l’avons construit.

Nous sortions chaque année une nouvelle version et le processus de développement du produit était une machine bien huilée. Nous construisions, construisions, construisions, construisions et nous lancions. Chaque automne et chaque fois que les enfants retournent à l’école pour qu’il y ait une nouvelle version de l’encyclopédie, nous savions vraiment comment faire ça.

L’équipe faisait ça depuis longtemps avant que j’arrive et c’était cool jusqu’en 2001. Maintenant, en 2001, un site web est sorti qui portait le nom de Wikipedia et au début, nous avons trouvé ça assez drôle, car vous pouvez voir qu’ils n’avaient même pas leur nom au-dessus du fold du site web. Mais avec le temps, c’est devenu moins drôle parce que très vite, il y avait plus d’articles que dans encarta et les gens n’allaient plus sur yahoo, ils allaient sur google.

Ils font des recherches, les résultats de Wikipedia apparaissent en haut de la page. C’était vraiment très mauvais pour nous, alors nous essayons de trouver quoi faire. Et nous avons réfléchi, nous nous sommes disputés et nous avons discuté avec les gens et vous savez, nous avons fait la même chose que lorsque les patrons sont arrivés, nous avons dû négocier avec différents patrons. Nous essayons de négocier entre nous et un nouveau problème est apparu, celui de l’aversion pour le risque.

Nous avions peur de tout gâcher et nous savions donc que nous gagnerions un peu d’argent en vendant notre produit actuel et, comme nous étions dépendants de cet argent, nous ne voulions pas essayer de donner notre produit gratuitement en ligne. Et cette aversion pour le risque a fini par faire chuter notre produit parce que nos ventes devenaient de plus en plus petites et finalement, comme nous ne faisions pas une concurrence efficace à wikipédia en ligne dans ce nouvel espace gratuit, il n’y avait aucune raison de maintenir le produit en vie.

Et puis Encarta a été fermé. Donc en 2005, je travaillais toujours chez Microsoft. Je suis allé travailler sur un nouveau projet. C’était une idée géniale. Nous avons eu l’idée de créer un appareil à écran tactile avec un magasin d’applications qui, avec le temps, nous dira que c’était une très bonne idée, mais vous avez peut-être remarqué que la plupart des appareils à écran tactile avec des magasins d’applications que vous utilisez ne sont pas créée par Microsoft.

Les raisons étaient les mêmes que celles qui m’ont troublé ailleurs où j’avais travaillé. Le patron avait une trop grosse voix, avait une aversion pour le risque, nous avons fait valoir que nous avions essayé de convaincre différents dirigeants de l’entreprise de soutenir notre plan et finalement, au bout d’un an et demi, ce projet a été tué. Avant même que nous ayons créé pu lancer le produit… frustrant !

Tellement frustrant ! J’ai pensé qu’il devait y avoir une meilleure façon de construire les choses, alors j’ai quitté mon emploi chez Microsoft pour aller travailler chez Google. Parce que je suis un traître, et chez Google j’ai travaillé sur Gmail. Et dans l’équipe de Gmail, j’ai trouvé beaucoup de problèmes identiques, mais sous une forme différentes. Nous avions des supérieurs qui essayaient de comprendre ce que Larry, Sergey ou Eric Schmidt pensaient. Et on entendait des ouï dire, et quand on  les rencontrait vraiment et ils proposaient des choses nouvelles, donc c’était un peu difficile.

Mais il y avait un nouveau problème : j’ai trouvé beaucoup de distractions chez Google. Tout le monde était tellement motivé pour faire de grandes choses. Ils étaient tellement responsabilisés et excités. Il y avait beaucoup de sollicitations. Au début, j’ai commencé à accepter des meetings à mon calendrier. J’étais ravi de commencer à rencontrer des gens c’était cool. Je me suis mis dans dans le rythme de l’équipe, mais très vite, mon calendrier a commencé à déborder, les calendriers de tout le monde étaient remplis et on travaillait sur plusieurs projets à la fois, on jonglait avec les contacts toutes les 30 à 60 minutes. Et il est impossible de faire avancer quoi que ce soit d’important quand on change constamment d’interlocuteurs et qu’on saute de reunion en réunion.

Ces problèmes étaient donc difficiles. c’était compliqué. Pour donner un exemple de l’impact que ça avait, en 2007, j’avais commencé à travailler sur un nouveau projet. C’est un projet que j’ai lancé avec quelques autres ingénieurs. Nous l’avions appelé « Google meeting ». Notre idée était de faire du chat vidéo multidirectionnel dans le navigateur web et nous avons pensé que cela serait utile pour les personnes dans les entreprises.

Nous avons donc travaillé sur ce projet pendant quelques années et pendant tout le temps, pendant lequel on y a  travaillé, on a essayé de trouvé du soutien pour faire avancer cette idée. Nous rencontrions tous ces mêmes problèmes de distraction, et en voyant cela, j’ai réalisé que oh mon Dieu, j’avais déjà connu ça: c’était vraiment similaire à ce qui s’était passé chez Microsoft. Il fallait donc faire quelque chose pour y remédier. En 2009, je suis allé à Stockholm, où les deux autres personnes travaillaient, et j’ai passé une semaine avec eux. Au mois de janvier.

Nous avons libéré nos calendriers et nous avons décidé de faire un prototype de cette vague idée; nous nous sommes mis d’accord sur ce à quoi elle pourrait ressembler. La vidéo en haut, les petits flux vidéo en bas, nous avons réfléchi un peu à la manière de commercialiser et d’expliquer ce qu’était ce produit “Google meeting”, puis l’ingénieur a construit un prototype qui fonctionnait déjà plus ou moins à la fin de la semaine.

Nous avons commencé à l’utiliser dans notre équipe Gmail, nous avons commencé à l’utiliser dans l’entreprise, et finalement cet outil a été lancée comme lieu de rencontre sur Google et finalement comme outil de réunion sur Google. Je pense que la pandémie a été très bonne pour leur business d’ailleurs.., mais ce projet m’a semblé assez cool quand j’y repense, parce que nous étions partis sur voie très mauvaise, marquée par les pires problèmes d’organisation, et nous avions construit un prototype en une semaine et une fois le prototype construit, on a pu aller de l’avant et tout a changé. 

Parce que nous avions alors confiance dans le fait que c’est quelque chose de précieux c’est quelque chose que nous devrions construire et nous avions compris, en gros, sous quelle forme cela fonctionnerait. Nous pouvions enfin nous arrêter de discuter et commencer à construire.

J’ai commencé à penser aux premières étapes des grand projet et je me suis dit que j’avais déjà travaillé dans plusieurs grandes entreprises et que je n’avais jamais vu de pratiques efficace pour le lancement de grands projets. Je n’ai jamais vu des équipes faire autre chose que d’être chaotiques et de se battre au début parce que c’est difficile quand on a une idée et que l’on doit la pousser plus loin. C’est difficile, on peut être paralysé en essayant de trouver par où commencer.

Je vais remonter le temps jusqu’en 2007.

2007 j’avais lu cet article dans le magazine New Yorker et cet article s’appelait la checklist. Vous pouvez encore le consulter maintenant, il est gratuit en ligne.

C’est fascinant, Atul Gawande, a fini par écrire un livre sur ce sujet appelé The Checklist Manifesto: How to Get Things Right. Et ce dont il parle de check-list, c’est de cette idée que, lorsque vous montez dans un avion. Ils ont suivi une check-list précise  avant de décoller, ils se sont assurés qu’ils avaient du carburant, ils ont vérifié tous ces différents systèmes et ils utilisent une checklist très précise. Ils s’assurent que tout est en ordre avant de décoller. 

Ce que Gawande proposait, on voit la même chose dans les hôpitaux, les soins médicaux sont devenus si complexes que nous ne pouvons pas simplement supposer que nous allons nous souvenir de toutes les étapes à chaque fois.

Que nous connaîtrons toutes les meilleures pratiques que nous devrions suivre. C’est une excellente idée et il a mis le lecteur au défi de réfléchir à la manière dont des check-lists pourraient être appliquées ailleurs dans le monde. Et quand j’ai lu ça, j’ai pensé : C’est une idée vraiment très intéressante.

En 2007, j’allais donc utiliser des check-lists pour tout ce que je pouvais faire dans mon travail. J’avais une check-list pour mon courrier électronique, avant de faire une présentation, avant de faire un travail de design. J’allais avoir une check-list pour garder une trace de mes différentes check-lists. J’étais satisfait de la manière dont ça marchait. Trois ans plus tard, j’ai commencé à réfléchir à la possibilité d’utiliser une check-list pour le début des projets. Et si je commençais à mettre au point un moyen de s’assurer avant le vol que nous avions fait les éléments dont nous avions besoin pour être sûrs de pouvoir démarrer et j’ai trouvé cette idée vraiment géniale.

Je me dis qu’il y a un truc à faire. Donc, je commence à travailler sur cette check-list de grand projet. Je n’étais pas sur ce qui devrait y figurer, je ne le savais vraiment pas en fait.  J’avais le sentiment que dans mes expériences passées, au cours de ma carrière, il y avait eu des points positifs, des éléments de mon processus qui avaient très bien fonctionné. Et j’avais un peu ce sentiment lorsque j’ai commencé à assembler cette check-list de design que j’avais créée au cours des dernières années.

J’avais aussi une idée des projets qui avaient très bien fonctionné, comme Google Hangout (Meet), et au début de ce projet, cette semaine où nous nous étions tous réunis, ça avait tout changé. Ca c’était vraiment génial, et il y a aussi eu des moments similaires quand j’ai travaillé sur Gmail. Il y a eu des moments comme ça chez Microsoft et Encarta. Il y avait ces points lumineux qui avaient bien fonctionné et j’avais vu des équipes qui étaient vraiment efficaces.

Et je me suis dit que je pourrais capitaliser sur certains de ces moments et que je pourrais peut-être aussi, si j’utilisais une check-list, y ajouter de nouvelles idées. Si je lisais quelque chose que je trouvais cool, je pouvais le faire.En fait j’essayais de garder une trace de tout cela sur une check-list, et voir ce qui fonctionnait ou non. L’idée c’était aussi d’améliorer les choses au fil du temps.

J’ai donc décidé d’appeler cela un design sprint et en 2010, en travaillant chez Google, j’ai lancé le premier design sprint dans l’équipe Gmail. Et au cours des deux années suivantes, j’en ai organisé environ 25 avec différentes équipes de Google. Ensuite, je suis allé travailler chez Google Ventures où j’ai commencé à faire des design sprints avec des start-ups. Et avec mes collègues, il y avait tellement d’entreprises et startups dans notre portefeuille que nous étions capables de faire 20 25 30 design sprints par an et qu’en 2016, nous avions réalisé plus de 100 de ces sprints et avions vraiment perfectionné cette check-list.

Pendant que je faisais ces design sprints, je suivais en quelque sorte ce qui marchait et ce qui ne marchait pas. Je prenais des notes, je notais des idées, je notais des choses et je suivais cette check-list. 



Vous voulez probablement savoir ce qu’est un design sprint. Parlons de cela très rapidement. Vous avez un grand défi à relever et vous réunissez une équipe de personnes. Il devrait y en avoir cinq à sept. J’ai trouvé que plus de sept ralentissent les choses. Vous en voulez en quelque sorte cinq pour avoir des opinions diverses, même si vous pouvez le faire avec moins ou plus s’il le faut.

Mais c’est le 5 à 7 le point idéal.  Il faut qu’ils aient des points de vue différents et qu’un décideur soit présent dans la salle. C’est la clé ! Vous devez faire entrer le patron. Vous prenez une semaine de temps, vous effacez le calendrier et puis au lieu des réunions normales, au lieu de tous ces emails et Slacks, toute cette routine qui nous rend tous fous.

Nous avons élaboré une check-list afin d’avoir une vue d’ensemble de son fonctionnement. C’est super granulaire et super spécifique mais avec en même temps une vision de haut niveau. 

Lundi l’équipe essaie de cartographie le problème et le contexte. la Map. Nous partons de ce problème initial et nous faisons en sorte que l’équipe se concentre sur un moment clé en partageant le maximum d’informations. On essaie de tout inscrire sur un tableau blanc et en choisissant à la fin de la journée un type de client cible et un moment clé sur lequel nous allons nous concentrer.

On décide donc que le reste de la semaine entière sera consacré à ce client, et à ce  moment. Nous recrutons cinq de ces clients cibles pour nous rejoindre le vendredi à la fin du design sprint et nous passerons le reste de la semaine à essayer de trouver des solutions. Nous pourrons ainsi essayer de simuler nos idées (les prototyper) et observer comment nos clients cibles réagissent.

Mardi, nous avons esquissé des solutions pour résoudre le problème Afin d’éviter de trop de discussions et que ça tourne en rond, j’ai trouvé le meilleur moyen de contourner ce problème pour uniformiser les règles du jeu et m’assurer que chaque membre de l’équipe puisse partager ses idées. 

La meilleure façon de progresser est de travailler seul dans la même pièce, en même temps, de sorte que tout le monde travaille en silence. Ils esquissent leurs propres solutions en détail. Nous pouvons alors avoir une saine concurrence entre les différentes solutions de chacun car elles ont été développées de la même manière. 

Mercredi, nous devons choisir entre ces différentes solutions. Le boss va être dans la pièce afin de valider la décision. Ce qui est très utile c’est que nous pouvons examiner et comparer toutes ces solutions. Nous pouvons le faire en silence, sans sales-pitch, parce qu’elles ont été esquissées. Nous faisons une “critique” rapide, nous écoutons le point de vue de chaque personne de l’équipe.

Mais en fin de design sprint, c’est le Décideur qui prend la décision en choisissant deux ou trois solutions qu’il veulent voir prototypées.

Jeudi, nous construisons ce prototype. Et afin de pouvoir vraiment éviter le problème  d’aversion au risque, on insiste bien en disant à l’équipe que l’on crée une simulation, pas un produit réel. Nous allons simplement simuler ce à quoi il pourrait ressembler une fois terminé. Et tout peut encore changer. 

Pour vous montrer à quoi ça peut ressembler, voici un exemple d’application iPad simulée. A première vue, elle semble se trouver dans l’app store, mais ce ne sont que des captures d’écran et des animations. Avec un bon designer, il est facile de créer un prototype réaliste comme celui-ci en une journée.

Vendredi, nous testons notre prototype et nous faisons venir de vrais clients pour tester, afin de simuler ce que ça sera,  au lieu de discuter de ce qui pourrait arriver dans le futur, ce qui est au cœur de la plupart des problèmes que j’ai rencontrés en créant des produits.

Et j’ai vu des équipes dont l’expérience de construction de produit se résumait à de l’incertitude. Nous voulons que les choses fonctionnent, alors nous nous disputons à ce sujet. Nous ne voulons pas perdre de temps, nous ne voulons pas gâcher l’opportunité de cette idée géniale, alors nous nous disputons.

Mais au lieu de cela, nous pouvons voir de nos yeux, et maintenant comment ça se passera, et en tirer des leçons, et c’est ce qui se passe le vendredi. Nous organisons des entretiens individuels avec une personne de l’équipe qui s’entretient avec 5 clients cibles, en les faisant utiliser le prototype. Ces cinq interviews se déroulent les uns après les autres, l’équipe observe depuis une autre pièce et prend des notes.

Nous sommes capables de faire des erreurs très tôt de cette façon, donc un tas de choses vont mal se passer pendant les tests de chaque design sprint. C’est attendu, c’est bienvenu, c’est exactement ce que nous voulons en fait. Nous voulons nous tromper tôt, nous voulons apprendre à la dure. En fait, dans un sens, ça n’est pas si difficile. De cette façon, nous sommes capables de construire la confiance avant de construire le produit. Ainsi nous pouvons éventuellement refaire un sprint, ou réparer les éléments qui doivent être améliorés, et tester ces modifications. Jusqu’à ce que nous soyons sûrs – que cette idée, est la bonne.

L’enjeu c’est que ce produit soit adapté au marché et que nous puissions aller tout droit,  au lieu de passer par cette longue route sinueuse. On fait une simulation au départ, puis on a la confiance nécessaire pour aller de l’avant, exécuter, lancer et construire ce produit de la bonne manière.

C’est donc comme ça que le design sprint fonctionne : on cartographie la situation (map), on décide d’un prototype et on le teste.

On se concentre sur un problème,  on efface le calendrier. Et on suit l’agenda du design sprint, L’équipe est concentrée, elle a des opinions, elle est décisive. C’est une façon complètement différente de voir le processus de création de produits.

Cela nous met dans un état d’esprit où on se permet de prendre des risques. On a le droit d’être audacieux et on ne sera pas punis par nos collègues si on se plante vite, et on ne sera pas punis non plus par le marché à long terme. Si nous avons tort, nous pouvons le découvrir d’emblée.

En 2016, je me sentais plutôt bien par rapport à ce processus, j’ai écrit un livre avec mes collègues, intitulé -Sprint (Solve big problems and test new ideas in 5 days). Ce livre contient une checklist super détaillée de 14 pages, et depuis quatre ans, le processus s’est vraiment étendu à partir de ces premiers sprints. Vous savez, avec ces start-up avec lesquelles nous avons travaillé avec Google, puis dans le monde entier.

Le sprint a été utilisé dans toutes sortes de contextes différents. Des design sprints ont été utilisés dans de grandes entreprises technologiques, chez Google, ce sont les premières équipes avec lesquelles j’ai travaillé en 2010 11 et 12 chez Google. Mais vous avez entendu Kai dire qu’elle a formé plus de 800 facilitateurs de sprints, elle a une véritable armée de personnes qui sont capables d’exécuter des design sprints tout autour de l’entreprise avec toutes sortes de produits.

Mais pas seulement sur les produits, comme vous l’a dit Kai. Il peut s’appliquer à différents types de challenges, comme des processus d’embauche, de la stratégie, des choses qui sont totalement liées à un système ou à un service que vous gérez au sein d’une entreprise. Les design sprints fonctionnent également dans les grandes entreprises technologiques qui détestent Google. J’ai entendu des histoires de design sprint dans des entreprises comme Apple, Amazon et même Microsoft et Facebook, qui détestent probablement plus que quiconque Google. Eux aussi ont utilisé des design sprints pour redessiner leur application et ont écrit à ce sujet publiquement.

Ce doit être parce que ça marche, je suppose, et non parce qu’ils aiment Google. Le design sprints fonctionne sans aucun doute dans les startups. Mon expérience de travail avec des entreprises a été super puissante et dans différents types de contextes, nous avons organisé des sprints avec une entreprise de café qui utilisait des design sprints

pour tester un service de livraison de café. Nous utilisons des design sprints avec Flatiron health, une entreprise qui a créé des logiciels d’oncologie,  avec One Medical, qui un réseau de cliniques de santé. Avec Uber, qui l’ont utilisé pour tester les nouvelles fonctionnalités et les nouveaux services qu’ils pourraient offrir. Avec Slack, qui utilise design sprints pour développer son marketing alors qu’il s’agissait au départ d’un outil pour entreprises de la tech,  qui au final s’est répandu au sein des corporates, dans le monde entier.

Ces entreprises avec qui on a travaillé  ont également réussi sur le plan commercial. Vous savez que certaines d’entre elles ont été rachetées par des entreprises suisses et que d’autres sont entrées en bourse. Vous savez, il a été prouvé que ces entreprises fabriquent des produits qui fonctionnent bien sur le marché. 

Mais le design sprints fonctionne également dans les organisations traditionnelles. Par exemple Save the Children, une organisation à but non lucratif au Royaume-Uni, qui a utilisé le sprint afin d’améliorer le développement précoce du langage chez les enfants.

Le British Museum utilise des design sprints pour améliorer l’orientation au sein du musée lui-même.

3M, avec l’aide de l’équipe de Kai à Google, a organisé des design sprints sur le post-it lui-même, ce qui est plutôt marrant, puisqu’on on utilise beaucoup de post-it dans un sprint.

Deutsche telekom utilise des design sprints pour réorganiser deutsche telekom, donc un peu peu méta, ils ont mené 12 design sprints d’un coup.  Le New York Times qui ne veut pas être en reste avec 13 design sprints  en même temps. 

Lego 80 design sprints en huit semaines pour tester de nouvelles idées de produits. Donc les design sprints fonctionnent vraiment pour toutes sortes de challenges.  Et vous savez, j’ai entendu des histoires de presque tout ce que je peux imaginer maintenant. C’est vraiment cool, c’est bien plus que ce que j’imaginais au départ et ça en est arrivé au point où les gens l’enseignent dans les universités : la London School of Economics enseigne les design sprints pour les étudiants de MBA. Je l’ai aussi enseigné au MIT. Ainsi qu’ aux étudiants de mba de la Harvard Business School.  Ces étudiants de MBA qui sont ces gens du mit et d’ Harvard qui créent réellement des startups et utilisent leur processus scolaire et design sprints pour tester ces nouvelles idées.

L’université de Reykjavik, en Islande, a organisé 96 sprints de conception en une seule fois il y a quelques années. L’année dernière, elle a organisé 100 design sprints en une fois et cette année, elle a organisé 100 design sprints en une fois mais entièrement en ligne. Tout cela online, en même temps.

Bien sûr, au cours de cette pandémie, c’est une autre histoire. On ne peut pas réunir cinq à sept personnes dans une même pièce, mais il s’avère qu’on peut faire des design sprints en ligne de manière vraiment efficace. Et voici quelques photos prises lors de ce sprint en islande. Si vous organisez un design sprint à domicile, les chats s’inviteront et aussi donc ça vaut le coup de zoomer sur les arrière-plans. 

Cette idée d’un design sprint à distance est quelque chose que des milliers d’équipes dans le monde entier ont expérimenté et et de plus en plus de choses sont en train d’être écrites sur les bonnes pratiques.

Voici donc une vidéo d’un design sprint que Steph Cruchon a en fait réalisé avec les Nations Unies et l’ONG Terre des Hommes. Je vais vraiment essayer de passer par-dessus ça très rapidement parce que le français n’est pas ma langue maternelle ni même une langue que je parle.

Mais vous pouvez voir ici dans ce laps de temps ce qui s’est passé. Ils ont trois design sprints parallèles avec des gens du monde entier, ce qui est en fait assez puissant de faire cela par vidéo conférence. Vous pouvez avoir des gens qui se trouvent dans des pays du monde entier et qui participent en même temps. C’est super cool ! 

Et tout cela est animé par le faciliateur  et, à l’aide d’un template, l’équipe dispose d’une sorte de salle commune, l’une d’entre elles étant destinée au tableau blanc partagé. Il y a outils plusieurs différents qui rendent cela possible comme Miro ou Mural. Il y a donc un template de Online design sprint que Steph a créé et j’y reviendrai à la fin de l’exposé.

Et nous avons mis au point avec mon co-auteur John Zeratsky et notre amie Jackie Colburn un template et des indications dans notre Remote Design Sprint Guide avec de nombreux détails sur la façon d’effectuer un design sprint online. Vous pouvez donc trouver tout cela à la fin, c’est totalement faisable.

Je dirais que c’est en fait un moment assez intéressant pour penser aux remote design sprints parce que les design sprints online  fonctionnent vraiment.  Ils vous aident à perdre moins de temps, à prendre plus de risques, à vous rapprocher de vos clients et d’entretenir le lien avec votre équipe.

Mais il est difficile d’essayer quelque chose de nouveau. Je me rends compte que je sais combien il peut être difficile d’essayer quelque chose de nouveau. Je vous ramène à ma cuisine. Vous savez, l’idée de cuisiner des œufs brouillés d’une manière différente était assez  intimidante. Ma femme m’a vu faire cela jour après jour après jour. Elle a vu l’expression sur mon visage et elle m’a dit : « Tu sais, pourquoi tu n’utilises pas un fouet ? Pourquoi ne pas mélanger les œufs avant de les mettre dans la casserole. J’ai dit que je n’utiliserai pas de fouet, je ne veux pas salir autre chose. Ça ne va probablement pas être mieux, pourquoi s’embêter.

Alors, année après année, je l’ai fait à ma façon, j’ai dit que c’était bon et finalement, après 20 ans,  j’ai dû préparer le petit déjeuner presque tous les jours pour mes deux garçons. Et ils n’aimaient pas mes œufs. Et parce qu’ils sont à la maison, parce qu’ils ne vont pas à l’école, j’en entends parler toute la journée.

Finalement, j’ai regardé autour de moi pour m’assurer que ma femme n’était pas là, j’ai pris des livres de cuisine et j’ai cherché comment faire des œufs brouillés. Ces livres de cuisine et ils disaient tous qu’il fallait utiliser un fouet. Alors j’ai sorti le fouet et j’ai mélangé les oeufs ensemble. Et vous savez ce qu’il s’est passé? Ces oeufs brouillés là étaient devenus excellents en fait… , donc la leçon de tout ça, ce n’est pas que j’aurais dû écouter ma femme il y a 20 ans, d’accord. Je veux juste être très clair à ce sujet, ce n’est pas la leçon.

La leçon, c’est que les recettes fonctionnent et que 2020 est une excellente année pour essayer quelque chose de nouveau. Je vous encourage donc à essayer la recette du design sprint. Essayez, vous savez, pour voir comment ça marche. Essayez-la à titre expérimental et vous en saurez plus à ce sujet sur jakeknapp.com

J’ai des liens vers le guide de Remote design sprint avec la template de Steph, l’histoire de la checklist, de ressources cool et plus sur design sprints.

Je vais maintenant répondre à quelques questions, mais avant cela, vous m’avez écouté parler pendant un certain temps. Je pense que vous avez mérité une autre petite dansante, nous allons donc prendre une dance break de 60 secondes avant de poser les questions.

Q&A

REMI RIVAS : Je me demandais le design sprint maintenant a plusieurs années,et il est de plus en plus populaire et de plus en plus de personnes qui ne sont pas familières avec le monde du design et des produits commencent à s’y mettre. J’ai remarqué un type de défi particulier, c’est-à-dire qu’ils sont OK de s’y mettre sérieusement pendant une semaine pour tester de nouvelles idées, mais le défi c’est souvent après. 

Vous avez montré comment prototyper et tester quelque chose grâce au Design Sprint, construire quelque chose grâce à design sprint, mais ce que nous observons la plupart du temps, c’est le retour soudain à la normale. Les clients ne sont pas préparés et l’organisation manque de personnes compétentes à l’interne. Auriez-vous des conseils à leur intention ou à la nôtre afin de capturer efficacement tout ce qui ressort du design sprint, afin qu’ils puissent exécuter derrière et maximiser les opportunités ? Vous savez que pour que cela devienne quelque chose de réel, il ne faut pas oublier ce qui va se passer dans quelques semaines ?

JAKE KNAPP : C’est une excellente question. C’est aussi un des grands défis que j’ai entendu. Kai a mentionné l’importance d’aligner le design sprint avec le moment où l’équipe est prête à exécuter. C’est aussi des choses que j’ai vues, c’est très frustrant. 

Ce n’est pas exactement ce dont vous parlez, mais le fait de perdre de l’élan par la suite parce que l’équipe ne commence pas à se construire directement après. 

Lorsque cela se produit, vous voyez cette grande idée, vous voyez que l’équipe a pris confiance, sait quoi faire, et a la confiance nécessaire pour exécuter. Et là il faut y aller. 

S’il n’y a pas une sorte de voie ferrée pour mettre ce train en marche immédiatement, cet élan n’a nulle part où aller.  Alors, l’une des condition numéro 1 c’est que l’équipe soit prête. En fait, avant de vous lancer dans un design sprint, il faut être sur que l’équipe a la capacité de construire derrière.

Mais une des choses que j’ai trouvé très utile, surtout quand une équipe se lance dans un projet ambitieux, c’est de faire suivre ce premier design sprint par un autre. Et lorsque vous améliorez ce que vous avez appris et vous arrivez vite au point où le prototype que vous avez créé pour votre design sprint et plus ou moins le modèle de ce que vous allez construire dans le futur.

Il montre aux gens ce à quoi il peut ressembler lorsque vous avez terminé et je pense que lorsque les gens voient quelque chose de réaliste, c’est très excitant. C’est ce que prouvent les tests effectués auprès des clients. De cette manière, cela peut changer la façon dont l’équipe fonctionne ; les gens peuvent se projeter et comprendre le concept car ça semble réel.

En général, vous savez, j’ai vu de nombreuses fois où les gens peuvent facilement renoncer à une idée trop abstraite, mais il est plus difficile de renoncer à une idée que vous avez vue et que vous avez expérimentée ; vous avez cliqué ou tapé dessus ou quoi que vous ayez utilisé la chose vous-même. S’il s’agit d’un prototype physique, vous l’avez tenu dans vos mains.

C’est très difficile de s’en éloigner, donc je pense que cela peut être puissant. 

En fait, on va toujours pousser le prototype jusqu’au point où il réponde à toutes les questions que vous vous posez. Et c’est assez cool pour motiver l’équipe. Mais une autre partie du design sprint consiste à raconter l’histoire de ce qui s’est passé pendant le sprint. et j’ai découvert que si je prends des photos pendant la semaine ou des captures d’écran, ça va faciliter le storytelling après coup. 

Et vous savez, lors des prochains mois, si j’ai des photos de ce qui s’est passé lors du design sprint, je pourrai facilement partager l’histoire. 

Il y a une histoire derrière chaque design sprint qui suit un arc similaire. Les détails sont différents, mais l’histoire est la même. 

Et c’est que nous avions un gros problème, une grosse question à laquelle nous devions répondre, nous avons réuni un groupe de personnes. C’est comme le Seigneur des Anneaux, the fellowship of the ring. 

Ensemble, nous avons décidé de répondre à cette question, nous avons dessiné ensemble une Map, comme au début de chaque grande histoire d’aventure, il y a une carte… et puis nous avons décidé que c’était là que nous allions nous concentrer, nous avons trouvé ces solutions. Nous avons construit ce prototype, que nous avons pu montrer aux gens et ce que nous avons appris. J’ai des images des personnes qui font les interviews, par la suite, je pourrai les montrer à qui de droit, et leur présenter les questions clés que nous avons posées. Et la fameuse scorecard, afin de montrer ce qui était vert ou rouge.

Ensuite, je peux parler de ce que nous avons décidé de faire par la suite et de cette histoire, cette sorte de mystère qui a été créé sur ce qui va se passer lorsque nous ferons le test. Et puis nous faisons le test et il y a des réponses. Je pense qu’il peut être utile de faire participer le reste de l’équipe si vous avez une petite équipe qui fait le design sprint et qu’elle doit ensuite aller diffuser cette idée aux autres au sein de l’entreprise.

Cela peut aider les gens à avoir l’impression de comprendre l’histoire de l’origine du projet et de ne pas se sentir comme si cet autre que vous connaissez avait été amené par des étrangers. On nous a juste demandé de faire mais au lieu de cela, on a l’impression de comprendre que nous savons pourquoi les choses sont comme elles sont et qu’en tant qu’humains, nous voulons juste savoir pourquoi on fait les choses.

REMI RIVAS: A propos de ce que vous avez dit sur le fait d’être sûr que le client est réellement prêt à se lancer dans des sprints. Je sais que vous adorez les check-list vous-même, auriez-vous des questions clés spécifiques qui vous viennent à l’esprit sur la façon de vérifier que le client est réellement prêt à effectuer des sprints ?

JAKE KNAPP : J’ai des questions clés et j’ai une sorte de check-list pour avant le design sprint et c’est assez simple en fait. L’une des questions est de savoir si le ou la boss qui est le décideur sur le projet sera là. Pouvez-vous être certain que cette personne sera dans la salle ? Si le décideur est absent, c’est déjà un très mauvais signe. C’est un signe qu’ ils ne sont pas investis que ce projet n’est pas aussi important que nous le pensions. C’est un indicateur que ça n’ira pas.

Le décideur doit être dans la pièce. L’équipe est-elle capable d’effacer complètement son calendrier, de se focaliser et de participer à tout le design sprint? Encore une fois, c’est une question assez simple, mais elle me dit aussi si ce projet est bon, s’il est prêt. Et puis la dernière question qui est très logique et fait – êtes vous prêts à construire, à executer dès que le design sprint est terminé? Quand ce projet va démarrer et si le projet ne démarre pas peu de temps après la fin du design sprint, vous devez vous inquiéter de savoir s’il va démarrer tout court.

SABRINA GOERLICH : Hello Jake, merci pour le talk. J’aimerais changer un peu de perspective. Je sais que vous écrivez un nouveau livre et qu’il s’agit de science-fiction, c’est juste ? Donc si design sprints faisaient partie de ce livre, quels problèmes résoudrez-vous avec lui? 



JAKE KNAPP : Comment utiliser le design sprint dans un processus d’écriture ? C’est vrai, le problème est en partie que je veux écrire un livre de science-fiction. Mais je pense que ce que j’essaie d’accomplir avec ce livre, c’est que je veux m’aider moi-même. L’écriture est en quelque sorte, pour moi, une façon pour moi de penser.

Si j’écris quelque chose, cela me permet d’organiser mes pensées d’une manière différente. Et donc ce livre est un moyen pour moi d’organiser mes pensées sur mon enfance, sur l’expérience d’être un enfant, sur la mémoire et la conscience, sur ce qui fait que les humains sont conscients et sur technologie… Je pense qu’il est vraiment intéressant de savoir ce qu’est l’intelligence artificielle et comment je peux essayer de mieux comprendre ce qu’elle signifie pour nous tous, à l’avenir.

C’est donc un problème très égoïste, je suppose que c’est à moi d’essayer de réfléchir à ces choses. Mais je pense qu’il y a peu de chances que je puisse le faire correctement parce que je suis un écrivain de business books et à priori pas un auteur de science-fiction mais si je pouvais le faire d’une manière ça marche bien pour moi, peut-être que ça sera intéressant pour d’autres personnes aussi. Et nous verrons cela, le temps nous le dira. Mais c’est un peu l’idée derrière tout ça.

MITTALI : J’ai des difficultés à obtenir du temps de la part des parties prenantes. Donc mon design sprint finit par se diviser en deux efforts sur trois semaines. Cela vous semble-t-il être un problème familier? 



JAKE KNAPP : Ça ressemble vraiment à un problème familier et euh, vous savez, si vous pouvez obtenir leur temps et c’est la seule façon de le faire. Ensuite, vous répartirez le design sprint. Deux semaines, c’est faisable. Trois semaines, j’imagine que ça devient difficile. C’est difficile de faire raccrocher les participants, se mettre dans le bain. Ce qui fonctionne si bien avec le design sprint, c’est que chaque jour, lorsque les gens reviennent, ils ont toujours à l’esprit tout le contexte, ce qui s’était dit, ce que nous avions construit ensemble. 

Toutes les informations qui ont été partagées depuis la veille. Nous sommes donc prêts à avancer ensemble, et à en faire plus. 

Cela signifie qu’à la fin de la semaine, ce que l’équipe est capable de faire et la rapidité avec laquelle elle est capable de prendre des décisions complexes est remarquable. C’est quelque chose que l’on ne voit jamais dans les réunions de 30 à 60 minutes que nous avons normalement. Vous y perdrez bien sûr, si vous devez découper les journées et répartir. Mais si c’est ce que vous devez faire pour impliquer les personnes clés, c’est faisable. 

J’essaierais de faire en sorte que ce soit réparti sur deux semaines et non sur trois, simplement parce que cela va devenir de plus en plus difficile à mesure que les réunions s’étalent. Divisez l’équipe en deux parties pour avoir une équipe de base qui soit là. Il y a un moyen d’obtenir une équipe de base qui est là toute la semaine et certains de ces acteurs clés que vous avez mentionnés ne sont peut-être là que le lundi. Et vous savez que le mardi ou le lundi et une partie de mercredi, mais la core-team continue de fonctionner tout au long de la journée. Le lundi on va faire les interviews d’experts, c’est un bon moyen d’inviter les personnes qui n’auraient pas le temps.

Ils pourront aider à la prise de décision.  Et peut-être aussi que votre core-team peut être présente plus longtemps et que c’est une façon de faire les choses. 

Le but pour maximer les avantages du design sprints c’est l’implication des personnes de votre équipe. 

STEPH CRUCHON: J’ai une question personnelle. Je sais que le Danemark, par exemple, a trouvé un moyen de financer des sprints au niveau gouvernemental.

Peux-tu nous dire si tu sais si cela existe dans d’autres pays, comment cela a fonctionné, comment ils ont réussi à y parvenir. 

JAKE: Oui c’est juste, je ne sais que très peu de choses sur ce qu’ils font au Danemark, je ne sais pas. C’est un programme remarquable, mais en fait, je dirais que les gens à qui j’ai parlé Les personnes qui travaillent dans ce programme et qui sont vraiment géniales n’étaient pas sûres à cent pour cent de la genèse de ce programme au sein du gouvernement danois, mais le programme consistait essentiellement en des subventions pour les petites entreprises.



Et c’est ainsi que l’organisation qui le dirige maintenant depuis le gouvernement danois va associer une agence de design à une petite entreprise de n’importe quel type pour les aider à faire un design sprint pour leur entreprise et ils aideront à payer l’agence pour le travail effectué lors de ce design sprint et donc, comme vous pouvez l’imaginer, ils sont capables d’amener l’idée aux entreprises. Par exemple pour aider un restaurant ou autre, qui ne penserait pas immédiatement à faire un design sprint. C’est un outil qui nous permet de normaliser les choses et de leur donner une idée très claire de ce qu’il faut faire.

Voici un groupe de personnes qui peuvent vous aider à le faire. Nous avons travaillé avec eux, nous savons qu’ils sont bons et nous vous aiderons à le payer, donc c’est vraiment génial. Et je pense que de mon point de vue, c’est une chose géniale à faire pour votre économie aussi, parce que j’ai vu la puissance des design sprints et le fait d’aider les gens à éviter de gaspiller des efforts sur de mauvaises idées. Aider à encourager les gens à prendre les bons types de risques, c’est génial pour la dynamique, la dynamique du travail, il y a beaucoup de bonnes choses.

Mais c’est difficile, je ne vais pas vous dire que ce n’est pas compliqué et que vous savez que la check-list à la fin de ce livre est intimidante. Je pense donc que tout ce qui peut être fait pour faciliter les choses est géniale et ce programme est super inspirant. Malheureusement très unique et spécial jusqu’à présent.

BETTINA : Comment gérer un design sprint quand l’entreprise n’a pas beaucoup d’exploration ou de recherche (UX research) auparavant, je veux dire par exemple le fait d’utiliser un persona ou un user journey parce que c’est très courant ici en Argentine.

JAKE KNAPP : Vous savez, pour vous dire la vérité, je n’utilise pas trop les personas ou des user journeys dans le design sprint, même si l’équipe en possède. Les personas ont toujours été difficiles pour moi. Je sais qu’il y a des moyens de faire des personas qui fonctionnent bien, mais vu mes expériences passées avec eux, c’est un mélange des genres et je ne fais donc pas d’effort particulier pour les intégrer dans le sprint.

Quand les équipes les ont et les partagent, je veux bien essayer de faire avec, mais l’essentiel c’est de savoir qui est est le vrai client. Avoir une bonne idée du client, qui est derrière  eux. Parce que je pense que lorsque les personas ne sont pas bien faits, ils peuvent apparaître comme une fausse copie de ce que notre client pourrait être. Et on cherchera toujours à privilégier une relation directe avec eux.  C’est ce que je veux créer avec un design sprint.

Donc je ne m’inquièterais pas de ne pas avoir fait de persona, car cela ne fait certainement pas partie du programme et si vous n’avez pas de user journey, pas de souci car cela ne fait pas non plus partie du processus de sprint. Et pour vous dire encore une fois la vérité, je ne sais même pas comment faire un bon user journey. J’ai entendu ce terme à plusieurs reprises et je l’ai vu, mais si vous demandez à Jake de s’asseoir maintenant et de faire un super user journey, je ne saurais même pas comment faire. Il faudrait que je cherche sur Google pour que ce soit bien.

Ce que l’on fait le lundi pendant le sprint, c’est en quelque sorte une carte zoomée très simple, c’est un peu comme le user journey mais basé sur une étape. Et l’on montre les clients, mais aussi les partenaires, le fonctionnement du système et la façon dont tout cela passe. C’est comme une histoire mais vraiment zoomée.

Et ce sera tout ce dont vous aurez besoin à ce stade, le design sprint est destiné à vous fournir tout ce dont vous avez besoin. Dont cette fameuse check-list.

LYNN : Les design sprints ont été une vraie innovation. Y a-t-il une tendance ou quelque chose que vous considérez comme la prochaine vague d’innovation et de design ?

JAKE KNAPP : Je vais être honnête avec vous, je suis encore très attaché aux design sprints et pour moi, je vois comme c’est tellement prometteur et excitant qu’il a déjà été utilisé dans de nombreux contextes et vous m’avez entendu me vanter de tous les endroits où il a été utilisé, mais la réalité est qu’il n’a presque pas été utilisé du tout en fait, à l’échelle du monde. Il y a tellement d’équipes et tant d’endroits où pourrait être testé et et je ne parle que pour moi. Je pense que si l’on demandait à Kai, elle nous dirait que c’est un travail constant pour elle, juste pour continuer à le diffuser sur Google.

De mon point de vue, la chose la plus excitante est d’essayer d’aider les gens à faire leur premier design sprint. Le monde a beaucoup changé au cours de l’année dernière, et le simple fait d’essayer d’aider les gens à le faire est assez puissant. Mais je pense qu’il y a aussi cette vision assez précise de ce qu’est le sprint, quelque chose d’assez excitant qui se produit et qui se prépare, cette idée que l’on peut designer le temps.

Donc avec le design sprint, on va appliquer cette idée de conception de produits ou de systèmes à la conception du temps et la façon dont nous travaillons. Ca peut devenir le point central de la façon dont nous concevons, et j’ai vu des gens commencer à créer des sprints pour d’autres sortes de choses et expérimenter sur ces nouveaux processus, et je pense que c’est super excitant.

Donc, en créant ce type de recettes, l’idée c’est de créer une sorte de livre de cuisine pour l’innovation. Demain, vous entendrez Alex Osterwalder et eux aussi ont créé toutes sortes de livres de cuisine ou de recettes pour l’innovation. Je pense qu’il y a beaucoup de place pour faire plus de choses comme ça et rendre le design et ses résultats plus prévisible et de risquer plus facilement ce qui ne marche pas. On est en train d’inventer ce futur et des checklists ou des recettes vont largement nous aider.

Je pense aussi qu’il y a une formidable opportunité dans la période où nous vivons, pour créer de nouveaux processus. Parce que de toute façon, tout est en désordre, alors on ne perd rien à essayer quelque chose de nouveau. Et ces processus sont une énorme opportunité pour faciliter la façon dont nous interagissons les uns avec les autres, la façon dont nous nous traitons les uns les autres en tant que collègues, en tant qu’êtres humains.

Pour rendre certaines choses plus équitables et plus justes, et quand nous le faisons, nous faisons entendre la voix de plus de personnes. Nous pouvons réellement tirer le meilleur parti de chacun, de nos collègues, et nous pouvons faire en sorte que la voix qui est entendue ne soit pas seulement celle de la personne qui ne fait que de parler et monopolise l’attention. C’est bon pour tout le monde.

Et surtout, nous obtenons de meilleurs résultats à la fin. C’est ce que je pense quand je pense à l’avenir du design dans ma vision étroite. Pensez simplement à la façon dont nous pouvons améliorer les processus et comment ils peuvent aider à faire ressortir le meilleur de notre humanité. Pour que notre temps de travail ne soit pas gaspillé et il existe de nombreuses façons de répondre à cette question au-delà des design sprints.

KATE : Je suis curieuse de savoir quelles sont vos suggestions concernant le choix du Sprint CHallenge pour les design sprints. Est ce qu’il doit être spécifique à une fonctionnalité, réservé aux nouveaux projets? J’ai vu une échelle dans l’un des contenus d’AJ&Smart entre quelque chose de  très spécifique par rapport à un challenge beaucoup plus large. Comment trouver le sweet spot, est ce que vous auriez des conseils à nous donner?

JAKE KNAPP : Oui, pour le trouver, voici un extrait d’une présentation faite par mon co-auteur John Zeratsky, qui a cette matrice. Voyons voir si je peux effectivement la montrer, mon ordinateur est en train de surchauffer.

En gros, pendant que l’ordinateur travaille, je vais vous dire que parfois, certains projets sont tellement petits qu’il faut juste les faire et avancer. L’un des premiers tests c’est de savoir si l’équipe est prête à prendre la semaine pour faire le design sprint.  Et si on a l’impression que ça va être un bon investissement du temps alors, oui ça mérite d’organiser un sprint. 

En fait, ce sentiment est pour moi un indicateur très puissant. Ce n’est pas toujours juste, il y a des fois on finit par perdre du temps sur le long terme,

Il y a des moments où nous voulons faire design sprints et cela semble super excitant et le projet n’était vraiment pas assez grand pour le justifier. Cela arrive certainement, mais je pense que l’intuition est assez puissante. Voici cette matrice que John Zeratsky utilise.

Voici la façon que John Zeratsky aborde un potentiel Sprint Challenge. C’est une sorte de matrice dans laquelle, sur un axe, il y a de la difficulté et sur l’autre, de l’incertitude, et si un projet est assez facile à réaliser, vous devriez peut-être juste exécuter, sans faire de sprint.

Et si un projet est difficile mais que l’incertitude est faible, alors oui, ça va être beaucoup de travail, mais vous savez quoi faire. Dans ce cas pas besoin de sprint. Je vais vous donner en exemple la refonte du site web du livre de sprint, un projet sur lequel je travaille avec John.

On sait que c’est beaucoup de travail, mais on sait aussi que l’on a  juste besoin de faire le travail. Pas besoin de prendre de grandes decisions ou d’imaginer quoi que ce soit. 

Dans cette partie de la Matrice, on voit que c’est un projet difficile et en plus qu’il y a de incertitude sur ce qui va se passer, c’est généralement là le sweet spot pour un design sprint. Je pense par exemple au début des grands projets comme étant un moment clé pour faire des design sprints.

Je pense à tout ce qui va prendre plus de six semaines à exécuter est un bon candidat pour un design sprint. Je conseille de faire un sprint pour des projets dont le coût d’opportunité est vraiment élevé. Y a-il un risque pour la réputation de notre marque? si je n’ai qu’une seule chance de faire ce truc? Ce lancement, ou toute autre chose, peut parfois représenter un enjeu très important.

Il faut que le challenge soit important. Et parfois une simple landing page marketing peut être un challenge vraiment important. Dans le livre, on parle de ce sprint que l’on a fait avec Slack au sujet de leur landing page, c’était un enjeu très important pour eux parce qu’ils allaient dépenser une tonne d’argent, qu’il venaient de lever early stage, pour lancer une grande campagne publicitaire et ils voulaient s’assurer que lorsque les gens viendraient de cette campagne publicitaire et iraient sur slack.com, ils auraient une expérience vraiment convaincante expliquant ce qu’était Slack.

Donc pour eux, réaliser une page marketing n’était pas si difficile mais c’était très risqué et potentiellement très rentable.  Ca valait la peine de faire un design sprint sur ce projet. C’est un peu comme ça que je vois les choses.

HELENE : Ma question porte essentiellement sur le format des design sprints que nous avons l’habitude de voir qu’ils servent à tester de nouvelles idées. Mais est ce qu’ils peuvent être utilisés dans d’autres cas, par exemple où l’entreprise a mis en place un projet, très long terme avec une approche très waterfall. Recommanderiez-vous d’utiliser un design sprint pour réaligner les équipes sur les objectifs et s’assurer que nous  avançons plus efficacement ? 

JAKE KNAPP : Oui, absolument. Mes premiers exemples sont en fait des contre-exemples. Il y a beaucoup de choses qui m’ont donné envie de tenter l’expérience des design sprints et l’une de ces mauvaises expériences en particulier m’a fait penser que le design sprint était important. C’est à l’époque où je travaillais chez Microsoft sur Encarta et le processus était définitivement waterfall. Même à Google, les équipes avec lesquelles je travaillais étaient plus ou moins waterfall. Elles réfléchissaient à un plan et ensuite exécutaient. 

Nous étions peut-être un peu plus flexibles dans l’exécution, mais c’était assez proche en fait. Et dans ces deux cas, chez Microsoft et chez Google, nous travaillions sur Encarta et Gmail ou ce qui est devenu Google Meet. En tant que designer, j’avais toute la responsabilité de trouver des réponses à quoi ça devait ressembler, comment ça allait  fonctionner, et l’utilisation ce que les ingénieurs allaient commencer à construire.

Et à un moment donné, un ingénieur est venu me voir et m’a dit : « Écoute, j’ai réfléchi à tout ça et je pense que l’on pourrait avoir un design plus efficace pour cette partie du produit. Et pour le coup, il avait raison. Et là,  je suis assis à mon bureau et je réalise que nous sommes en retard de plusieurs mois. Ils ont déjà investi des longs mois et construit le produit à ma façon mais comme je n’avais pas envisagé d’approches concurrentes au début, je dois  maintenant admettre que leur façon de faire est en fait bien meilleure.

Et je réalise qu’on va devoir le refaire à sa façon, et le pire, c’est que je vais devoir lui demander de détruire tout le travail qu’il a fait et revenir en arrière, ce qui au final coûte du temps et de l’argent pour tout reconstruire. 

Et l’alternative pour moi aurait été de prétendre que j’avais raison parce et être un parfait connard. Peut être être toujours dans les temps, mais au final avec une équipe de développeurs qui me déteste ou un produit n’est pas aussi bon. Donc ça peut être vraiment puissant dans une situation de waterfall de faire un design sprint au début avant d’exécuter.

En fait, je dirais que, comme beaucoup d’entreprises avec lesquelles j’ai travaillé, même si ce sont des start-ups, elles travaillent avec cette approche en chute d’eau (waterfall). Je pense que c’est une façon de travailler un peu démodée et terrible, mais il faut quand même reconnaître que la plupart des projets les mieux exécutés ont demandé du temps et beaucoup d’ambition au départ. Et puis passer du temps à exécuter, c’est plus ou moins l’esprit de Waterfall.

Je l’ai vu ça avec des startups qui prennent leur temps pour exécuter du hardware, par exemple Nest. Faire un design sprint au départ, pour s’assurer que vous êtes dans la bonne direction est super puissant je dirais. Ensuite, comment faire pour que l’exécution fonctionne bien, je vous indiquerais une ressource qui vient en fait de Steph Cruchon.

Elle s’appelle le « design sprint Quarter » et il a mis au point une sorte de modèle pour vous aider à plannifier le Sprint et penser en  « quarters » trimestriels.  C’est une excellente façon de penser aux « design sprints » parce que souvent les équipes décident de ce qu’elles vont faire, surtout lorsqu’elles utilisent des OKR. Le design sprint Quarter vous donne une sorte de plan pour passer d’un design sprint à ce qui sera finalement soit un design sprint agile, soit une approche en waterfall.  Et je pense que c’est assez facilement adaptable.

Je vais mettre un lien dans le chat, vous pouvez aussi chercher le design sprint Quarter en ligne.  Je pense que c’est une bonne idée.

KAYLA : comment éviter que les participants viennent avec une idée préconçue sur ce que devrait être la solution et qui n’auraient pas confiance dans le processus du sprint. Comment gérer cette dynamique?

JAKE KNAPP : En fait, pour vous dire la vérité, j’adore lorsque les gens arrivent avec une idée préconçue de ce que devrait être le résultat. Car si quelqu’un a réfléchi à la solution pendant des jours, des semaines, des mois, des années, vous savez avant que nous nous lancions dans le sprint. Ils auront eu plus de temps pour y réfléchir, leur solution sera peut être beaucoup plus sophistiquée que ce que nous serons capables de générer. Lors du sprint, nous passerons plus d’une journée avant de faire les croquis et nous passerons beaucoup de temps à les rassembler et à les étudier, mais j’invite les gens à apporter avec eux de vieilles idées. En fait, je demande aux gens d’essayer de les déterrer, si vous avez de vieilles idées, nous voulons les voir. Ou si vous en êtes au Solution Sketch et que vous en avez l’opportunité, mettez votre vieille idée dessus. Votre vieille idée est probablement meilleure que celle que nous venons de trouver dans la salle. 

Et je pense que trop souvent, nous voulons que vous sachiez que la nouvelle idée a plus de mérite ; bien souvent, il y a une excellente solution qui est arrivée au mauvais moment, vous savez. L’équipe n’était pas prête à l’exécuter et donc quand quelqu’un a eu cette idée, ce n’était pas le bon moment pour la présenter. Ou bien ils avaient une idée géniale mais ils n’ont pas réussi à convaincre l’équipe.

Dans le contexte du design sprint, ils pourront être capables de convaincre l’équipe parce que maintenant, il ne s’agit pas de savoir qui a amené cette idée ou quel est son poste dans l’entreprise, ni de savoir comment vous vous habillez, ni de savoir comment vous présentez votre solution. Il s’agit de savoir si l’idée de solution est bonne. Et si vous n’êtes pas sûr, vous le saurez. 



Je pense que la question qui se pose est celle de quelqu’un qui ne veut pas croire que le processus du design sprint donne le meilleur résultat. Le fait qu’ils aient la chance de mettre sur papier exactement ce qu’ils pensent et qu’ils pourront voir ce qui se passe ensuite, ça les rassure. Et la compétition qui s’ensuit une fois que toutes les esquisses sont été créées se veut aussi juste que possible..

Ce n’est pas parfaitement équitable mais c’est le plus proche que je puisse faire étant donné les contraintes du monde dans lequel nous vivons. Ainsi, ils peuvent voir leur solution comparée à celle des autres, ils vont pouvoir voir comment les autres membres de l’équipe réagissent à leur solution, anonymement, sur le mur. Ces autres solutions anonymes, ils vont pouvoir voir comment le décideur réagit à leur solution ; ce qu’ils choisissent, ils peuvent l’argumenter s’ils le veulent à la toute fin, mais cela dépendra finalement de la qualité de cette solution.

Et ce que le décideur choisira. Une fois ce choix fait, on construira le prototype et on le testera. Et si leur idée n’est pas retenue, leur solution n’est pas retenue mais que la solution choisie échoue le vendredi, ils pourront certainement la reprendre pour le prochain sprint.

Ou vous savez, si la solution choisie fonctionne, je vois généralement les gens laisser tomber cet attachement émotionnel au cours du processus. Et voir en direct le résultat des tests, permet de renforcer la confiance dans les solutions qui seront retenues pour être exécutées.

Parfois, c’est l’idée préconçue ira au bout du chemin, mais quand elle ne passe pas, et qu’on en retient une autre, et donne de raisons claires sur le pourquoi on a fait ces choix.  Cela permet d’éviter de futurs conflits qui au final ne feraient que de ralentir les choses.

Je pense que le processus du design sprint permet de gérer la majeure partie de ces problématiques d’attachement émotionnel lié aux idées.