De Capitaine Train à Memo Bank : les leçons d’un Product Manager

En 2017, nous nous sommes embarqués dans un projet ambitieux : construire une nouvelle banque pour les petites et moyennes entreprises, en partant de rien, et sans prendre aucun raccourci au passage.

À l’époque, l’équipe qui travaillait sur ce nouveau projet était majoritairement composée d’anciens de Capitaine Train, un site de vente de billets de train, racheté par Trainline en 2016. Comme les occasions de changer de projet sans changer complètement d’équipe sont rares, nous avons profité de notre nouvelle aventure pour perpétuer ce qui nous avait plu chez Capitaine Train, tout en améliorant ce qui pouvait l’être.

Capitaine Train était apprécié pour la qualité de son produit, de ses applications web et mobile. Nous avions l’obsession du service client et le goût du travail bien fait, ce que nos utilisateurs pouvaient sentir au travers de nos interfaces. Notre équipe était composée d’ingénieurs et de spécialistes du service client, qui travaillaient main dans la main pour rendre la réservation de billets de train rapide et facile.

En tant qu’employés de Capitaine Train, nous avions la chance de pouvoir utiliser notre produit tous les jours. Nous étions nos premiers utilisateurs. Nous n’avions donc aucun mal à nous mettre à la place de nos clients pour comprendre leurs besoins.

Pourtant, en matière de développement du produit, de Product management comme on dit, nous avions des marges de progression :

• La culture de Capitaine Train avait été définie par des ingénieurs, des développeurs ; la notion de produit, et la fonction de product manager, ont été adoptées en cours de route, après coup. À l’époque, nous avons fait beaucoup d’efforts pour ménager de la place au produit, mais nous aurions sans doute gagné à mieux équilibrer le rapport de force entre l’ingénierie et le produit.
• Nous aurions pu standardiser nos méthodes de travail, celles qui nous permettaient de sortir de nouvelles fonctionnalités, pour aller plus vite à chaque nouveau projet et embarquer plus de monde à chaque fois. La mise en place de cycles de développement et d’objectifs clairs en matière de produit auraient pu aider.
• Notre façon de hiérarchiser les fonctionnalités à développer aurait elle aussi gagné à être un peu plus structurée. Par exemple, nous aurions pu considérer la complexité de chaque fonctionnalité par rapport à la valeur apportée à l’utilisateur ou à l’entreprise.
• Nous écoutions énormément nos utilisateurs, ce qui faisait de nous des acharnés de l’analyse qualitative, mais notre biais pour les avis des clients nous a parfois détourné de l’analyse quantitative, des données brutes que nous aurions pu utiliser pour éclairer certaines décisions.

Ce qui est possible dans un secteur ne l’est pas forcément dans un autre, nous nous en sommes bien rendus compte en passant du rail à la banque. Quand on construit une banque pour les professionnels, on ne peut pas en être client à titre personnel, personne dans l’équipe ne peut donc utiliser le produit au quotidien. Dans la banque, les décisions qui façonnent le produit sont prises à la lumière des analyses de marché et des clients potentiels, elles reposent sur des faits, des données, plus que sur des intuitions issues de l’expérience.

Autre changement : le nombre de personnes qui ont leur mot à dire sur le produit est décuplé, en interne comme au-delà des murs de l’entreprise. En interne, les objectifs de certaines équipes divergent : ceux des chargés d’affaires ne sont pas forcément solubles dans ceux des spécialistes du risque. À l’extérieur, les contraintes imposées par le régulateur sont parfois impossibles à concilier avec les demandes des utilisateurs.

La multiplicité des sujets n’arrange rien. Le périmètre à couvrir est immense. En plus de servir au mieux ses utilisateurs, une banque destinée aux professionnels doit aussi se différencier des autres banques du même type, dont les offres sont souvent plus complètes et déjà éprouvées.

Enfin, la complexité inhérente à l’industrie bancaire ajoute de l’inertie au cocktail, puisque tous les membres de l’équipe doivent prendre le temps d’en comprendre les règles et les contraintes. Cette complexité se traduit par un besoin de formation des nouvelles recrues : les ingénieurs reçoivent une formation bancaire pendant que les banquiers sont introduits à la technologie.

