Comment Notion a créé un système de gestion de produit qui met toutes les équipes d’accord

Quand des centaines de tickets de service client ont commencé à affluer en l’espace d’une nuit, on a vite compris qu’on atteignait nos limites. Les ingénieurs avaient lancé une nouvelle fonctionnalité sans en parler au service client, et on a passé le reste de la nuit à se démener pour répondre aux questions des clients.

Mais le problème était bien plus vaste que cela. Pendant les semaines qui ont précédé ce lancement, l’équipe de marketing produit demandait à une douzaine d’ingénieurs de rédiger des notes de mise à jour chaque semaine. Nos différentes équipes organisaient des réunions de suivi, indépendamment les unes des autres, pour un même lancement. Collectivement, nous perdions beaucoup de temps à essayer de communiquer.

Notion était en pleine croissance — cinq équipes d’ingénieurs, plusieurs projets menés en parallèle — mais dans cette effervescence, peu d’entre nous comprenaient la dynamique globale ou la finalité des projets. Si nous n’arrivions pas à trouver une meilleure façon de coordonner nos équipes, nous n’allions pas pouvoir faire évoluer notre entreprise.

La croissance de toute start-up est semée d’embûches. J’ai observé la même situation au sein des équipes produit chez Twitter, Oculus, Robinhood, et enfin Notion (personne n’est à l’abri !). J’avais donc envie de partager avec vous les quelques clefs qui nous ont permis de concevoir la bonne solution pour nos équipes.

Dans cet article, je vous fais découvrir les systèmes et processus que nous avons mis en place pour garder toutes nos équipes à jour de notre progression, qu’il s’agisse de la conception ou de la gestion de produit. En bonus, vous y trouverez des liens vers nos modèles, pour pouvoir appliquer dès maintenant les approches qui vous intéressent à votre propre équipe.

Quand j’ai rejoint Notion, j’ai commencé par aller discuter avec les ingénieurs et les designers pour comprendre quelles étapes ils suivaient généralement pour la conception et la livraison des produits. Certaines équipes utilisaient des systèmes de tâches et de sprints classiques, tandis que d’autres enregistraient leurs avancées dans un gros fichier partagé.

Rien de bien surprenant : à mesure que les entreprises se développent, les différentes équipes se forgent leurs habitudes, ce qui complique la coordination du travail. Et c’est normal ! Les équipes doivent pouvoir travailler de la façon qui leur convient le mieux, a fortiori à l’ère du travail à distance. Ce que nous avions besoin de standardiser, c’était la façon dont nous communiquions sur le travail de nos équipes.

Mais comment savoir quoi standardiser quand chacun fait les choses à sa façon ? Il faut trouver ce que tout le monde utilise à peu près de la même manière, et commencer par là.

Chez Notion, nos équipes ingénierie, produit et design s’organisaient globalement autour de trois concepts : les équipes, les projets et les tâches (voir nos définitions ci-dessous). Nous avons pris le temps de définir chacune de ces composantes, puis nous les avons codifiées dans un document partagé à l’échelle de l’entreprise, pour que chacun suive les mêmes étapes de création de projet.

Il était également important de se mettre d’accord sur ce qu’il ne fallait pas standardiser. Par exemple, chez Notion, on ne dicte pas à nos équipes la façon d’organiser leurs réunions, ou quels outils de prototypage utiliser. Tâchez de vous concentrer vous aussi sur quelques règles de base, tout en laissant vos équipes travailler librement par ailleurs.

L’identification et la standardisation de ces composantes stratégiques nous ont aidés à articuler tous les aspects de notre activité sur un même modèle. Mais pour aller plus loin, il fallait pouvoir communiquer en permanence avec le reste de l’entreprise sur la progression du travail, dans un langage que tout le monde comprendrait.

Pour pouvoir le faire efficacement, nous avons créé un système de communication en quatre parties :

• Équipes : groupes de personnes qui prennent en charge des projets.

• Projets : blocs de travail distincts et livrables individuellement, pouvant être divisés en tâches.

