Product management en PME : qui tranche quand il n'y a pas de chef de produit

Qui tranche à la place d'un chef de produit dans une PME de 30 à 150 personnes

Trois profils portent cet arbitrage de fait, aujourd'hui, dans la quasi-totalité des entreprises de cette taille que nous avons vues, qu'il s'agisse d'une application métier maison ou d'un site avec des fonctions dédiées. Le premier profil est le fondateur ou le dirigeant, encore proche du terrain et des clients, qui tranche entre deux réunions sans y consacrer un temps dédié. Le deuxième est le responsable technique, qui voit passer toutes les demandes parce qu'il doit les coder ou les faire coder.

Le troisième profil est différent des deux premiers : c'est le client le plus bruyant, celui qui relance par mail toutes les semaines, qui appelle directement le développeur, ou qui menace de partir si sa demande n'avance pas. Ce client n'a reçu aucun mandat pour arbitrer, et pourtant il obtient souvent gain de cause, simplement parce qu'il insiste plus que les autres.

Ce troisième cas est le pire des trois, et de loin. Le fondateur et le responsable technique connaissent au moins l'ensemble des demandes en attente et l'état réel du logiciel. Le client le plus insistant ne voit que sa propre demande, ignore ce qu'elle coûte à développer, et ignore surtout les dix autres demandes qui attendaient avant la sienne.

Une entreprise gouvernée par la voix la plus forte finit par construire un logiciel qui reflète qui a su le plus insister, pas ce qui sert le plus de monde. Les clients silencieux, souvent les plus fidèles, voient leurs besoins reportés indéfiniment pendant que le logiciel s'alourdit de cas particuliers réclamés par une minorité vocale.

Le fondateur qui tranche seul porte, lui, un autre risque : il devient le goulot par lequel toute décision doit passer, ce qui ralentit l'entreprise dès qu'il part en déplacement ou se concentre sur autre chose. Le responsable technique qui tranche seul, de son côté, priorise parfois ce qui est intéressant à coder plutôt que ce qui rapporte réellement à l'entreprise.

Nommer qui tranche ne veut donc pas dire choisir un sauveur parmi ces trois profils. Cela veut dire écrire noir sur blanc qui a le dernier mot cette année, sur quelle base il tranche, et prévoir comment ce rôle se transmet le jour où cette personne change de poste ou quitte l'entreprise.

Le symptôme qu'on reconnaît tout de suite : la liste qui ne finit jamais

Presque toutes les entreprises sans arbitrage nommé partagent le même symptôme, visible en une phrase : une liste de demandes qui grossit chaque mois et ne se vide jamais complètement. Elle vit dans un fichier partagé, un tableau, ou pire, dans la tête de plusieurs personnes qui n'ont pas la même version des priorités.

Le signe le plus parlant est la demande redemandée trois fois. Un commercial réclame un export en janvier, personne ne répond, il relance en avril, toujours rien, puis il le redemande en septembre en pensant que c'est une idée neuve. Chaque relance recommence la discussion depuis le début, comme si les deux précédentes n'avaient jamais existé.

Autre signe : les priorités changent à chaque réunion, sans qu'aucune décision précédente ne soit annulée formellement. La fonction jugée urgente en comité de direction lundi devient secondaire mardi parce que le responsable technique a évoqué une autre urgence, et personne ne sait plus laquelle des deux compte vraiment.

Prenez un exemple daté et concret, observé chez une entreprise de service d'une soixantaine de personnes : en un trimestre, quatorze demandes avaient été notées, aucune fermée, et trois d'entre elles avaient été reformulées deux fois par des personnes différentes qui ignoraient l'existence l'une de l'autre.

La liste qui ne finit jamais n'est pas un problème d'organisation au sens où l'entendent les grandes entreprises, avec des outils dédiés et des rituels hebdomadaires. C'est un problème plus simple : personne n'a le mandat de dire non, alors tout reste ouvert, et rien ne se ferme jamais vraiment.

