Quel modèle pour construire son produit ?

Cet article a été initialement publié sur Medium le 30 janvier 2019.

Tous les mois, nous organisons chez Qonto des meetups qui nous permettent d’échanger avec des entrepreneurs et employés de startups. Le mois dernier, c’était au tour du produit ! Nous avons reçu deux experts pour une session de “Ask Me Anything” :

• Thomas Vuchot, Head of Product chez Qonto
• Edouard Wautier, Lead Design chez Alan

Vous n’avez pas pu regarder le direct du meetup ni venir ce soir là, pas de panique ! On vous partage la vidéo ici :

Pour ceux qui préfèrent l’écrit, nous avons résumé le meetup en quelques précieux conseils :

Non, vous n’allez pas trouver dans cet article la formule magique pour mieux organiser votre équipe produit 🌟!

Chez Qonto comme chez Alan, les équipes ont grandi et se sont structurées de manière organique. Logique : plus on a de clients , plus on a besoin de besoins !

Chez Qonto, tous les Product Managers peuvent travailler sur tous les sujets. Ce n’est que très récemment que certains ont commencé à se spécialiser (par exemple sur l’infrastructure bancaire ou les sujets opérationnels). Les Product Managers sont au centre de tous les besoins qui nécessitent un développement, mais aussi de toutes les réflexions qui nécessitent de comprendre et qualifier un besoin utilisateurs (et de prioriser le développement d’une fonctionnalité de développer une fonctionnalité ou pas).

Les équipes tech et design sont incluses le plus tôt possible dans le process mais c’est bien au Product Managers de centraliser et coordonner le projet, depuis l’expression du besoin, au suivi du développement, jusqu’à la livraison de la fonctionnalité.

L’équipe d’Alan s’est longtemps passée de Product Manager (pendant 2 ans). La responsabilité des projets était avant partagée entre les designers et les ingénieurs. Les Product Managers sont arrivés il y a quelques mois et n’ont pas nécessairement vocation à “leader” les projets mais plutôt à apporter une nouvelle perspective (plus orientée data ou business) ou à coordonner des projets complexes (notamment les projets reposant sur des partenariats).

Chez Alan, les projets sont menés de manière collaborative et une personne de l’équipe est toujours “owner” du projet (pas forcément un Product Manager).

Les deux caractéristiques les plus recherchées chez les Product Managers par Thomas et Edouard : la curiosité et la passion pour le produit. A la question, où recrute-t-on de bons Product Managers ? Pas de réponse magique non plus !

Les deux intervenants se sont accordés sur un point : il n’y a pas d’éléments tangibles sur un CV. En général, c’est la polyvalence qui est recherchée : on va se tourner vers des candidats qui ont eu des “side projects”, qui ont construit des choses et ont une sensibilité pour le produit.

La discipline étant relativement récente, il n’existe pas encore de “background” idéal. Chez Alan, on va privilégier les profils venant de l’ergonomie, de l’ingénierie ou des arts appliqués.

Vous voulez devenir Product Manager chez Alan ? Voici leur process de recrutement :

• 2 entretiens techniques d’une heure : un exercice pour comprendre comment il raisonnera sur les solutions
• 1 entretien pour vérifier le “fit” du candidat avec la culture
• 1 “free day” : les candidats viennent une journée et travaillent sur un sujet

Il y a autant d’équipes produit que de méthodes. Voici un aperçu de celles d’Alan et de Qonto !

• Alan : structuration par “crews” et culture de la transparence

Chez Alan, les équipes sont structurées en “crews” sur une problématique donnée avec une durée de vie limitée dans le temps.

Dans une “crew”, on va retrouver tous les profils d’Alan : un designer, plusieurs ingénieurs, parfois un Product Manager, une personne de l’équipe assurance, une personne du support, une personne data si besoin. La roadmap est collaborative, ce qui permet à définir les priorités en fonction des objectifs de l’entreprise. Puis, à intervalles réguliers, des “roadmap sessions” sont organisées.

