AccueilBlog › Guide opérationnel de gestion de portefeuille

Note de terrain · Opérations de portefeuille

Le guide non écrit pour gérer 12 applications avec 5 personnes

Lundi matin. Vous êtes un studio de cinq personnes avec douze produits en ligne. Trois 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 lancée ce week-end. L'un 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 inexplicablement augmenté de 30 %. Burak demande un appel sur la feuille de route. Quelqu'un dans l'équipe pose des questions sur le Jeu 7. Votre semaine commence dans huit minutes.

C'est ce qu'on appelle les opérations de portefeuille. Personne n'a écrit le guide pour cela.

La plupart des conseils opérationnels ont été écrits 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. Configurez 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 entreprise plus petite. 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 par produit superficiel, contexte inter-produits riche. 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 guides conçus pour l'une ou l'autre forme s'étirent et se brisent.

La plupart des studios le découvrent autour de 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 mené ici ne peut pas vous mener à dix.

Cette forme n'a pas encore de nom établi. Certains opérateurs l'appellent un portefeuille. Certains l'appellent une holding. La plupart se contentent de dire « nous gérons un tas de trucs ». 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 guides pour un seul produit échouent dans les studios multi-produits, et ce qu'il faut faire à la place.

Les cinq modes d'échec

1. Le balayage manuel dévore le lundi matin

Le premier échec est le plus facile à repérer et le plus difficile à corriger. Chaque matin, quelqu'un de l'équipe scanne chaque produit. Tableaux de bord de 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 fait plus, et le studio découvre les vrais problèmes via les tickets clients.

Le balayage manuel de portefeuille ne passe pas à l'échelle. 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 passer de savoir laquelle des douze alertes produit est réellement importante.

Le travail à accomplir est le tri des signaux, et il doit avoir lieu 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'App 2 en mars dernier ». Puis tout le monde réalise que personne ne se souvient de la solution réelle.

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'App 2 l'a, mais seul le responsable de l'App 2 lit ce runbook. La mémoire inter-produits ne réside de manière fiable dans la tête de personne.

La solution n'est pas un wiki plus grand. La solution est une mémoire institutionnelle structurée par produit mais lisible à travers les produits. Le problème du Jeu 4 et la solution de l'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 multiproduit a le même arriéré : des décisions qui auraient dû être prises mardi dernier et ne l'ont pas été. Le prix plancher sur le Jeu 4 qui aurait dû être ajusté il y a des semaines. La mise à jour de la fiche produit sur l'App 7. Le test de rétention sur le 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, il est donc repoussé. Repoussé suffisamment de fois, il cesse d'avoir lieu.

Ce qu'il faut, c'est une cadence de décision : une garantie que pour chaque produit, certaines décisions sont prises à 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. Le contexte transfonctionnel se fragmente

Dans un petit studio, « transfonctionnel » 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 gère aussi 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.

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 le 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 forker 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.

Un cycle de croissance autonome est un cycle dont le système reste conscient : il signale quand le cycle se dégrade, quand ses hypothèses ont changé, quand il doit se diviser. 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 fondamental, 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 de manière douloureuse. Voici la version plus courte.

1. L'unité est le produit, pas l'entreprise.

La plupart des outils opérationnels par défaut utilisent 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. Le Jeu 4 a son propre enregistrement de décision, son propre journal de signaux, son propre magasin de contexte. Le portefeuille les consulte si nécessaire, mais l'unité est le produit.

C'est ce qu'on appelle les mémoire par produit. Cela semble évident ; presque aucun outil standard ne l'offre par défaut.

2. Les décisions sont des éléments de premier ordre, 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 Jeu 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 apprendra 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 selon 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 tout demander à 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 esprit opérationnel unique 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 esprit opérationnel unique: 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 : de petits studios de 2 à 10 personnes gérant 3 à 20 jeux ou applications en direct. L'architecture est une mémoire par produit, des agents spécialisés et un cerveau de portefeuille partagé. Le mode par défaut est humain dans la boucle. La métrique sur laquelle nous nous évaluons est l' ennui de l'opérateur: si un fondateur lisant un écran Qualia bâille, l'écran est incorrect.

Nous en sommes aux débuts. Deux clients. 30 minutes de configuration. Si vous dirigez un studio multi-produits et que l'un des modes de défaillance ci-dessus vous ronge la semaine, nous aimerions en discuter. Réserver une démo.

Pourquoi ceci est inédit

La plupart des playbooks supposent que vous faites évoluer une seule chose. Les opérateurs de portefeuille évoluent 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. Et le playbook aussi.

Si vous avez trouvé des versions de ceci que nous avons manquées, nous voulons les connaître.

Par , Co-fondateur, Qualia ·

Articles similaires