Dans de telles conditions, s’entourer des bonnes personnes fait toute la différence, car de bons recrutements peuvent faire gagner un temps fou par la suite.

Dans ce contexte compliqué, un chef d’orchestre n’est pas de trop ; et ce chef d’orchestre, c’est le product manager. Son rôle consiste à faire prendre la mayonnaise, en dépit des contraintes qui pèsent sur l’organisation. Le product manager est un chef d’orchestre sans baguette, son costume est différent mais sa vision d’ensemble est la même que son homologue en queue de pie.

Quand on travaille avec des personnes issues d’entreprises dans lesquelles les commerciaux ne parlaient jamais aux équipes techniques, la bonne coopération des uns et des autres repose sur la crédibilité accordée au product manager. Sa présence permet d’éviter le fonctionnement séquencé, segmenté, qui caractérise les organisations en silos.

Dans notre cas, nous expliquons le rôle du product manager dès les premières formations auxquelles assistent les employés.

La complémentarité des spécialités

Dans la banque, pour un sujet donné, les informations peuvent être rares et sujettes à des interprétations contradictoires. Par conséquent, personne ne peut tout faire tout seul. Pour parvenir à la meilleure solution possible, plusieurs intelligences doivent se frotter les unes aux autres. Sans confrontation des points de vue, point de salut. Cette gymnastique intellectuelle implique de composer avec des personnes aux formations et aux expériences différentes, toutes lancées vers un objectif commun. Pour que la coopération fonctionne, les équipes doivent parler la même langue, s’entendre sur ce qui est attendu d’elles, et communiquer régulièrement.

Voici ce que j’aurais aimé savoir avant de devenir le premier product manager d’une jeune banque destinée aux professionnels.

Avoir confiance en son rôle

Personne ne s’attend à ce qu’un product manager sache tout sur tout. Vous n’êtes pas là pour avoir réponse à tout, mais pour poser les bonnes questions. Faites preuve d’humilité face à la complexité, mais sans vous laisser écraser. Vous devez diffuser l’enthousiasme, pas l’anxiété. Faites de votre mieux, communiquez souvent, mettez en mouvement les motivations de vos collègues, et vous parviendrez à vos fins.

Définir la vision produit

• Prenez le temps de trouver les concepts qui conviennent à votre secteur. Cet exercice demande du temps et des efforts, ne le négligez pas. Une fois que vous aurez la bonne grille de lecture en tête, les bonnes catégories, les bons schémas, tout s’éclairera et vous parviendrez plus rapidement à de meilleures décisions.
• Parlez aux gens. Rencontrez des utilisateurs potentiels, mais aussi des régulateurs et des partenaires. Dans notre cas, nous avons parlé à des dirigeants, car ce sont eux qui prennent la décision d’ouvrir un compte en banque, mais nous avons aussi parlé aux personnes qui les assistent, car elles vont utiliser notre produit au moins autant que les dirigeants. Nous avons aussi diffusé deux questionnaires, un pour les entrepreneurs et un autre pour les banquiers, dans le but de mieux comprendre notre marché.
• Intéressez-vous à la stratégie de l’entreprise. Parlez aux fondateurs, lisez le business plan et participez aux discussions stratégiques. Plus vous ferez vôtre la stratégie de l’entreprise et mieux vous la traduirez en objectifs concrets pour les différentes équipes.

Apprendre à marcher avant de courir

Aidez vos collègues, simplifiez leur quotidien : adoptez les bons outils, partagez ce que vous savez, et améliorez le fonctionnement de l’organisation — en limitant le nombre de réunions, par exemple. Recommencez autant de fois que nécessaire. Quand nous avons commencé à travailler avec un designer indépendant, nous avons eu du mal à partager ses travaux avec le reste de l’équipe. Pour y remédier, nous avons mis en place Abstract, un outil de design collaboratif. Désormais, tout le monde peut contribuer à l’élaboration des interfaces.

Notre équipe est composée de personnes aux expériences différentes : certaines viennent d’entreprises technologiques, d’autres de la banque. Inutile de dire qu’elles n’ont pas le même avis sur l’utilité des réunions. Pour résumer très grossièrement les opinions des uns et des autres, disons que les employés du numérique apprécient peu les réunions alors que ceux des banques ont l’habitude d’y passer une bonne partie de leur temps. Trouver un terrain d’entente entre les deux camps n’est pas une mince affaire. Dans un article de blog, les équipes de chez Alan proposent une alternative intéressante aux réunions : la note écrite.

