Le Product Owner

Product Owner

Le Product Owner est chargé de la conception d'un produit. Mais comment fait il ?Penchez-vous sur toutes les spécificités de ce métier.

START

Index

En quoi consiste ce métier ?

Quels rôles et responsabilités?

ses participations

l'agilité à l'echelle

Notions bonus

liens utiles

quelles qualités ?

01 Quelles qualités ?

Le Product Owner est un pillier au sein de l'equipe, mais quelles sont les qualités essentielles pour devenir Product Owner ?

Ses qualités

Quelles sont qualités essentielles pour un Product Owner ?

> Savoir questionner son client sans idée préconçue : Le Product Owner ou PO est curieux, et a une bonne compréhension du Business. De facto, il sait questionner pertinemment les utilisateurs et doit s'assurer d'un bon feedback. > Savoir négocier avec le client et avec l'équipe : pour trouver les bonnes solutions, il doit avoir des aptitudes de négociation pour exprimer les possibilités que peut offrir l'équipe.> Savoir faire preuve de fléxibilité et savoir communiquer : Il doit être disponible et posséder un talent naturel de communiquant. Il sait s'exprimer clairement avec toutes les parties prenantes

Info

Il ne suffit pas de poser des questions à son interlocuteur, encore faut-il savoir poser les bonnes questions au bon moment ! La questiologie peut alors venir en aide au Product Owner, pour en savoir plus rdv dans les Notions Bonus.

Ses qualités

> Savoir cultiver et entretenir sa relation avec le client : il doit doit entretenir la relation avec le demandeur tout au long du projet et fait preuve d'assertivité et de réalisme. Il est également optismiste quant à la réussite de l'équipe de developpement.

> Savoir exprimer ce qui va ou pas : lorsque c'est nécessaire le PO est en capacité de dire ce qui va ou ne va pas afin d'effectuer des équilibrages. A l'inverse, il doit aussi être capable de valoriser le travail produit par son équipe.

> Posséder des connaissances dans son domaine d'activité : même s'il ne produit pas lui-même, le PO doit avoir des notions et une certaine sensibilité à la technologie. C'est avec ses connaissances qu'il pourra activer les leviers afin d'aider l'utilisateur à se projeter.Même si le Scrum Master est là pour l'aider, il est préférable qu'il ait une bonne connaissance du management de projet et de la méthode Scrum.

Ses qualités

> Savoir faire des analyses de données : une autre qualité est de savoir faire des analyses de données (KPI), leur synthèse pourra être utilisée par les équipes de developpement afin de driver leur travail.Bien entendu, le PO connait son produit sur le bout des doigts.> Savoir véhiculer les valeurs Scrum : ces dernières sont inhérents aussi bien à l'équipe qu'au PO qui

• est Focus sur les attentes de ses users
• Fais preuve de courage en défendant ses points de vue. Il sait à ce titre dire non sans difficulté, en fonction des contraintes contextuelles
• Fais preuve d'ouverture en laissant place au changement et en s'adaptant
• Fais preuve d'engagement aussi bien envers le client, qu'envers son équipe et le projet.

02 Quels rôles et responsabilités ?

Le Product Owner est détenteur de la vision globale du produit, mais comment fait-il ?

02 Quels rôles et responsabilités ?

Le rôle de Product Owner (ou PO) peux évoluer en fonction de l'environnement, il assume généralement plusieurs résponsabilités clés, allant de la stratégie au design du produit. Il doit maximiser la valeur du produit et sa valeur commerciale grâce à une gestion continue du Backlog.Mais qu'est de qu'un PO ?Fondamentalement, un PO Agile ou Scrum est chargé de maximiser la valeur des produits crées par une équipe de développement Scrum. Pour ce faire, il endosse plusieurs rôles, notamment celui de strastège, de designer, d'analyste de marché, d'agent de liaison avec les parties prenantes.

En résumé, il fait partie intégrante de toute l'équipe Scrum.

