Article original : Zero to 1.5 Million coders: nine lessons learned while building Grasshopper
Par Laura Holmes
Il y a deux ans et demi, je me suis lancée dans l'enseignement de la programmation à partir de zéro sur téléphone. À ce jour, 1,5 million de personnes ont téléchargé Grasshopper. Même avec 10 ans d'expérience en gestion de produits chez Google, j'étais en territoire inconnu en développant Grasshopper. Voici quelques-unes des choses que j'ai apprises en cours de route :
Construisez ce que vous connaissez
Je suis arrivée à l'apprentissage de la programmation par accident. Je suis allée dans un lycée public en Californie où le cours d'informatique consistait à apprendre à taper. Lorsque je suis arrivée à Stanford, j'ai entendu parler de "science informatique", mais je n'avais aucune idée de ce que c'était. Mon assistant résident de première année m'a recommandé de suivre un cours appelé "CS106A". Je l'ai suivi sur sa recommandation. J'ai découvert plus tard que c'était le cours d'introduction à l'informatique de Stanford.
Dès que j'ai commencé le cours, j'ai adoré l'informatique mais j'ai obtenu des B. Beaucoup de gens étaient surpris que je suive ce cours puisque j'étais une "fille qui aimait parler". Il y avait tant de choses que je ne comprenais pas. Je me souviens avoir demandé de l'aide à un membre du personnel de mon dortoir une fois, et il a ri en disant : "Tu ne connais pas Unix ?! Comment peux-tu ne pas connaître Unix ?"
Il y avait tant de barrières pour se sentir à l'aise en apprenant à coder : le jargon, les outils, la perception des gens sur ce à quoi ressemblait un codeur. Tous ces obstacles me donnaient l'impression de ne pas être à ma place. J'ai fini par obtenir mon diplôme en informatique. J'ai décroché un emploi chez Google, mais des centaines de fois, j'ai douté de pouvoir le faire.
Avance rapide d'environ une décennie de travail chez Google. Je voulais trouver ce que je pouvais faire pour aider à plus de diversité et d'inclusion dans l'industrie technologique. Il y a beaucoup de travail incroyable qui se fait. Basé sur ma propre expérience, je voulais changer une chose : je voulais que plus de gens se sentent capables de coder. Je voulais que les gens aient plus de facilité que moi à entrer dans l'industrie du logiciel.
J'ai fini par proposer à Area 120 de Google une application gamifiée pour apprendre à coder, avec un minimum d'instructions et sur mobile (pour que plus de gens puissent l'utiliser).
Entourez-vous de grandes personnes
"Seul, nous pouvons faire si peu, ensemble nous pouvons faire tellement." — Helen Keller
Un groupe de grandes personnes qui se soucient de rendre l'éducation à la programmation plus accessible a construit Grasshopper. Au début, nous étions quelques-uns. Au cours des deux dernières années, des gens ont rejoint et certains sont partis. À travers chaque itération, les décisions concernant les personnes étaient au cœur même de l'application.
J'ai appris au cours des deux dernières années que vous pouvez être intelligent, vous pouvez être chanceux, et vous pouvez avoir des gens avec une expertise approfondie dans votre équipe. Ce n'est pas suffisant. Vous devez vous entourer de gens qui vont être des joueurs d'équipe. Les compétences peuvent être apprises. À la fin de la journée, j'avais souvent tort. C'est le travail acharné et la patience de mes coéquipiers qui nous ont permis de pivoter vers ce qu'est Grasshopper aujourd'hui.
Mettez quelque chose entre les mains des utilisateurs aussi rapidement que possible
Nous avons commencé à construire Grasshopper en septembre 2016 et avons fait nos premiers tests utilisateurs en octobre. Nous n'avions encore rien construit, nous avions juste des prototypes papier dessinés à la main.
En novembre, nous avions notre premier prototype et nous l'avons envoyé à 10 personnes pour Thanksgiving (seulement 2 personnes l'ont utilisé).
À chaque itération, nous avons appris ce qui fonctionnait et ce qui ne fonctionnait pas. Nous avons réalisé tôt que les puzzles de codage étaient délicieux. Nous devions nous assurer que les jeux ne semblaient pas trop enfantins (par exemple, pas de graphiques de tortue). Nous avons appris où les utilisateurs voulaient cliquer pour ajouter une nouvelle ligne dans notre éditeur de code (et que nos contrôles initiaux étaient confus).
En juin, nous avions une application brute qui comportait 13 puzzles et nous l'avons mise sur le Play Store. Nous avons acheté du trafic. Nous avons gardé un profil bas et continué à apprendre.
De bonnes métriques vous aident à dire non
Nous n'étions pas sûrs de ce à quoi ressemblerait le succès lorsque nous avons commencé Grasshopper. Je savais que les métriques nous aideraient, mais je n'étais pas sûr des chiffres qui comptaient. J'ai lu beaucoup de blogs sur la croissance. Ensuite, j'ai commencé à examiner les métriques suivantes pour évaluer le succès de Grasshopper : utilisateurs actifs, succès de l'intégration, rétention de la semaine 1, coût par acquisition, achèvement du programme et création de contenu par semaine.
C'est beaucoup de métriques différentes.
Avoir beaucoup de métriques rendait difficile la prise de décisions.
Voulions-nous construire une fonctionnalité pour augmenter nos utilisateurs actifs quotidiens ? Ou réduire le coût d'acquisition ? Voulions-nous que les gens passent plus de temps dans l'application ou qu'ils suivent nos leçons ? Que signifiait-il lorsqu'une métrique augmentait et qu'une autre diminuait ? Quelles métriques étaient les plus importantes ?
Il a fallu quelques mois pour que je réalise que je devais me concentrer. Nous avons décidé de nous concentrer sur seulement deux métriques : la rétention du jour 1 et le taux de diplomation. Nous nous sommes tenus responsables de l'apprentissage des étudiants (taux de diplomation), tout en construisant un produit engageant qui inciterait les utilisateurs à revenir (rétention du jour 1). Et nous nous sommes concentrés sur la rétention du jour 1 car c'était notre première opportunité de mesurer le retour d'un utilisateur. Tous les autres objectifs de rétention sont en aval du jour 1.
On remarque l'absence de toute métrique de croissance des utilisateurs. Nous n'avions pas besoin de croître jusqu'à ce que nous ayons maîtrisé ces deux autres métriques. Si nous ne gardions pas les utilisateurs intéressés et si nous n'enseignions pas à nos étudiants, nous n'étions pas prêts à verser plus d'essence sur le feu.
Se concentrer sur deux métriques de succès était clarifiant. Nous n'avons pas passé de temps sur le marketing au-delà de quelques campagnes payantes simples. Nous pouvions examiner notre liste d'idées et nous concentrer sur les meilleures en fonction de leur aide à la rétention ou à la diplomation. Des choses comme le support des tablettes, la prise en charge de plus de cas d'utilisation par l'éditeur de code et les références n'étaient plus importantes.
Une fois que nous avons eu un ensemble d'objectifs partagés, nous avons pu commencer à prendre certaines décisions difficiles.
Vos utilisateurs ont raison
De juin à décembre 2017, les choses étaient difficiles. Nous avions convenu de nos métriques de succès, mais nous ne faisions pas augmenter ces chiffres.
Nous avons apporté beaucoup de changements à l'application. Nous avons élargi notre programme pour créer un meilleur "point final". Rien ne semblait améliorer nos métriques. J'espérais que le prochain changement serait le bon, mais ce ne fut pas le cas.
Nous avons continué à entendre des utilisateurs que notre programme était confus et qu'ils voulaient vraiment une barre de progression. Je ne comprenais pas. Nous avions conçu notre programme pour qu'il soit dynamique afin que la leçon parfaite suivante soit choisie pour l'utilisateur en fonction de ses performances. De cette façon, les leçons pouvaient également être échangées. Et nous venions d'ajouter une barre de progression. Pourquoi les utilisateurs ne comprenaient-ils pas ? Ne voyaient-ils pas la barre de progression ?
En même temps, certains membres de mon équipe avaient commencé à noter qu'ils ne se sentaient pas à l'aise avec le programme dynamique. C'était confus pour eux, et c'était coûteux en calcul.
C'est alors que j'ai réalisé : Nos utilisateurs avaient raison. Ils m'avaient dit tout le temps que notre application était confuse, mais je ne comprenais pas. Et mes coéquipiers les avaient entendus aussi, et je n'écoutais toujours pas. J'étais trop attachée à la façon dont nous avions fait les choses et aux investissements que nous avions faits.
Nous avons donc pivoté pour rendre notre programme linéaire, avec une progression claire et un suivi. Nous avons arrêté d'essayer d'être trop intelligents et nous avons écouté. Et c'est alors que tout a commencé à changer pour le mieux : tous nos chiffres ont commencé à augmenter et à aller dans la bonne direction.
Restez fidèle à votre cœur, le reste n'est que des détails
Lorsque nous avons pivoté d'un programme dynamique à un programme linéaire, j'étais très préoccupée. Nos investisseurs pensaient que le programme dynamique était cool, tout comme les gens de notre équipe. Cette nouvelle stratégie était-elle suffisamment intéressante pour garder notre équipe enthousiaste ? Et ce nouveau modèle nous faisait utiliser des points et des réalisations. Était-ce de la triche ?
C'est alors que je me suis rappelé pourquoi je voulais construire Grasshopper : je voulais enseigner à plus de gens à apprendre à coder. Le programme dynamique ne fonctionnait pas ; échangez-le contre un programme qui fonctionne. Qui se soucie si vous utilisez un système de points, tant que plus de gens apprennent ?
Construire Grasshopper a été un voyage d'apprentissage dans le lâcher-prise et l'autonomisation des personnes de mon équipe pour prendre des décisions (et c'est un voyage que je suis encore en train de faire). Il s'avère que si vous avez une grande équipe, les meilleures idées viendront d'eux. Mon travail en tant que leader est de m'assurer que nous arrivons tous au même endroit : enseigner à plus de gens à apprendre à coder.
Depuis notre pivot l'année dernière et la réalisation que j'étais trop attachée à une version de l'application qui ne fonctionnait pas, j'ai été plus ouverte aux suggestions et à l'expérimentation. J'ai un peu lâché prise, et ce fut formidable de voir ce que mon équipe a fait avec plus de responsabilité. Mon équipe a construit des fonctionnalités, développé de nouveaux cours et apporté des changements à Grasshopper auxquels je n'étais pas initialement favorable. Mais il s'est avéré que j'avais tort, et les fonctionnalités développées par mon équipe ont augmenté nos métriques principales. Nous avons également supprimé certaines choses. Mais la chose la plus importante a été de rester fidèle à notre mission et de ne jamais vaciller. Le reste n'est que des détails.
Lancez-vous dans la croissance lorsque les métriques sont bonnes
Au cours de mes années chez Google, j'avais appris que vous ne voulez pas surpromettre et vous tromper. Vous ne pouvez jamais récupérer la confiance des utilisateurs. Lorsque je travaillais sur Project/Google Fi, nous avons intégré les utilisateurs lentement jusqu'à ce que nous sachions que nos clients auraient une excellente expérience, et cela s'est bien passé. Je voulais suivre un modèle similaire avec Grasshopper, et ne pas faire de marketing et de presse jusqu'à ce que nous sachions que nous avions un excellent produit.
Après des mois et des mois de métriques stagnantes, nous sommes revenus des vacances avec des graphiques qui montaient et allaient dans la bonne direction. Nous étions si excités. Le pivot vers le programme linéaire a porté ses fruits !
En septembre 2017, nous avions fixé des objectifs pour la rétention du jour 1 et le taux de diplomation, et nous les avons atteints en février 2018.
En plus de voir nos métriques de succès augmenter, nous avons effectivement vu la croissance organique décoller. À partir de janvier, nous avons vu un pourcentage de plus en plus grand de notre croissance venir de manière organique.
En février, nous savions que nous avions trouvé quelque chose qui fonctionnait, alors nous avons décidé de mettre en action les plans d'annonce. Nous avons été surpris que personne n'ait prêté attention à Grasshopper même s'il était public depuis des mois. Parce que nous avons gardé un profil bas, nous nous sommes donné l'opportunité d'annoncer et de raconter notre propre histoire une fois que nous savions que le produit était bon.
La surveillance et le support à grande échelle portent leurs fruits
Le jour de l'annonce, nous sommes arrivés au bureau à 5 heures du matin PT. Le magazine TIME a fait un exclusif sur Grasshopper, et il devait être publié sur le site à 6 heures du matin PT. Rien n'était ouvert, alors nous avons apporté un gaufrier au bureau et cuit du bacon dans notre micro-ondes.
Une fois l'article publié, nous avons vu nos métriques commencer à grimper. C'était super excitant ! TechCrunch a fait un article. Et puis un tas d' autres médias ont commencé à nous relayer. À 15 heures, les choses s'étaient stabilisées et nous avons décidé de sortir pour prendre une bière pour célébrer. Nous avions lancé, obtenu beaucoup de nouveaux utilisateurs et rien n'avait cassé. La croissance était modeste, mais nous étions dans la nature. Un travail bien fait. Nous sommes rentrés chez nous ce soir-là en nous sentant bien.
Le lendemain matin, tout était en feu. L'Asie avait relayé notre lancement. Notre équipe d'ingénierie a été alertée juste à temps, et ils ont désactivé les services non essentiels (comme nos tableaux de bord) avant que la charge de notre serveur n'empêche Grasshopper de fonctionner.
Une fois que nous avons récupéré nos données, nous avons découvert que nous avions multiplié par 63 notre précédent record sur 24 heures. Nous espérions 10 fois. Les semaines suivantes ont été difficiles. Notre équipe d'ingénierie a travaillé pour réécrire notre backend pour qu'il soit scalable, et notre équipe de programme et de support a géré les problèmes des utilisateurs. Nous avons survécu parce que nous avions investi dans la surveillance, dans la construction de bascules pour désactiver rapidement les services, et dans un forum et un système de feedback in-app qui s'adaptait à une croissance massive des utilisateurs.
Si vous vous trouvez un jour dans une situation similaire, je ne peux pas insister assez sur l'utilité d'avoir toutes ces choses en place avant de faire une annonce.
Il n'y a pas de chose telle que l'équilibre entre vie professionnelle et vie privée ; il y a un compromis entre vie professionnelle et vie privée
Avance rapide jusqu'à aujourd'hui, et nous avons maintenant 1,5 million d'utilisateurs utilisant Grasshopper. Je suis si fière de l'équipe et de ce que nous avons accompli, et fière de nos étudiants pour tout ce qu'ils ont appris à coder. Mais il est temps de devenir un peu personnel :
Pendant tout cela, j'ai aussi eu mon premier bébé. J'ai traversé l'épuisement du premier trimestre tout en exécutant notre pivot. J'étais enceinte de 35 semaines lorsque nous avons fait notre annonce publique en avril. Et j'ai encore l'impression de me remettre de mon congé de maternité, même si je suis retournée au travail depuis quelques mois. S'adapter à la parentalité + travailler sur Grasshopper a été rempli de défis inattendus.
Je souhaite avoir des conseils pour les gens ici. Je souhaite pouvoir vous dire qu'avec une carrière réussie et beaucoup de ressources, l'équilibre entre vie professionnelle et vie privée se met en place. Je ne peux pas. Mais ce que je peux offrir, c'est d'être réelle sur ce que c'est, équilibrer entre être un leader et une mère : c'est f-ing difficile. L'équilibre entre vie professionnelle et vie privée implique qu'il existe un état idéal de bonheur qui peut être atteint si l'on travaille suffisamment dur. Au lieu de cela, je fais constamment des compromis entre m'occuper de ma famille et de mon entreprise.
Je quitte le travail à 17 heures pour pouvoir passer du temps avec ma fille avant de la mettre au lit. Certaines nuits, je saute le temps avec mon mari pour travailler sur Grasshopper, pour que ma fille se réveille exceptionnellement tôt le lendemain. Je ferai de mon mieux pour la nourrir, mais parce que je suis si fatiguée, nous ne sourions pas autant ensemble avant que je parte au travail. Et puis je suis moins créative en pensant à la stratégie de Grasshopper pendant la journée.
Être un parent qui travaille donne l'impression de faire une analyse complexe du retour sur investissement pour chaque activité, pour le travail et la famille. Tout ce que je peux espérer, c'est que je fais les bons choix en cours de route, et être humble face aux défis. J'espère qu'en étant honnête sur le défi, cela donne aux parents qui travaillent et qui lisent cet article la permission de célébrer tous les compromis quotidiens incroyables que vous faites. Et si vous lisez ceci et n'êtes pas parent, mais travaillez avec des gens qui le sont, pensez peut-être à leur dire à quel point vous pensez qu'ils font du bon travail dans leurs deux rôles.
Si vous avez lu jusqu'ici, merci beaucoup ! J'espère que vous avez trouvé certaines des leçons précieuses, et j'espère revenir bientôt sur le blog de freeCodeCamp pour partager d'autres informations de Grasshopper. Et si vous cherchez un moyen de commencer votre voyage en codage, téléchargez Grasshopper. J'adorerais avoir vos commentaires et retours.
Je écris et tweete également sur des sujets de diversité et d'inclusion. Pour me suivre, voici mon Twitter et mon blog.