L’échec est une éventualité dans le développement de logiciels. Non seulement nous échouons, nous sommes encouragés à échouer itérativement. Faisons-le encore et encore!
Et pourtant, le travail de chef de produit s’accompagne d’un niveau de responsabilité et de contrôle unique. Les chefs de produit sont invités à prendre en charge toutes les facettes du développement d’un produit, de la conception au lancement. De la conception du logiciel à l’expérience utilisateur. Des besoins des consommateurs aux points d’intégration. Travaux à réaliser, réflexion orientée design, microservices, orientation objet, orientation service, user stories, adéquation produit-marché, stratégie de lancement, modèles de données, segmentation client, framework après framework, après framework. Une connaissance pratique de certains de ces éléments suffit à faire tourner la tête de quiconque, sans parler de tout contrôler afin de livrer des produits performants.
Après tout, une grande partie de l’industrie de la technologie est en affaires précisément parce qu’elle sait que nous échouerons, et les progrès dans le développement de logiciels soulagent de plus en plus l’échec. Le cloud computing permet une élasticité dans tout, de l’équilibrage de charge à l’utilisation du serveur, introduisant la possibilité de prendre une décision humaine hors de la mise à l’échelle. Les craintes de paiement excessif ont été atténuées par les modèles de paiement à l’utilisation. Le versionnage nous permet de graduer lentement notre approche et de tester de nouvelles fonctionnalités. La reprise après sinistre et le basculement nous assurent que nous serons en sécurité malgré des accidents colossaux.
De plus en plus, la communauté technologique assimile le fait de ne pas tomber sur un trampoline et de sauter à nouveau. Nous n’avons plus besoin d’anticiper tous les besoins des clients, de rendre le voyage parfait du premier coup ou de planifier des charges inattendues – Amazon, Microsoft et Google nous pardonneront de mal planifier (à petit prix bien sûr).
L’industrie évolue à un rythme sans précédent car il est si facile de se relever après un échec. Le déploiement et le lancement sont plus faciles que jamais, nous sommes donc encouragés à arriver au marché. Expédiez simplement. Souvent, on nous demande de faire trop de choses à la fois sans vraiment bien faire une seule chose.
L’échec est devenu la norme, l’imitation trop facile et les coûts diminuent chaque jour. Malgré toutes ces bonnes nouvelles, le travail du chef de produit semble être devenu plus compliqué. Si l’imitation est trop facile, il est difficile de prouver un avantage concurrentiel. Et si les coûts deviennent négligeables, nous avons tellement d’options qu’il est difficile de fixer des limites. Il est de plus en plus difficile de conserver un avantage concurrentiel et d’être sûr que nous prenons les bonnes décisions.
Alors, comment pouvons-nous prendre les bonnes décisions dans une mer d’options et de produits concurrents? Bien que j’ai toujours eu du mal à comprendre toutes mes options, j’ai constaté que la meilleure façon d’informer mon processus de prise de décision est de retrousser mes manches et de décocher chaque option. La tâche ardue de vraiment comprendre comment tout fonctionne s’est avéré utile lors de la sélection des fournisseurs, du choix des fonctionnalités à prioriser et de la création de produits qui évolueront – en luttant constamment contre l’envie de proposer d’abord des solutions et des feuilles de route de haut niveau. Commencez par le bas, bloc par bloc. Voici quelques-uns des hacks et des outils que j’ai trouvés qui ont facilité ma prise de décision et qui ont contribué à faire de mes échecs une expérience d’apprentissage positive.
1. Traitez le système
S’il existe une variété d’outils disponibles et que la commutation est facile, trouvez celui qui vous convient le mieux. Cela semble trivial, mais profitez des essais gratuits et des démos gratuites. Mets-toi les mains sales! Jouez même en tant que chef de produit pour comprendre exactement quel ensemble d’outils vous obtenez. Exemple: inscrivez-vous pour un compte AWS, GCP, Heroku. Ils sont tous gratuits pour commencer, et vous pouvez avoir une bonne idée de la suite de produits qu’ils proposent et des options de mise à l’échelle qui vous conviennent le mieux. Et vous êtes autorisé à demander des cadeaux. N’hésitez pas à demander. S’il existe un fournisseur dont vous recherchez l’API, soyez autorisé à demander une API de test. Le plus qu’ils diront est non.
Sur l’un de mes projets, mon équipe avait besoin de créer un site Web statique pour faire connaître notre produit rapidement. Nous étions cependant limités par les processus de gouvernance de nos clients et par l’accès à leur compte AWS d’entreprise. Après avoir moi-même joué avec AWS, j’ai réalisé que nous pourrions tout aussi facilement héberger notre site Web statique via Dropbox, car la technologie sous-jacente est la même. Je savais qu’il évoluerait bien – ne serait-ce que pour atteindre l’objectif unique de rediriger les utilisateurs vers notre produit principal. Non seulement cela a résolu un problème immédiat à court terme, mais c’était l’approche plus simple et plus rapide qui nous a permis de nous concentrer sur les hypothèses de produits plus larges que nous voulions tester avec nos clients.
2. Unissez vos forces
Réfléchissez vraiment à savoir si le construire vous-même est la réponse. Dans un monde open source, il y a de fortes chances que quelqu’un l’ait déjà construit. Vous pensez peut-être que ce que vous recherchez est assez facile à construire vous-même, et c’est votre décision. Mais une partie de votre expertise consiste à comprendre combien de temps et combien il faudrait pour le construire vous-même et à comparer cela avec le coût d’achat. Cela pourrait même être gratuit! Faites la recherche.
3. Construisez-le vous-même
Cela semble contraire au numéro deux, je sais. Parfois, il y aura des produits qui feront ce dont vous avez besoin, mais pas toujours de la manière dont votre équipe ou votre produit en a besoin. Faites de votre mieux pour évaluer avec précision si votre équipe peut construire cela, car si elle le peut, vous disposerez de votre propre technologie propriétaire parfaitement adaptée à votre objectif. Et s’ils ne peuvent pas, c’est encore mieux. Vous aurez appris une variété de leçons sur votre ensemble de données que vous n’auriez pas prévues auparavant. Les contraintes de temps et de ressources dicteront si vous pouvez vous permettre d’aller avec le numéro deux ou le numéro trois.
4. Déployez aussi souvent que possible
Le pipeline de déploiement n’est souvent pas entre les mains du chef de produit, mais lorsque vous pouvez contrôler la fréquence d’expédition de votre équipe, faites-le. Chaque version vous apprendra une variété de leçons, en particulier sur vos dépendances et vos points de données. Vous ne serez pas en mesure d’anticiper chaque cas de bord et chaque liaison tant que vous n’en aurez pas réellement fait l’expérience. Plus vous relâchez, plus les choses vont casser. Réparez-les et passez à autre chose. Si vous ne l’avez pas déjà deviné, c’est le thème de cet article! L’urgence ici n’est pas de sortir ou d’expédier rapidement, l’urgence est d’apprendre rapidement. Et un sage, quelque part, a dit un jour: «vous apprenez le plus de vos erreurs».
En tant que chefs de produit, notre travail n’est pas de prévenir ou de réduire les échecs, mais plutôt de surmonter les échecs après les échecs tout en tirant le meilleur parti de nos produits et de nos équipes. Nous devrions donc regarder au-delà de «tout faire correctement» la première fois, voire la deuxième fois. Les échecs en eux-mêmes sont élastiques, et la leçon importante à tirer de chaque échec est ce que chacun nous a appris sur les besoins et les préférences de nos clients, les méthodes de travail de nos équipes, les données dont nous disposons et les parcours qui en apporteront le plus. valeur.