.png){kind=small}
NB : cet article s'adresse à des chef des projets ou entrepreneurs dans le secteur technologique.
La plupart des livres de références pour les startups qui parlent de product management s’appliquent en réalité surtout à des startups qui font du software ou une combinaison “software + service”. En effet, celles-ci possèdent un avantage fort en termes de flexibilité grâce à des CAPEX faibles et une capacité à micro-itérer constamment.
Nombre de ces principes peinent à s’appliquer tels quels dans une startup hardware, ou les réalités techniques, temporelles et économiques sont extrêmement différentes. Des notions comme l’agilité ou le MVP nécessitent d’être remis en question.
Voici quelques réflexions sur la façon dont les contraintes propres aux startups hardwares nécessitent de repenser le product management et sur les différences hardware/software.
Anticiper et prendre des risques lors de la phase de prototypage
Lorsqu’on fait du prototypage hardware, itérer prend beaucoup de temps. Ce temps s’est considérablement réduit grâce à l’apparition de l’impression 3D, mais reste nettement supérieur au temps d’itération d’une startup hardware. En software, itérer implique de repenser le design, de réécrire le code, de tester puis de pousser en production.
Faire une nouvelle version d’un prototype hardware implique de redessiner une CAO, d’imprimer en 3D (compter quelques heures à quelques jours) et/ou de commander des composants chez des fournisseurs (de quelques jours à quelques semaines), d’assembler le tout et de tester. Les durées varient fortement mais on peut dire sans trop prendre de risque qu’une itération en hardware est facilement 10 fois plus longue qu’une itération en software.
La conséquence est double.
D’une part, il faut anticiper les risques en hardware. Une erreur lors d’une itération risque d’être beaucoup plus coûteuse qu’en software, donc on ne peut pas se permettre de faire une petite erreur sur le dimensionnement d’un composant ou sur une CAO. La conséquence, c’est qu’il faut mettre en place des process solides de vérification lors de la conception pour minimiser les erreurs.
D’autre part, et paradoxalement, il faut également être prêt à prendre plus de risques en hardware. En effet, on ne peut pas se permettre de faire 50 mini-itérations. Il faut essayer de viser rapidement une version finale, et pour cela intégrer autant de changements que possibles d’une version à l’autre. L’équilibre est délicat à trouver.
Avoir un vrai MVP vendable et pas seulement un MVP
La réalité économique des startups hardware impose de penser très rapidement à la monétisation. Alors qu’une startup software peut se permettre de fournir à ses clients un MVP en freemium puis ajouter des fonctionnalités payantes par dessus par exemple, cela serait beaucoup plus difficile à réaliser pour une startup hardware, où les coûts sont beaucoup plus importants. Voici un certain nombre de coûts auxquels font face les startups hardware, que n’ont en général pas les startups de software :
acheter des composants
avoir un atelier de prototypage (outillage : impression 3D, CNC, petits outils, etc.)
investir dans des machines pour la production (moules à injection,...)
coûts liés aux brevets
coûts liés à la certification
Et d’une manière générale, les temps de développement étant plus longs en hardware, les frais de personnel sont plus importants également, puisqu’il faut payer des salaires d’ingénieurs sur des durées longues.
Cette notion de MVP vendable d’un produit hardware doit être intégré très tôt dans la démarche de développement de produit. Non seulement il doit être vendable, mais il doit idéalement l’être à un coût supérieur au coût de production.
Le mur de la valeur
Les coûts de production en hardware impliquent de vendre son produit cher et donc de bien réfléchir en amont à la valeur ajoutée créée pour le client. Elle doit être très importante - suffisamment pour justifier d’investir des sommes importantes dans un équipement robotique. C’est assez différent en software où, le coût marginal de déploiement d’un produit supplémentaire étant presque nul pour certains logiciels, celui-ci peut-être vendu pour un prix dérisoire.
Repenser le management face à des phases d’exécutions beaucoup plus longues
Développer un produit ou une fonctionnalité en hardware prend beaucoup de temps. Après une phase d’idéation, on réalise un prototype (ce qui implique d’attendre des pièces de fournisseurs et/ou les imprimer en 3D, ce qui prend plusieurs heures voire jours). Puis on le teste et on itère si le projet intègre une dimension R&D avec de l’incertitude. Chaque itération peut prendre plusieurs semaines ou mois en fonction de l’envergure du projet.
En conséquence, le rôle du chef de projet ou product manager hardware sera assez différent de celui de product manager software. En hardware, une fois un premier cahier des charges établi, il faudra attendre longtemps avant de le voir être concrétisé, si bien qu’un pilotage trimestriel peut suffire (en ce qui concerne la dimension produit - la dimension technique, elle, nécessitera un pilotage plus fréquent). En software, on fait généralement des réunions hebdomadaires ou bi-mensuelles de product management pour constater les progrès sur le produit et éventuellement décider des nouvelles priorités.
Anticiper l’infrastructure du produit : des choix qui auront beaucoup d’impact
En hardware comme en software, changer l’infrastructure qui sous-tend un produit est coûteux. Par exemple, changer de framework ou de langage de programmation après plusieurs années de développement produit peut-être particulièrement pénible en software.
Cependant, quels que soient les choix techniques initiaux, ajouter de nouvelles fonctionnalités à un logiciel restera généralement de l’ordre du faisable.
En hardware, une fois les choix de conception figés, certaines fonctionnalités deviendront tout simplement impossibles à réaliser. Par exemple, un robot lourd avec beaucoup de fonctionnalités ne sera jamais compact et facile à transporter. Tandis que dans un software, on peut facilement choisir de montrer ou cacher des fonctionnalités aux utilisateurs pour faire une version “Débutant” et une version “Avancée”, afin d’avoir des produits qui répondent à des attentes de consommateurs très différents, mais utilisant les mêmes fondations. Il faut donc prendre des décisions fortes en hardware, dès le début du projet, en sachant qu’on ne pourra pas revenir en arrière !
Intégrer la dimension économique en amont de chaque choix technique
Le coût des composants hardware force les ingénieurs à intégrer la dimension économique très en amont dans les choix techniques et à faire des compromis en permanence. Des matériaux plus résistants ou des moteurs avec des couples importants seront plus chers que des composants n’ayant pas ces caractéristiques. Bien dimensionner ses composants est clefs. Cela signifique que les ingénieurs hardware doivent avoir une connaissance raisonnable des coûts de tels ou tels composants ou procédé pour pouvoir trancher. En software, on rencontre moins ses problématiques. Il faudra bien dimensionner ses infrastructures, mais cette problématique se pose surtout pour les projets ou des sites internets avec un trafic très important. Pour les plus petits entreprises, qui reposent aujourd’hui souvent sur des infrastructures cloud scalable où l’on paye en fonction de la capacité de serveur utilisé ou du nombre de requête API, le problème se pose moins.
Conclusion : remarques pour entreprendre de le hardware
En résumé, pour entreprendre dans le hardware, il faut être patient, développer un produit qui apportera une valeur ajoutée réelle et importante à ses clients et se donner les moyens (financiers et temporels) d'y parvenir. Bon courage à tous les entrepreneurs du secteur, et à ceux qui souhaitent s'y lancer :)
Opmerkingen