Développer en interne ou acheter une solution externe ? Telle est souvent la question pour des Product Managers. Brice Bottégal, Senior Product Manager chez Doctolib, a justement écrit récemment une série d’articles sur ce sujet du Make or Buy. Interview.
7 min (bien investies) de lecture
✉️ Article issu du Ticket N°62
Salut Brice. Pourquoi as-tu décidé d’écrire des articles sur ce sujet qui n’est pas très courant dans l’écosystème ?
Brice Bottégal : Justement parce qu’il n’existait pas de ressources très actionnables sur cette question, alors qu’elle est légitime et essentielle en tant que Product Manager. N’oublions pas qu’au fond, nous sommes moins des concepteurs de fonctionnalités que des accélérateurs d’impact. Cette distinction change la perspective sur notre métier et la vision que les entreprises en ont.
Ton point, c’est de dire qu’il ne faut pas toujours penser à développer une fonctionnalité pour répondre à un problème, c’est ça ?
B.B. : Exactement. Face à une problématique donnée, il me semble que la grande majorité des PM vont tout de suite se dire qu’il faut développer une fonctionnalité. Alors que ce n’est qu’une possibilité parmi d’autres options.
D’ailleurs, en écrivant mon 1er article, je me suis rendu compte que la première question à se poser n’est pas “développer ou acheter”, mais plus globalement comment avoir l’impact espéré le plus rapidement possible ? Cela peut être l’amélioration d’un process, le recrutement d’une personne… Bref, je trouve que ça fait prendre du recul par rapport au rôle de PM. En se concentrant avant tout sur l’outcome, on s’ouvre plein de perspectives.
Une feature team classique peut vite atteindre 900 000 € par an. Soit 225 000 € le trimestre ou 40 000 € le sprint de deux semaines ! À ce prix, tu peux te payer un bel outil…
D’autant que, comme tu l’écris, on sous-estime souvent le coût d’une équipe produit.
B.B. : Oui, si vous prenez une feature team classique avec un·e Engineering un·e Product Manager, 4 dev et des UX Designer, Data Analyst, User Research et des profils transverses à temps partiel, on peut vite atteindre 900 000 € par an. Soit 225 000 € le trimestre ou 40 000 € le sprint de deux semaines ! À ce prix, tu peux te payer un bel outil…
C’est un estimatif pour une scale-up qui comprend tous les coûts de structure (de l’ordinateur à la chaise de bureau) et les salaires chargés. Le montant est moindre dans une startup, mais, il n’empêche, cela permet d’appréhender la question du Make or Buy sous un angle différent. Sans compter évidemment les coûts d’opportunité, ce que vous ne faites pas pendant que vous travaillez sur un sujet.
Peux-tu nous raconter l’expérience concrète que tu as vécu chez Doctolib qui t’a amené à écrire la série d’articles ?
B.B. : Je suis arrivé en mars 2021 pour devenir PM d’une nouvelle feature team, appelée DC (pour Data Collection). En résumé, notre mission, c’est de produire de la data la plus qualitative et complète possible sur des professionnels de santé pour nos clients internes, notamment les commerciaux, mais également pour les patients. Quand vous vous rendez sur le site Doctolib, c’est ce qui permet de produire la fiche d’un praticien afin de le contacter, même s’il n’est pas client chez nous. On est donc plutôt une équipe orientée back-end.
Cela fait 3 ans qu’un outil a été développé en interne par plusieurs équipes en fonction de leur bande passante. Et pour répondre à un nombre croissant de cas d’usage, il a été décidé d’y dédier une feature team à part entière, d’où mon recrutement.
À quel moment te rends-tu compte qu’il s’avère plus judicieux d’acheter une solution existante plutôt que de continuer le développement en interne de cet outil ?
B.B. : Assez vite en fait. Avec mon manager, on a commencé par faire ce qu’on appelle chez Docto un document de référence, dans lequel on retrouve la mission, les KPI et les grands besoins utilisateurs de l’équipe. Et c’est à ce moment, en se posant avec l’Engineering Manager, qu’on s’est rendu compte que, pour atteindre cette mission, cela nécessiterait environ 2 ans de travail. Ça fait beaucoup !
À l’été 2021, on décide donc de regarder s’il n’y a pas moyen de faire autrement plus rapidement, et on commence à explorer la piste des prestataires externes.
Donc si on résume : on t’embauche pour développer un produit… et tu proposes de passer par une solution externe ! Comment ont réagi tes parties prenantes, sachant que tu scies un peu la branche sur laquelle tu es assis, non ?
B.B. : En effet, ça secoue un peu en tant que PM. Mais encore une fois, on est là pour avoir de l’impact le plus rapidement possible, quel que soit le chemin que l’on prend. Si on atteint en 6 mois notre objectif au lieu de deux ans, on a rempli notre mission, peu importe la manière d’y arriver.
Après, je dirais que c’était plus perturbant pour l’équipe que pour moi. Il est plus difficile pour des dev de se dire qu’ils ne vont pas développer une solution mais des choses autour de cette solution. Une personne a été honnête et m’a dit que ça l’intéressait moins et elle a rejoint une autre équipe par exemple. Il est important de bien expliquer le contexte et la raison de cette décision.
Idem pour le management : si tu montres que factuellement, il est plus pertinent d’aller dans cette direction, on va te challenger un peu mais on te fera confiance au final.
L’exercice a dû être d’autant plus difficile qu’il y avait un historique de 3 ans derrière…
B.B. : Oui, le contexte n’aidait pas avec des personnes attachées à la solution existante en interne. Rétrospectivement, il aurait fallu se poser cette question 3 ans plus tôt. Mais c’est là où c’est intéressant : à l’époque, les logiciels dont on avait besoin n’existaient pas et la conclusion aurait été malgré tout de le faire en interne !
En fait, cette question du Make or Buy ne doit pas se poser ponctuellement quand on lance un produit ou une fonctionnalité mais tous les ans. Des nouvelles technos arrivent régulièrement sur le marché et peuvent potentiellement rabattre les cartes de son investissement sur tel ou tel sujet.
Le Product Management pertinent (mais pas chiant)
Pour boucler l’histoire chez Doctolib, où en êtes-vous actuellement ?
B.B. : Nous avons donc mené tout un travail de recherche de la meilleure solution. J’explique dans les articles comment : du screening via les études de Forrester ou Gartner, en passant par les phases de Request for Information (RFI), de Request for Proposal (RFP), de démo et de Proof of Concept (POC).
De là, nous avons choisi notre prestataire et on est aujourd’hui en train de finir le set-up de cette solution et d’affiner sa configuration pour exploiter pleinement sa valeur. On est vraiment content du résultat. C’était certes plus difficile que prévu à mettre en place mais on a beaucoup plus de potentialités qu’auparavant !
Penses-tu que vous auriez pris la même décision s’il s’agissait du produit coeur de Doctolib ?
B.B. : Je dirais qu’il faut systématiquement se poser la question, oui. Peu importe s’il s’agit de ton produit cœur ou pas. Il y a beaucoup de boîtes qui peuvent avoir une solution qui répond à tout ou partie du problème que tu veux résoudre. Après, il y a évidemment tout l’enjeu de l’avantage concurrentiel que tu veux développer et du risque stratégique de reposer sur un prestataire externe. Sans oublier le modèle économique en cas de passage à l’échelle.
Tu peux aussi décomposer ton produit et voir ce que tu peux externaliser. Par exemple, sur une fonctionnalité comme l’authentification, il existe déjà sur l’étagère des briques technologiques sans que tu aies besoin de réinventer la roue. Idem pour la recherche avec un acteur comme Algolia ou l’envoi de SMS avec Twilio.
En fait, ce que l’on retient, c’est que cette question du Make or Buy fait partie de la phase de Discovery et correspond à notion de recherche de la solution par rapport à un problème identifié, dans le double diamant.
B.B. : Il faut effectivement consacrer un temps proportionnel à l’investissement de développement. Si tu as 2 ou 3 jours de dev, il ne faut pas passer plus d’une heure à voir si quelque chose existe déjà. Si, comme c’était notre cas, ton temps de dev dépasse un an, ça vaut le coup de passer un mois pour vérifier que l’investissement sera pertinent !
