Lessons learned: comment le produit permet à la deep tech d’avoir un impact sur le business

uptime a 4 ans. Chez uptime, 50% de l’équipe est focus sur la R&D depuis la création. Nous travaillons sur une petite niche de sales gosses : les ascenseurs. Un oligopole de quatre multinationales qui pèsent plus de 100 milliards d’€ de valorisation grâce à leurs revenus récurrents de maintenance, pas toujours dans l’intérêt des clients (KONE — KNEBV est valorisé 37x son profit, comme Alphabet — GOOG).

En 4 ans, nous avons développé la plateforme de maintenance prédictive la plus avancée de l’industrie, grâce à trois ingrédients et une recette spéciale :

  • une vision qui place la maintenance prédictive au coeur d’une refonte complète du modèle
  • une équipe de missionnaires impliqués et autonomes
  • un apprentissage complet sur la méthode produit… et son importance à tout élément de la stack.

La recette ? Full-stack innovation avant le scale. Créer immédiatement une entreprise de service, afin de prendre intégralement la verticale (du technicien en CDI sur le terrain jusqu’au client syndic) chez uptime, et être en mesure de contrôler toute la chaîne de valeur pour définir le produit qui la révolutionne. Et une fois que le produit émerge, le transformer en une plateforme mondiale pour tous les acteurs de service de l’industrie.

Mais pour y arriver, il a fallu apprendre quelques leçons.

Quand le produit n’est pas un add-on, mais core business

La majorité des start-up définissent un produit software qui vient s’ajouter à une stack d’outils très large, sur une verticale précise, ou pour tout type d’entreprise. Le défi d’uptime est tout autre : comment créer la plateforme tech qui fait sortir une industrie de l’obsolescence, en remplaçant intégralement son modèle productiviste du passé par un modèle centré client ?

Notre plateforme travaille avec des persona sur l’intégralité de la chaîne de valeur :

  • Le technicien, qui passe du papier-crayon à une application amie qui va l’aider du matin au soir pour toute son activité
  • Le manager Opérationnel, qui dépasse son rôle de terrain entre contrôle et urgences, à une responsabilité directe dans la satisfaction client grâce à un outil de pilotage et d’anticipation
  • Le commercial et customer-success manager, qui passent de la vente “relationnelle” à la vente de valeur, avec des outils et des rapports pour démontrer la performance et valoriser la transparence
  • Le client, syndic par exemple, qui passe d’un mode de défiance “je n’ai pas accès à l’information et seulement quand nous haussons le ton nos fournisseurs s’activent” à une relation de confiance grâce à l’info transmise en temps réel et la transparence sur toute l’activité
  • Le propriétaire et même l’usager, qui ne paie plus un service fantôme et n’a plus peur des pannes : il peut suivre l’activité de son prestataire, être notifié de tout incident, et savoir que son appareil est maintenu sans gâchis, sans remplacement de pièces peu nécessaire.

La technologie est au coeur du réacteur, pas uniquement un petit ajout sur le côté. Pour y arriver, nous combinons de la deep tech, hardware & data, et des problématiques UX à de nombreux niveaux.

🤔 Comment y arriver avec des ressources contraintes, celles d’une startup early stage ? Comment avons-nous pu révolutionner tout cela, créer une boîte hardware et IoT + une boîte software + une stack data + une boîte de service en même temps, avec les mêmes ressources que n’importe quel projet SaaS ?

Impact & produit : tout démarre du leadership de l’entreprise

Un des fléaux classiques du produit en startup est son incompréhension par les équipes de direction, fondateurs, directeur Sales, Ops, … En startup B2B on entend souvent les PM dire “le Head of Product est en réalité le Head of Ops ; la R&D est une fonction service, voire une fonction support”.

Nous sommes aussi passés par là au début de l’aventure, et pouvons aisément affirmer que la résolution de ce problème est fondatrice pour avoir un réel impact.

Aujourd’hui, nous fonctionnons en Product-First : la vision Produit et la stratégie Produit décident des priorités, plutôt qu’une liste de features souhaitées par les stakeholders, le Product Committee avec le CoDir n’est pas un outil de définition de roadmap et challenging de deadlines, mais un espace de présentation des avancées et implication des stakeholders, nous avons un RACI solide qui définit la coopération entre le Produit et les différents départements, les PM ont toute latitude pour trouver le meilleur moyen d’atteindre les objectifs business, pour définir les métriques des OKRs, etc. Le produit est ni drivé par les Sales ou les Ops, ni drivé par une techno en particulier (l’IoT par exemple) mais par des objectifs business et l’impact sur le client.

Comment faire ? Nous sommes passés par une évangélisation et une pédagogie intense, par une démonstration de l’impact quand on avance product-first, et donc un onboarding progressif des stakeholders qui ne peuvent pas refuser une méthode qui maximise l’impact ! Faites leur une offre qu’ils ne peuvent refuser.

