J’ai presque toujours eu un side project. Cela a commencé quand étudiant en électronique j’ai commencé à faire des sites web. Au départ c’était pour réaliser des idées qui n’ont jamais abouties à un véritable business mais ça m’a permis de découvrir le monde de la programmation web. En effet à part un projet universitaire qui consistait à créer un site web tous les cours que j’ai suivis en informatique étaient consacrés à des sujets moins concrets et plus théoriques comme la programmation système ou la théorie des langages. Ainsi j’ai commencé par apprendre les bases du web à savoir le trio HTML/CSS/Javascript puis le PHP avant de m’attaquer aux systèmes de gestion de contenu emblématiques de l’époque. C’était PHP Nuke dont le développement s’est arrêté a priori, Joomla et même Drupal vers la fin. Afin de mieux bénéficier de la puissance de ces outils j’ai continué à approfondir mes connaissances en PHP. Ce voyage m’a conduit à m’intéresser au framework MVC Zen Framework. Sans me rendre compte j’apprenais des choses qui me seront utiles dans ma carrière par la suite.
Ces compétences se sont d’abord avérées utiles lorsque je devais mon stage à l’issue de ma formation d’ingénieur. Bien que ce fut un stage en télécommunications il y avait une composante importante de modélisation et de code. Les intuitions et les muscles développés à faire mes side projects en PHP m’ont beaucoup aidé quand je devais implémenter des protocoles de communications mobiles en langage C.
Plus tard en début de carrière j’étais ingénieur R&D dans une startup télécom qui développait des outils logiciels. Là encore mes compétences acquises en faisant des side projects se sont avérés très utiles dans mon travail.
J’ai continué à parfaire mes connaissances en dévorant des bouquins et des articles de blog sur les langages de programmation divers, les bonnes pratiques, l’architecture, les frameworks… En parallèle je testais mes nouvelles connaissances dans des petits projets. Ainsi pour apprendre GWT j’ai développé une petite application qui transformait une recherche Youtube en playlist automatiquement et écrit un moteur de blog déployé sur Google App Engine pour me familiariser avec cette plateforme cloud… Un autre side projet qui a beaucoup contribué à structurer mes apprentissages fut mon blog technique. En effet j’y partageais ce que j’apprenais et cela me permettais de mettre les choses en perspective.
En 2011, après quatre années passées en startup, j’avais envie de changement, j’ai donc décidé d’intégrer une société de service. Là encore mes side projects ont joué un rôle important. Ayant été un terrain de jeu pour apprendre, explorer et expérimenter ils m’ont permis de décrocher un boulot cette fois-ci pour coder au quotidien. Ce n’était pas la fin de l’histoire car je continue, à ce jour, à avoir des side projects en programmation, un domaine en évolution constante où on est vite largué si on s’endort sur ces acquis.
Donc en tant que développeur j’ai pu avoir apprécié l’intérêt des side projects tout au long de ma carrière.
Qu’en est-il de mon rôle de product manager ?
En effet je suis product manager à plein temps depuis deux ans. C’est un métier extrêmement complexe qui demande des compétences dans de nombreux domaines comme l’ingénierie, l’expérience utilisateur, l’analyse de données, de la psychologie humaine etc.
Le product manager et l’équipe produit d’une manière générale disposent d’un ensemble d’outils pour faire un produit qui puisse satisfaire un besoin réel, apporter de la valeur à ses utilisateurs tout en étant rentable économiquement. En pratique cela reste extrêmement difficile à réaliser et se fait au prix d’aller-retours incessants entre hypothèses, expérimentations et prise en compte de retours du terrain (analyse de données comportementales, interviews des utilisateurs etc.).
La littérature est très riche de méthodes et de recettes pour « découvrir le bon produit », améliorer le taux de conversion ou la rétention mais quand on travaille sur un produit mature avec des enjeux business importants (money :-)) on n’a pas la main complètement libre pour expérimenter ces méthodes et recettes.
Ainsi comme le développeur ou le chercheur en laboratoire le Product Manager a besoin d’un side project, son jouet cassable (breakable toy) qu’il utilisera plus tester les techniques les plus folles en matière de product management son seul but étant d’expérimenter et d’apprendre sans les contraintes liées à un « vrai produit ». Les possibilités sont infinies ! Créer des habitudes chez les utilisateurs, optimiser la conversion d’une page, améliorer la retention…
Mais qu’est-ce qui change par rapport à mes sides projects de développeur ?
Plusieurs choses ! Livraison, livraison ! Oui livrer le produit, le mettre dans la main des utilisateurs. C’est la différence la plus importante. En effet le processus d’apprentissage ne commence que si les utilisateurs peuvent utiliser le produit. C’est à partir de ce moment là qu’on commence à récolter des feedbacks qui nourriront ensuite les évolutions futures du produit.
La deuxième différence majeure concerne le code. Il ne sera pas nécessairement le plus beau ou le plus robuste mais sera plutôt optimisé pour aller vite dans l’exécution. En effet en considérant cette idée de side project pour améliorer mes compétences en product management je me suis aussi attaché à simplifier la stack technique et l’architecture. Cela m’a conduit à faire les choix suivants pour mon premier side project product.
L’architecture sera monolithique ! En effet pas de besoin de séparer le frontend et l’API. Cela fera plus de travail pour le déploiement et de la plomberie pour connecter les deux sans être justifié. J’ai également fait le choix d’une stack 100% Javascript, Express/Vue/Nuxt plus mature (car bénéficiant de l’écosystème de Node JS), plutôt que d’aller sur une stack Play/Scala (que je connais très bien) avec une intégration webpack. Cela donne accès à plus d’outils pour faire une webapp moderne sans devoir me battre avec les outils.
Le dernier point et non le moindre est l’utilisation de services tiers pour encore une fois gagner du temps; Algolia à la place d’Elasticsearch, Mongo Atlas ou MLab plutôt que de gérer soi-même une instance Mongo, l’API de sendgrid en lieu et place d’un serveur SMTP.
