Le rôle du chef de produit a été créé à l’origine pour gérer la complexité des lignes de produits d’une entreprise, ainsi que pour s’assurer que ces produits étaient rentables. Les chefs de produit peuvent provenir de nombreux horizons différents, car leurs compétences principales impliquent de bien travailler avec les clients et de comprendre les problèmes que le produit est censé résoudre.
Un chef de produit est chargé d’orchestrer les diverses activités associées à la livraison d’un produit qui répond aux besoins des utilisateurs. Le rôle d’un chef de produit logiciel varie au fur et à mesure que le logiciel avance dans son cycle de vie ; plus tôt dans le processus de développement, le chef de produit rencontre le public visé par le produit pour s’engager dans l’élicitation des exigences, tandis que plus tard dans le cycle de vie, le chef de produit peut se concentrer principalement sur les tests d’acceptation du produit. À toutes les étapes du processus de développement du produit, le chef de produit représente les besoins des utilisateurs finaux, évalue les tendances du marché et la concurrence, et utilise ces informations pour déterminer les caractéristiques à construire. Par exemple, un chef de produit peut décider qu’une fonctionnalité est nécessaire parce que les utilisateurs la demandent, ou parce que cette fonctionnalité est nécessaire pour rester compétitif. Afin de faciliter ce processus de prise de décision, le chef de produit peut définir une vision du produit ou un cadre général pour la prise de décisions concernant le produit. Le chef de produit assure également une atmosphère de cohésion et de collaboration ciblée entre tous les membres de l’équipe, dans le but de faire avancer le produit. On pense souvent que les chefs de produit sont assis à l’intersection des affaires, de la conception et de la technologie.
Dans un environnement de développement logiciel agile, des responsabilités similaires sont assumées par un propriétaire de produit, un rôle de projet qui peut être rempli par un chef de produit qui est le rôle correspondant dans une organisation. Alors que le gestionnaire de produit a une perspective stratégique et à long terme avec un fort accent sur le succès commercial d’un produit, un propriétaire de produit vise à maximiser la valeur commerciale du produit ou de l’incrément créé par un projet agile qui peut inclure des avantages au sein d’une organisation et ne se rapporte pas explicitement à la possibilité de commercialisation d’un produit. Par conséquent, un propriétaire de produit se concentre principalement sur le développement d’un produit alors qu’un gestionnaire de produit a une perspective plus holistique. Une autre différence est l’orientation temporelle des deux rôles : un projet est limité dans le temps, ce qui limite la responsabilité d’un propriétaire de produit dans un projet à la durée de ce dernier. Le rôle de chef de produit, en revanche, exige une perspective à long terme et n’implique souvent aucune échéance. Le rôle de propriétaire de produit dans un projet peut être exercé par une personne ayant un rôle de chef de produit dans l’organisation, ce qui peut contribuer à assurer une mise en œuvre réussie des considérations stratégiques pendant le développement opérationnel d’un produit.
Les responsabilités quotidiennes d’un propriétaire de produit/gestionnaire de produit au sein d’un projet agile comprennent la création et la hiérarchisation du backlog de produit, qui est une liste de choses à faire par l’équipe de développement, afin de maximiser la valeur commerciale créée par le projet. Le backlog de produit est souvent composé d’histoires d’utilisateur, « un espace réservé pour une conversation entre le gestionnaire de produit… et l’équipe de développement. » Il s’agit de brèves descriptions narratives de ce qu’une fonctionnalité doit faire, y compris une liste de contrôle des éléments qui doivent être en place pour que la fonctionnalité soit considérée comme terminée, appelée critères d’acceptation. Les détails du développement de la fonctionnalité sont élaborés par les développeurs et les concepteurs. À la fin du sprint de développement, le responsable de produit est chargé de vérifier que les critères d’acceptation ont été respectés ; ce n’est qu’à ce moment-là que le travail sur la fonctionnalité est officiellement terminé.