Prello, c’est la startup qui facilite l’achat de résidence secondaire en copropriété bâtie quasi entièrement sur des solutions no-code. Influence sur l’orga produit, rôle du Product Builder, avenir de la profession… On fait le point sur le sujet avec deux de ses PM, Johanna Prevost et Théo Rouland, des anciens de Payfit et Solocal.
| Retrouve tous nos articles sur le No-code dans le produit ici. |
Salut Johanna et Théo. Pour commencer, pouvez-vous nous raconter comment vous en êtes venus au no-code ?
Johanna Prevost : Personnellement, j’ai fait une école d’ingé en informatique et, en sortant, je ne savais pas s’il fallait que je m’oriente vers un poste de PM ou de software engineer… donc je postulais aux deux !
Puis PayFit m’a contactée et j’ai été embauché en tant que Product Builder, en septembre 2019. C’était le rôle parfait puisque tu gères tout de A à Z, du product management à l’UX design en passant par le dev, avec le langage propre à PayFit, le JetLang. Tu es un peu une triforce toute seule !
Théo Rouland : Pour ma part, je me considère un peu comme un profil couteau suisse. J’ai fait une école de commerce mais je m’intéresse rapidement à la tech et je participe au bootcamp en développement Web Le Wagon.
Je travaille ensuite chez Solocal. Au début en tant que product manager et data analyst, puis je me retrouve au lancement d’une nouvelle verticale qui s’appelle lebongaragiste.fr, que je développe avec l’outil low-code Bubble. C’est comme ça que je commence dans cet univers. A ma connaissance, il s’agit d’ailleurs de la première tentative de Solocal en no-code orientée produit externe. Et depuis, ils ont décidé de lancer certains de leurs produits en no-code.
« En tant que Product Builder, c’est l’enfer pour se projeter si tu veux rester dans cette voie, car c’est un métier qui n’existe pas vraiment encore »
Comment êtes-vous organisé au produit chez Prello ?
Johanna Prevost : Je suis arrivée il y a une semaine donc je vais laisser Théo répondre ! (rires)
Théo Rouland : Nous sommes 10 personnes réparties dans 3 unités business : grosso modo le site, le calendrier dynamique pour que les utilisateurs réservent leurs semaines de vacances et l’app interne pour alimenter le contenu. Et pour chaque unité, il y a 3 personnes : une spécialiste produit, une qui s’occupe du design et de l’intégration et une au dev’ qui gère la logique backend.
En soi, on n’est donc pas vraiment des Product Builders. Les PM ne sont pas censés consacrer la majeure partie de leur temps à mettre les mains dans les outils no-code. Même s’ils les connaissent et sont en mesure d’estimer précisément combien de temps prendra un projet. Voire d’aider ponctuellement.
On utilise principalement les outils Webflow et Bubble et, pour donner une idée, on a environ 80 % de no-code et 20 % de code.
Et toi Théo, tu crois à cet objectif de garder Prello en low-code à long terme, comme le dit ton head of product ?
Théo Rouland : Complètement ! Souvent, on cite l’exemple de Comet qui a fait son premier produit en no-code avant de basculer, plus tard, vers une architecture en code pur. Cela dépend évidemment des enjeux des boîtes mais, entre-temps, Bubble a évolué à la vitesse de la lumière.
Aujourd’hui, leur techno est très solide et ils sont en train d’améliorer leur vitesse de chargement, qui est actuellement leur défaut principal. Donc d’un point de vue technologique, c’est sûr qu’on n’aura jamais plus besoin de repasser sur du full code.
Par contre, pour scaler, il faut en effet une architecture en microservices, reliée par des API. Et recruter des anciens dev’ ! Ils apportent des connaissances que souvent les gens qui font du no-code ne maîtrisent pas. Et c’est pour cela qu’ils atteignent des plafonds.
« Franchement, étant donné les performances des technos aujourd’hui, il est de moins en moins pertinent de partir sur du code pour un projet. »
Quel est votre avis sur ce nouveau rôle de Product Builder qui, comme tu le disais Johanna, mêle un peu les trois casquettes, produit, dev et design. N’est-ce pas le risque de tout faire moyennement ?
Johanna Prevost : Je pense que cela marche essentiellement sur un scope restreint. Au début, il faut construire une base solide donc il est nécessaire, dans la mesure des moyens disponibles, d’avoir une triforce avec des expertises spécifiques.
Mais quand tu atteins un certain stade, tu peux découper ton scope en plus petites sous-parties et en confier la responsabilité à une seule personne, avec ce rôle de Product Builder. Le grand avantage, c’est que cette dernière peut itérer super vite. En effet, elle passe moins de temps sur la formalisation et le transfert de connaissances, ce qui représente un gain en efficacité considérable.
Théo Rouland : C’est vrai que cela te permet de squizzer beaucoup de tâches en termes de planification et de rédaction de specs, comme tu as tout dans ta tête. Et je suis d’accord, ce n’est pas gérable quand le scope est trop grand.
Johanna Prevost : J’ajouterais que ce métier de Product Builder s’applique bien quand tu as une dimension métier complexe. Ce qui était typiquement le cas chez PayFit, d’où la création dès l’origine du JetLang. Il fallait pouvoir s’adapter très rapidement aux fréquentes mises à jour légales et conventionnelles (c’était particulièrement le cas avec l’activité partielle et les absences COVID, des décrets sortaient presque tous les 2 mois et s’appliquaient de manière rétroactive). Et donc disposer de profils capables de comprendre des règles métiers puis rapidement les traduire fonctionnellement, sans la contrainte de la syntaxe d’un langage classique.
Théo Rouland : Par contre, le désavantage à être tout seul, c’est qu’il n’y a personne pour te contredire ou t’apporter de nouvelles idées.
Johanna Prevost : C’est vrai. Chez PayFit justement, afin de briser cet isolement, on faisait challenger nos plans de dev’ par d’autres personnes et on avait une design review avec plusieurs Product Builders durant laquelle on montrait ce que l’on avait fait. Ce qui permettait également d’assurer une cohérence globale au produit, pour ne pas que chacun fasse ce qu’il veut dans son coin.
D’ailleurs Johanna, tu cherchais spécifiquement un poste dans une boîte qui faisait du low-code, après ton expérience de Product Builder chez PayFit ?
Johanna Prevost : Je dirais que c’est un heureux hasard. Je cherchais en effet à rester dans le low-code mais je n’étais pas dupe : il n’y a pas beaucoup d’offres sur le marché. Donc je m’ouvrais à un poste de PM.
Et un jour, Nicolas, le head of product de Prello, m’ajoute sur Linkedin. Je regarde ce que fait la boîte, découvre qu’elle est basée sur du low-code… et j’écris à Nicolas pour savoir s’il cherche du monde. Et me voici !
Théo Rouland : C’est vrai que c’est vraiment encore très difficile de trouver des gens dans ce domaine. Par exemple, il est quasiment impossible de trouver des ingés développeurs sur Bubble qui veulent travailler en CDI ! Il faut prendre des freelances et les convaincre de rester ensuite…
Johanna Prevost : Oui, je confirme qu’en tant que Product Builder, c’est l’enfer pour se projeter si tu veux rester dans cette voie, car c’est un métier qui n’existe pas vraiment encore. C’était mon problème chez PayFit . Si je voulais bouger, je devais faire un choix : me recentrer sur le produit ou le design. Ou recommencer de zéro en apprenant un nouveau langage Web. Voire bosser dans des agences no-code.
Théo Rouland : J’avais le même questionnement chez Solocal : est-ce que je continue en tant que product builder en freelance ou je passe PM ? Bon, finalement, je n’ai pas trop eu le temps de me poser la question car le fondateur de Prello, Ludovic, qui est un ancien de Solocal, m’a contacté pour me proposer ce compromis idéal : être PM dans une boîte low-code.
Avec du recul, je dirais que je préfère malgré tout le métier de PM. Chez Solocal, j’avais un peu trop la tête dans le guidon. J’avais peu de temps pour penser stratégie et effectuer beaucoup d’analyses de données. Même si je faisais beaucoup de Discovery grâce à l’outil Testapic, qui me faisait gagner un temps fou. Là, chez Prello, c’est plus le cas. Je n’ai plus que 20% de mon temps consacré au no-code.
De ce que l’on comprend de votre orga chez Prello, le rôle de PM n’est pas très différent de celui que l’on voit traditionnellement dans l’écosystème ?
Théo Rouland : Effectivement, en termes de stratégie ou de discovery, cela ne change pas beaucoup. En delivery, on est sur des sprints d’une semaine pour coller à la rapidité du no-code. Et la petite distinction, c’est qu’on a parfois, en plus, quelques tâches de dev no-code. Hier par exemple, j’ai créé une fonctionnalité.
Comment se fait l’arbitrage dans le sprint planning entre ce que les ingés et les PM doivent développer ?
Théo Rouland : Cela dépend beaucoup des disponibilités du moment, de la complexité des fonctionnalités et des échéances à respecter. Mais en soi, on intervient plus pour lisser les pics d’activité. Les gros sujets de fond restent faits par les dev’.
On ne peut pas s’empêcher de finir par la grosse question tarte à la crème : c’est quoi les limites que vous voyez du no-code ?
Théo Rouland : On parle beaucoup du no-code pour faire des MVP. Mais institué au sein d’une équipe, c’est très peu connu et donc il n’y a quasiment aucune littérature sur le sujet. C’est un défi mais c’est aussi ce qui rend le job intéressant. On invente tous les jours des process que l’on renseigne dans une espèce de bible qu’on agrège sur Notion et qui nous permet in fine de faire scaler notre équipe et nos produits low-code.
Johanna Prevost : On entend souvent la question de la scalabilité aussi. L’exemple de PayFit montre justement que c’est possible d’adopter une approche low-code à l’échelle. Par contre, il y a le souci des performances : parfois on est obligé de faire des workarounds pas possible en low-code pour faire quelque chose qui pourrait être fait en 10 lignes de Javascript.
Théo Rouland : Franchement, étant donné les performances des technos aujourd’hui, il est de moins en moins pertinent de partir sur du code pour un projet. Sauf s’il y a des gros enjeux de sécurité, comme dans la santé. Ou liés au RGPD : Bubble n’a pour l’heure aucun serveur en Europe par exemple. Mis à part ça, les limites techniques ont bien été repoussées ces dernières années… et ça ne va aller qu’en s’améliorant.
Si tu veux aller plus loin sur le sujet :
| Retrouve tous nos articles sur le No-code dans le produit ici. |