N’ayez pas peur de perdre du temps pour en gagner, de prendre le temps d’apprendre, de laisser à l’expérience le temps de vous instruire. Nous avons consacré plusieurs mois à l’élaboration d’un prototype, dans le seul but de nous familiariser avec notre nouveau métier. Une partie des membres de l’équipe ne voyait pas l’intérêt de commencer par un prototype, mais l’initiative s’est avérée concluante, non seulement pour apprendre à travailler ensemble, mais aussi pour nous faire une première idée de notre architecture technique. Le prototype en question ne nous sert évidemment plus, mais nous avons gardé de cette période d’excellents souvenirs et de quoi fonder une camaraderie — les personnes impliquées parlent encore de cette période avec le sourire.

Créer une feuille de route (roadmap)

Quelques conseils pour partir du bon pied :

• Concentrez-vous sur l’essentiel. Gardez en tête que vous n’avez pas besoin de réinventer la roue pour réussir — et personne ne vous en voudra si vous ne le faites pas. Faire la même chose, en mieux, suffit souvent à imposer sa différence. Dans notre cas, le coût (en temps et en moyens) nécessaire pour proposer les mêmes fonctionnalités que nos concurrents était si élevé, qu’il nous a forcés à faire des choix, à ordonner nos priorités — ce qui implique de laisser de côté, au moins temporairement, des projets qui nous sont chers. Pour créer notre feuille de route dans ce contexte, nous avons dû choisir entre deux pistes, deux prototypes radicalement différents. Inévitablement, nous avons longuement débattu avant de prendre une décision. Mais une fois notre décision prise, une fois notre choix fait, toute notre équipe a fait corps derrière notre projet et tous nos objectifs se sont alignés pour pointer vers la même direction, ce qui nous a permis de nous mettre au travail rapidement.
• Prenez le temps d’écouter tout le monde, pour vous assurer d’oublier le moins de choses possibles — car certains éléments vont nécessairement vous échapper.
• Impliquez votre équipe technique dans l’élaboration de la feuille de route. Sollicitez vos collègues le plus tôt possible, le plus en amont possible. Vous vous épargnerez ainsi des pépins par la suite — qu’ils soient d’ordre technique ou relationnel.
• Laissez-vous de la marge pour des ajustements de dernière minute. Commencez par travailler sur les fonctionnalités qui vous semblent essentielles et ne planchez sur les autres que s’il vous reste du temps à la fin.
• Une fois votre feuille de route créée, partagez-la et mettez-la souvent à jour. Product Board est un bon outil pour ça.
• Fixez-vous des objectifs tangibles, concrets, chiffrés. Et montrez régulièrement ce sur quoi vous avez travaillé lors de démonstrations destinées aux autres employés.

Envisager à court terme les besoins de long terme

Nous construisons une banque, une vraie banque indépendante. Nous abordons donc tout ce que nous faisons comme un projet industriel, ce qui nous oblige à voir plus loin que la fin du mois en cours. Si nous ne considérons pas suffisamment un sujet aujourd’hui nous en paierons le prix demain, ou après-demain. Par conséquent, nous faisons toujours le choix de la qualité, même si une solution passable aurait pu faire l’affaire à court terme et à moindre coût. Nous optons pour la voie la plus exigeante, non seulement en matière de produit, mais aussi en matière de procédures et d’outils internes.

Par exemple, nous cherchons à éviter les dépendances et les intermédiaires autant que possible, pour rester maîtres de notre infrastructure. Ce choix n’est pas gratuit, certes, mais il nous a poussés à investir du temps dans l’élaboration d’une architecture technique aussi exotique que prometteuse.

C’est presque vain de le rappeler, mais le choix de la qualité se fait au prix de la rapidité. Privilégier l’une revient à se détourner de l’autre. Pour autant, nous considérons notre biais pour la qualité comme un placement de long terme dont nous toucherons les intérêts plus tard. Quand viendra le temps de faire tourner nos opérations à grande échelle, nous pourrons monter dans les tours sans craindre de casser le moteur.