Le PO dirige de nombreuses facettes du développement de produit. Certains jours il doit se servir de sa connaissance pointue du marché pour élaborer une stratégie et présenter sa vision aux parties prenantes. Le lendemain, c'est à son tour de retrousser ses manches pour aider l'équipe à atteindre ses objectifs au cours du Sprint.

+ info

Ses rôles et responsabilités

Le Product Owner est un vrai caméléon funambule, mais quels sont ses rôles et responsabilités ?

1/ Définir la vision :Il est l'interlocuteur principal de l'équipe de développement. Il utilise sa perspective globale pour définir des objectifs et créer une vision pour les projets de développement.Il est chargé de communiquer avec toutes les parties prenantes, notamment les clients, les responsables métier et l'équipe de developpement, afin de s'assurer que les buts sont clairement définis et que la vision est conforme aux objectifs fixés.Disposer d'un PO avec une perspective globale permet à l'équipe de preserver une vision cohérente malgré la nature flexible et généralement rythmée du développement de produit AgileLe PO pourra aider l'équipe à maintenir cette vision en créant un Roadmap Product.

Le Roadmap Product est une synthèse visuelle stratégique qui décrit la vision et l'orientation de l'offre produit au fil du temps. Il s'agit à la fois d'un guide stratégique auquel les parties prenantes peuvent se référer et d'un plan d'exécution pour l'équipe de développement. Pour savoir comment faire un Roadmap Product, rdv dans les Notions Bonus.

+ info

Ses rôles et responsabilités

2/ Gérer le Backlog ProductL'une des plus grandes responsabilités d'un PO est la gestion du Backlog Product. Le Product Owner est chargé de créer la liste des élèments qui compose le Backlog et de les classer par ordre de priorité en fonction de la stratégie globale et des objectifs.En outre, le PO devra déterminer les dépendances du projet afin de définir le plan de développement à suivre.Le Backlog n'est pas pour autant une simple liste de tâches. Il s'agit d'un document dynamique qui doit être continuellement actualisé en fonction de l'évolution des besoins du projet tout au long du developpement.Il est amené à changer fréquemment, le Product Owner doit veiller à ce que la liste soit accessible et disponible pour toutes les parties prenantes et en particulier les développeurs afin de garantir les résultats du projet.

Un Backlog Product correspond pour l'essentiel à une liste de tâches à effectuer par l'équipe de développement. Il s'agit d'une série de travaux à accomplir dans le cadre d'un projet plus vaste. Il est important de noter qu'il ne s'agit pas d'éléments sur lesquels vous travaillez au cours du Sprint, mais il permet d'anticiper les tâches à venir afin que votre équipe puisse planifier et publier rapidement de nouvelles fonctionnalités. Pour en savoir sur le Backlog Product rdv dans les Notions Bonus.

+ info

Ses rôles et responsabilités

3/ Classer les besoins par ordre de prioritéAutre rôle clé du Product Owner, la hierarchisation des besoins. En d'autres termes, il doit jongler entre budget et temps, en pondérant les priorités en fonction des besoins et des objectifs des parties prenantes.

4/ Superviser les phases de developpementUne fois la vision, la stratégie et les priorités établies, le Product Owner doit consacrer une partie importante de son temps à superviser le développement du produit à proprement parler. Il joue un rôle central à chaque étape, notamment lors de la planification, de la rétrospective, de la Review et du Sprint.Pendant les phases de planification, le PO collabore avec les parties prenantes afin d'identifier et d'organiser les étapes requises pour la prochaine itération. Il se reunit ensuite avec son équipe pour affiner le processus, identifier les points à améliorer et encadrer le Sprint.

Le Backlog Refinement (ou affinage) est un processus qui consiste à détailler de manière suffisamment claires les tâches du Backlog Product, afin qu 'elles soient perçues comme des éléments d'actions et non comme des idées abstraites. Il existe 2 écoles de pensée en ce qui concerne le Backlog refinement : certaines équipes préfèrenet affiner tous les élèments d'un Backlog tandis que d'autres préfèrent "nettoyer au fur et à mesure". Au final un Backlog Product permet de simplifier considérablement votre Sprint Planning.