• Tâches : éléments de travail affectés à une personne.

• Bulletins : aperçus brefs et lisibles de chaque projet, publiés toutes les deux semaines.

Certaines parties aident les équipes d’ingénieurs à se coordonner entre elles, et d’autres, comme les mises à jour, s’adressent au reste de l’entreprise. Chacune d’entre elles est une base de données Notion, toutes étant reliées entre elles pour créer le système. Nous considérons que ce système comporte quatre couches, chacune d’entre elles fournissant un niveau de contexte différent pour les différentes équipes.

Votre système ne ressemblera pas forcément au nôtre. Il pourrait, par exemple, reposer sur des feuilles de calcul ou sur un dossier de documents. Vous pourriez organiser le travail en sprints ou en jalons. Cependant, si vous avez envie de vous inspirer du nôtre pour démarrer, vous trouverez ci-dessous sa configuration exacte, sous forme de modèle.

Passons maintenant en revue chaque partie de notre système, sa structure et ses destinataires.

Savoir exactement « qui fait quoi » facilite l’organisation des projets. Mais créer une liste d’équipes cohérente s’avère plus difficile qu’il n’y paraît. La structure d’un logiciel ne doit pas être celle d’un organigramme. Ce qui nous intéresse, ce sont les virtuels que les personnes forment pour créer des choses. Des personnes qui occupent des fonctions auxquelles on ne penserait pas forcément d’emblée peuvent donc se retrouver dans une même « équipe » : par exemple une personne ingénieur, une designer, une responsable de marketing produit, une juriste et probablement encore quelques autres.

Pour identifier ces équipes, on peut se baser sur les canaux Slack qu’elles créent pour organiser leur travail autour d’un projet. Ces canaux révèlent généralement la nature des équipes non officielles qui fonctionnent à une période donnée.

Une fois ces équipes identifiées, vous pourrez créer une liste aussi simple ou complexe que vous le souhaitez. La nôtre contient le nom de l’équipe, ses membres, une courte description de leurs rôles, et deux ou trois autres éléments utiles, comme leur canal Slack et les chartes d’équipe.

Une fois que vous avez vos équipes, c’est le moment d’identifier des projets pour chacune d’entre elles. Chez nous, les projets sont des éléments livrables qui constituent généralement une priorité commune pour les différents membres de l’entreprise.

Cette composante intéresse aussi les équipes commerciales et juridiques, par exemple, ainsi que d’autres sous-équipes d’ingénieurs : même si ces membres ne participent pas activement à la création du projet, ils ont souvent besoin de comprendre sa progression pour jouer au mieux leur rôle. Tous ont besoin du même niveau de contexte :

• le problème que le projet résout ;

• son état d’avancement ;

• sa date de sortie ;

• quelles décisions et idées il faut approfondir.

Notre base de données « Projets » est optimisée pour répondre à ces questions : elle inclut le nom du projet, une description « tl;dr », son état d’avancement, sa date de lancement et des pointeurs vers les documents plus détaillés du projet. Toutes ces informations sont présentées sous forme de table, pour que chaque membre puisse rapidement visualiser la liste des projets actifs et trouver les réponses dont il a besoin.

Une fois les projets correctement identifiés, les ingénieurs, designers et responsables produit peuvent les organiser sous forme de tâches adaptées à chaque rôle. Les tâches représentent le travail quotidien de l’équipe et doivent être suffisamment précises et détaillées pour être correctement menées par les personnes dont c’est le travail. Quand on cherche à présenter les tâches de façon à ce qu’elles soient comprises par tous, elles deviennent vagues et inutilisables.

Pour rendre les tâches compréhensibles pour les membres qui les exécutent, nous utilisons des propriétés spécifiques permettant de suivre l’ordre de priorité, l’avancement du contrôle qualité, l’ingénieur(e) responsable, le projet associé à la tâche, et toute autre information utile aux ingénieurs pour mener à bien leur travail.

