Restructuration de l'équipe produit Braze

La force motrice la plus importante derrière tout produit logiciel est le groupe de personnes qui le construisent et leurs relations les unes avec les autres. Par conséquent, il est important d'organiser les équipes de manière à leur permettre d'avoir autant de poids et d'impact que possible.

Chez Braze, nous avons longuement réfléchi à la conception de notre organisation de produits et d'ingénierie, et nous souhaitons partager les enseignements tirés d'une réorganisation départementale majeure qui nous a permis d'améliorer considérablement la façon dont nous hiérarchisons les fonctionnalités, développons l'expertise de l'équipe et construisons notre produit plus efficacement.

Structure initiale : adéquation produit/marché et au-delà

Trouver l'adéquation produit/marché - et en tirer parti pour développer une entreprise - est un creuset par lequel toutes les startups doivent passer. Tout au long de cette étape du développement d'une startup, la vitesse d'expérimentation et la capacité à capitaliser rapidement sur les opportunités sont essentielles. À cette fin, la structure originale de notre équipe produit ressemblait à ceci :

Cette structure, qui a divisé notre équipe en fonction des spécialités fonctionnelles, a bien fonctionné pour plusieurs raisons.

Tout d'abord, cela nous a permis d'aborder efficacement les changements de produits transformationnels sur la voie de l'adéquation produit/marché - les experts pouvaient posséder d'énormes pans de notre base de code et utiliser les langages, les cadres et les décisions de conception avec lesquels ils étaient le plus à l'aise. Alimentées par des quantités massives de caféine, les « équipes » de projet de l'armée d'un seul se sont régulièrement attaquées à d'énormes efforts. Celles-ci comprenaient la création de notre API publique orientée client et la refonte de l'ensemble de notre infrastructure d'envoi de messages, remplissant souvent le rôle d'ingénieur, de chef de produit et de concepteur unique. Ces types de mesures extrêmes seraient de la folie dans une grande entreprise, mais elles sont nécessaires et presque routinières au début de la croissance.

De plus, cette structure nous a permis d'acquérir une maîtrise approfondie de certains domaines techniques avec seulement une équipe de 10 à 15 personnes. De nombreux éléments de nos produits de base, par exemple la couche modèle-vue-contrôleur de notre frontal, les API et le code d'envoi de messages à haut débit, n'étaient parfaitement compris que par quelques personnes.

À l'époque, c'était simple et tout ce dont nous avions besoin. Lorsque la vitesse est primordiale, l'organisation basée sur des directives simples a aidé à réduire les frais généraux cognitifs et nous a permis de concentrer notre attention là où cela pourrait faire le plus de bien.

Structure ultérieure : croissance et mise à l'échelle

Au fur et à mesure que notre équipe a dépassé les 30 ou 40 personnes, cette structure a commencé à s'effondrer. Nous avons finalement identifié la réorganisation de notre équipe produit comme une solution à certains de nos plus grands défis. Nous déployions des efforts insoutenables pour jongler entre les compétences et les délais pour composer des équipes pour des projets stratégiques. Nous avons également passé énormément de temps à établir des priorités et nous nous sommes souvent retrouvés à hiérarchiser toutes les priorités des produits dans l'entreprise, car notre structure d'équipe basée sur la technologie ne correspondait pas directement aux besoins les plus essentiels en matière de produits. Et enfin, nous avons eu peu d'occasions pour les membres de l'équipe de développer une expérience approfondie avec des cas d'utilisation particuliers de clients.

Nous sommes finalement passés à une organisation structurée autour d'équipes transverses Agiles similaire au modèle Squad/Tribe popularisé par Spotify. Notre nouvelle structure organisationnelle ressemble à ceci :

La majorité de notre équipe travaille dans des «produits verticaux», correspondant à un domaine clé de notre produit ou de notre entreprise. Par exemple:

• Notre équipe Email & Enterprise gère les e-mails de haut en bas, ainsi que certains domaines de produits tels que la gestion des autorisations qui sont essentiels pour bon nombre de nos plus gros clients.
• Notre équipe de messagerie et d'automatisation possède plusieurs domaines de produits liés à la segmentation des utilisateurs, à la messagerie et à notre produit phare d'orchestration, Canvas.

Au sein d'une verticale, nous nous attendons à ce que la hiérarchisation soit (relativement) simple, car chaque verticale correspond à un ensemble spécifique de besoins des clients. Certaines équipes telles que Visual Design, DevOps et nos groupes d'ingénierie d'infrastructure couvrent l'ensemble de la plate-forme, renforçant la cohérence dans les domaines clés.

Répercussions