+ info

Ses rôles et responsabilités

5/ Anticiper les besoins clients :Un Product Owner doit être capable de comprendre et d'anticiper les besoins du client afin de gérer plus efficacement le processus de développement.Sa connaissance approfondie du marché et ses compétences en communication lui permettent d'anticiper les difficultés ou les attentes et d'y répondre.Gardez une longueur d'avance sur vos clients en cartographiant leurs parcours.6/ Agir comme référent principalLe PO constitue également l'interlocuteur et le lien principal entre les parties prenantes et les équipes. En tant que tel, il doit être expert en communication, s'assurer de l'adhésion à toutes les décisions et stratégies importante et veiller à ce que les instructions et les produits soient clairs pour les développeurs.

Une carte de parcours client vous permet de créer une vision commune de l'expérience client.Vous économiserez du temps et des efforts et pourrez consacrer toute votre énergie à résoudre les attentes et problème de vos clients. Pour en savoir plus, rdv dans les Notions Bonus.

+ info

Ses rôles et responsabilités

7/ Evaluer l'avancement du produit à chaque itération :Le PO est responsable de chaque phase du processus de développement ainsi que du produit final.Il joue un rôle primordial en inspectant et en évaluant l'avancement du produit à chaque itération.C'est à lui qu'il revient de juger de la performance et de décider si l'équipe doit revoir sa copie ou si elle peut passer aux étapes suivantes.8/ Protéger l'équipeLe Product Owner accompagne son client à chaque étape de l'élaboration du projet afin de s'assurer que l'équipe est toujours dans la direction souhaitée.Il est à proscrire le fait de délivrer les nouvelles données du client lorsqu'un Sprint est déjà en cours. On ne doit pas déconcentrer l'équipe qui est déjà en train de concevoir le MVP.Le Product Owner veille donc à la protection de la concentration de l'équipe, toutes les demandes passent par lui.

Le MVP (ou Minimum viable Product) est une 1ère version d'un produit limité au stricte minimum de sa forme et de ses fonctionnalités. Son but est de permettre le développement et la livraison rapide d'un produit, afin que les utilisateurs puissent l'utiliser très vite. Plus d'informations dans les Notions Bonus.

A retenir

Les Product Owners donc plusieurs casquettes, ils s'adaptent aussi rapidemment que leurs rôles évoluent.

03 Quelles participations ?

Le Product Owner est au centre de chaque cycle de développement. Mais dans quelles activités est-il impliqué ?

+ info

+ info

Ses participations

Le Sprint

Le Product Owner s'assure que l'équipe a bien compris les objectifs, le domaine et la portée du produit. Il suit la progression des développement et peut intervenir en cas de changement de trajectoire.

Le Refinement

Le product Owner passe en revue avec l'équipe, les tâches qui sont pour lui les prochaines à prendre dans les sprints suivants. Il s'assure que le besoin et compris et précise avec les développeurs les tâches si elles ne le sont pas suffisamment pour l'équipe.Ce rituel vient compléter le rôle de rédacteur d'US du Product Owner.

Un sprint à une durée définie de 1 semaine à 1 mois (la norme commune est de 2 semaines) et se déroule ainsi :

• Le démarrage du sprint débute à J1 avec le Sprint Planning
• Un Daily quotidien est tenu durant le Sprint
• A J14 se déroulent le Sprint Review et la Sprint Rétrospective.
• Les sprints se succèdent, un nouveau sprint débute dès que l'actuel prend fin.
• Tous les évènements sont inclus dans un sprint.

Ce qui n'existe pas :

• Le Sprint 0
• Pas de phase spécifique à l'intérieur d'un Sprint
• Pas de Sprint spécialisé sur les corrections ou bugs (ils sont embarqués dans les sprints comme les nouvelles fonctionnalités et évolutions).

