Nampoina Rakotoniaina, Head of Product et coach Produit chez Thiga, vient de vivre une première expérience au sein d’une entreprise qui conçoit des produits physiques. Un choc des cultures dont il témoigne afin de bâtir des ponts entre deux mondes si différents et pourtant si proches. Récit.
Avril 2023. Cela fait déjà 10 ans que je travaille dans le digital et me voilà propulsé au sein d’un groupe international coté en Bourse de plus de 135 000 personnes : Schneider Electric. Travailler en mission pour un spécialiste des équipements électroniques, comme des boutons poussoirs, des interrupteurs, des circuits électriques, des capteurs sensoriels ou des disjoncteurs, est une première pour le coach Produit que je suis. Je me demande alors : “Produit physique vs produit numérique… Fait-on le même métier et qu’avons-nous à apprendre les uns des autres ?”
Si certains produits embarquent bien du software, ce monde m’est totalement inconnu. Ma mission ? Bâtir des ponts ! Mon objectif ? Accompagner la transformation agile d’une équipe de 70 personnes basée en immense majorité à l’étranger. Je me rappelle encore de ce voyage à Zlín, en République Tchèque, quelques semaines seulement après mon arrivée. Je rencontre des personnes bienveillantes mais aussi assez méfiantes pour certaines, et notamment sur le sujet de l’agilité.
🤔 Leçon n°1 : “Notre métier, c’est douter”
Je l’ai dit, les débuts sont loin d’être confortables. D’une part, pour les équipes qui doivent remettre en cause leur façon de travailler et de penser. Mais également pour moi, qui doit apprendre leurs spécificités et questionner mes convictions.
Je le savais déjà mais cette expérience met en lumière une évidence : le doute fait partie intégrante de notre métier. On doute des retours des utilisateurs ou encore des solutions trouvées. Là, je doute des méthodologies agiles du software appliquées dans un environnement hardware ! Avec cette question, lancinante au début : “Serai-je crédible à leurs yeux ?”
Mais notre rôle est justement de cheminer pour faire progressivement diminuer cette incertitude. En l’occurrence, en se posant fortement la question du “pourquoi” dans nos pratiques respectives, en essayant de se comprendre les uns les autres et de trouver les points de convergence entre nos deux univers.
🍕 Leçon n°2 : “Oubliez les ‘pizza teams’ !”
Pour un produit numérique, il n’est pas surprenant d’avoir des tâches qui peuvent être réparties entre développeurs. Que cela soit en backend ou en frontend, il y a souvent une notion de full stack qui permet d’avancer efficacement.
La fabrication d’un produit physique demande parfois des expertises très spécifiques qui interviennent à des moments très précis de la conception du produit : électroniciens, mechanical designer, acheteur, chargé de certification… Si l’un d’entre eux est absent, c’est tout le processus qui s’enraye. Par ailleurs, l’auto-organisation, la montée en compétence et l’amélioration continue d’une équipe sur le modèle cyclique de Scrum n’est pas si simple pour des équipes hardwares et on a vite fait d’y renoncer.
Si tu viens du numérique et que tu n'adaptes pas ton prisme, tu fonces droit dans le mur…
Néanmoins, une tendance apparaît : celle de penser le travail en équipes, autour de “module” (un ensemble de composants délivrant de la valeur à l’utilisateur, comme le système de suspension et de freinage d’une voiture, apportant sécurité, confort, stabilité) plutôt que de laisser seule une personne travailler sur un composant (la pédale de frein).
Pour aller plus loin : téléchargez gratuitement notre livre Les Clés du Product Management
⏱️ Leçon n°3 : “Une temporalité différente de la Go Product roadmap”
Dans le numérique, lorsque l’on pense “roadmap”, on cherche à se donner de la visibilité. D’abord sur le “now” (l’horizon à trois mois), puis sur les initiatives qui viendront en “next” (l’horizon à 6-9 mois), et enfin sur celles qu’il faut dégrossir mais qui arriveront éventuellement sur le “later” (9 mois et plus). Tout juste arrivés dans l’univers du produit physique, on nous assène : ”En trois mois, on ne fait rien !”. La temporalité est différente pour un produit numérique et un produit physique. Ce dernier suit un cycle de fabrication très linéaire : un temps de conception, puis un temps d’industrialisation et enfin un temps de distribution, avec des délais parfois incompressibles. Encore une fois, si tu viens du numérique et que tu n'adaptes pas ton prisme, tu fonces droit dans le mur...
De plus, en hardware, une "erreur" ne se règle pas simplement en modifiant une ligne de code en production : la résolution ne se compte pas en jours mais en semaines - si ce n’est pas en mois - avec parfois de multiples et lourdes conséquences : rappel de tous les produits vendus en magasin, revue en usine de la conception physique d’une partie voire de l’ensemble du produit… Par ailleurs, certaines notions sont invisibles ou négligeables en software. Je pense aux enjeux de sécurité, de certification mais aussi et surtout de coût par exemple.
Contrairement au numérique, parce que le produit s'intègre dans un foyer, un bureau ou encore une usine, il faut impérativement respecter des normes de sécurité physiques très strictes, qui peuvent varier selon les pays ou régions. Et certaines de ces règles s'appliquent parfois aux prototypes : on ne peut pas tout tester dans n'importe quelles conditions. Ajoutez à cela le coût des tests de fiabilité et on comprend rapidement qu'on doit repenser (sans l'abolir) la notion de proximité avec l'utilisateur tout au long de la conception du produit. C’est cette complexité qui explique l’horizon temporel beaucoup plus lointain en hardware.
🧗 Leçon n°4 : “Des itérations plus complexes… ”
Assurer une collaboration permanente entre les utilisateurs et les équipes est plus compliqué en hardware. Les fréquences d’itérations n’ont rien à voir. Je pense aux tests qu’on doit faire d’un prototype : ce sont souvent des démos clients qui s'appuient alors sur des prototypes très avancés. Tout le contraire du numérique, où l'on teste souvent une partie du produit développée lors de la précédente itération.
L’enjeu est donc celui d’un changement culturel dans le hardware, en incitant à itérer aussi souvent que possible. Comme me l’a confié une coach Agile de Schneider Electric, “c’est aussi savoir accepter de mettre à l'épreuve des prototypes imparfaits”. L’important n’étant pas l’output (le prototype en tant que tel), mais l’outcome (ce que nous apprend le prototype, sa manipulation, son usage.) Une philosophie qui fait écho chez un Head Of Product IoT concurrent : “Si on n’avait pas eu près de 400 ambassadeurs pour tester un de nos produits tout au long du processus de conception, on n’aurait pas eu autant de retours sur certains problèmes. Là, on les a détectés avant de lancer la production en masse.”
📚 Leçon n°5 : “Ne surtout pas succomber au ‘by the book’”
L’Agile selon les règles n’est jamais gage de réussite : si cela est vrai dans le numérique, ça l’est encore plus pour un produit physique ! Il faut sans cesse s’adapter à son environnement. Sinon, cela signifie qu’on n’a rien compris à son métier de Product Manager.
Au fur et à mesure de l’avancement de ma mission, j’essaye de toujours me questionner sur la pertinence des modèles à déployer. Cette interrogation se matérialise notamment au moment de la mise en place des OKR. Généralement, ce concept est lié à l’impact que vous voulez avoir. Or, on l’a vu, mettre à disposition un produit physique prend plus de temps, car il doit être “terminé”. Pour les produits connectés, on peut toujours mettre à jour le logiciel ou anticiper une évolution en choisissant bien les composants. Mais cela reste complexe de “renouveler” la plus-value du produit, en proposant, comme en software, des améliorations très régulièrement.
C’est pourquoi, au lieu de m’enfermer dans une vision rigide, je décide de mettre de côté ce que j’avais appris en termes de bonnes pratiques, en adoptant une approche d’OKR parfois orientés output et non uniquement outcome. Le tout en gardant une vision stratégique à 5 ans avec un objectif commun à toute l’équipe. Le but ? Aligner les parties prenantes, prendre du recul et que tous aient à l’esprit le bénéfice final pour le client
A la fin de ma mission de 5 mois, nous avions réussi à planter une graine Agile dans ce terrain hardware. De quoi offrir aux équipes une meilleure capacité à s’adapter, à penser outcome et résultats plutôt qu’output et fonctionnalités. En bref, de quoi leur permettre d’être plus efficaces et de livrer de meilleurs produits.
Cela m’a également beaucoup appris sur mes propres pratiques en tant que Product Manager. Au lieu de rester dans ma zone de confort, j’ai dû adopter une approche pratique : nous sommes revenus à l’essence de l’agilité en s’appuyant sur ses grands principes non pas avec dogmatisme, mais avec flexibilité, en les subordonnant à la réalité matérielle. Par exemple, en faisant des concessions sur le rythme de livraison ou le travail quotidien avec les utilisateurs. Les règles, c’est bien mais le pragmatisme, c’est parfois mieux !
Je me suis surtout rendu compte qu’au fond, nos métiers ne sont pas si différents. Stratégie, discovery et delivery restent les trois piliers de nos disciplines. Les outils et les façons d’y arriver divergent, mais les principes et l’ambition restent les mêmes. Nous avons certainement des choses à apprendre les uns des autres. Encore faut-il avoir l’humilité de remettre en cause ses pratiques…
