Obtenir des résultats produit à partir d'idées, de leur conception à leur livraison
Au sein de Jira Product Discovery, les « idées constituent le principal objet avec lequel vous travaillez dans votre backlog produit. Afin de soutenir un processus de validation et d'apprentissage continus, nous traitons les idées comme des objets durables. Une idée quitte le backlog au moment où le développement commence. Elle perdure néanmoins tout au long des itérations de découverte et de livraison, jusqu'à avoir l'impact attendu.
Les équipes produit performantes adoptent un état d'esprit expérimental. Elles réitèrent l'idée au fil du temps en y intégrant du contexte, le feedback des utilisateurs, des spécifications et des éléments de conception. À chaque étape du cycle de vie des idées, ces équipes évaluent ce qui a (ou n'a pas) fonctionné en répondant à des questions clés et en vérifiant leurs hypothèses, afin de s'assurer que leurs investissements sont alignés sur le feedback et les éléments de validation qu'elles reçoivent.
Grande ou petite, chaque idée compte
Même s'il est connu sous le nom d'« idées », l'objet utilisé dans Jira Product Discovery peut de fait représenter des idées de produits, des opportunités, des problèmes, des solutions, etc. Un backlog produit peut être conçu pour contenir des idées impliquant différentes formes et différents niveaux de granularité.
Il est important de définir ces catégories et d'obtenir l'accord de toutes les personnes participant au processus. Cela évitera que le backlog produit ne devienne un mélange de tâches, de la plus grande à la plus petite, sans aucun framework pour les classer et les comparer.
Rochers, pierres et cailloux : une seule façon de classer les idées
Au sein de l'équipe Jira Product Discovery, nous organisons les idées en trois niveaux : rochers, pierres et cailloux.
Rochers, pierres et cailloux.
- Rochers : un investissement important avec des bénéfices potentiels importants, mais également une grande incertitude
- Exemple : nouveau pari important, nouveau pilier de produit, grand projet d'ingénierie
- Pierres : des investissements de taille moyenne présentant moins de risques
- Exemple : nouvelles fonctionnalités, nouvelles expériences d'intégration, refontes en fonction du feedback
- Cailloux : petits investissements généralement simples
- Exemple : petites améliorations de l'expérience utilisateur, corrections de problèmes de type « coupures de papier »
- Exemple : petites améliorations de l'expérience utilisateur, corrections de problèmes de type « coupures de papier »
Notre équipe utilise des points de vue distincts pour aborder ces différentes catégories d'idées :
Vue des Rochers dans Jira Product Discovery.
Vue des Pierres dans Jira Product Discovery.
Vue des Cailloux dans Jira Product Discovery.
Attributs d'une idée
Dans Jira Product Discovery, chaque idée est accompagnée d'un résumé en une ligne, d'une description détaillée, d'informations telles que le feedback des clients et des liens vers des tickets Jira pour la livraison de l'idée.
Une idée dans Jira Product Discovery.
Panneau de présentation d'une idée dans Jira Product Discovery.
Pour être aussi utile et réalisable que possible, chaque idée du backlog produit doit être dotée des attributs suivants :
caractéristique | De quoi s'agit-il ? |
|---|---|
| Résumé | De quoi s'agit-il ? Une phrase sur l'idée. |
| Description | De quoi s'agit-il ? Une description plus détaillée de l'opportunité, du problème, de la solution. |
| Champs | De quoi s'agit-il ? Les différentes facettes de l'idée : l'objectif auquel elle contribue, son stade, la partie du produit qu'elle touche, les informations permettant de la hiérarchiser, comme l'impact ou l'effort, les liens vers les spécifications ou les designs. |
| Analyses | De quoi s'agit-il ? Informations recueillies sur tous les canaux au fur et à mesure : principaux enseignements tirés du feedback des utilisateurs, snippets de conversations avec des clients et de rapports de recherche, ou analyses de produits qui expliquent clairement pourquoi cette idée est importante. |
| Livraison | De quoi s'agit-il ? Liens vers des tickets de livraison dans Jira (epics ou initiatives) concernant le travail de livraison visant à livrer l'idée du produit. |
La collecte de toutes ces informations pour chaque idée peut prendre du temps. Au départ, l'idée pourrait entrer dans votre backlog avec un résumé d'une ligne, par exemple un point de vue recueilli lors d'une conversation avec un client. Au fil du temps, vous collecterez de plus en plus d'informations à ce sujet sur la base d'entretiens avec les utilisateurs, du feedback des ventes ou de l'assistance, ou des changements de la stratégie de l'entreprise.
Une phrase avec un feedback d'utilisateur.
Avec le feedback des utilisateurs et une analyse de l'impact potentiel.
Avec une solution validée et une livraison bien avancée.
Il existe deux manières de décrire des idées : directement dans Jira Product Discovery, ou en associant Confluence au projet Jira Product Discovery de votre équipe.
Dans Jira Product Discovery, rédigez un résumé ou une définition dans le champ de description de l'idée. Utilisez l'un des modèles fournis, ou créez le vôtre, pour fournir une formule cohérente permettant de décrire les problèmes, les solutions, les hypothèses et plus encore en lien avec l'idée.
Si votre équipe utilise également Confluence, vous pouvez créer un lien entre l'idée et les pages Confluence : soit dans la description de l'idée, soit en utilisant des champs de liens hypertextes personnalisés. L'avantage de cette approche est que vous pouvez tirer parti de toutes les fonctionnalités de collaboration de Confluence, comme les commentaires contextuels.
Le contenu de la description elle-même dépendra du type d'idée et de son stade d'avancement.
Le cycle de vie de l'idée
L'évolution d'une idée dans le temps est tout aussi importante que son contenu. C'est pourquoi il est important de définir des étapes claires pour chaque idée au cours de son cycle de vie. Le fait d'avoir un vocabulaire commun pour décrire les étapes du cycle de vie des idées rend chaque conversation plus productive, à la fois au sein de l'équipe et avec les parties prenantes.
Chez Atlassian, nous utilisons quatre étapes : Interrogation, Exploration, Création, Impact. Chez Atlassian, tout le monde connaît la signification de chacune de ces étapes. À chaque étape, nous connaissons le type de travail dans lequel l'équipe est engagée, le type de questions à poser et le type d'aide dont l'équipe pourrait avoir besoin. Cette cohérence vaut pour les discussions au sein de l'équipe, avec d'autres équipes ou avec les hauts dirigeants.
Lors de la création de Jira Product Discovery, notre équipe a utilisé cette approche pour développer, valider et mettre en œuvre nos idées. Pour chaque étape du cycle de vie, nous expliquerons comment notre équipe l'a mise en pratique.
Interrogation, Exploration, Création, Impact
Avant d'entrer dans ce cycle de vie, chaque idée commence sur un parking. À ce stade, il ne s'agit généralement que de résumés d'une ligne, contenant les informations qui ont mené à leur création. Ces informations peuvent provenir d'un atelier, d'un rapport de recherche, d'une discussion avec un client ou avoir été partagées par un responsable des ventes ou du support.
Une fois que le travail actif sur l'idée a commencé, les quatre étapes sont respectées :
- Interrogation : discutez des problèmes ou des opportunités que l'idée pourrait résoudre, des personnes sur lesquelles elle aura un impact et de leur importance.
- Exploration : trouvez des solutions potentielles jusqu'à en trouver une qui soit validée par le feedback des clients.
- Création : créez la solution et itérez-la jusqu'à ce qu'elle réponde aux besoins d'un nombre suffisant de clients.
- Impact : lancez la solution, mesurez les résultats et continuez à l'améliorer jusqu'à ce qu'elle produise les résultats souhaités.
Les étapes de l'idée pour l'équipe Sirius dans Jira Product Discovery.
Vue Tableau des idées au sein de l'équipe Jira Product Discovery, par étape de l'idée.
Il ne s'agit pas d'un modèle en cascade, ces étapes ne sont pas nécessairement linéaires. Par exemple, il est très courant qu'une idée dans Exploration revienne à Interrogation, car le fait de tester des solutions nous en apprend davantage sur le problème. On s'attend également à ce que vous abandonniez certaines idées, si vous ne trouvez pas de solution adaptée au bout de quelques essais.
Dans les sections suivantes, nous illustrerons chaque étape en montrant comment notre équipe les a suivies lors de la création de Jira Product Discovery.
Si ce processus vous intéresse, regardez cette conférence pour plus de détails :
Émerveillement
L'étape Interrogation consiste à valider un problème ou une opportunité.
À ce stade, vous vous basez généralement sur des entretiens qualitatifs avec des clients. Grâce à cette étude, votre équipe pourra mieux comprendre les avantages et les résultats que l'idée vise à apporter, mesurés en termes de valeur pour les clients et pour l'entreprise. Elle élaborera également une hypothèse pour mesurer le succès.
À ce stade, vous pouvez appliquer à vos idées le modèle « Définition de problème » dans Jira Product Discovery ou bien créer votre propre modèle.
Modèle « Définition de problème » dans Jira Product Discovery.
Tout au long des étapes Interrogation, Exploration, Création et Impact, saisissez les enseignements tirés des recherches et des conversations avec les clients dans la section Insights (Informations) de l'idée :
Le champ Insights (Informations) pour une idée dans Jira Product Discovery.
Interrogation en action
Voici à quoi ressemblait l'étape Interrogation lorsque nous avons créé Jira Product Discovery. L'idée originale de ce produit est venue :
D'entretiens avec des responsables produit qui utilisent Jira pour la livraison de logiciels
D'analyses des recherches menées par l'équipe Research & Insights d'Atlassian et par des cabinets d'analystes tels que Gartner and Forrester
Des exemples de bonnes pratiques en matière de développement produit, comme les blogs de Marty Cagan et le livre de Teresa Torres.
La collecte de ces informations nous a permis de constater que :
- Les responsables produit se heurtent à de nombreuses difficultés, qu'il s'agisse d'établir des priorités de manière efficace ou de convaincre tout le monde de l'intérêt de leurs feuilles de route
- Les responsables produit se tournaient vers Jira pour résoudre ces problèmes, mais leur succès était limité, car Jira n'était pas conçu pour cela
- Les responsables produit étaient bloqués dans la livraison, concentrés sur les résultats comme la livraison de fonctionnalités, alors qu'ils pourraient adopter un état d'esprit axé sur la découverte et produire des résultats
- La gestion des produits est devenue une fonction clé, même au-delà des entreprises technologiques. Nous pensions donc qu'il s'agissait d'une opportunité importante et qu'il y aurait une forte demande pour une solution.
Notre page de destination pour Jira Product Discovery.
Nous nous sommes particulièrement attachés à valider notre hypothèse sur la demande, car il s'agissait de notre hypothèse la plus risquée. Si nous nous trompions, nous créerions un produit que seules quelques entreprises achèteraient.
Avant d'écrire la moindre ligne de code, nous avons créé une page web faisant la promotion du produit.
Les résultats ont confirmé notre hypothèse : 3 000 personnes se sont inscrites sur la liste d'attente en quinze jours.
Explorer
Dans l'étape d'Exploration, nous conceptualisons, testons et validons des solutions aux problèmes ou aux opportunités identifiés dans Interrogation.
Nous savons que de nombreuses idées de produits sont vouées à l'échec. Cela fait partie du processus ! Pour identifier plus rapidement les idées les moins prometteuses et laisser la place aux bonnes, Marty Cagan propose aux responsables produit de gérer quatre risques principaux. Utilisez-les pour évaluer les solutions possibles aux problèmes et aux opportunités que vous avez identifiés.
- La solution est-elle intéressante pour les clients ? Si ce n'est pas le cas, par exemple parce qu'ils ont déjà accès à de meilleures solutions, vous risquez que les gens n'utilisent pas la solution que vous avez mise au point.
- La solution est-elle facile à utiliser et intuitive ? Pour que les utilisateurs puissent tirer profit de la solution, celle-ci doit être facile d'accès et d'utilisation. Si ce n'est pas le cas, vous risquez de lancer une fonctionnalité qui sera peu utilisée.
- Cette solution est-elle techniquement réalisable ? Même si une idée est prometteuse, vos ingénieurs doivent disposer des compétences et des technologies nécessaires pour la mettre en œuvre. Sinon, vous risquez d'épuiser des ressources inutilement.
- La solution est-elle viable compte tenu des ressources et des contraintes de l'entreprise ? Plusieurs itérations seront probablement nécessaires pour parvenir à la solution appropriée. Vous devez vous assurer que l'entreprise est prête à investir pour ne pas consacrer trop de temps à une idée qui sera finalement abandonnée.
L'objectif de votre équipe est de limiter les risques le plus efficacement possible et d'éviter un investissement excessif guidé par une intuition ou par un emballement pour une solution. C'est généralement ce qui se produit lorsque vous livrez une fonctionnalité et que vous procédez ensuite à des itérations ou à une revue de ses performances. Utilisez plutôt des techniques plus simples, en créant par exemple dans Figma des prototypes que vous présenterez aux clients pour recueillir leur feedback avant de commencer à écrire du code.
Si vous décidez de livrer une fonctionnalité, essayez de créer un prototype en direct avec de nombreuses limites, de le tester auprès d'un petit groupe d'utilisateurs précoces et d'itérer rapidement. Ainsi, vous n'aurez pas à penser à tous les « corner cases » (problèmes marginaux). Si l'idée ne leur convient pas, vous découvrirez bien plus rapidement pourquoi, et vous pourrez continuer à itérer jusqu'à ce qu'elle soit adaptée, ou bien l'abandonner si elle n'aboutit pas.
En cas de fortes incertitudes, faites un point technique dans le cadre de l'étape d'exploration. Cette approche vous aidera à comprendre les contraintes de votre équipe, à déterminer ce qui est techniquement réalisable et à identifier les domaines de complexité technique.
À ce stade, vous pouvez appliquer à vos idées le modèle de définition de solution dans Jira Product Discovery ou bien créer votre propre modèle.
Modèle de définition de solution dans Jira Product Discovery.
Dans votre backlog produit, associez l'ensemble des documents, spécifications et designs liés à chaque idée afin de les avoir à portée de main pour en discuter avec votre équipe et les parties prenantes. Nous vous recommandons de créer des champs « hyperliens » pour chaque idée afin de garder une trace de chaque élément (document d'une page ou design).
Cette démo vous explique comment procéder :
L'exploration en action
Lors de la création de Jira Product Discovery, nous avons utilisé les techniques suivantes pour valider nos solutions auprès de nos clients :
Nous avons tout d'abord soumis aux responsables produit des diapositives présentant différentes solutions possibles afin d'identifier celle qui leur convenait le mieux. Grâce à ces échanges, nous avons beaucoup appris sur les difficultés de nos clients et sur ce qu'ils recherchaient. C'est ainsi que la « priorisation » est devenue le premier pilier de Jira Product Discovery.
💡 Faciles à créer, à tester et à modifier, les diapositives sont parfaites pour cette étape de validation.
Nous avons ensuite créé dans Figma des prototypes que nous avons présentés aux utilisateurs en leur demandant en quoi les solutions pouvaient les aider. Le premier prototype testé était une solution destinée à aider les responsables produit à utiliser le feedback des parties prenantes pour établir des priorités.
Bien qu'il présentait un réel intérêt, les responsables produit ont estimé que sa mise en place nécessitait trop d'efforts avant de pouvoir en tirer profit. Nous avons donc abandonné l'idée.
Après avoir recueilli de nombreux commentaires de ce type, nous avons exploré la solution qui allait devenir Jira Product Discovery : un espace collaboratif pour discuter d'idées de produits.
À ce stade, les échanges avec les utilisateurs ont radicalement changé. Beaucoup demandaient quand ils auraient accès à la solution, car elle les aiderait beaucoup. C'est à ce moment-là que nous avons su que nous étions sur la bonne voie.
Après avoir recueilli de nombreux commentaires de ce type, nous avons exploré la solution qui allait devenir Jira Product Discovery : un espace collaboratif pour discuter d'idées de produits.
À ce stade, les échanges avec les utilisateurs ont radicalement changé. Beaucoup demandaient quand ils auraient à la solution, car elle les aiderait beaucoup. C'est à ce moment-là que nous avons su que nous étions sur la bonne voie.
Création
Lors de l'étape de création, les équipes élaborent et valident les solutions qu'elles ont choisies pendant l'exploration. C'est là qu'intervient l'essentiel du travail de développement.
Cette étape aboutit à un logiciel fonctionnel (qu'il s'agisse d'un nouveau produit ou d'une nouvelle fonctionnalité, ou bien d'améliorations apportées à une expérience existante), qui a prouvé sa capacité à produire les résultats attendus, qui a été adopté par un nombre suffisant de clients pour prouver sa valeur et qui est prêt à être utilisé par tous les clients.
Au lancement de la livraison, lors de cette étape ou de l'étape d'exploration, vous associerez l'idée aux tickets de livraison dans Jira (nous recommandons le niveau epic ou un niveau supérieur). Suivez l'avancement des livraisons depuis Jira Product Discovery, et bénéficiez d'une vue d'ensemble sur l'avancement de toutes les initiatives relatives aux produits et de toutes les équipes.
Relation entre une idée et la livraison dans Jira.
Si plusieurs équipes participent à la livraison d'une idée et travaillent sur différents projets Jira, vous pouvez associer tous leurs tickets de livraison à l'idée dans votre backlog produit.
Idée livrée par trois équipes Jira.
Vous pouvez ensuite suivre l'avancement de la livraison depuis JPD, et bénéficier d'une vue d'ensemble sur l'avancement de toutes les initiatives relatives aux produits et de toutes les équipes.
Tableau de bord du travail en cours sur les produits.
Pour en savoir plus, vous pouvez visionner notre webinaire « Comment associer découverte et livraison dans Jira » dans la section Ressources.
N'oubliez pas que la solution ne produira sans doute pas immédiatement les résultats attendus. Il est préférable de prévoir des livraisons rapides et régulières aux clients, et de poursuivre les itérations jusqu'à ce que le résultat soit satisfaisant. Continuez à alimenter l'idée avec ce que vous apprenez des échanges avec les clients. La méthode de mesure de la réussite dépendra du type d'idée : nouvelle fonctionnalité, initiative de croissance ou autre. Assurez-vous que tout le monde en est informé et que vos plans prévoient des itérations.
La création en action
Lors de la création de Jira Product Discovery et de l'ajout de nouvelles fonctionnalités importantes au produit, nous avons procédé à des tests et à des validations auprès de groupes de clients de plus en plus larges. Ce processus a nécessité quelques semaines dans certains cas et quelques mois dans d'autres.
| 0 → 10 clients | Pendant l'étape d'exploration, nous avons effectué des itérations avec un petit groupe de clients présélectionnés. Nous avons travaillé en étroite collaboration avec eux pour élaborer la solution. Nous avons poursuivi les itérations jusqu'à ce que les clients nous confirment que la solution résolvait le problème auquel ils étaient confrontés. |
| 10 → 100 clients | Nous avons ensuite progressivement mis la solution à la disposition d'un plus grand nombre de clients. Cela nous a aidés à identifier différents scénarios auxquels nous n'avions peut-être pas pensé au départ. Nous avons poursuivi les itérations jusqu'à ce que la solution compte 100 clients actifs. |
| 100 → 1 000 clients | Nous avons ensuite élargi l'accès, jusqu'à atteindre 1 000 clients. À ce stade, nous avons étudié les chiffres d'utilisation issus des analyses des produits, les tickets de support et les commentaires entrants. Nous avons utilisé ces informations pour améliorer l'expérience utilisateur ou pour corriger des bugs. Si les chiffres d'utilisation sont trop faibles pour être utiles, nous étudions la visibilité de la fonctionnalité. |
| Disponibilité générale | Pour finir, nous avons mis en place des outils de support, des outils d'aide à la vente, des tableaux de bord opérationnels, ainsi que des améliorations de performances et d'évolutivité. |
Lorsque nous travaillons sur ce type de solutions, nous utilisons généralement une page Confluence distincte que nous appelons « Document de fonctionnalité en direct ». C'est une page très simple que nous ouvrons à chaque réunion d'équipe lorsque nous discutons du périmètre de l'itération en cours. Nous mettons ce document à jour fréquemment, au fur et à mesure que nous en apprenons plus sur les éléments simples ou complexes à livrer. Il n'est pas axé sur des tâches individuelles, mais sur l'expérience produit, c'est-à-dire sur les points sur lesquels toutes les équipes doivent être alignées, du produit au design en passant par l'ingénierie.
Document de fonctionnalité en direct dans Jira Product Discovery.
Impact
Dans le modèle de produit, tout commence et se termine par des résultats. Les équipes établissent la priorité des idées pour parvenir aux résultats souhaités, et après la livraison, elles continuent à suivre l'avancement par rapport à ces résultats. Cela vous permet de mettre à jour vos objectifs et vos stratégies, et de définir la priorité de vos prochaines actions.
Même une fois livrée, une solution n'est jamais vraiment « terminée » : lorsque vous ajoutez une fonctionnalité, elle fait partie intégrante de votre produit. Vous devez continuer à l'améliorer pour vous assurer qu'il présente un intérêt pour les utilisateurs, qu'il est facile à utiliser et qu'il ne crée pas de confusion. Gardez un œil sur les demandes des clients, sur ce qu'ils pensent des nouvelles fonctionnalités et sur la fréquence à laquelle celles-ci apparaissent dans les tickets de support.
Impact en action
Au sein de l'équipe Jira Product Discovery, nous procédons à des revues mensuelles et trimestrielles, dans lesquelles nous comparons l'impact que nous avons obtenu à ce que nous avions prévu de faire. Parfois, nous sommes satisfaits des résultats et nous ne changeons pas grand-chose, parfois nous réinitialisons la feuille de route pour essayer quelque chose de différent.
Après avoir livré une solution, l'une des techniques que nous utilisons consiste à créer une idée d'amélioration correspondante où nous recueillons des informations, telles que :
- le feedback entrant des utilisateurs
- les signaux indiquant que la fonctionnalité résout ou non les problèmes pour lesquels elle a été conçue dans le feedback, les enquêtes et les entretiens
- les données d'utilisation provenant de l'analyse produit pour comprendre si la solution est réellement utilisée. Si ce n'est pas le cas, il peut y avoir des problèmes de découverte, ou simplement moins d'enthousiasme pour la fonctionnalité que nous avions prévue.
Vue pour suivre le feedback des clients sur les idées déjà livrées dans Jira Product Discovery.
Nous examinons ces données régulièrement, et chaque équipe alloue un budget à l'amélioration des fonctionnalités. Les nouvelles idées et les améliorations apportées aux idées existantes figurent sur la feuille de route de chaque équipe :
L'avancement d'une idée
Jira Product Discovery propose un ensemble de champs pour suivre l'avancement des tickets de livraison sur une idée. Mais nous ne pensons pas que ce soit nécessairement le meilleur moyen de communiquer les avancements aux parties prenantes. Le fait que les tâches d'une epic soient accomplies à 60 % ou 80 % ne révèle pas les avancements réels de l'équipe.
Voici un moyen plus efficace de communiquer les avancements aux parties prenantes : marquez chaque idée comme étant sur la bonne voie, à risque ou repoussé (via un champ) et commentez (dans la description de l'idée). Il s'agit d'une collaboration primitive très simple, mais elle est très efficace pour communiquer avec les parties prenantes lorsque vous avez besoin d'aide.
Vue de la communication des avancements aux parties prenantes dans Jira Product Discovery.
Plus de détails sur une idée dans la vue « Partage des avancements ».
Si vous êtes client d'Atlas, vous connaissez déjà cette approche. Regardez la vidéo expliquant comment associer les idées de Jira Product Discovery aux projets Atlas dans la section Ressources. Cela donne une image meilleure et plus précise que les vues ci-dessous, qui mesurent les avancements en pourcentage de tickets Jira livrés :
Une vue Jira Product Discovery qui montre l'avancement des tickets livrés dans Jira.
Plus de détails sur une idée dans la vue d'avancement axée sur les tickets.
Et maintenant ?
En utilisant les idées comme moyen de proposer des solutions pendant l'idéation, la validation et la mise en œuvre, les équipes produit peuvent organiser leur personnel et se concentrer sur les résultats.
Dans le reste de ce manuel, nous expliquerons en détail comment utiliser un backlog produit pour :
- mettre en place des canaux de feedback et collecter des insights pour valider des idées
- prioriser les idées susceptibles d'avoir un impact
- créer des feuilles de route auxquelles vos équipes et les parties prenantes pourront adhérer.
Nous vous fournirons des exemples sur la façon dont nous procédons au sein de l'équipe Jira Product Discovery, en utilisant Jira Product Discovery ainsi que d'autres produits.
Backlog produit
Gérez efficacement les backlogs produit pour hiérarchiser les idées, améliorer la collaboration et stimuler le développement produit.
Feedback et insights
Découvrez comment l'intégration d'insights dans le processus de développement produit peut améliorer la prise de décisions, répondre aux besoins des clients et favoriser de bons résultats.