Ce symptôme se repère en moins de dix minutes, sans outil particulier : demandez à voir la liste des demandes en attente, et regardez sa date de dernière mise à jour réelle. Si personne ne sait répondre précisément, ou si la réponse remonte à plusieurs mois, l'arbitrage manque déjà.

Quand ça reste gérable sans process dédié

Toutes les entreprises n'ont pas besoin de nommer cet arbitrage tout de suite, et le dire honnêtement fait partie de cette page. En dessous d'une dizaine d'utilisateurs réguliers du logiciel, un simple carnet ou un fichier partagé suffit largement à suivre les demandes sans rien formaliser de plus.

Une entreprise avec un seul produit et un fondateur encore au contact direct de ses clients garde en général une vision claire de ce qui compte le plus, sans avoir besoin d'écrire une règle d'arbitrage. La mémoire d'une seule personne, tant qu'elle reste disponible et proche du terrain, remplace une méthode formelle sans perte réelle.

Le signal à surveiller n'est pas la taille de l'entreprise en elle-même, mais le nombre de personnes capables de dire non à une demande sans en référer à quelqu'un d'autre. Tant que ce nombre reste à un ou deux, et que ces personnes se parlent chaque semaine, un carnet suffit.

Nous le disons directement à des dirigeants qui nous consultent pour ce sujet précis : si votre logiciel sert une seule équipe, si les demandes restent rares, et si vous connaissez déjà par cœur les trois priorités du trimestre, ne payez rien pour formaliser un arbitrage qui fonctionne déjà sans être écrit.

Le moment où ce confort s'arrête arrive en général sans prévenir : un deuxième produit qui apparaît, une deuxième équipe qui utilise le même logiciel avec des priorités différentes, ou simplement le fondateur qui délègue une partie de ses décisions à quelqu'un d'autre pour la première fois.

Ce moment coïncide souvent avec la fin du premier chantier, quand un premier périmètre restreint vient d'être livré et que l'entreprise découvre, en même temps que les premiers retours d'usage, la longue liste de tout ce qui n'y était volontairement pas inclus au départ.

Quand l'absence d'arbitrage commence à coûter cher

Le basculement se repère à des signaux concrets, toujours les mêmes d'une entreprise à l'autre. Le premier est le doublon : deux équipes développent, chacune de son côté, une version proche de la même fonction, parce que personne n'avait de vue d'ensemble des demandes en cours au moment où chacune a démarré.

Le deuxième signal est la fonction livrée que personne n'utilise. Elle a coûté du temps de développement réel, elle a fait patienter d'autres demandes derrière elle, et six mois après sa mise en ligne, les statistiques d'usage montrent qu'elle ne sert presque à personne. Elle avait été construite parce qu'elle avait été réclamée fort, pas parce qu'elle était utile largement.

Le troisième signal, le plus coûteux, est le client perdu pour une demande jamais traitée. Il avait signalé un manque précis, la demande s'est noyée dans la liste sans jamais être arbitrée, et il est parti vers un concurrent qui a répondu plus vite, parfois avec un outil réellement moins complet que le vôtre.

Ces trois signaux partagent une cause commune : l'absence de règle de décision ne se voit pas tout de suite, elle se voit dans les conséquences, plusieurs mois après. Une entreprise sans arbitrage nommé ne constate pas un problème de product management, elle constate un client parti, un doublon découvert trop tard, ou une fonction qui dort.

Le coût réel n'est presque jamais le développement en lui-même. Il est dans le temps perdu à reconstruire ce qui existait déjà ailleurs dans l'entreprise sans que personne ne le sache, et dans la confiance perdue chez un client qui a attendu une réponse qui n'est jamais venue, ni oui ni non.

Repérer ce basculement à temps évite le plus gros du dégât. Une entreprise qui compte deux signaux parmi les trois cités ci-dessus, sur les douze derniers mois, a largement dépassé le stade où un simple carnet suffit, même si personne n'a encore mis de mot dessus.

La méthode en quatre arbitrages pour trancher sans chef de produit dédié

