product builder image Uncode School

Pourquoi le Product Builder émerge t-il maintenant ?

Résumé_

L'histoire du Product Builder est encore jeune. Toutefois, il faut bien constater que l'histoire de l'informatique, qui va vers de plus en plus de simplification ainsi que le développement des fonctions Product au sein des entreprises, conduit assez naturellement à l'émergence d'un profil de Product Builder. Finalement, ce nouveau métier / profil qui profite à plein du développement des outils no code pourrait devenir, à terme, un chaînon indispensable de la transformation digitale des entreprises. Retour sur un historique qui puise ses sources dans l'histoire de l'informatique et qui voit dans l'émergence des outils no code une belle opportunité pour faire émerger un nouveau profil clé.

Dans un précédent article, nous avons parléparlé de notre vision du Product Builder tel que nous le voyons chez Uncode School.

Pour rappel, le Product Builder, dans la manière dont nous le définissions, est un nouveau rôle hybride qui a la tâche de pouvoir avoir une véritable culture Product combinée à la capacité de réaliser effectivement les produits via des outils no code. En d'autres termes, alors qu'avant (et qu'aujourd'hui encore), on donne un rôle différent à la personne qui recherche la problématique métier (Product Manager/Designer) et un autre rôle à une personne en charge de réaliser la solution (développeur). Le Product Builder à la tâche de combiner à la fois ces 2 rôles sur des problématiques particulières.

On remarque que le métier de Product Builder arrive sur le marché avec la conjonction de deux phénomènes.

D'une part, ce nouveau rôle est poussé par l'émergence des outils no code qui sont de plus en plus matures pour réaliser techniquement un très grand nombres de solutions techniques. Le développeur a bien évidemment toujours un vrai rôle, mais son rôle va changer notamment suite à l'arrivée de ces outils no code.

D'autre part, on voit arriver progressivement sur le marché de vraies demandes pour ce type de profil. Et pour cause. Ce profil hybride est particulièrement adapté à la transformation digitale des entreprises puisqu'il est capable de posséder une culture Product ainsi qu'une cutlure de développeur. Et pour être totalement honnête, il y a déjà pas mal de profils sur le marché qui correspondent déjà à ce type de profil. Toutefois, force est de constater que le marché n'était pas encore mature pour les voir effectivement arriver. C'est en train de changer !

Attention, notre discours n'est pas de dire que le Product Builder est finalement le "meilleur profil" et qu'il faut mieux payer un Product Builder qu'un Product Manager et un développeur. Cela serait probablement une erreur parce que ce n'est pas comme cela qu'il convient d'analyser la situation. Parce que, selon nous, chacun de ces profils à beaucoup de valeur en entreprise. Mais encore faut-il savoir les (re)positionner.

Non, le/la Product Builder c'est pas un magicien(ne). Pas plus que d'autres profils. Toutefois, ses compétences vont être plus que bienvenues dans le contexte de transformation de nos entreprises actuelles.

Dans cet article, nous allons essayer de revenir sur les origine de la construction de ce nouveau rôle afin de mieux le cerner.

