chef de Produit vs Propriétaire du Produit

c’est une question intéressante et qui prend du temps à déballer. Regardons d’où proviennent ces Termes et disciplines et comment certains cadres communs les expliquent.,

quand j’ai commencé ma carrière, on m’appelait analyste D’Affaires. J’ai fait très peu d ‘” analyse commerciale  » comme nous l’examinerions dans les entreprises informatiques traditionnelles. Honnêtement, j’ai fait très peu de ce que j’enseigne en tant que Gestion de produits maintenant. J’ai été chargé de rassembler les exigences des ventes, de trouver une solution, de la concevoir, puis d’expédier le document de spécification au développement à construire.

j’ai continué à être appelé Analyste commercial alors que je travaillais dans des banques et d’autres sociétés de services financiers. Je n’ai pas été appelé un chef de produit jusqu’à ce que je renfloué de cela et atterri dans une start-up., C’était tout le même travail que j’avais fait auparavant, mais maintenant il avait un nom différent. J’ai aimé ce nom. « Chef de produit » semblait avoir gravité à elle, et quand je regardais d’autres entreprises de technologie dans la vallée, je pouvais voir un cheminement de carrière clair taillé pour moi alors que les analystes D’affaires étaient différents à chaque entreprise.

je n’avais entendu parler du terme Product Owner que des années plus tard. La première fois que j’ai entendu le terme, j’ai demandé à quelqu’un ce que cela signifiait. Ils m’ont dit que c’était la même chose qu’un chef de produit, mais c’était un terme utilisé dans Scrum., Nous utilisions Scrum depuis des années, mais j’étais toujours appelé chef de produit, donc le fait qu’ils soient interchangeables était logique pour moi. J’ai rarement pensé par la suite.

c’était jusqu’à ce que j’aie ma première expérience dans l’enseignement de la gestion de produits dans une entreprise utilisant le framework SAFe. Je faisais un atelier pour une très grande banque quand l’un des participants a sonné.

« Vous nous apprenez à parler aux utilisateurs, mais je suis un Product Owner. Le chef de Produit parle à tous les utilisateurs et nous dit quelles sont les exigences., Je passe tout mon temps à écrire des histoires d’utilisateurs à partir de celles-ci et à travailler avec l’équipe pour exécuter la solution. Je suis confus. »

C’est à ce moment que j’ai commencé à creuser les différences entre ces deux rôles et comment différentes philosophies les enseignent. Afin de comprendre comment nous sommes arrivés ici

la gestion des produits remonte à 1931. Hewlett Packard a été l’une des premières entreprises technologiques à mettre en œuvre ce travail et à s’organiser par produits dans les années 1940., La plupart des entreprises de la Silicon Valley ont eu des chefs de produit depuis le début, et beaucoup de mes amis qui y ont travaillé dans les années 80 et 90 étaient en effet, chefs de produit. Cette discipline n’est donc pas nouvelle, mais elle évolue rapidement à mesure que de plus en plus d’entreprises se tournent vers des organisations logicielles et commencent à se structurer autour de produits.

Scrum est entré en scène juste avant la rédaction du Manifeste Agile en 2001. Il a introduit le concept de propriétaire de produit. C’était une personne qui était un proxy pour le client et dirait que les développeurs les exigences pour ce qui devait être construit., Au début, lorsque de nombreux créateurs de ces processus travaillaient en tant que consultants dans des entreprises, le Product Owner était le client — une personne interne de l’entreprise qui s’asseyait avec l’équipe et donnait la priorité au retard de travail. En fait, les objectifs d’apprentissage 2017 de leur certification Certified Scrum Product Owner par Scrum Alliance indiquent: « enseignez que le rôle du Product Owner est généralement joué par le client, ou le représentant du client, tel qu’un chef de produit., »

lorsque vous examinez le rôle du Product Owner dans la plupart des publications Scrum, leurs trois principales responsabilités sont les suivantes:

• définir le Backlog produit et créer des user stories exploitables pour les équipes de développement. (Qui crée les user stories varie en fonction de la formation Scrum)
• Groom et prioriser le travail dans le backlog.
• acceptez les user stories complétées pour vous assurer que le travail remplit les critères.,

alors que les programmes changent entre les enseignants et les organisations, ce sont les choses qui sont principalement axées sur les cours de deux jours pour certifier les propriétaires de produits. Alors que Scrum a beaucoup d’informations sur les processus et les rituels de ce qu’il faut faire en tant que Product Owner, il laisse beaucoup de questions qui sont importantes pour créer des produits réussis sans réponse. Ceux-ci sont principalement centrés sur « Comment savons-nous que nous construisons la bonne chose?”

c’est là que la gestion des produits entre en jeu., Un bon chef de produit apprend à hiérarchiser le travail par rapport à des objectifs clairs axés sur les résultats, à découvrir et à valider la valeur réelle du client et de l’entreprise, et quels processus sont nécessaires pour réduire l’incertitude quant au succès du produit sur le marché.

Sans cette expérience dans la gestion de produits, quelqu’un peut effectivement passer par les mouvements du rôle de propriétaire de produit dans Scrum, mais il ne peut jamais réussir à s’assurer qu’il construit la bonne chose.,

Si vous enlevez votre équipe Scrum, si vous enlevez Scrum en tant que processus pour votre organisation, vous êtes toujours un chef de produit. La gestion des produits et Scrum fonctionnent bien ensemble, mais la gestion des produits ne dépend pas de Scrum. Il peut et doit exister avec n’importe quel cadre ou processus.

