Shipper des features complètes sans devs ? Comment on a rendu ça possible chez Papernest
Product managers, CEOs, marketing managers, avouez-le : vous ne rêvez que d’une seule chose, sortir votre produit et ses nouvelles features plus vite.
Qui dit startup, dit ressources limitées. Qui dit startup tech, dit en plus travail de fond complexe gourmand en ressources (aka les développeurs). Cerise sur le gâteau, les développeurs, c’est cher (toute startup ne peut pas se permettre d’embaucher 20 devs), c’est dur à trouver (ils sont très sollicités) et c’est dur à garder (sauf quand on a une super culture, comme chez Papernest 😉). On vient là de résumer un des problèmes de fond les plus coriace des jeunes pousses tech : le bottlenecking par les pôles de développement.
Si “speed is king”, comme le dit notre cher Loic Le Meur, alors moi je dis “dev speed is king”.
Okay, mais alors comment s’y prendre pour augmenter au maximum l’output des équipes tech ?
Parmi les façons de répondre au problème, en voici 3 souvent abordées :
- L’agilité de conception, aka le MVP → La doctrine de base en développement de produit.
- L’outsourcing → La rustine. Quand on monte une startup tech, on doit un jour ou l’autre bâtir la compétence en interne.
- Ne plus avoir besoin de devs pour livrer des features → L’objet de cet article. Un levier considérable se cache là dessous.
Chez Papernest, ce troisième point, nous l’avons poussé dans ses derniers retranchements. 50% des features livrées le mois dernier sont réalisées et shippées sans la moindre intervention d’un dev. Le tout en maintenant un super niveau de qualité et de design …. Comment ? Lisez la suite !
Les textes™
Les “textes”, c’est donc le nom de notre solution magique. Pour résumer, plutôt que de développer des parcours de souscription, nous avons commencé par développer un outil interne de création de parcours de souscription. Simple me direz-vous ? Oui, simple et puissant. Voilà ce que cela nous a permis :
- Tester plus de 19 versions de notre parcours de souscription à l’énergie sans travail de dev, en 2 mois.
- Corriger un bug de formulaire, une tournure de phrase qui ne marche pas, en un clin d’oeil, en production (qui n’a jamais passé des semaines avec un vilain bug en prod’ qui l’empêchait de dormir ?)
- Bâtir en 3 coups d’éditeur des prototypes de parcours de souscription pour aller les tester sur des gens, dans la vraie vie. Sans rien mettre en prod, utiliser le générateur en local pour créer des parcours à expérimenter. #userResearch
Mais avant d’en dire plus, un peu de contexte s’impose :
Qu’est-ce que l’App de Papernest? Si je vulgarise, c’est aujourd’hui un ensemble de formulaires (complexes) permettant à nos utilisateurs d’enquiller une multitude de contrats liés à leur logement (box, énergie, assurance habitation, redirection de courrier). Plus d’info sur ce que fait Papernest ici.
Notre mission produit, c’est donc, dans un premier temps, de faire les meilleurs formulaires de l’histoire du web. Nous voulons transformer le remplissage de données en un moment simple, appréciable et intelligible (et faire de même avec l’administratif au sens large !). #quelleBelleMission.
Pour en arriver là, une fois les fondements d’un bon formulaire maîtrisés, il faut mener un travail d’optimisation fin sur plein de paramètres : ordre des questions, séquencement des grandes étapes, formulation, design, UX etc…. Nous itérons ainsi en continu sur plusieurs combinaisons composées selon ces moult variables. Le but est de gagner en conversion, en compréhension, et bien entendu en customer love 💖💖💖.
Partant du constat que nous allions rapidement mettre la clé sous la porte si nous devions nous synchroniser sur les sprints de développement (nous fonctionnons en scrum) pour livrer chaque petit changement et itérer sur les résultats (2 semaines de sprint, 2 semaines pour lire les résultats = cycles d’un mois), nous avons conçu un système capable d’opérer des changements sur nos parcours de souscriptions sans aucune intervention technique.
Le concept de base est simple, on fournit un texte structuré (chez nous un JSON) et un générateur transforme ce texte en parcours de souscription. Le texte contient toutes les spécificités du parcours : étapes, questions, relations entre questions, GUI , copie, etc… Autrement dit, nous avons commencé par créer un moteur de création de parcours (un peu à la “typeform”) mais plus profond et adapté à nos spécificités de business et de marque : composants custom comme des fiches produit, branding / design adapté, notifications utilisateurs programmables…
Voici quelques exemples concrets de possibilités offertes par le générateur :
- Définir le parcours utilisateur, sous-divisé en étapes, qui elles-mêmes contiennent des questions. Ces questions peuvent être interdépendantes :
- Définir un thème global : formulaire “classique” ou “chatbot”
- Définir la GUI utilisée pour chacun des éléments du formulaire. Par exemple, voici 4 façons de représenter une question à choix unique (radio-button) :
- Insérer des modules conversationnels n’importe où dans le parcours : popin, chat, SMS, notifications ou bannières visuelles à tout moment choisi. (Screenshot)
Un tonne d’autres possibilités sont offertes en plus de ces quatre exemples, ce qui rend possible la construction d’une multitude de parcours utilisateurs. Pour plus d’info, déchainez vous dans les commentaires !
La beauté du mécanisme se cache juste après : une fois ces “morceaux d’app” générés, l’équipe produit peut les pousser “live” indépendamment des releases dev (des tests automatisés s’assurent bien entendu du bon fonctionnement du tout avant de mettre en ligne). Et là, c’est la révolution : 50% des releases libérées des équipes tech.
Constatant l’immense apport de ce joli process, nous avons progressivement augmenté sa portée et ses performances. Si bien qu’aujourd’hui, notre système ne se limite plus à livrer les parcours de souscription mais couvre aussi notre on-boarding, notre dashboard et notre partie “mon compte” (soit grosso-modo 90% de l’app, “shippable” par l’équipe produit).
“De quoi relâcher légèrement la pression sur un backlog. Un simple générateur de parcours s’est ainsi transformé en solution de désintermédiation technique majeure.”
Ouvrir la voie aux tests
Après avoir rendu possible la livraison de fonctionnalités par l’équipe produit, restait encore la question de bien évaluer leurs résultats. Pour en faire ainsi dans les règles de l’art, nous devions penser AB tests. Nous avons pu aisément bâtir sur notre framework initial :
- Plusieurs versions de nos “morceaux d’app” générés peuvent être distribuées parallèlement à nos utilisateurs. L’équipe produit peut définir des règles d’attribution à tout moment via une interface d’administration (ex : texte A sur 50% de nos utilisateurs, texte B pour le reste). Un test à Shipper ? 3 minutes.
- En se basant sur nos outils de tracking (sous-tendus par notre meilleur ami segment), nous avons créé des rapports automatisés de mesure des performances des différents morceaux d’app et leurs significativité statistique. Fini les doutes !
A qui le tour ?
Vous pensez peut-être “c’est bien sympa, mais c’est pas facile pour ma boite”. La recette est pourtant simple : développez un “third party” créateur d’app plutôt que développer l’application elle-même. Votre app est déjà existante, et plutôt touffue ? Appliquez cette méthode sur quelques features pour commencer puis étendez peu à peu la couverture au reste de l’app.
Cela paraît complexe mais ne l’est pas tant en réalité, c’est au contraire un bon moyen de s’assurer dès le début d’avoir une architecture saine et scalable.
Procéder de la sorte ralentira bien sûr votre développement en premier lieu mais vous fera gagner 30 fois ce temps par la suite. Garanti. En plus, le challenge technique s’avère être très stimulant pour les équipes tech !
Tout commence par faire les efforts suivants pour chaque story / projet :
- Niveau dev, pensez composants réutilisables (rien de nouveau, le fondement de nombreux frameworks d’aujourd’hui). Mettez aussi au maximum l’accent sur la “scalabilité” dans votre philosophie de développement.
- Niveau architecture, essayez de rendre ces composants paramétrables de l’extérieur. Techniquement, on vous invite à aller regarder le design pattern “pageObject”. Poussez cela au plus loin, la magie s’opère ici (si vous voulez un article plus technique détaillant notre archi, faites-le nous savoir !).
- Niveau design pensez comme le dev : composants unitaires réutilisables fonctionnant peu importe le contexte. Prévoyez aussi plusieurs layouts pour chaque composant, histoire d’être bien équipé pour tester plein de possibilités.
Rétrospectivement, j’aurais adoré avoir un tel système de désintermédiation dans les boîtes où j’ai travaillé précédemment. De quoi rendre un fier service pour optimiser nos tunnels de conversion, délester nos devs des petites tâches triviales et reprendre le contrôle sur nos roadmaps.
A l’heure où la capacité à tester des solutions ultra-rapidement devient un facteur clé dans la réussite d’une startup tech, voici un avantage compétitif qui vous suivra tout au long de votre développement produit !
