Business : Laisser les chefs de produit s’engager dans la base de code

Les chefs de produit ont le plus souvent besoin d’agir comme des «couteaux suisses» pour leurs équipes: piloter la stratégie, l’exécution tactique et s’assurer que l’équipe atteint ses objectifs. Cela peut signifier différentes choses pour différentes équipes, et j’étais sur le point de découvrir ce que cela signifiait vraiment pour moi et mon équipe. Au cours de l’été, je suis sorti de ma zone de confort et j’ai fait quelque chose en tant que chef de produit contre lequel beaucoup mettraient en garde: j’ai appris les bases de la contribution à notre base de code pour l’équipe.

Préparons le terrain: c’était en juin 2019, et nous étions dans le pétrin. Nous étions à court de capacité en raison de facteurs imprévus, et nos équipes de vente et de marketing comptaient sur nous pour aider à lancer nos produits d’assurance-vie axés sur les conseillers (Coverpath) dans 5 nouveaux États avant leurs plans de promotion.

L’un des principaux obstacles a été la mise en place d’un grand nombre de formulaires pour l’eSignature des clients et des conseillers dans le cadre de notre processus de candidature. Bien que nous soyons fiers de créer une plate-forme conviviale pour l’achat d’assurance-vie, il n’est pas possible d’échapper à la nécessité de signer de nombreux documents, étant donné que chaque État et chaque type de produit d’assurance ont leurs propres règles pour signer les documents. Nous tirons parti de DocuSign pour une grande partie de cela, mais une pièce clé du puzzle est notre configuration maison, basée sur JSON, décrivant tous les formulaires, la source de données pour chacun des champs qu’ils contiennent et les règles pour les inclure ou pas pour un client donné.

Nous avons découvert que nous avions trois options à considérer pour que nous puissions sortir la fonctionnalité

Nous avons décidé de l’option # 1. J’étais particulièrement bien placé pour configurer notre expérience eSignature client pour les nouveaux lancements d’état depuis que je comprenais si bien les exigences de produit et de conformité. Notre théorie était que je pouvais être encore plus efficace qu’un ingénieur dans ce domaine en raison de mes antécédents avec DocuSign et la connaissance approfondie que j’avais des exigences complexes, ce qui annulerait la nécessité de les traduire pleinement dans l’équipe.

J’avais toujours exprimé mon intérêt à être démantelé pour aider l’efficacité de notre équipe et mon équipe m’a accepté. Un des ingénieurs m’a proposé de m’aider à me placer derrière le siège du conducteur et se mettre au travail en validant le travail dans la base de code.

«Les chefs de produit chez Haven n’ont pas peur de tous les petits caractères de l’assurance. Et l’édition d’un fichier JSON poilu n’est pas si différente que la modification d’une feuille de calcul poilue; le format est vraiment secondaire à la nécessité de faire attention aux détails. Nous avions le pressentiment que donner à Luke nos outils pour éditer le fichier directement serait plus rapide que d’obtenir une interface graphique opérationnelle et fiable (ou même un script pour convertir une feuille de calcul en configuration compte tenu de tous les cas critiques qu’il devrait gérer). » – Michael, développeur

Avec cela, l’équipe m’a mis au travail et j’ai agi en tant que contributeur de code à temps partiel, PM à temps partiel. J’ai appris les bases de l’exécution de nos systèmes localement sur mon propre ordinateur, de l’extraction et de la transmission des modifications à Git et de la mise à jour de base de la configuration de nos documents.

Après environ un mois dans les tranchées avec l’équipe, nous avons livré la version à 5 nouveaux états à temps! Il y a eu quelques appels rapprochés, de nombreux bugs introduits (et résolus) par mon travail et un coaching de l’équipe. Dans l’ensemble, je suis fier de dire que notre expérience a été un succès. Cela a posé des défis, mais nous sommes devenus une équipe plus efficace dans le processus. J’ai appris plus que ce à quoi je m’attendais et, sans surprise, j’ai été humilié par l’expérience.

Apprendre à contribuer aux tâches d’ingénierie en un clin d’œil a été une courbe d’apprentissage abrupte pour moi, mais je suis heureux de l’avoir utilisée comme une opportunité d’améliorer mes compétences et d’obtenir une meilleure compréhension du travail quotidien des développeurs de mon équipe. et journée.

Je me considère maintenant comme un couteau suisse (un peu) moins ennuyeux, un état d’esprit que tous les PM devraient viser pour contribuer au succès de leurs équipes!