Voici le cœur du sujet, réduit à quatre questions posées à chaque demande qui arrive sur le logiciel. Elles ne demandent aucun outil particulier, aucune certification, et se posent en quelques minutes une fois l'habitude prise. Elles suffisent à trancher la grande majorité des demandes rencontrées en pratique.

Premier arbitrage : qui a le dernier mot. Une seule personne, nommée à l'avance, doit pouvoir dire oui ou non sans consulter tout le comité de direction à chaque fois. Cela ne veut pas dire décider seule dans son coin : cela veut dire que la discussion se termine quelque part, au lieu de rester ouverte indéfiniment entre plusieurs personnes qui ne trancheront jamais.

Deuxième arbitrage : sur quelle preuve. Une demande appuyée sur un usage réel, plusieurs clients qui posent la même question, une perte de temps mesurée chaque semaine, pèse plus lourd qu'une intuition ou qu'une fonction vue chez un concurrent sans savoir si elle sert vraiment. Demander la preuve avant de dire oui suffit à écarter une bonne partie des fausses urgences.

Troisième arbitrage : à quel rythme. Les demandes ne se tranchent pas au fil de l'eau, dans le couloir, entre deux portes. Un rendez-vous fixe, toutes les deux semaines ou une fois par mois selon le volume de l'entreprise, où la liste entière repasse devant les yeux de la même personne, évite que la demande la plus récente écrase toutes celles qui attendaient déjà.

Quatrième arbitrage : comment on dit non. Une demande refusée sans explication revient toujours, reformulée, quelques mois plus tard. Une demande refusée avec un motif clair, communiqué directement à qui l'a posée, ferme le sujet la plupart du temps, même quand la réponse ne fait pas plaisir sur le moment.

Ces quatre arbitrages ne remplacent pas la frontière posée avant le début d'un projet par un cahier des charges, qui fixe ce que le premier chantier construit avant de signer. Le product management commence après cette étape, une fois le logiciel livré, quand les demandes continuent d'arriver sans qu'aucun document initial ne les ait prévues.

Une entreprise qui applique ces quatre questions pendant trois mois constate en général un changement simple à observer : la liste des demandes en attente cesse de grossir sans fin, même si elle ne se vide pas d'un coup. C'est le premier signe que l'arbitrage tient vraiment, au-delà des bonnes intentions du premier mois.

Ce que ça change dans les livraisons, concrètement

Avant l'arbitrage nommé, chaque livraison ressemble à une négociation recommencée depuis zéro : personne ne sait pourquoi telle fonction passe avant telle autre, et les développeurs découvrent souvent la prochaine priorité au dernier moment, sans avoir pu s'y préparer ni poser de question sur ce qu'elle sert réellement.

Après, le changement le plus visible est le nombre de demandes en attente, qui se stabilise au lieu de grimper d'un mois sur l'autre. Il ne tombe pas à zéro, et ce n'est pas l'objectif : une liste vide signalerait plutôt que plus personne ne demande rien, ce qui serait un signal inquiétant sur l'usage réel du logiciel.

Les développeurs, qu'ils soient internes ou prestataires, gagnent une chose simple qui change beaucoup : ils savent pourquoi ils construisent telle fonction plutôt qu'une autre. Cette clarté réduit les allers-retours, parce qu'une équipe qui comprend l'intention derrière une demande la construit correctement du premier coup plus souvent.

Un logiciel sur mesure vit longtemps après sa première mise en ligne, souvent des années, et la majorité du temps de développement se passe après cette première livraison, pas avant. Négliger l'arbitrage sur cette période longue revient à bien préparer le départ d'un chantier tout en laissant sa suite au hasard.

Le client final, lui, sent la différence même sans connaître le mot product management. Une entreprise qui arbitre explique pourquoi telle demande est traitée en premier et telle autre attend encore, avec une raison réelle à donner. Une entreprise qui n'arbitre pas répond souvent par un silence gêné, ou par une promesse vague qui ne se réalise jamais.