Le Refinement Scrum est une pratique qui permet d'affiner le Product Backlog. Cette pratique est également appelée Product Refinement ou Grooming de Backlog. Elle consiste à s'assurer de la pertinence du Product Backlog pour les prochaines itérations (Sprints) et permet de mieux se préparer au PI Planning (Framework Safe) ou le Sprint Planning. L'objectif est d'affiner la liste des tâches à réaliser pour le projet. Cette activité permet de s'assurer de la clarté du Backlog et de sa priorisation. Le Backlog Refinement est une activité collaborative impliquant l'équipe au complet.

+ info

+ info

+ info

Ses participations

La Review

La revue de sprint est un événement Scrum rassemblant l'équipe Scrum (Product Owner, Scrum Master, Equipe de développement) et les parties prenantes du projet.L'objectif est d'inspecter le travail réalisé dans le cadre du sprint, d'obtenir du feedback et de discuter de la suite du projet.En tant que membre de l'équipe le PO y joue plusieurs rôles importants.

La rétrospective

La rétrospective de sprint, ou sprint retrospective, est une réunion destinée à l'amélioration continue, qui clôture le sprint.C'est l'occasion pour l'équipe Scrum d'inspecter le déroulement du dernier sprint et de trouver des axes d'amélioration à implémenter lors des prochains sprints, afin de continuellement s'améliorer.La participation du PO intervient dans le cadre de sa qualité de membre de l'équipe.

Le Sprint Planning

L'ensemble de l'équipe Scrum (Product Owner, Scrum Master, et équipe de développement) se réunit lors du sprint planning, et travaille de manière collaborative pour construire un plan d'action cohérent sur la durée du sprint, et permettant d'atteindre un sprint goal. Le sprint planning est une réunion animée par l'équipe. Ce n'est pas le Product Owner qui dicte aux membres de l'équipe de développement quoi faire dans ce sprint. Il propose un objectif de sprint à l'équipe et lui donne du sens.Le PO a un rôle crucial dans ce rituel.

Sa durée est de 4h maximale pour un Sprint de 1 mois La Sprint Review est une session de travail non une simple démonstration. Elle demande donc une préparation organisée entre les développeurs, et le product Owner avec l'aide du Scrum Master. En tant que responsable et propriétaire du produit, le PO y a les rôles suivants :

• Rappeler l'objectif de sprint.Le Product Owner ouvre la revue de sprint en rappelant quel était l'objectif de sprint à atteindre, et indique si celui-ci a été atteint ou pas.
• Présenter l'état actuel du produit.Il présente alors le travail réalisé et terminé pendant le sprint, par le biais de l'incrément de sprint. Il est possible de réaliser une courte démo pour montrer cela à l'ensemble des parties prenantes, mais ce n'est pas obligatoire.
• Expliquer les décisions prises.Il explique également à tous les choix qui ont été faits pendant le sprint, et pourquoi ceux-ci ont été pris.
• Exposer les évolutions envisagées pour les futurs sprints.Il explique aux participants les évolutions futures du produit qui sont envisagées, et propose l'objectif du prochain sprint. C'est l'occasion d'avoir des échanges avec les parties prenantes, sur la valeur apportée par telle ou telle fonctionnalité, et sa priorité.
• Répondre aux questions des parties prenantes.Enfin, le Product Owner répond aux questions des différentes parties prenantes quant au produit, au product backlog et à ses évolutions futures.

Sa durée est de 3h maximale pour un Sprint d'un mois. Elle est préparé par le Scrum Master afin de permettre une participation positive de l'équipe. Tout comme les autres membres de l'équipe, le Product Owner participe également activement à la rétrospective de sprint. Il agit et intervient ainsi au même niveau que les membres de l'équipe de développement. Il participe donc aux discussions concernant le déroulement du dernier sprint et choisit également (de manière collaborative) les axes de progrès à mettre en œuvre lors des prochains sprints.