Cela s’applique à l’intégralité de la stratégie… et de la stack.

Hardware : comment le produit guide des cycles longs

Le hardware fonctionne en cycle longs et les décisions ne sont pas réversibles. Il est donc impossible d’avoir une approche autre que celle du project management long terme… faux. A l’inverse, comme les décisions sont parfois irréversibles, il est essentiel que la conception soit orientée valeur business et fit utilisateur, et pas uniquement un composant technique d’une stratégie tech. Cf Apple, nous avons vite intégré la question de la valeur dans la conception. En 2 ans, nous avons itéré sur 3 versions de hardware différentes, avec du make, du buy, et différentes choix architecturaux (capteurs physiques, captation des données électroniques déjà présentes, connectivité…).

Cela nous a permis de créer une nouvelle version de notre propre produit qui incorpore tous ces apprentissages clés et qui se place en rupture par rapport à l’ensemble de notre éco-système concurrent.

Sans le focus sur la valeur business et celle utilisateur et sans les itérations rapides (pour du hard), nous n’aurions peut-être jamais pu créer cette avance majeure sur le marché.

Et quand on regarde la suite, les bénéfices du produit sont encore plus flagrants : à présent que notre hardware a validé son intérêt pour l’utilisateur final et permet une approche plateforme pour y ajouter des fonctionnalités, la majorité de la valeur générée vient du software embarqué. Bien qu’éloigné de l’utilisateur, les choix techniques et les priorisations à ce niveau ont un impact sur toute notre stack et chaîne de valeur en aval (quelles données remonter en priorité vs. fréquence, quelle harmonisation vs. spécificité parmi les modèles, quelle persistence vs connectivité, quel contrôle à distance, etc.). La méthode produit a donc un impact fort, à l’opposé d’une démarche ingénieur “FIFO” où je dépile les problèmes les uns après les autres, au rythme où ils se présentent.

Data : comment le produit passe de AI-bullshit à impact business

Combien de startups et de grands groupes parlent de AI, de ML, et ne peuvent démontrer un impact réel de leurs algorithmes, en KPI business (💰) et/ou en valeur utilisateur ?

De la même manière ici, il y a plusieurs approches à la création de valeur :

  • lancer tous les datasets dans une grande “forêt” et essayer d’apprendre des trucs
  • définir des use cases métier qui créent une valeur immédiate et quantifiable, les tester avec des heuristiques simples, et construire progressivement la stack des algorithmes.

La deuxième approche, qui met à nouveau le focus sur la rapidité de discovery sur des hypothèses de valeur vérifiables, nous a permis de sortir des cycles trop longs de data science, qui n’aboutissent qu’à très long terme sur un impact terrain / utilisateur ; et de générer des fonctionnalités utilisées chaque jour par nos utilisateurs avec une valeur démontrée.

Comme pour le Hardware, la Data n’est pas décorrélée du produit, c’est une démarche commune vers un objectif business commun, pilotée par une seule équipe et des squads qui ont l’habitude de travailler ensemble.

Utilisateurs terrain 👨‍🔧 : proximité & implication

Comment impliquer dans une innovation de modèle radicale, avec une forte composante de software, une population de terrain qui n’a pas bénéficié de toute la vague de B2B SaaS pour améliorer son quotidien ?

L’écrasante majorité des startups software B2B s’adresse à une population similaire — des collaborateurs de bureau, connectés, qui travaillent majoritairement par email (maintenant un peu avec Slack), qui font des visio, et à qui on vend un CRM, ou un Dashboard, ou un Plugin, ou un ERP, etc. Il y a nettement moins de startups software qui se soient penchées sur l’UX des populations de terrain, qui font des actions mécaniques, dans le cambouis, au fond d’une cage d’ascenseur, et seuls toute la journée. Dont l’email n’est qu’une partie extrêmement mineure de leur quotidien.

Chez uptime, nous avons résolu cela en ayant une proximité maximale avec les utilisateurs, et en les impliquant aux différentes étapes du cycle produit : les techniciens en CDI font partie de l’équipe d’innovation, et participer à l’élaboration des solutions, au testing des features, aux feedback sur la valeur terrain et client, fait partie de leur mission.

Et après ?

Aujourd’hui uptime est en train de passer à la phase 2 de son histoire : scale global en tant que plateforme de maintenance prédictive pour tous les acteurs du marché. Nous fournissons les pelles et les pioches d’une ruée vers l’or mondiale, où les ascensoristes valorisent leurs données et leurs organisations grâce à la technologie, et basculent dans un monde customer-centric. L’enjeu maintenant, c’est de passer à l’échelle toutes ces leçons et notre équipe. Rendez-vous dans 1 an pour le debrief ⚡

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store