[#t-matiere-1]Product Builder : une continuité de l'histoire de l'informatique ?[#t-matiere-1]

Dans cette partie, nous allons essayer de revenir de manière "historique" sur l'émergence du Product Builder.

[#t-matiere-2]Aller vers toujours plus de simplification informatique[#t-matiere-2]

Pour bien comprendre les origines du Product Builder, il faut remonter rapidement aux débuts de l'nformatique.

A l'origine, pour communiquer avec la machine (l'ordinateur), les développeurs.ses ont inventés des langages de programmation pour simplifier l'interaction entre les machines et les hommes. Du Fortran, en passant par le C, le Java et aujourd'hui le React JS pour ne citer qu'eux, il fallait avoir des connaissances en développement informatique. Si vous saviez écrire du code, vous aviez un "super pouvoir" et la possibilité de construire des Produits que peu de personnes dans le monde étaient capables de créer.

Cependant, il faut savoir que le nombre de développeurs.ses a considérablement augmenté également avec la volonté de simplifier les langages informatiques afin de les rendre plus maléables et permissifs. Demandez à un développeur C++ ce qu'il pense du langage Javascript, en règle générale il va probablement vous dire que ce langage est bien plus facile à maîtriser car des éléments ont été largement simplifiés. On ne rentrera pas trop dans les détails, mais sachez simplement que les langages informatiques cherchent à se simplifier de plus en plus tout en proposant de plus en plus de liberté dans l'écriture du code. Ce qui est d'ailleurs un point très attendu par le marché qui a besoin de plus en plus de développeurs.ses pour répondre à la demande croissante d'applications.

Si cela a permis une véritable augmentation du nombre de développeurs.ses dans les 10 dernières années, force est de constater que le milieu du développement reste arride et que créer une application de A à Z reste un travail encore complexe malgré de véritables efforts de simplification.

D'autres développeurs ont donc imaginé pouvoir "coder visuellement" des applications pour simplifier encore plus le process de création. Et cela ne date pas d'hier. De nombreuses entreprises se sont engouffrées dans le domaine, mais ce n'est véritablement que depuis 2019 qu'on voit une véritable accélaration de ce type de constructeurs visuels d'applications.

On pourrait avancer plusieurs explications pour parler de l'émergence de ce phénomène dit "no code" : l'instauration du Cloud, les développement des API, une véritable amélioration des Graphical User Interfaces (GUI), le manque de développeurs.ses, le développement de l'entrepreneuriat, le Covid-19...

Bref, ce qu'il faut surtout retenir, c'est que l'histoire de l'informatique suit depuis toujours le même chemin : la simplication. Simplification à la fois pour les développeurs ainsi que pour les utilisateurs. Il était donc naturel que les outils no code arrivent un jour à percer sur le marché et deviennent des outils indispensables pour l'entreprises qui seraient pris en main par des métiers qu'on n'attendait pas auparavant.

[#t-matiere-3]Un rôle Product arrivé à maturité[#t-matiere-3]

A côté du monde du développement, un autre métier spécifique au digital s'est également développé. Il s'agit d'une personne en charge du Product. Avec différents types d'acceptions, parfois Product Manager, Designer, Owner, Ops... ce profil a toujours le même objectif : faire en sorte que le produit développé corresponde exactement aux besoins des utilisateurs et que le développement du produit se fasse de manière agile. Le Product a donc notamment pour objectif, grâce à ses utilisateurs, d'itérer constamment sur son produit pour faire en sorte qu'il soit adopté.

Un(e) développeur(se) ne peut pas faire ce travail. Et ce n’est d'ailleurs pas son rôle. En tant que développeur(se), vous devez écrire le code, tester, débugger, ajouter de nouvelles fonctionnalités... Tous ces éléments très complexes à réaliser vous éloigne forcément de l'utilisateur. Il faut donc une personne en charge de recueillir les attentes, besoins et retours utilisateurs pour collaborer avec le/la développeur(se). Cette personne, c'est celle qui est en charge du "Product".

Depuis maintenant une bonne quinzaine d'années, le rôle Product (Manager et Designer) est en passe de devenir un standard pour les nouvelles entreprises du web. Et avec cela, c'est toute une théorie passionnante sur ces nouveaux métier qui s'est créée avec des concepts propres à cette profession. Profession dont le rôle, on le rappelle, est de faire matcher les besoins business et les besoins utilisateurs avec le produit effectivement créé.

Toutefois, force est ici de constater que dans ces rôles de Product Manager et de Designer, on retrouve souvent des profil hybrides capables de passer du business, à la maquette, à l'interview utilisateur... et qui ont souvent un point commun : ils/elles sont pragmatiques et problem solvers. Et bien souvent, on retrouve une véritable volonté de créer de la part des ces profils Products. Et cela tombe bien, l'avènement du no code est en train de leur apporter ce qu'il leur manquait justement !

[#t-matiere-4]De nouveaux outils = un nouveau métier celui de Product Builder[#t-matiere-4]

[#t-matiere-5]Une conjonction de facteurs qui rend le Product builder indispensable sur le marché[#t-matiere-5]

Plusieurs facteurs peuvent expliquer que le rôle du Product Builder arrive progressivement sur le marché.

Tout d'abord, la pénurité de développeurs sur le marché conjugué avec l'arrivée à maturité des outils no code. C’est un facteur indéniable de l'intérêt pour les outils no code. D'un côté, on a une demande en création d'applications de plus plus forte et de l'autre on manque clairement de développeurs(ses) chevronné(e)s pour les réaliser. Il était donc intéressant de se tourner vers des outils plus simples et rapide à prendre en main capables de fournir des applications de qualité.

Ensuite, le développement très important des API est un vecteur d'accélération des outils no code. Sans API, chaque applications devrait refaire à chaque fois des fonctionnalités tels que le paiement, le stockage... L'intérêt c'est que la plupart des services actuels proposent des API qui permettent de se connecter facilement à plein de services. Et la force des outils no code c'est de prendre ces briques et de pouvoir les agencer ensemble pour créer de nouveaux services. Zapier et Integromat sont probablement les services les plus connus dans l'utilisation des API, mais il s'avère qu'un grand nombre d'outils no code comme Bubble par exemple vous permettent d'utiliser les API pour augmenter leur outil. Au lieu de recoder chaque fonctionnalité, "il suffit" de les assembler ensemble pour créer de nouveaux services. Chez Uncode School, on pense que l'assemblage de manière strcuturée de ces nouveaux blocs entre eux sera un des rôles dévolu aux Product Builders. Grâce aux API, le Product Builder pourra donc répondre sans l'aide d'un développeur à la construction de projets informatique. Et ça c'est un gros changement de paradigme !

Enfin, le dernier facteur qui nous semble important à souligner pour démontrer la montée la puissance du Product Builder, c’est probablement le rôle que joue l'entrepreneuriat dans notre société. Force est de constater que l'entrepreneuriat à le vent en poupe et que de nouveaux projets se créent chaque jour. L'arrivée des outils no code est donc en ce sens une véritable aubaine pour ces nouveaux entrepreneurs qui voient donc la barrière technique à l'entrée se réduire. Au lieu de devoir recruter un CTO dans un premier temps, ces nouveaux entrepreneurs choisissent la voie de réaliser aux mêmes leur projets. En ce sens, ils/elles sont également Product Builders.

Ainsi, la conjonction de ces 3 facteurs (d'ailleurs non exhaustifs) rendent, selon nous, le marché apte à s'emparer de ce concept de Product Builder pour accélérer la transformation digitale des entreprises.

[#t-matiere-6]Le Product Builder, clé de voûte de la transformation digitale actuelle ?[#t-matiere-6]

Pour terminer donc cet article, on posera donc la question suivante : avec l'avènement des outils no code, le Product Builder sera t-il la clé de voûte de la transformation digitale des entreprises ?

Le terme clé de voûte serait probalement trop fort. Dans une entreprise, la clé de voûte, c’est l'équipe toute entière. Toutefois, chez Uncode School, nous pensons que le Product Builder deviendra un chaînon indispensable de l'entreprise et qu'il va permettre d'accélérer la transformation digitale des entreprises.

Pour nous, le Product Builder va accélerer cette transformation digitale des entreprises de 2 manières :

  • En mettant en place des outils internes dans l'entreprise pour la rendre plus productive et plus efficace. C'est notamment le sujet de l'automatisation.
  • En créant de nouveaux services pour les utilisateurs. Le Product Builder va ici utiliser les outils no code et les méthodologies Product pour créer de A à Z (ou en collaboration avec des développeurs(ses)) des produits dont les utilisateurs ont vraiment besoin. Mais de manière plus rapide que ce qui se passe actuellement sur des développements plus longs.

Avec l'avènement des outils no code, il faut bien se rendre à l'évidence que le marché de l'informatique est donc en train de se structurer en prenant en compte ce changement. Toutefois, on attire votre attention sur le fait que même si il est certes plus simple de créer de nouveaux services via des outils no code et API, il faut bien se rendre à l'évidence que le monde de l'informatique n'a pas changé dans sa conception. Les concepts informatiques restent les mêmes (frontend, backend, API...). Ils sont juste plus simplifiés et abstraits. Chez Uncode School, nous en sommes convaincus : cette simplification de l'informatique ne veut pas dire simplicité ! Il est plus que nécessaire pour le Product Builder de se former et de maîtriser les bons concepts informatiques pour créer une application qui a du sens pour les utilisateurs et qui est capable de durer.

En conclusion

Nous en sommes convaincus, historiquement, le rôle du Product builder est une suite logique des attentes du marché de l'informatique.Son rôle hybride n'a pas pour projet d'effacer les autres rôles, mais plutôt de les compléter. Même plébiscité par le marché et les entreprises, l'histoire du Product Builder est encore naissante et la suite de son rôle au sein des entreprises reste encore à écrire.

Vous venez l'écrire avec nous ?

Prêt à embarquer ?

Démarre l'aventure Uncode School et apprend à créer les produits que tes utilisateurs attendent.