Notre réorganisation a considérablement réduit les dépendances inter-équipes. Auparavant, nous luttions avec le problème de planification de type Sudoku consistant à trouver le bon équilibre entre des ensembles de compétences spécialisées (ingénierie, conception, gestion de produits, etc.) sur un projet donné à un moment donné. Cela a également aligné les incitations à court terme - avant la transition, les équipes se retrouvaient souvent à dépendre de contreparties qui visaient des objectifs sans rapport. Avec notre nouvelle structure, les équipes de produits sont indépendantes, ont beaucoup plus de contrôle sur les délais et sont entièrement alignées sur les objectifs, ce qui augmente la productivité et le moral.

La nouvelle conception de l'organisation a également amélioré la hiérarchisation. Par exemple, notre équipe Email & Enterprise peut avoir à choisir entre la mise à niveau de notre infrastructure de messagerie, la création d'une fonctionnalité de messagerie de base ou la résolution d'un problème d'utilisabilité d'entreprise - une décision simple et facilement quantifiable, car les trois se rapportent aux besoins de nos clients de manière similaire. .

Une équipe aux prises avec trop de besoins prioritaires est également un indicateur que son domaine de produits a besoin de plus de ressources. Cela nous permet de recadrer les problèmes difficiles de hiérarchisation en tant que besoins en personnel, qui sont toujours difficiles mais conceptuellement simples à résoudre.

Enfin, la concentration de la plupart des équipes sur un domaine de produit particulier a permis aux individus de développer une expertise approfondie et des relations de travail hautement productives au fil du temps. Au départ, au cours des premières années de construction, les individus pouvaient avoir pratiquement tout le produit et la base de code dans leur tête, mais au fur et à mesure que nous avons grandi, cela est devenu impossible. Les problèmes de produit sont fractals : chaque fois que vous regardez de plus près, vous trouvez plus de nuances et de profondeur. Par conséquent, passer de nombreuses heures dans un domaine particulier d'un produit ou d'une base de code et comprendre en profondeur ses besoins commerciaux est l'un des meilleurs moyens de réaliser de véritables percées de produit. De plus, la création d'équipes ciblées à long terme renforce l'appropriation et les relations, et permet aux relations de travail tacites entre un ensemble cohérent de collaborateurs de se concrétiser.

Bien sûr, aucun système n'est parfait. En mettant l'accent sur les piliers axés sur les produits, nous avons accru le potentiel d'optimisation des équipes pour les besoins localisés au détriment des priorités globales. Par exemple, on pourrait se concentrer sur la dette technologique localisée ("ce contrôleur est lourd") plutôt que sur les problèmes mondiaux ("changer notre cadre frontal augmenterait la vitesse d'ingénierie globale"). En prévision de ce besoin, nous avons pris des mesures pour établir les équipes transversales mentionnées ci-dessus et avons utilisé des comités dédiés pour d'autres grands projets, par exemple, un comité pour construire un système de produit/conception holistique de composants frontaux et de modèles de conception. .

Notre nouvelle structure apporte également une énergie d'activation plus élevée pour des changements de produits holistiques et transformationnels. Certains domaines de notre produit, tels que nos API back-end, sont détenus conjointement par plusieurs équipes. Le seuil pour apporter des changements radicaux à de larges zones transversales de notre base de code est plus élevé, donc ce type de structure fonctionne mieux une fois que le squelette de votre produit est en grande partie formé.

Plats à emporter

Dans l'ensemble, nous avons été satisfaits de notre structure organisationnelle de produit repensée : nous avons résolu ou grandement amélioré nos défis concernant les dépendances d'équipe, la hiérarchisation et la création d'une expertise produit à long terme, et nous avons également une feuille de route utile pour savoir comment nous allons évoluer. En particulier, nous avons appris que :

• La suppression des dépendances et l'alignement des incitations entraînent d'énormes gains d'efficacité.
• La hiérarchisation des pommes aux pommes est à la fois plus simple et plus efficace.
• Une expertise approfondie d'un client ou d'un besoin commercial particulier conduit à de meilleurs résultats de produit.
• Travailler avec les mêmes membres de l'équipe sur une longue période est essentiel pour établir de bonnes relations de travail.

Je recommanderais cette structure à toute équipe partageant certaines caractéristiques clés : une organisation interfonctionnelle dans laquelle les experts fonctionnels tels que les chefs de produit, les concepteurs et les ingénieurs sont des parties prenantes égales ; plus d'environ 15 à 20 personnes dans l'équipe combinée de développement de produits ; et, le plus important, une bonne adéquation produit-marché. Et si ce type de structure d'équipe vous intéresse, nous recrutons !