Élever le niveau en matière de gestion de produits : le cycle de vie d'un produit de A à Z avec Aaron Bonko

Bienvenue dans notre série Élever le niveau en matière de gestion de produits. Dans cette série d'articles, nous analysons en profondeur les subtilités de la gestion de produits technique pour partager des données, des bonnes pratiques et des expériences issues du monde réel et aider les chefs des produits techniques (que l'on appelle aussi chez Amazon techniciens-chefs de produit ou PMT) à monter en compétences, à comprendre la façon dont nous travaillons chez Amazon Ads et à en savoir plus sur le travail qui nous passionne.

Dans ce premier épisode, nous recevons Aaron Bonko, responsable senior en chef du programme technique (TPM) au sein de l'équipe Suivi, mesures et science des données. Avec près de neuf ans d'expérience chez Amazon, le rôle d'Aaron le place au croisement entre technologie et stratégie commerciale. Il nous parle ici de la manière dont nous gérons en règle générale le cycle de vie d'un produit chez Amazon.

Le cycle de vie du produit chez Amazon Ads

Chez Amazon Ads, le cycle de vie d'un produit n'est pas radicalement différent de celui que l'on trouve dans d'autres entreprises technologiques. Toutefois, au fil des années, nous avons affiné notre approche afin de correspondre à la culture d'investissement personnel et d'obsession client d'Amazon. Nous décomposons généralement le cycle de vie du produit en cinq étapes :

Avant le développement : C'est ici que tout commence. Chez Amazon, nous parlons toujours de « travailler à rebours », c'est-à-dire que nous commençons par bien comprendre nos clients et leurs besoins. Le processus amazonien consiste à contextualiser le produit au sein de notre portefeuille plus large et à développer un CP/FAQ (communiqué de presse/questions fréquentes) centré sur les données, qui imagine le produit à la date de son lancement et les avantages qu'il apportera aux clients. Cet énoncé de vision constitue la base de l'ensemble du travail sur le produit. Nous ne commençons pas son développement tant que tout le monde n'est pas satisfait du CP/FAQ.
Développement et tests : C'est ici que nos idées prennent vie. Nous préparons des designs, concevons des prototypes et réalisons des tests approfondis. Contrairement à un modèle en cascade traditionnel, nous n'attendons pas d'avoir un document de critères complet et exhaustif. Nous commençons plutôt par un aperçu de haut niveau et interagissons dès le début avec nos équipes techniques. Cela nous permet d'obtenir des retours précieux sur la complexité et les simplifications potentielles dès le départ.

Chez Amazon, nous cherchons toujours à créer un produit un minimum appréciable plutôt qu'un produit un minimum viable. « L'obsession client » est notre premier principe de leadership, et même la version la plus simple d'un produit que nous lançons doit ravir les clients. Nous intégrons des tests tout au long de notre processus de développement, et non pas seulement à la fin, et nous employons une combinaison de tests d'unités, d'intégration et d'acceptation par les utilisateurs. L'une des pratiques qui nous a bien aidés est le fait d'impliquer, dès que possible, de vrais clients dans nos phases de test. Nous lançons souvent des programmes bêta au cours desquels des clients triés sur le volet peuvent essayer de nouvelles fonctionnalités et partager leurs retours. Ces tests en conditions réelles s'avèrent précieux pour identifier des problèmes d'utilisation et affiner nos produits avant leur lancement complet. Lors de cette phase, nous veillons également particulièrement aux exigences non fonctionnelles. Les performances, l'évolutivité et la sécurité ne viennent pas après coup, mais font partie intégrante de nos processus de développement et de test. Nous effectuons des tests de chargement pour nous assurer que les produits peuvent faire face au volume de trafic attendu et des audits de sécurité pour nous assurer que les données de nos clients sont protégées, ce qui est une priorité pour nous.
Lancement : La mise en œuvre est essentielle au cours de cette phase. Lorsque nous lançons notre plan de mise sur le marché, il est important de réfléchir à ce qui va influencer notre approche de lancement et à l'incidence qu'elle peut avoir sur notre portée technique. Au cours de la phase de lancement, nous travaillons également en étroite collaboration avec les équipes commerciales et marketing et surveillons de manière rigoureuse les statistiques de lancement, souvent en temps réel. Ainsi, nous pouvons nous assurer d'atteindre nos objectifs et d'identifier rapidement tout problème à résoudre. L'une des principales leçons que j'ai apprises au fil du temps, c'est l'importance d'être flexible au cours de cette phase. Quelle que soit la qualité de votre planification, il y aura toujours des surprises. La capacité à effectuer une transition rapide en fonction des données et des retours issus du monde réel est essentielle.
Après le lancement : Le travail ne s'arrête pas après le lancement. Nous continuons à surveiller les statistiques de réussite à long terme et recherchons des signaux « Jour 2 » qui pourraient indiquer que nous perdons de vue ce qui compte vraiment pour nos produits. Parmi ces signaux, on peut citer le fait pour nos équipes de trop vouloir atteindre certaines statistiques ou certains objectifs aux dépens de ce qui compte vraiment pour les clients ou l'entreprise. Un autre exemple est celui d'une équipe qui mettrait trop l'accent sur la création de processus et de mécanismes, mettant à mal la créativité et l'agilité. Bien que ces mécanismes soient importants et constituent un aspect essentiel de notre fonctionnement chez Amazon, ils doivent permettre de progresser, pas nous empêcher de le faire.
Itération et évolution : Lors de cette dernière étape, nous utilisons les données post-lancement pour valider notre hypothèse d'origine ou déterminer si nous avons besoin de modifier ou d'ajuster notre vision. Par exemple, la demande des clients en faveur de notre produit ne correspond peut-être pas à nos attentes, ou alors ils ne comprennent peut-être pas la proposition de valeur du produit. Nous intégrons ces découvertes aux versions futures du produit, ainsi qu'aux autres produits que nous créons au sein de notre portefeuille. Nous communiquons avec les clients et analysons l'utilisation des données pour obtenir des retours sur le produit et nous assurer de répondre à leurs préoccupations et aux lacunes du produit lorsque nous prévoyons les améliorations futures.