j’ai récemment eu un propriétaire de produit dont les développeurs ont été déplacés vers une autre partie de l’organisation, car ils craignaient de ne plus pouvoir être une personne de produit dans cette entreprise. Leur identité entière apparemment articulée sur avoir une équipe de développeurs.,

en tant que chef de Produit, vos rôles et responsabilités changeront en fonction de votre contexte et de l’étape de votre produit. Sans une équipe Scrum ou avec une équipe plus petite, vous pourriez faire plus de travail de stratégie et de validation avec la découverte de problèmes dans un produit qui n’a pas encore été défini. Avec une équipe Scrum, vous pouvez être plus concentré sur l’exécution des solutions. En tant que chef de produit, vous pourriez diriger la stratégie pour une plus grande partie du produit et entraîner vos équipes à découvrir et à bien exécuter.,

le cadre SAFe enseigne cela différemment, et je pense que c’est l’un des points les plus faibles de tout le cadre. Dans SAFe, Les chefs de produit sont les gestionnaires des propriétaires de produits et sont responsables des interactions et du travail externes. Ils parlent aux clients, ils définissent les exigences et la portée des produits à construire, et ils le communiquent aux propriétaires de produits. Les propriétaires de produits sont internes, définissent les composants de la solution et travaillent avec les développeurs pour l’expédier.,

J’ai formé des dizaines d’équipes qui sont à l’aide de Coffre-fort et je n’ai jamais vu cela. Les propriétaires de produits sont déconnectés de leurs utilisateurs et incapables de créer pour eux des solutions efficaces qui résolvent vraiment leurs problèmes, car ils ne comprennent pas bien les problèmes., Les chefs de produit sont essentiellement waterfalling vers le bas les exigences pour eux et les équipes ne sont pas autorisés à prouver si ce sont les bonnes choses à construire ou non. Personne ne fait de travail de validation.

j’ai écouté de nombreux arguments selon lesquels les propriétaires de produits n’ont pas le temps de jouer les deux rôles. Dans le contexte actuel, c’est vrai. Les propriétaires de produits avec qui je parle passent 40 heures par semaine à écrire des histoires d’utilisateurs. À ce stade, vous devez vous demander, ces histoires d’utilisateurs sont-elles même précieuses? Quels sont-ils les priorités contre? Comment savent-ils que cela résoudra un problème?,

Si une personne passe autant de temps à écrire des histoires d’utilisateurs Chaque semaine, chaque semaine, vous tombez dans le piège de la construction — en vous concentrant sur la quantité d’articles que vous libérez et non sur la qualité.

avec un bon cadre stratégique en place et une hiérarchisation impitoyable autour de quelques objectifs clés, une personne peut efficacement parler aux clients, comprendre leurs problèmes et aider à définir les solutions avec l’équipe. Même le PDG de Scrum.org convient que cela peut être le cas, bien que, semble-t-il, à contrecœur., Scrum Inc dit également que le Product Owner devrait passer la moitié de son temps à parler aux clients et l’autre moitié à travailler avec l’équipe. Je ne suis pas à 100% à bord avec cette scission, mais la direction est bonne. La quantité de travail externe vs interne changera en fonction de la maturité et du succès de votre produit. Vous ne devriez jamais faire tout ce travail à la fois.,

j’enseigne à mes clients que les chefs de produit occupant des postes de direction (VPs ou Product Leads ou middle managers) se concentrent sur la définition de la vision et de la stratégie des équipes sur la base d’études de marché, d’une compréhension des objectifs et de la stratégie de l’entreprise, et en examinant l’état actuel Les chefs de produit sans équipes Scrum ou avec des équipes plus petites (un concepteur UX et un développeur, par exemple) aident à valider et à contribuer à cette stratégie pour les futurs produits. Une fois que nous avons validé la direction, nous créons de plus grandes équipes Scrum autour de ces personnes et développons des solutions.,

Il est important d’avoir cette flexibilité dans la taille de l’équipe ainsi selon le stade de votre produit. Si vous donnez à un chef de produit un grand backlog de l’équipe scrum pour continuer à remplir pendant que vous êtes en mode découverte, ils garderont ce backlog rempli. Mais, ils seront également déchirés entre garder le travail qui coule aux développeurs et essayer de faire le travail pour valider la direction. En conséquence, ni se fait bien.

Si vous voulez créer des produits qui créent de la valeur pour vos entreprises et vos clients, vous avez besoin de bonnes bases de gestion de produits dans votre entreprise., Si vous voulez un cheminement de carrière pour vos employés, vous devez leur donner cette base afin qu’ils puissent évoluer dans des rôles plus élevés. Alors rappelez à vos gens qu’ils sont tous des chefs de produit. Ils jouent peut-être le rôle d’un Product Owner dans une équipe Scrum la plupart du temps, mais nous avons encore besoin d’eux pour penser comme un chef de produit et valider que nous construisons les bonnes choses.

— —

Melissa Perri est la PDG de Produx Labs, une société de conseil qui aide les organisations à apprendre et à adopter de bonnes pratiques de gestion de produits et de Leadership de produits., Elle dirige une école en ligne pour les chefs de produit à Product Institute et pour les chefs de produit à CPO Accelerator. Elle est maître de conférences à la Harvard Business School.

ceci a été publié à l’origine le melissaperri.com