Product Management : de l’ascenseur au code

Fille d’expatriés depuis mes 12 ans, j’ai grandi, étudié puis commencé à travailler à Londres, où je suis restée jusqu’à mes 25 ans, portée par le côté dynamique de cette ville.

Si vous m’aviez dit quelques années plus tôt que quand je partirais de Londres ce serait pour rentrer en France, je ne vous aurais pas cru.

Et pourtant, il y a 6 mois, j’ai emménagé à Paris, où l’effervescence nouvelle autour des startups m’a attirée. Et quoi de mieux finalement que de rejoindre une équipe dynamique dans un domaine fortement réglementé qui a peu évolué depuis 150 ans?

J’ai rejoint WeMaintain en tant que Product Manager afin d’utiliser les outils numériques pour transformer le marché de l’ascenseur. Entendons-nous bien sur le mot transformer et non remplacer : nous avons la conviction profonde chez WeMaintain que le métier de technicien de maintenance est essentiel et irremplaçable.

Un technicien est un expert qui ne peut certainement pas être remplacé par des capteurs : il utilise ses mains, effectue des tâches différentes sur des technologies variées et doit se déplacer de site en site. Certains parlent d’ascenseurs connectés, nous préférons la vision du technicien augmenté ! Il est indispensable car il doit intervenir sur site pour faire du préventif et traiter le curatif.

Routine Jobs vs Non-routine Jobs – les techniciens ne sont pas prêts d’être remplacés

Cependant le métier de technicien de maintenance a globalement peu profité des évolutions technologiques et nous avons identifié une vraie urgence à développer un produit – en l’occurrence une application smartphone – qui lui permettrait de faire sa maintenance plus simplement et de se concentrer sur l’essentiel en limitant les tâches qui peuvent être automatisées.

S’il ne m’a pas fallu plus d’une heure pour être sûre de vouloir rejoindre cette aventure, convaincue par les valeurs de la startup et sa volonté de revaloriser les métiers techniques, j’appréhendais un peu comment j’allais pouvoir interagir dans mon travail avec les techniciens, n’ayant absolument aucune connaissance sur le sujet.

Je ne vous apprends rien, quand on doit tout apprendre, il ne faut pas avoir peur de se retrousser les manches et d’aller sur le terrain.

Product manager et un peu technicienne ?

En effet, je n’avais pas vraiment le choix : pour comprendre les attentes des utilisateurs de l’application, j’ai passé la moitié de mon temps avec eux y compris sur site pour comprendre leur façon de travailler et leurs contraintes et leurs besoins.

En vrai des moments plutôt sympas avec Patrick et tous les techniciens partenaires

Un exemple tout bête : notre promesse est de pouvoir fournir aux clients des rapports d’intervention avec photos à l’appui des informations. Mais encore fallait-il que l’application soit hyper-ergonomique pour que le technicien puisse prendre des photos sans effort alors qu’il est peut-être à ce moment-là dans une position inconfortable.

Ou encore lorsqu’il s’agit d’écrire son rapport en ligne via l’application c’est bien mais sans réseaux.. c’est plus compliqué. Comment rendre possible la rédaction du rapport en instantané dans un enceinte métallique qu’est la cage de Faraday, étanche aux champs électriques ? Créer une application qui fonctionne en offline était l’une de nos features (fonctionnalités) principales pour la V2.

Ces discussions de groupe et 1-to-1 avec les techniciens me sont apparus comme absolument essentiels. C’est par les techniciens que passe notre service, ils sont en contact direct avec les clients et si l’interface client doit être parfaite, l’application pour les techniciens ne doit pas l’être moins.

Nous avons formalisé ces échanges et au-delà des feedbacks quotidiens j’ai mis en place un moment hebdomadaire avec la communauté de techniciens. Ces moments nous ont aussi permis d’apprendre à mieux nous connaître.

Les connaître et comprendre leurs besoins était le début. Transcrire ces besoins et les rendre compréhensibles est très facilement intégrables par l’équipe de développeurs c’était encore une autre histoire.

From tech(niciens) to tech(nologie)

Pas plus que moi, avant de rejoindre l’aventure, l’équipe de développeurs n’avait de connaissances “ascenseurs” et c’est normal ce n’est pas leur métier. Ne pas connaître grand-chose au monde de l’ascenseur n’est pas un frein dans ce cas, c’est même souvent un atout pour challenger certaines pratiques et remettre en question le statu quo.

La mission de l’équipe dev c’est de pouvoir développer un super produit extrêmement rapidement et de l’améliorer en quasi temps-réel.

Chez WeMaintain nous travaillons en mode agile avec comme outil principal Jira.

Ce n’est pas l’objet de cet article de détailler ce qu’implique cette méthode de travail. Il faut retenir que grâce à ce mode de travail, nous livrons tous les 15 jours une nouvelle version du produit que l’on peut donc tester immédiatement, avoir un retour utilisateur et changer de direction le cas échéant.

A titre d’exemple, une de nos features les plus importantes développées ce dernier trimestre est la mise en place d’un calendrier optimisé pour les techniciens. Ils doivent en effet assurer de multiples visites régulières de maintenance, des interventions en urgence, des astreintes etc. dans une journée très chargée. Le premier réflexe aurait été de spécifier puis développer un calendrier « parfait » ayant toutes les fonctionnalités rêvées ce qui aurait pris du temps sans garantie que cela conviennent aux principaux concernés : les techniciens. Nous avons préféré repartir des contraintes des techniciens pour développer une fonctionnalité viable et utile pour eux puis d’itérer à partir de là avec l’équipe de développeurs.

Gestion d’évènements des techniciens (scheduling)

Au-delà de comprendre le besoin et de correctement le retranscrire pour l’équipe des développeurs, il faut en permanence se poser la question de l’équilibre entre demande business (« j’ai absolument besoin de cette fonctionnalité ») et complexité technique associée évaluée par l’équipe technique. Cette question nous permet d’identifier LA priorité parmi toutes les priorités que nous avons et d’avancer progressivement.

Dit plus simplement, nous ne développons pas pendant un an un produit complètement à côté de la plaque – nous interagissons énormément avec les usagers et si ce n’est pas bon nous ne persistons pas. Nous préférons fonctionner avec des améliorations incrémentales mais rapidement réalisables plutôt que de se lancer dans des chantiers titanesques sans certitude.

La mission derrière le produit

Alors certes nous ne venons pas tous du monde de l’ascenseur chez WeMaintain mais je crois que c’est justement notre force. A nous de coordonner nos compétences si variées pour transformer le modèle dominant tout en revalorisant les principaux acteurs : les techniciens. Sans considération pour eux, il ne peut exister de service digne de ce nom !

Aujourd’hui, être à Paris, au sein d’une startup dans la maintenance d’ascenseurs, me paraît bien naturel. Bien sûr, cela interpelle souvent quand je me présente, mais cela prouve au final que le statu quo est en train d’être bousculé.

Product Manager @ WeMaintain

Rédiger une réponse:

Votre adresse email ne sera pas publiée.

Pied-de-page du site