Les réunions de suivi changent aussi de nature. Au lieu de redécouvrir chaque semaine la liste entière des demandes, l'équipe se concentre sur ce qui a réellement bougé depuis la dernière fois, et sur les deux ou trois arbitrages qui restent à trancher. Une réunion qui durait deux heures sans conclusion claire se ramène souvent à trente minutes utiles.

Les pièges qui remplissent la liste au lieu de la vider

Le premier piège, le plus fréquent, est de dire oui à toutes les demandes pour ne fâcher personne. Cela semble gentil sur le moment, et cela coûte cher ensuite : chaque oui donné sans arbitrage ajoute une fonction de plus à maintenir, et l'entreprise finit par payer indéfiniment l'entretien de fonctions utilisées par une seule personne.

Le deuxième piège est de copier une fonction vue chez un concurrent sans vérifier qu'un client la demande vraiment chez vous. Le concurrent l'a peut-être construite pour une raison propre à son marché, ou l'a construite sans qu'elle serve à grand-chose non plus. La suivre sans preuve d'usage réel revient à arbitrer sur une intuition empruntée à quelqu'un d'autre.

Le troisième piège est de confondre une demande unique et un besoin général. Un client isolé réclame souvent une fonction très spécifique à sa manière de travailler, différente de celle de vos autres clients. La construire pour lui seul alourdit le logiciel pour tout le monde, alors qu'une réponse ponctuelle, hors du logiciel, aurait suffi à le satisfaire.

Le quatrième piège, plus discret, est de traiter les demandes dans l'ordre d'arrivée, comme un guichet, plutôt que selon leur poids réel. La demande arrivée en dernier n'est pas forcément la moins importante, et celle arrivée en premier n'a pas de droit d'ancienneté automatique sur les suivantes.

Le cinquième piège est de laisser la personne qui tranche décider aussi seule de ce qui compte comme preuve, sans jamais confronter son avis à un usage mesuré. Une préférence personnelle, même sincère, finit par peser plus que les faits si personne d'autre ne la questionne au fil du temps.

Reconnaître ces pièges suffit en général à ne plus y tomber, une fois qu'ils sont nommés. Aucun n'exige de méthode compliquée pour être évité : chacun se corrige en repassant simplement par les quatre arbitrages posés plus haut, à chaque nouvelle demande.

Trois décisions qu'un cadrage tranche avant que le développement commence

Sur nos propres chantiers, trois décisions reviennent systématiquement avant d'écrire la première ligne de code, et elles évitent la moitié des allers-retours constatés sur des projets qui n'ont pas pris ce temps. Aucune n'a besoin d'un vocabulaire compliqué pour être posée telle quelle à une équipe.

La première : quelle fonction passe en premier. Sur un projet qui compte, par exemple, huit fonctions demandées, toutes ne servent pas également le premier usage réel du logiciel. Trancher laquelle ouvre le chantier, avec un motif écrit, évite qu'elle soit choisie simplement parce qu'elle a été mentionnée en premier dans une réunion.

La deuxième : quelle demande attend. Certaines fonctions, réelles et légitimes, ne servent qu'une fois le premier usage installé et prouvé. Les mettre de côté par écrit, avec une date de réexamen, évite qu'elles soient oubliées tout en évitant qu'elles retardent ce qui doit sortir en premier.

La troisième : quelle demande ne se fera jamais. Une fonction parfois demandée avec insistance ne sert en réalité qu'un cas rare, ou contredit l'usage principal que le logiciel doit servir. La refuser tôt, avec une explication posée par écrit, coûte moins cher que de la construire puis de la retirer un an plus tard faute d'usage.

Ces trois décisions, une fois posées, ne se rejouent pas à chaque réunion suivante : elles servent de référence quand une nouvelle demande arrive et ressemble à une question déjà tranchée. C'est cette mémoire écrite, plus que la décision elle-même, qui fait gagner du temps sur la durée du projet.

Un dirigeant nous a résumé cette étape ainsi, après un chantier de refonte pour son équipe commerciale : « avant, on redécidait tout à chaque réunion, maintenant on retrouve la réponse dans le document et on passe à autre chose ». Ces trois décisions posées à l'avance servent à cela, et à rien d'autre.

