Bienvenue sur le podcast Artisan Developer, l'émission pour les programmeurs qui veulent vivre une carrière épanouissante.
Prêt à passer au niveau supérieur ? C'est parti !
Aujourd'hui je suis avec Guven Urganzi, Guven bonjour.
Bonjour.
Est-ce que tu peux te présenter en une minute pour ceux qui ne te connaissent pas ?
Tout à fait, donc je m'appelle Guven, je suis co-fondateur de noscrm.io,
c'est un logiciel d'aide à la conspection commerciale, c'est un anti-crm,
notre site internet c'est youlantny.com, vous n'avez pas besoin d'un CRM.
Et donc je suis, j'ai un profil un peu hybride entre le développeur, chef de produits,
et NoCRM c'est une entreprise de 17 personnes qui exigent depuis 6 ans,
en tout cas, produits exigent depuis 6 ans et aujourd'hui on fait 2 millions d'arrières
avec des clients partout dans le monde.
Et ce que je trouvais super sympa c'est que tu me disais,
toi ce qui t'intéressais, à la fois tu as les mains dans le code,
j'ai bien compris, en tout cas tu l'as eu, je sais pas où est-ce que tu en es aujourd'hui,
c'est pas fort ta formation initiale, mais par la force des choses et le temps,
tu as appris à mettre les mains dedans.
C'est ça, j'ai une formation d'infographiste web designer avec un peu de web development,
et donc mon profil à la base il est plus fontaine de web design, UX, etc.
Mais j'ai toujours été intéressé par le développement
et on fait du Ruby on Rails depuis 2008,
et j'ai été séduit par la philosophie du framework
et j'ai toujours été intéressé d'implementer mes propres idées aussi dans l'application,
et donc de filer en aiguille, je me suis formé sur le sujet,
et aujourd'hui j'ai un profil un peu full stack, on va dire.
Donc je code toujours.
Oui, sur une semaine tu codes combien de temps à peu près ?
Ça va varier, il y a des semaines où je vais peut-être coder vraiment 2 jours sur 5,
et il y a des semaines où ce sera 5 jours sur 5.
Ah oui, tu es encore vraiment bien les mains dans le code, ok, c'est cool.
Et ce que je trouvais cool dans l'échange qu'on a vu,
tu me disais, le code ça me plaît, mais c'est pas une fin en soi,
ce qui me plaît c'est avant tout de développer un produit,
et je trouve ça super intéressant parce que quand on est passionné,
notamment par le dev, par le code,
c'est un truc que je trouve qu'on a un peu tendance à oublier, les développeurs,
et parfois on est arrivé à se faire des petites cajoleries sur le dernier framework,
ou sur une stack, ou sur un truc,
et j'ai piqué cette phrase, je crois que c'était à Jean-Pierre Lambert qui disait,
on n'est pas là pour écrire du code, c'est un peu provocateur,
mais je pense que ça va te parler à toi, question pense.
Non absolument, on développe un produit,
on le vend des clients, les clients ils nous payent et ça paye nos salaires,
on n'est pas là donc pour écrire du code, on est là pour développer un produit.
C'est un peu différent.
Alors évidemment, écrire le code c'est hyper important parce que c'est ça qui nourrit le produit,
écrire du code, du beau code, maintainable,
c'est ce qui va permettre au produit d'être facilement maintainable
et de le faire évoluer plus facilement, donc c'est de l'investissement aussi.
Mais il ne faut pas oublier, c'est ça qu'on vend un produit,
et ce code qu'on écrit, l'utilisateur ne le voit pas.
Je le dis souvent ça, ça peut être un peu,
il y a des développeurs qui vont un peu s'arracher les cheveux en entendant ça,
mais c'est vrai que le code, l'utilisateur ne le voit pas.
Disons que quand l'utilisateur commence à avoir du code, c'est pas bon.
Non c'est ça, c'est bon.
Moi, est-ce que tu fabriques un éditeur mais sinon...
Non tout à fait.
Donc il ne faut pas m'éprendre, j'accorde beaucoup d'attention aux choses bien écrite,
on fait des codes review et on écrit des tests,
et on refactorise du code, etc.
Mais j'estime et j'aime qu'on puisse de temps en temps se donner un peu de flexibilité et dire voilà,
ça on sait que c'est moche, c'est pas bien fait,
mais on en a besoin maintenant et on se donnera le temps de l'écrire mieux,
peut-être juste après l'avoir mis en prod, ou deux semaines après.
Ouais, moi sur ça je suis assez souple aussi,
un poids y est dans les valeurs de l'artisanalogiciel, y a le pragmatisme.
Je pense que ça fait clairement partie du pragmatisme d'être capable à un moment donné
de prendre un court-circuit et d'aller droit au but.
Moi, je t'avoue que j'ai plutôt le retour.
En fait, le truc c'est que, moi personnellement, quand je ne vois plus trop le...
Pour moi, c'est devenu tellement plus simple de le faire en gardant mes pratiques
que je ne gagne pas forcément de temps à essayer de court-circuit et quoi que ce soit.
Mais par contre, je comprends tout à fait qu'à un moment donné,
y a un truc qui puisse être fait un peu bancal, un peu vite.
Mais moi, ça ne me pose pas de souci intrinsèquement,
parce que si ton produit est là, c'est ce qui permettra demain de nourrir tout le monde, de grandir.
Ce qui pourrait être un problème, si tu commences à accumuler de la dette.
Ça, ça devient un problème assez vite.
Mais du coup, comment tu fais toi pour garder ce cap-là ?
Parce que je me disais que vous aviez une équipe de cinq ou six développeurs.
Comment vous faites pour que les devres restent alignés sur cette philosophie ?
Comment tu t'assures, Clé, de partager cette philosophie avec ton équipe ?
C'est du rappel quotidien.
Si bien, c'est qu'il y ait une espèce de balance entre les développeurs qui veulent écrire des tests,
passer du temps pour sortir le code propre et pas nécessairement rocher vers une mise en ligne rapide.
Il y a cette balance entre... et aussi de mon côté, où je vais justement arriver à tirer un peu de la productivité,
si on veut, à faire en sorte que les développeurs vont essayer de prendre du recul
et accepter de ne pas toujours aller au bout des choses et à, comme tu dis, à être un peu flexible,
et à se permettre de chier du code, de capacité 100% testée, qui n'est pas écrit de la meilleure façon du premier coup.
Et du coup, comment tu t'y prends pour développer ton produit ?
C'est quoi les grands trucs ? Comment tu pilotes ça d'une manière plus globale ?
Parce qu'on a dit qu'il n'y avait pas que du code, c'est quoi les grands axes et les paradigmes que tu utilises pour piloter ça ?
Quand on développe des fonctionnalités dans l'outil, on essaye de garder en tête une enrègle
qu'on a lu dans un article d'un investisseur qui disait des choses très intéressantes là-dessus,
sur les différenciateurs de ton produit.
C'est-à-dire que quand on développe des fonctionnalités, on va avoir du retour du feedback utilisateur,
on va avoir sa propre vision, etc. et on va développer des sectes de fonctionnalités.
Des fois, on oublie de développer ou d'améliorer ou de renforcer ce qui te différencie.
Les différenciateurs, en fait, il y a deux, trois types de fonctionnalités.
Bon, évidemment, si tu développes un produit, admettons un CRM,
tu vas avoir besoin de gérer des contacts et de mettre des rappels et de mettre des montants sur les opportunités, etc.
Donc ça, c'est vraiment la base du produit, ce qui est requis, le minimum requis en termes de fonctionnalités.
Ensuite, tu vas avoir des neutralisateurs, donc ce sont des fonctionnalités qui ont la concurrence
et que tu n'as pas et qui vont devoir que tu vas développer pour neutraliser la concurrence.
Et il y a une troisième catégorie de fonctionnalités qui est très importante, qui sont les différenciateurs.
Pourquoi ton outil est meilleur qu'un d'autres ?
Et en fait, il ne faut pas oublier de développer ces différenciateurs aussi
pour justement se démarquer de la concurrence et continuer à aussi faire vivre la promesse
et la promesse que tu délivres avec ton outil.
Pourquoi il est différenciant ? Pourquoi il va aider ton client et pas le produit concurrent 1 ou 2 ?
Et en quoi c'est un challenge de développer ces produits et des features différenciantes ?
C'est un challenge parce qu'on a tout un pipe de demande qu'il faut arriver à trier
et on est souvent tenté de répondre oui à un client parce qu'il nous paye, il a une idée intéressante
mais si on ne filtre pas et si on ne fait pas un tri et qu'on n'essaye pas d'avoir une équilibre entre ces 3 types de fonctionnalités
on se rend compte à la fin qu'on développe juste le même produit que la concurrence, que tous les autres produits sont sur le marché
et c'est comme l'appel des techniques on va payer plus tard le fait qu'on ressemble à tous les autres CRM
ou à tous les autres outils de gestion de projet etc.
Et c'est pour ça que c'est très important de garder un peu de recul et d'essayer de balancer un peu ces types de fonctionnalités.
En gros ce que tu dis, je comprends bien c'est que la demande des utilisateurs vous pousse vers les attentes globales
et ce n'est pas forcément l'utilisateur qui va tâmer à travailler ta différenciation
tu as un exemple de fonctionnalité que tu as développé récemment qui était justement là pour marquer votre différenciation ou la développer.
Pas nécessairement un exemple vraiment concret de fonctionnalité mais notre promesse c'est de dire au commerciau
vous n'oublierais plus jamais la prochaine action que vous avez à faire sur l'opportunité, notre ligne c'est ça.
On ajoute des fonctionnalités, notre produit est devenu vraiment très complet on va dire
et constamment il faut qu'on fasse un on-boarding c'est-à-dire qu'on recrée un compte sur notre produit
et on essaie de prendre de recul 5 minutes et de dire je fais un nouveau l'utilisateur
est-ce que je perçois toujours la promesse de cette simplicité d'avoir une opportunité, un rappel sur la prochaine action.
Et ajouter des fonctionnalités, on connaît le produit depuis 4, 5, 6 ans
on a l'impression qu'il est simple mais il faut toujours arriver à se remettre dans l'appaule d'un utilisateur
qui va arriver pour la première fois sur le produit et qui va ne plus percevoir la promesse de cette simplicité
parce qu'il ne connaît pas, il n'a pas l'historique du produit etc. c'est son premier contact avec.
Je trouve ça super dur à faire parce que surtout quand tu l'as fabriqué, quand tu l'as conçu et fabriqué
ça te paraît évident mais il suffit de me... moi des fois je tombe sur des interfaces utilisateurs
je me dis mais c'est pas possible, à quoi ils ont pensé les gars quand ils ont fabriqué ce truc là
ben ils sont tombés dans le même travers et je suis sûr que dans ce que je fais je suis sûr de l'avoir fait plein de fois
et on y travaille mais c'est un vrai challenge de regarder avec un regard neuf d'utilisateur.
J'ai un exemple intéressant c'est en 2017 on a sorti une V2 c'est une refonte complète de notre interface
parce que le produit avait pas mal évolué justement on se perdait un petit peu
on a voulu le recentrer un peu le produit, on a amené des nouvelles techno etc. pour avoir un produit plus rapide, plus optimisé
et on a sorti notre V2 et tous nos clients étaient mes ravis
par contre quelques semaines et mois après on se rendait compte qu'on avait une acquisition de merde simplement
parce qu'on avait oublié simplement de penser aux utilisateurs de nouveaux entrants
qui ne connaissaient pas le produit avant cette V2 donc on a eu des retours très positifs par rapport de nos clients
mais on avait complètement oublié cette phase de compréhension de l'application
donc toute la phase de boarding j'arrive à quoi sert l'outil, comment je m'en sert et comment j'effectue mes premiers pas dessus.
Super intéressant je te propose que ce soit le mot de la fin, Gwen, si les utilisateurs, les auditeurs veulent en savoir plus
sur udontenis2srm.com
où ils peuvent essayer notre opti gratuitement tout simplement
Merci Gwen
Merci à toi
Quant à toi cher auditeurs j'espère que tu as apprécié ce podcast, si c'est le cas je t'invite à le partager
le partager avec un groupe de copains, tu peux peut-être le partager sous forme d'écoute mutualisée
je pense que le thème s'y prête assez bien, tu prends ton équipe de développeurs, de produits, de potes
et vous regardez ce qu'ils, vous les coutez ensemble et vous en débriefez autour
d'un café, d'un thé, d'un petit truc à manger
si d'ici ce que ce podcast sorte, on est déconfiné et qu'on a le droit de se retrouver physiquement
Voilà je te souhaite une bonne journée, je te remercie, je te dis à bientôt