La réunion du Sprint Planning dure au maximum 8h pour un Sprint de 1 mois (on ajuste donc la durée). Le rôle du Product Owner y est crucial, car :

• Il propose à l'équipe un objectif de sprint à atteindre.Le Product Owner propose à l'équipe un objectif de sprint en fonction du travail déjà accompli et des derniers feedbacks remontés lors de la dernière sprint review, afin d'améliorer le produit et de maximiser sa valeur.
• Il présente le Product Backlog ordonnancé selon la priorisation et la valeur des différents items le composant.Il montre et détaille à l'équipe de développement les différents éléments composant le Product Backlog à date, en commençant par ceux apportant le plus de valeur ou ayant un rapport avec l'objectif de sprint.
• Il porte la voix des parties prenantes du projet.Il est le porte-parole du client et des utilisateurs finaux, et explique à l'équipe pourquoi le travail à réaliser est important et ce que ça va apporter aux utilisateurs finaux du produit.
• Il échange et collabore avec l'équipe de développement.Il collabore avec les développeurs tout au long du sprint planning afin qu'ils puissent construire leur sprint backlog, déterminer quoi faire durant le sprint, ainsi que la meilleure manière de le faire.
• Il peut animer le sprint planning.Enfin, le Product Owner peut animer le sprint planning, bien que je ne le recommande pas, afin d'éviter de retomber dans un schéma classique du "product owner tout-puissant", qui dicte aux autres quoi faire.

+ info

+ info

Ses participations

Le Daily

En terme de participation, seule celle des développeurs est obligatoire. Celle du Scrum Master est souhaitable afin d'être le Time Keeper de ce rituel mais surtout pour s'assurer qu'il est bien lieu.Le Product Owner quant à lui n'a qu'une présence facultative selon le besoin de l'équipe.

Les tests et la mise en production

Le PO est le propriétaire du produit, à ce titre il a la charge d'inspecter et de valider les délivry. L’inspection et le contrôle recouvrent l’examen usuel d’un produit pour s’assurer qu’il répond à des critères spécifiques, le PO a donc la casquette de "testeur"Si la qualité et les performances sont validés alors le Product Owner autorise la mise en production.

Sa durée maximale est de 15 minutes (Time Box) Il est tenu tous les jours à la même heure et au même endroit pour éviter toute complexité inutile. Il permet au Product Owner de :

• Échanger et collaborer avec les membres de l'équipe de développement.C'est LE moment quotidien pour s'harmoniser en tant qu'équipe, et maintenir une dynamique de groupe. Mais ce n'est pas le seul moment d'échange : il ne faut pas attendre le daily Scrum pour remonter une alerte ou pour travailler ensemble.
• Inspecter le Scrum board.C'est l'occasion d'inspecter le travail en done (fini à 100% selon la definition of done), d'inspecter les user stories en cours de réalisation, et de vérifier que le travail mené correspond bien à l'objectif de sprint.
• Adapter le plan pour atteindre l'objectif de sprint.Le daily Scrum permet à l'équipe de développement d'adapter son plan d'action pour les prochaines 24 heures dans l'optique d'atteindre l'objectif de sprint. Ce devrait d'ailleurs être son unique objectif.

L’évaluation du produit, peut être effectuée par des tests et des essais qui permettent de déterminer une ou plusieurs caractéristiques d’un produit. A la suite de ce contrôle, le Product Owner remplira le PV (Procès Verbal) de livraison, soit par :