Comment le cadrage Techmind installe cet arbitrage dès le départ

L'offre de cadrage ne vend pas un document de plus à ranger dans un tiroir. Elle installe, avant d'écrire la première ligne de code, les quatre arbitrages décrits plus haut : qui décide chez vous, sur quelle preuve, à quel rythme, et comment un refus se formule sans abîmer la relation avec qui l'a demandé.

Concrètement, nous passons du temps avec les personnes qui remontent le plus de demandes dans votre entreprise, commerciaux, comptabilité, direction, pour recenser ce qui est réellement attendu du logiciel, et pas seulement ce qui a été le plus répété récemment. Cette étape sert de base aux trois décisions détaillées à la section précédente.

Nous écrivons ensuite qui, chez vous, tiendra l'arbitrage une fois le projet livré, en général le responsable technique existant ou le fondateur, plutôt que d'imposer un rôle nouveau. Ce choix se pose selon qui a déjà le contact avec vos clients et vos équipes, pas selon une préférence de méthode venue de l'extérieur.

Le prix de cette étape se situe entre 5 000 et 15 000 euros selon la taille de l'entreprise et le nombre de personnes à rencontrer, et se rembourse souvent par les seuls allers-retours de développement évités sur le chantier suivant. Elle précède, quand elle est retenue, un projet de logiciel sur mesure de 15 000 euros et plus selon son ampleur.

Nous ne restons pas ensuite décider à votre place, mois après mois : ce n'est pas ce que l'offre vend, et ce n'est pas ce dont une entreprise a besoin durablement. L'objectif est que la méthode tienne seule chez vous, portée par quelqu'un qui existe déjà dans votre organisation, une fois notre intervention terminée.

Pour voir comment nous cadrons ça avec vous, la page de l'offre détaille le déroulé complet, les personnes rencontrées et ce que vous recevez à la fin : voir l'offre de cadrage Techmind.

Transmettre l'arbitrage quand l'équipe grandit et change

L'arbitrage posé aujourd'hui repose souvent sur une seule personne, et cette personne finit un jour par changer de poste, prendre plus de responsabilités ailleurs dans l'entreprise, ou simplement partir. Une méthode qui n'existe que dans sa tête disparaît avec elle, et l'entreprise revient au point de départ, sans même s'en rendre compte tout de suite.

Le signe qui annonce ce moment est souvent la croissance elle-même : une deuxième équipe qui utilise le logiciel, un deuxième produit qui apparaît, ou simplement plus de personnes qui remontent des demandes qu'une seule personne ne peut plus toutes connaître par cœur, contrairement à quand l'entreprise comptait trente personnes.

Écrire l'arbitrage, même en une page, change la donne au moment de la transmission. Les quatre questions posées plus haut, une fois notées avec des exemples concrets de décisions passées, se relisent en une demi-heure par la personne suivante, au lieu de se réapprendre sur plusieurs mois d'essais et d'erreurs.

Certaines entreprises attendent que la personne qui tenait l'arbitrage soit déjà partie pour s'en préoccuper, et perdent alors plusieurs mois à reconstruire une mémoire qui existait déjà, mais seulement dans une tête. Prévoir cette transmission avant qu'elle ne devienne urgente coûte largement moins cher que de la subir dans l'urgence.

Ce sujet touche aussi les entreprises qui grandissent par la reprise d'une autre structure, ou qui ouvrent un deuxième site : l'arbitrage tenu jusque-là par une personne proche du terrain doit alors s'exprimer pour des équipes qui ne la connaissent pas encore, ce qui n'est possible que si la méthode a été écrite quelque part avant.

Une entreprise qui traverse cette transmission sans y avoir réfléchi retrouve en général les mêmes symptômes que celle qui n'avait jamais nommé d'arbitrage du tout : la liste qui regonfle, les priorités qui changent à chaque réunion, et le client le plus bruyant qui reprend la main faute d'une règle claire à faire valoir.