Le travail est divisé en deux phases :

• 1. Framing : identifier les causes des problèmes (souvent dirigé par un designer ou Product Manager). Une description textuelle de la solution est écrite à la suite de cette phase.
• 2. Making : implémenter la solution avec la liste des tâches (dirigé par un ingénieur)

C’est la même équipe qui travaille sur les deux phases.Les équipes d’Alan n’organisent jamais de réunion, tout est écrit sur Github.

Elles utilisent aussi Trello pour suivre et faire évoluer les idées d’un état à un autre.

La culture de la transparence est totale : si un sujet intéresse quelqu’un, il peut participer à la discussion en cours.

• Qonto : le “visual management”

L’approche de Qonto est différente. On essaie de limiter les réunions qu’on remplace par des rituels le matin. Les “stand-up” quotidiens permettent de :

• S’aligner sur les sujets définis comme stratégiques
• Éviter l’“overlap”
• Rendre le travail visuel, ce qui permet de mieux travailler en équipe

Peu d’outils sont utilisés en plus des tableaux dans les bureaux et Slack.

“Ce qui est important, c’est ce qu’on met dans les outils plutôt que les outils eux même”

Ni Alan ni Qonto n’a d’équipe QA. Chez Qonto, Thomas justifie ce choix :

• Les développeurs sont responsables de la qualité de ce qu’ils livrent. Cela permet de ne pas diluer la responsabilité
• Ce sont les Product Managers qui définissent les critères d’acceptabilité d’une fonctionnalité
• C’est le Product Manager qui donne son “Go!” pour la mise en production

Chez Alan, les ingénieurs sont responsables de ce qu’ils livrent !

La question des indicateurs de réussite est primordiale. L’objectif premier est celui de l’adoption. Chez Qonto, on monitore aussi des données opérationnelles : le nombre de tickets générés, le montant des opérations…

La roadmap est fondée sur les besoins des clients et de l’équipe, des frustrations aux demandes très précises. Chez Qonto, nous utilisons ProductBoard, un outil qui permet de centraliser tous les retours, recueillis par le service clients, l’équipe sales, le marketing… C’est la roadmap “crowdsourcée” !

On en a qualifié plus de 8 000 depuis notre lancement 😱.

On ne peut évidemment pas décider de répondre à toutes les demandes utilisateurs, au risque d’avoir un produit qui manque de cohérence. Il y a donc une étape de qualification des demandes, faite par les Product Managers, qui doivent rester en alignement avec l’orientation stratégique de l’entreprise.

Cela ne veut pas dire que les équipes produit ne réfléchissent pas à des fonctionnalités à horizon 6 mois mais plutôt que les équipes préfèrent réduire le nombre de projets pour respecter leur capacité à délivrer. Pour s’attaquer à des sujets de complexités variables, la logique veut que l’on découpe les problèmes de la manière la plus granulaire possible. Edouard estime qu’il faut entre une demi-heure et 6 semaines pour résoudre un problèmes.

Cela permet aussi un ancrage fort dans la réalité.Exemple : Alan a obtenu son agrément le 20 octobre. Un mois et demi après, leur site était en ligne. Ils savaient qu’ils auraient peu d’utilisateurs au début. Ils ont donc créé une interface simple avec du contenu et quand une action était demandée, une “pop-up” Intercom apparaissait pour déclencher l’action. La team care se chargeait alors manuellement de réaliser l’action.

Un objectif chiffré est fixé pour chaque projet, afin de mesurer le succès de ce qu’on a fait. Le sujet le plus complexe, quand on s’attaque à des secteurs comme la banque ou l’assurance, reste l’aspect réglementaire.Vous rêvez de rejoindre une équipe produit pour construire et faire grandir un projet ambitieux ? De nombreux postes sont encore ouverts chez Qonto. Tous les postes sur cette page !