Cette couche finale s’adresse aux personnes qui ne savent pas quels projets les intéressent en particulier et ont plutôt besoin d’une vue d’ensemble. Tout comme un projet couvre un grand nombre de tâches, un bulletin couvre un grand nombre de projets. De cette façon, les personnes concernées n’ont pas à passer en revue cinquante projets. Le système leur montre directement ce qui les intéresse.

Comme les bulletins hebdomadaires concernent l’ensemble de l’entreprise, je les rédige moi-même sous forme de texte simple et lisible. J’extrais le contenu des mises à jour individuelles que rédigent les différentes équipes d’ingénieurs pour le produit, puis je le retranscris simplement sur des pages Notion, pour que les informations soient faciles à trouver et à rechercher dans l’historique des bulletins. Cela dit, vous pouvez aussi diffuser vos bulletins d’information sous forme d’e‑mails ou de documents.

Actuellement, je structure les bulletins hebdomadaires en trois catégories :

• Livraisons : une simple liste de tous les projets livrés à nos clients externes dans la semaine.

• Annonces : la liste des choses qui évoluent, en bien ou en mal. On pourrait par exemple y trouver un nouveau document de spécification technique ou informer l’équipe d’un retard important sur un projet.

• Pour info : cette catégorie rassemble les enseignements tirés de précédents projets, ou informe de changements d’ordre général dans la gestion de produits ou dans les équipes techniques, par exemple.

Mais cette structure peut bien sûr varier avec les priorités de votre entreprise. Pour le moment chez Notion, on se concentre sur les livrables et on s’assure de bien informer toutes les équipes des différentes étapes. Si votre équipe s’organise autour de trois grandes priorités, vos bulletins d’information peuvent s’axer sur leur progression.

Tout ce dont on vient de parler est réduit à néant si personne n’utilise votre système. Pour assurer le succès de notre système, il fallait prouver sa valeur aux principaux intéressés.

Notre objectif était de les tenir informés efficacement, tout en leur demandant le moins d’efforts possible. C’est un équilibre difficile à trouver. Pour ce faire, nous avons recherché autant de moyens que possible de connecter les différentes parties du système entre elles. De cette façon, lorsqu’on ajoute des informations dans une partie donnée, les autres parties prennent aussi de la valeur, ce qui incite les membres à contribuer au système global.

Par exemple, j’intègre notre suivi de projets à chaque bulletin hebdomadaire en bas de page. Si les membres souhaitent en savoir plus sur un projet en particulier, ils savent exactement où aller et peuvent y accéder en quelques clics. Cette intégration encourage les ingénieurs à tenir la liste de projets à jour.

Les différentes équipes d’ingénieurs intègrent également une vue filtrée de la base de données des tâches dans chaque document de projet, sur laquelle seules les tâches liées au projet apparaissent. Quiconque ouvre la page du projet peut immédiatement voir comment le travail a été réparti et comment les tâches progressent.

Créer des liens avec les systèmes d’autres services de l’entreprise crée aussi de la valeur. Par exemple, nos responsables du marketing produit peuvent récupérer les dates de lancement en externe dans le suivi de projets, pour mettre à jour leur propre calendrier de lancement.

En bout de chaîne, nous avons réussi à créer un système permettant de suivre toutes les tâches de conception et de gestion de produit au même endroit, et de communiquer leur progression au reste de l’entreprise à moindre frais. Nous espérons que cette structure pourra aider votre équipe à son tour.

Mais les choses vont vite dans les start-up ! Au fil de notre croissance, le système précis que nous utilisons évoluera. Et le vôtre aussi.

Chez Notion, nous avons constaté que pour faire évoluer nos systèmes dans le bon sens, l’essentiel était de comprendre ce que nos équipes avaient besoin de savoir. Pour concevoir un produit, c’est toute l’entreprise qu’il faut mobiliser. Et c’est en nous assurant de bien prendre en compte les besoins de chacun à chaque étape que nous avons réussi à maintenir le même niveau de transparence au fil de notre croissance.