« C’est officiel, Prello lève 13M ! Et un des secrets de cette réussite tient en 2 mots : Low & code. » Le 3 février dernier, Nicolas Szczepaniak, head of product de la startup qui facilite l’achat de résidence secondaire en copropriété, révélait sur Linkedin ses coulisses techniques. Creusons le sujet no-code et product management avec lui.
| Retrouve tous nos articles sur le No-code dans le produit ici. |
Salut Nicolas. Alors avant de parler de votre fonctionnement chez Prello, est-ce que tu peux rappeler comment tu es tombé dans la marmite du no-code à titre perso ?
Nicolas Szczepaniak : A l’origine, je viens du design industriel. Et c’est en foirant un projet entrepreneurial que je découvre le no-code.
Un mal pour un bien au final puisque c’est ce qui me permet de découvrir Bubble, une solution pour bâtir des web apps sans coder, et de me réinventer professionnellement, en intégrant l’agence Tinkso, une référence dans le no-code. C’est comme ça que j’apprends le métier de Product Manager no-code.
« Il ne fallait pas que la tech soit une entrave à notre approche utilisateur. Le focus doit rester sur le métier. Uniquement le métier. »
Et comment arrives-tu chez Prello ?
N.S. : C’est l’histoire classique de la rencontre à la salle de sport ! On fréquente la même avec Ludo [NDLR : le CEO et cofondateur de Prello] et on commence à discuter, dès fin 2018, de sujets no-code.
Lui a ce projet en tête d’achat à plusieurs de résidence secondaire, un concept qui se développe rapidement aux Etats-Unis. Et il a cette grosse intuition qui se transforme vite en conviction forte de vouloir le lancer en no-code. Comme je bossais dans le domaine, on a convergé rapidement et Prello est né en septembre 2021.
Question bête mais pourquoi avoir voulu se lancer absolument en no-code ?
N.S. : Pour la vélocité ! On est sur un nouveau domaine dans lequel il y a un vrai momentum. La question du timing est primordiale, ça se joue quasi à la semaine.
Avoir un produit fonctionnel rapidement nous a d’ailleurs clairement aidés dans la levée de fonds que l’on vient de conclure [NDLR : Prello vient de lever 13 M€ début février… soit 6 mois seulement après sa création !] Preuve que les mentalités changent sur le sujet : les investisseurs perçoivent la valeur du no-code et constatent que les barrières sont progressivement repoussées.
Quand je parle de vélocité, je précise : cela sous-entend des itérations rapides pour nous concentrer sur la satisfaction client. Autrement dit, il ne fallait pas que la tech soit une entrave à notre approche utilisateur. Le focus doit rester sur le métier. Uniquement le métier. Et non sur la complexité technique. Cette simplification permet ainsi de revenir à la question de base du produit : à quoi doit servir ce que l’on est en train de faire pour l’utilisateur ? Peu importe si c’est fait en code ou no-code.
Tu indiques dans une publication Linkedin que votre vision, c’est de grandir avec le low-code sur le long terme… au-delà du MVP. Vous n’envisagez donc pas de passer à l’échelle avec une version en code traditionnelle ?
N.S. : L’objectif, c’est en effet de rester sur une solution low-code pérenne. Ce qui ne veut pas dire que ça ne coexistera pas avec une partie en code pur non plus. On sait en effet qu’on devra passer avec des briques de code malgré tout. Mais cet horizon s’éloigne au fur et à mesure que l’on avance et que l’on découvre de nouvelles possibilités !
Par exemple, l’enjeu que l’on voit actuellement concerne le volume de données que l’on sera en capacité de gérer si la croissance se poursuit ces prochaines années. On a encore de la marge, mais on y va un peu avec la machette dans la jungle. Même si, d’ici là, les outils auront vraisemblablement beaucoup évolué.
Il y a aussi la question du mobile natif ou de l’algorithmie, pour pousser la logique un peu plus loin sur ces domaines. On mène actuellement un benchmark pour voir ce qui existe sur le marché. Mais je me répète : l’idée n’est pas de remplacer tout l’écosystème technique, juste d’ajouter des briques de code.
On imagine que vous avez tout de même vérifié au préalable que votre projet était compatible avec une dimension no-code, non ?
N.S. : Tout à fait. Autant si on avait voulu créer un équivalent de Binance dans la crypto, on ne l’aurait pas fait en no-code. Mais là, on savait que Prello était un projet low-code friendly.
C’est-à-dire ?
N.S. : On a déjà regardé les volumes de données et les volumes de workflow nécessaires en simultané : en quoi cela allait tirer sur les serveurs ? Ensuite, on a vérifié qu’on allait bien pouvoir faire les fonctionnalités requises. Et on a vu qu’il y avait des solutions, donc, go !
Une précision : on est sur une base no-code mais on a toujours une couche low-code pour pouvoir aller plus loin. En gros, le no-code, c’est le diamant brut et le low-code, c’est la façon de le polir.
Aussi, on a adopté une approche en microservices. Ce qui nous permet d’y aller avec plus d’assurance : on sait qu’on peut remplacer des briques sans tout avoir à refaire.
Mais aussi parce que les outils no-code ne sont pas faits pour bosser à beaucoup dessus. Donc, pour que ça scale, on a compris qu’il fallait découper en spécialités sur des apps différentes. Du coup, chaque outil a un rôle bien spécifique.
Ça donne quoi concrètement ?
N.S. : On utilise Webflow pour le site et le CMS et Bubble pour la gestion des micro apps et des outils tiers qui gravitent autour. Type Pipedrive pour le CRM ou Calendly. Bubble est très permissif pour tout interconnecter.
Ainsi, on commence progressivement à avoir une logique de backend décentralisé. On était sur AWS au début mais ce n’était pas super concluant, car on voulait que cela soit pris en charge par notre équipe de product building, et non une équipe tech dédiée. Donc on a décidé de pousser le vice et d’assumer nos convictions jusqu’au bout en prenant Xano. Et on reste toujours ouvert sur les nouveaux outils qui arrivent.
Parlons produit un peu. Comment êtes-vous organisé ?
N.S. : Prello, déjà, c’est une trentaine de personnes. L’équipe product building en comprend 10. On se considère tous et toutes comme des Product Builders. Tout le monde est polyvalent, a cette appétence no-code et est réuni sous la même bannière. Mais il y a toujours des spécialistes produit, design et dev.
Autrement dit, on fonctionne en sprint d’une semaine et chacune de nos squads est composée de 3 personnes, une de chaque spécialité.
La triforce classique en fait !
N.S. : Oui, les rôles et les tâches ne sont pas très différents de ce qui existe ailleurs. Sauf que le low-code est un langage commun entre designer, PM et dev. Il permet à chacun de pouvoir modifier des composantes sans lourdeur inutile. Dans les sprints, on capitalise d’abord sur les forces design et dev et on ajuste en fonction, en attribuant quelques points aux PM.
Par exemple, pas besoin de faire un ticket pour ajouter une section au produit : le PM peut directement mettre les mains dans le cambouis. Il passe donc moins de temps à faire des specs. Cela lui permet aussi de mieux comprendre les enjeux techniques. Autre avantage : cela reconnecte les dev aux sujets métier.
Cela peut sembler paradoxal mais c’est très précieux d’avoir des développeurs dans un environnement low-code ! Chez nous, il y en a un qui a par exemple 15 ans d’expérience et c’est un crack en low-code. Il apporte une vision sur l’implémentation du workflow qu’un autre spécialiste métier ne pourrait pas avoir.
Est-ce que les PM ont le temps de faire de la discovery, s’ils passent un peu de leur temps à “no coder” ?
N.S. : Oui, c’est important. On parle toujours du duel delivery / discovery. Ma vision, c’est que, justement, la vélocité permise grâce au no-code permet de résoudre ce problème.
D’une part, la grosse vitesse d’exécution en delivery, couplée à une bonne logique data, permet d’avoir des réponses produit plus fiables que des retours utilisateurs en amont. La donnée va parler.
Par contre, quand il y a besoin de défricher certaines idées ou de travailler sur des fonctionnalités à forte valeur ajoutée, là, on peut prendre d’autant plus de temps en discovery que l’on sait que ça ira vite ensuite en delivery. La discovery devient ainsi ultra qualitative.
Pour finir, c’est quoi ta vision sur l’évolution du métier de PM en lien avec cet essor du no-code ?
N.S. : Je pense que, pour la plupart, le no code sera une corde à leur arc supplémentaire. Ou, du moins, une piste d’exploration à prendre en compte pour comprendre de nouvelles logiques car, en soi, les PM font partie du public cible du no-code.
Et pour certains, en fonction des projets et des boîtes, cela peut même déboucher sur une vraie transition professionnelle. C’est-à-dire que cela peut apporter une variante du product management un peu différente, dans une nouvelle typologie d’équipe qui comporte moins de silos entre les rôles.
Si tu veux aller plus loin sur le sujet :
| Retrouve tous nos articles sur le No-code dans le produit ici. |