Apprentissages sur le cycle de vie du produit

À mesure que nous affinions notre approche de ces cinq phases au fil des ans, nous avons obtenu des données précieuses sur le cycle de vie du produit au sens large :

Le cycle de vie est rarement linéaire : Nous présentons ces étapes les unes à la suite de l'autre, mais, en réalité, elles se chevauchent et se répètent souvent. Une fonctionnalité peut être en phase de post-lancement pendant que nous sommes en phase de pré-développement de la suivante.
Les besoins des clients évoluent rapidement : Ce qui était avant-gardiste l'année dernière peut devenir un enjeu important aujourd'hui. Nous avons appris à intégrer la flexibilité dans nos visions à long terme afin de nous adapter à l'évolution de la dynamique du marché.
Les données sont essentielles, mais le contexte est d'autant plus important : Même si nous sommes orientés sur les données, nous avons appris que les chiffres seuls ne suffisent pas. Comprendre le contexte associé aux données entraîne souvent des innovations révolutionnaires.
Éviter d'avoir à penser au Jour 2 commence dès le Jour 1 : Nous avons découvert que planifier la réussite sur le long terme et éviter les pièges potentiels dès le départ donne naissance à des produits plus durables.
La rapidité compte, mais elle ne doit pas se faire au détriment de la qualité : Même si notre objectif est d'agir rapidement, nous avons appris à nos dépens que nous précipiter en lançant un produit imparfait peut nuire à la confiance des clients.
Les idées les plus percutantes viennent souvent d'endroits inattendus : Certaines de nos meilleures améliorations de nos produits proviennent de tickets envoyés par des clients au support ou de commentaires reçus dans le cadre de nos sessions de tests utilisateurs.

Ces données ont non seulement façonné la façon dont Amazon aborde chaque étape du cycle de vie du produit, mais a aussi renforcé l'importance de la collaboration interfonctionnelle tout au long du processus. Cet esprit de collaboration n'est pas seulement un avantage, il est essentiel à la façon dont nous fonctionnons et innovons. Chez Amazon Ads, nous ne suivons pas le modèle formel RACI (responsible, accountable, consulted and informed, en français « réalisateur, approbateur, consulté, informé ») à la lettre. Nous avons plutôt mis en place des directives qui favorisent l'investissement personnel et la responsabilité :

Les chefs de produit s'occupent du « quoi ».
Les ingénieurs sont chargés du « comment ».
Et les TPM sont responsables du « quand ».

Ces règles ne sont toutefois pas rigides. Notre culture encourage chacun à apporter sa contribution au-delà de ses responsabilités principales afin de promouvoir l'innovation et la résolution rapide des problèmes.

L'évolution se poursuit

Créer des produits chez Amazon Ads est un processus en constante évolution : nous apprenons sans cesse de nos clients et de leurs attentes. Nous nous efforçons constamment d'innover et, à ce titre, de proposer des expériences qui ravissent nos clients.

Dans le prochain article Élever le niveau de la gestion de produits, l'un de nos directeurs PMT parlera de comment influencer sans autorité.

En attendant, apprenez-en plus sur nos rôles de gestion de produit.