• Un Go sans réserve
• Un Go sous réserve
• Un no Go (dans ce cas l'équipe doit revoir sa copie)

Il est conseiller en cas de livraison de toujours prévoir avec l'équipe un plan de Rollback, qui permettra de retirer la livraison de la production sans dommage.

04 L'agilité à l'échelle

Qu'est ce que l'agilité à l'échelle ? et surtout quel impact pour le Product Owner ?

+ info

L'agilité à l'échelle

L'agilité à l'échelle, également appelée Agile@scale correspond à la mise en place d'un cadre qui permet à plusieurs équipes Agiles de travailler ensemble autour d'un même ou de plusieurs produits.Cela implique la création d'une organisation permettant à différents services de s'aligner sur un objectif commun, tout en déployant les principes et valeurs de l'agilité.Le rituel le plus connu est le PI Planning.L’agilité à l’échelle permet une meilleure réactivité sur les tâches importantes, une meilleure gestion des équipes et la mise en place de process innovants qui permettent une évolution continue.L'agilité à l'échelle Le Product Owner y a un rôle important, car il est également responsable de la communication avec les autres équipes agiles pour s’assurer que le travail est coordonné et que les dépendances sont gérées efficacement.

Le PI planning (Program Increment planning) est une réunion de planification qui se déroule à intervalles réguliers (généralement tous les trois mois) dans le cadre de l’agilité à l’échelle. Cette réunion de deux jours qui se déroule tous les trois mois, permet aux équipes agiles de planifier et de coordonner leur travail pour le prochain programme incrémental. On parle alors d'être dans le "même train".

Les Notions Bonus

Quelques notions et outils qui deviendront vite des réflexes !

START

NEXT

La Questiologie

La Questiologie est un outil qui permet de concevoir des questions inédites – au-delà de simples questions ouvertes/fermées – en fonction de la situation et de l’interlocuteur, et ainsi d’acquérir « l’art et la science de poser la bonne question au bon moment »Cette méthodologie développe une capacité d’analyse du dialogue pour choisir ses questions, apporte un savoir et un savoir-faire uniques, et renforce un savoir-être d’écoute perspicace.Elle permet notamment de diversifier ses questions et donne une grille de lecture pour sélectionner la plus adéquate en fonction de la situation, de la relation et de son interlocuteur. Riche de toutes ces alternatives, on gagne une écoute plus sereine, plus confiante... on booste son agilité relationnelle. Poser la bonne question au bon moment enclenche des réponses pertinentes, créatives, adéquates… et révèle des trésors de co-élaboration et de co-construction.La questiologie se révèle être complémentaire des techniques modernes comme la sémantique, la linguistique, la PNL, la systémique…Voici quelques vidéos qui vous aiderons à mieux l'appréhender :Qu'est ce que la questiologie L'art de poser les bonnes questions

NEXT

La Roadmap

La Roadmap est une feuille de route qui permet la planification à partir de différents objects et aspects : tels que les technologies ou les produits, leurs connexions au fil du temps ainsi que des différentes stratégies commerciales ou opérationnelles.C'est un cadre temporel qui aide l'équipe à s'assurer qu'ils auront les moyens de mener à bien leur stratégie. La Roadmap relie les données stratégiques de l'entreprise et du marché avec les décisions de produits et de technologies, afin d'inviter l'équipe à être précise sur les caractéristiques et performances prévues en terme de besoin client. C'est un outil de prévision qui sert à révéler les dépendences et les lacunes dans les plans de produits.Grâce à la Roadmap ils deviennent immédiatement apparents et peuvent être corrigés avant de devenir de vrais problèmes.C'est un outil qui permet de fixer des objectifs plus compétitifs mais surtout plus réalistes dans le domaine concurrentiel.La Roadmap fournit un guide à l'équipe, lui permettant de reconnaitre et d'agir sur des changements de direction éventuels.

NEXT

Le Backlog Product

définition

Importance

création

contenu

organisation

composition

Un Backlog produit est une liste de tâches qui représente la série de travaux a accomplir pour la réalisation d'un projet. Il n'est pas uniquement constitué des éléments pris dans le Sprint en cours, mais il permet d'anticiper et de planifier.

Le Backlog Product est une liste de tâches qui correspond à une série de travaux à accomplir dans le cadre d'un projet. Il permet d'anticiper les tâches à venir et de planifier à plus long terme que le Sprint en cours.

Il permet au PO et à l'équipe d'apporter des améliorations méthodiques et intelligentes à un produit sur une période longue. Il est important qu'il : soit organisé, facile à gérer, puisse être facilement priorisé, modifiable, permette de visualiser les dépendances.

Chaque élément contenu doit apporter de la valeur, être classé par priorité et avoir été évalué. Il contient les fonctionnalités, les fonctions, les exigences, les améliorations et les correctifs.

Etapes pour élaborer le backlog : > Ajouter les idées pertinentes > Obtenir des précisions sur le besoin et sa valeur, pour clairement définir les éléments > Classer du plus prioritaire (en haut) au moins prioritaire (en bas) > Actualiser régulièrement

> Les éléments hautement prioritaires doivent être affinés et présenter une grande valeur pour le produit. > Les moyennement prioritaires doivent être candidats au refinement > Les faiblement prioritaires ne doivent pas constituer de dépendances et peuvent être ignorés jusqu'à ce qu'ils soient candidats au refinement.

Selon Scrum, il est composé de tous les éléments devant être inclus dans le produit. Il contient donc des retours d'informations de la part de l'équipe de développement, des clients et des parties prenantes.

NEXT

La cartographie du parcours client

Steeve Jobs a déclaré " Il faut commencer par l'expérience client et remonter vers la technologie et non l'inverse".Une carte du parcours client est une représentation visuelle de l'expérience d'un client. Elle décrit les différentes phases d'interaction, les moments clés et les impressions de celui-ci (frustration, confusion....). Ces cartes permettent de mieux comprendre ce qui motive sa prise de décision.Pour la réaliser il est important de définir votre objectif, d'établir votre personae, de décrire les points de contacts (web/magasin/service....), de modéliser l'état actuel et l'état futur.Il est préférable de se limiter à un seul personae et un seul scénario à la fois.Elles permettent de :

• Renforcer l'engagement client par l'optimisation des canaux
• Identifier et exploiter les moments de vérité dans l'expérience utilisateur
• Eliminer les points de contact improductifs
• Passer d'une perspective centrée sur l'entreprise à une approche centrée sur le client
• Supprimer le cloisonnement et combler des lacunes entre différents services
• Cibler des personnes spécifiques pour des campagnes marketing
• Comprendre les circonstances qui ont pu produire des anomalies dans les données quotidiennes
• Assigner des responsables, pour les différents points de contacts afin de stimuler l'implication des employés
• Evaluer le retour sur investissement des projets d'interface utilisateur/expérience client.

NEXT

Le MVP

Largement utilisé dans les projets Agiles, le MVP est un "1er brouillon" d'un produit qui est utilisable.En effet, selon une étude faite en 2014, le groupe Standish a observé que seulement 20% des fonctionnalités sont fréquemment utilisées par les clients et qu'à contrario 50% ne le sont pratiquement jamais.En se reposant sur cette étude et le manifeste Agile, il est conseillé d'appliquer le principe de PARETO et de se concentrer sur les 20% de fonctionnalités qui rapportent 80% de la valeur du produit. Ce principe vous aidera également à prioriser les fonctionnalités d'un produit.Les fonctionnalités développées et non-utilisées constituent un gaspillage de ressources de développement. Un produit viable, lui répond aux demandes des utilisateurs en remplissant une fonction principale et se suffit des fonctionnalités réduites au minimum.Le plus risqué dans le lancement d'un produit, n'est pas la technologie mais si les clients sont prêts à l'utiliser. Confronter son idée à la réalité est donc le seul moyen de savoir si le produit est un succès et s'il mérite d'y investir plus de temps et plus d'argent dans son amélioration.

Les liens Utiles

C'est quoi Product Owner ?

5 conseils sur le Product Backlog et le Product Goal

Le Refinement

Cest quoi l'incrément ?

La Roadmap Agile

Lean

Comment découper les Users Stories ?

Félicitations !

Vous faites désormais partie de la Ligue des Super Product Owners.