Lundi matin. Vous êtes un studio de cinq personnes avec douze produits actifs. Trois d'entre eux génèrent des alertes de crash que vous devrez lire à un moment donné. Deux perdent de la rétention à cause d'une mise à jour d'application concurrente qui a été publiée ce week-end. L'un d'eux a une fiche de magasin qui doit être rafraîchie avant vendredi, sinon il perdra sa place en vedette. Il y a 47 avis clients en attente. Les dépenses pour le Jeu 4 ont augmenté de 30 % d'une manière ou d'une autre. Burak demande un appel de feuille de route. Quelqu'un dans l'équipe demande des nouvelles du Jeu 7. Votre semaine commence dans huit minutes.
Ceci est opérations de portefeuille. Personne n'a encore écrit le manuel pour cela.
La plupart des conseils opérationnels ont été rédigés pour une structure inadaptée
Le canon des opérations (les livres, les fils de discussion, les publications LinkedIn) suppose que vous gérez une seule chose. Embauchez un responsable de la croissance. Mettez en place votre tableau de bord d'entonnoir. Organisez votre conseil produit hebdomadaire. Choisissez une métrique North Star.
Rien de tout cela ne survit au contact d'un portefeuille.
Un studio de cinq personnes gérant douze produits n'est pas une petite entreprise. Ce n'est pas une startup à grande échelle. C'est une forme d'exploitation entièrement différente : effectif réduit, nombre élevé de produits, contexte superficiel par produit, contexte riche entre les produits. Le calcul des effectifs signifie que vous ne pouvez pas embaucher un responsable de la croissance pour chaque produit. Le calcul du nombre de produits signifie que vous ne pouvez pas organiser un conseil produit hebdomadaire pour chacun d'eux. Les manuels conçus pour l'une ou l'autre forme s'étirent et se brisent.
La plupart des studios le découvrent vers leur cinquième produit. Les trois premiers semblaient gérables. Le quatrième était difficile. Le cinquième a clairement montré : le cadre qui vous a amené ici ne peut pas vous mener à dix.
La forme n'a pas encore de nom établi. Certains opérateurs l'appellent un portefeuille. Certains l'appellent une holding. La plupart l'appellent simplement « nous gérons un tas de choses ». Quel que soit le nom que vous lui donnez, la discipline opérationnelle est une chose à part entière (opérations de portefeuille), et la majeure partie n'est pas écrite car elle vit dans la tête des opérateurs qui n'ont pas le temps d'écrire.
Ce billet est une tentative de commencer à l'écrire. Plus précisément : les cinq points où les manuels monoproduit échouent pour les studios multiproduits, et ce qu'il faut faire à la place.
Les cinq modes de défaillance
1. Le balayage manuel dévore le lundi matin
La première défaillance est la plus facile à repérer et la plus difficile à corriger. Chaque matin, quelqu'un de l'équipe scanne chaque produit. Tableaux de bord des crashs. Avis sur les magasins d'applications. Rapports de dépenses. Panneaux d'engagement. Boîte de réception du support client.
Pour le produit un, c'est le travail du fondateur et cela prend trente minutes. Pour le produit cinq, c'est toujours le travail du fondateur et cela prend trois heures. Pour le produit douze, cela ne se produit plus, et le studio découvre de vrais problèmes dans les tickets clients.
Le balayage manuel du portefeuille ne s'adapte pas. Non pas parce que les opérateurs sont mauvais, mais parce que le travail est intrinsèquement linéaire par rapport au nombre de produits et que l'opérateur est une seule personne. Vous pouvez gagner du temps avec des tableaux de bord, mais vous ne pouvez pas vous en sortir en ayant besoin de savoir laquelle des douze alertes produit est réellement importante.
Le travail qui doit être fait est le tri des signaux, et il doit être fait avant que l'opérateur n'ouvre le tableau de bord, pas après.
2. Les leçons se perdent entre les produits
Trois mois après avoir géré plusieurs produits, vous aurez la même conversation douloureuse deux fois : quelqu'un de l'équipe soulève un problème sur le Jeu 4, et un coéquipier plus ancien dit « nous avons résolu cela sur l'Application 2 en mars dernier ». Puis tout le monde réalise que personne ne se souvient de ce qu'était réellement la solution.
Les organisations monoproduit résolvent cela avec des wikis et des runbooks. Les studios de portefeuille ne le peuvent pas, car la leçon pertinente est enfouie dans le contexte d'un produit différent. Le runbook du Jeu 4 ne l'a pas. Le runbook de l'Application 2 l'a, mais seul le responsable de l'Application 2 lit ce runbook. La mémoire inter-produits ne vit de manière fiable dans la tête de personne.
La solution n'est pas un wiki plus grand. La solution est mémoire institutionnelle structuré par produit mais lisible sur tous les produits. Le problème de Jeu 4 et la solution d'App 2 doivent avoir la même forme, au même endroit, par défaut, sans que personne n'ait à les reformater.
3. Les moments de décision s'échappent
Chaque studio multi-produits a le même arriéré : des décisions qui auraient dû être prises mardi dernier et qui ne l'ont pas été. Le prix plancher de Jeu 4 qui aurait dû être ajusté il y a des semaines. Le rafraîchissement de la fiche de App 7. Le test de rétention sur Jeu 11 que personne n'a pensé à forker.
Le studio ne manque pas de jugement. Il manque de moments. L'appel qui prendrait dix minutes si le contexte était prêt prend deux heures de préparation, donc il est repoussé. Repoussé suffisamment de fois, il finit par ne plus avoir lieu.
Ce qu'il faut, c'est une cadence de décision: une garantie que pour chaque produit, certaines décisions se produisent à un rythme prévisible, avec le contexte déjà assemblé. Pas un calendrier de réunions, mais un contrat que le moment arrivera préparé.
4. Fragmentation du contexte interfonctionnel
Dans un petit studio, « interfonctionnel » ne signifie pas différentes équipes. Cela signifie les trois mêmes personnes portant trois casquettes. La personne qui gère les publicités gère aussi la fiche produit et les opérations en direct. Elles ne sont pas désalignées ; elles sont déphasées avec elles-mêmes.
Le problème est la surface d'exploitation. Les dépenses publicitaires se trouvent dans un outil. La fiche produit se trouve dans un autre. Le document des opérations en direct se trouve dans un troisième. Chacun raconte une histoire différente sur le même produit le même jour. L'opérateur est la seule chose consciente qu'il s'agit du même produit.
Le contexte interfonctionnel dans un studio de portefeuille ne concerne pas de meilleures réunions. Il s'agit d'un enregistrement unique par produit que la même personne peut lire sous trois casquettes différentes. Lorsque la question est « que se passe-t-il avec Jeu 4 aujourd'hui ? », il devrait y avoir une seule réponse à lire, pas trois à assembler.
5. Les boucles de croissance se dégradent silencieusement
L'échec le plus coûteux dans les opérations de portefeuille est celui que personne ne remarque. Une boucle de croissance est lancée, fonctionne pendant deux semaines, puis dérive. Le test de rétention qui devait être forké après la première cohorte n'est jamais forké. La courbe de monétisation qui a été ajustée en mars revient par défaut en juin. Personne n'est en tort ; personne ne fait même rien de mal. La boucle n'est tout simplement pas maintenue.
Dans les opérations monoproduit, le fondateur s'en souvient. Dans les opérations de portefeuille, le fondateur a onze autres choses à retenir.
Une boucle de croissance autonome est une boucle dont le système maintient la conscience : elle se manifeste lorsque la boucle se dégrade, lorsque ses hypothèses ont changé, lorsqu'elle doit être forkée. L'opérateur décide toujours. Le système s'assure que le moment de décider ne passe pas inaperçu.
Ce qui fonctionne réellement
Les solutions aux cinq modes de défaillance ne sont pas cinq outils distincts. C'est le même changement sous-jacent, appliqué à différentes surfaces. La plupart des studios multi-produits qui survivent au-delà de douze produits ont trouvé une version de cela par eux-mêmes, généralement douloureusement. Voici la version plus courte.
1. L'unité est le produit, pas l'entreprise.
La plupart des outils d'exploitation par défaut sont un espace de travail d'entreprise : une base de connaissances, un canal, un tableau de bord. Pour les studios multi-produits, c'est le mauvais défaut. L'unité canonique de mémoire doit être le produit. Jeu 4 a son propre enregistrement de décision, son propre journal de signaux, son propre magasin de contexte. Le portefeuille les lit au besoin, mais l'unité est le produit.
C'est la mémoire par produit. Cela semble évident ; presque aucun outil standard ne le fait par défaut.
2. Les décisions sont de première classe, pas des documents.
La plupart des outils enregistrent ce qui a été fait. Ce qui est nécessaire, c'est aussi pourquoi cela a été fait, quel signal a déclenché l'appel, et ce qui a été considéré et rejeté. Un « enregistrement de décision » n'est pas un document. C'est un artefact structuré qui survit à l'oubli de l'opérateur.
Le test : dans trois mois, un nouveau coéquipier pourra-t-il lire l'enregistrement du match 4 et reconstituer le raisonnement de l'opérateur au moment de l'appel ? Si oui, l'enregistrement fait son travail. Si non, le studio va apprendre la même leçon deux fois.
3. Cadence plutôt que capacité.
Vous ne résoudrez pas les opérations de portefeuille en embauchant. Vous les résoudrez en vous assurant que les décisions qui doivent être prises, le sont à un rythme que le studio peut soutenir. La « cadence de décision » est le contrat. Le travail du studio est de l'honorer.
4. Agents spécialisés, pas assistants généraux.
La tentation, lorsque les outils d'IA sont apparus, était de poser toutes les questions à un assistant général. Cela n'a pas survécu au lundi matin dans un vrai studio. Ce qui fonctionne, ce sont les « agents spécialisés» : un par fonction opérationnelle, avec une mémoire limitée et une seule tâche. Celui qui surveille les rapports de crash n'essaie pas de rédiger du texte. Celui qui surveille les listes de magasins ne propose pas de changements de monétisation.
La portée est le mécanisme de confiance. Un agent spécialisé avec une mémoire complète d'une fonction peut être audité, calibré et inversé. Un agent général avec tout ne le peut pas.
5. Un seul esprit opérationnel pour l'ensemble du portefeuille.
Les cinq points ci-dessus ne fonctionnent que s'ils vivent au même endroit. Sinon, vous avez simplement remplacé douze tableaux de bord par douze meilleurs. Le but du travail est « un seul esprit opérationnel» : le même cerveau lisant chaque produit, les mêmes agents agissant sur chaque ligne, l'opérateur n'étant plus la seule couche d'intégration.
Une note sur Qualia
C'est le playbook sur lequel nous construisons Qualia. Le produit est l'« AI COO » pour les opérateurs de portefeuille : petits studios de 2 à 10 personnes gérant 3 à 20 jeux ou applications en direct. L'architecture est une mémoire par produit, plus des agents spécialisés, plus un « cerveau de portefeuille partagé». Le défaut est intervention humaine. La métrique sur laquelle nous nous évaluons est l'ennui de l'opérateur: si un fondateur bâille en lisant un écran Qualia, l'écran est incorrect.
Nous sommes au début. Deux clients. Installation en 30 minutes. Si vous dirigez un studio multi-produits et que l'un des modes de défaillance ci-dessus vous ronge la semaine, nous aimerions discuter. Réserver une démo.
Pourquoi ceci est inédit
La plupart des manuels supposent que vous développez une seule chose. Les opérateurs de portefeuille se développent face à la multiplicité : plus de produits, le même effectif, pas de Slack par produit. Le travail est différent. Les outils doivent donc l'être aussi. Et le manuel aussi.
Si vous avez trouvé des versions de ceci que nous avons manquées, nous voulons les connaître.
Par Doğan Turan, Co-fondateur, Qualia ·