Le Discovery en product management est un processus continu d’exploration, de recherche et de validation d’idées, de fonctionnalités et de problèmes à résoudre avant de passer à la phase de développement (Delivery) d’un produit. Il sert à comprendre les besoins des utilisateurs, le marché et les opportunités potentielles. Il contribue à définir la vision et la stratégie du produit d’un côté, qui peuvent influencer la vision et la stratégie à l’échelle de l’entreprise, et à alimenter les spécification du produit à réaliser de l’autre. Il permet de s’assurer de répondre à un réel besoin avec une solution désirable, utilisable, réalisable, viable et éthique. Le célèbre ouvrage Inspired de Marty Cagan est une véritable encyclopédie sur le sujet. Il est complété par d’autres ouvrages très pragmatiques tels que Continuous Discovery Habits de Teresa Torres, Escaping the Building Trap de Melissa Perri et Sprint de Jake Knapp.
Le Discovery contient globalement dix activités principales qui sont les suivantes :
Recherche utilisateur : Il s’agit de comprendre les besoins, les motivations et les comportements des utilisateurs cibles pour créer un produit qui leur apporte de la valeur.
Exemples d’activités liées :
- Réaliser des entretiens individuels avec des utilisateurs potentiels
- Mener des enquêtes en ligne pour collecter des données quantitatives
- Organiser des ateliers de co-création avec les utilisateurs
Analyse de marché et de la concurrence : Évaluer le marché, les tendances, les opportunités et les concurrents pour identifier les niches et les avantages concurrentiels.
Exemples d’activités liées :
- Analyser les produits et services concurrents
- Examiner les tendances du marché et les rapports d’analystes
- Identifier les opportunités de différenciation et de création de valeur
Définition des problèmes, besoins ou désirs : Identifier et décrire clairement les problèmes à résoudre pour les utilisateurs et l’entreprise, ou leurs besoins ou désirs. Il est important de définir des problèmes spécifiques et mesurables. L’article sur la valeur au sens du bénéfice client apporte des éclaircicement sur les problèmes, besoin ou désirs.
Exemples de problèmes :
- Les utilisateurs d’un site de réservation de voyages ont du mal à trouver rapidement les offres les plus pertinentes.
- Les clients d’un logiciel de gestion de projet éprouvent des difficultés à suivre l’avancement des tâches en temps réel.
Génération d’idées : Brainstorming et exploration de solutions potentielles pour résoudre les problèmes identifiés. Les idées peuvent être générées par l’équipe de product management, les parties prenantes ou les utilisateurs eux-mêmes.
Exemples d’activités :
- Proposer des solutions pour améliorer la personnalisation des recommandations d’un site de commerce électronique.
- Explorer des idées pour simplifier la navigation dans une application mobile de gestion financière.
Identification et priorisation des fonctionnalités : Déterminer les fonctionnalités clés du produit en fonction des besoins des utilisateurs, des contraintes techniques et des objectifs de l’entreprise.
Exemples d’activités liées :
- Utiliser des techniques de brainstorming pour générer des idées de fonctionnalités
- Prioriser les fonctionnalités en fonction de leur valeur pour l’utilisateur, de leur coût de développement et de leur alignement avec les objectifs
- Créer une « roadmap » de produit pour planifier les étapes de développement
Validation des hypothèses : Tester les hypothèses clés sur les utilisateurs, les fonctionnalités et le marché pour minimiser les risques et optimiser les chances de succès.
Exemples d’activités liées :
- Créer des maquettes et prototypes pour les confronter à la réalité et aux utilisateurs
- Réaliser des tests d’utilisabilité pour valider les concepts de design
- Lancer des prototypes ou des versions bêta pour obtenir des retours d’utilisateurs
- Mesurer l’adoption et l’engagement des utilisateurs pour évaluer le succès du produit
Définition du produit et des features : Définir les spécifications fonctionnelles et techniques du produit, et documenter l’architecture.
Exemples d’activités liées :
- Concevoir l’architecture du produit, une feature ou un composant
- Rédiger les spécifications sous la forme de Product Backlog Items (User Stories, Technical Stories, etc.)
- Documenter le fonctionnement du produit
- Rédiger les descriptions et les critères d’acceptation pour chaque backlog item, en s’assurant qu’ils sont clairs, compréhensibles et réalisables.
- Estimer le temps et les ressources nécessaires pour mettre en œuvre chaque item, en consultation avec l’équipe de développement (Extreme Quotation pour la planification globale, planning pocker pour l’estimation en sprint planning).
Priorisation des sujets, problèmes et solutions : Sur les différents axes abordés dans le Discovery, les sujets traités et les activités relatives doivent être priorisées pour garantir que le maximum de valeur soit produit avec le minimum d’effort. La priorisation des sujets et items se fait en fonction de leur valeur pour les utilisateurs, de leur alignement avec les objectifs de l’entreprise et de leur faisabilité technique.
Exemples de techniques de priorisation :
- MoSCoW : Cette méthode classe les éléments en quatre catégories : Must-have, Should-have, Could-have et Won’t-have. Elle est utile pour déterminer rapidement les éléments essentiels et ceux qui peuvent être reportés ou abandonnés.Exemple : Dans le développement d’une application mobile, les fonctionnalités de base comme l’inscription et la connexion sont des Must-have, tandis que les notifications push pourraient être des Should-have ou des Could-have.
- Matrice d’impact et d’effort : Cette technique évalue les éléments en fonction de leur impact potentiel sur les utilisateurs ou l’entreprise et de l’effort nécessaire pour les mettre en œuvre. Elle est utile pour identifier les éléments à fort impact et faible effort, qui offrent le meilleur retour sur investissement. Exemple : Une fonctionnalité qui améliore considérablement l’expérience utilisateur avec un effort de développement minimal serait priorisée par rapport à une fonctionnalité à faible impact et à effort élevé.
- RICE Scoring : RICE est un acronyme pour Reach (portée), Impact (impact), Confidence (confiance) et Effort (effort). Cette méthode attribue un score à chaque élément en fonction de ces quatre critères. Elle est utile pour évaluer les éléments de manière plus quantitative et pour faciliter la prise de décision. Exemple : Une fonctionnalité qui toucherait un grand nombre d’utilisateurs, aurait un impact significatif sur leur expérience, bénéficierait d’une confiance élevée quant à son succès et nécessiterait un effort modéré aurait un score RICE élevé et serait prioritaire.
- D’autres exemples de techniques de priorisation sont disponibles dans l’article dédié.
Création ou actualisation de la feuille de route (roadmap) : Projection sur une frise chronologique des fonctionalités ou impacts visés par le produit au cours du temps.
Exemples d’activités :
- Extreme quotation
- Alignement et négociation
Mesure et suivi des résultats : Une fois les solutions mises en œuvre, mesurez et suivez les résultats pour évaluer l’efficacité des solutions et déterminer si des ajustements ou des améliorations sont nécessaires.
Exemples d’activités :
- Suivre les indicateurs clés de performance (KPI) pour une nouvelle fonctionnalité de recommandation de contenu sur un site web d’actualités.
- Mesurer l’adoption et l’utilisation d’une nouvelle fonctionnalité de partage de fichiers dans une application collaborative.
Les 5 types d’hypothèses à valider
Tout d’abord, rappelons en quoi consiste le Discovery. C’est un outil qui permet de s’assurer que l’on produit quelque chose de bénéfique pour les clients et de profitable pour l’entreprise ; d’ailleurs, il permet en premier lieu de vérifier que des clients saisiront l’opportunité de l’offre prévue autour du produit. Le Discovery permet cela grâce à cinq axes de validations : la désirabilité, l’utilisabilité, la faisabilité, la viabilité et l’éthique. Derrière chacun de ces axes, nous trouvons des types d’hypothèses et des outils pour les vérifier. En fonction du moment choisi, certains outils seront plus pertinents que d’autres. Plus les hypothèses sont posées et testées, plus on élimine mécaniquement des travaux qui étaient imaginés initialement et on se concentre sur les caractéristiques du produit (ou fonctionnalités) qui apportent réellement de la valeur au client, et qui est profitable pour l’entreprise.
Voici la description de chaque axe de vérification inspirée des 5 types d’hypothèses de Teresa Torres, p147 de Continuous Discovery Habits.
Type d’hypothèse | Espace du problème | Espace de la solution |
---|---|---|
Désirabilité | * Le désir ou besoin est-il assez important pour être considéré ? * A-t-on bien défini les Buyer Personas et éventuellement Buyer roles ? * Quels modèles sont déjà connus pour convaincre ? | * Quelqu’un veut-il réellement ce dont nous sommes en train de parler ? * Quel est le tunnel d’aqcuisition adapté ? * Quels seraient les freins à l’adoption ? |
Utilisabilité | * A qui s’adresse-t-on ? Quelles sont les contraintes des utilisateurs cibles ? A-t-on bien identifié tous les acteurs ? * Quelle est la cartographie de l’expérience actuelle des clients, des différents acteurs en jeux (systèmes et humains), éventuellement des utilisateurs si le produit existe déjà, et de leurs peines ? * Connaît-on bien les User Personas et/ou rôles ? | * Les utilisateurs seront-ils en mesure d’atteindre leur objectif facilement avec ce que nous proposons ? * Vont-ils comprendre comment l’utiliser ? * Est-ce accessible ? |
Faisabilité | * Connaît-on bien nos points forts, axes de compétences et capacité de réalisation ? * Connaît-on bien l’écosystème autour du produit qui lui donnerait ses chances d’être réalisé ? (modules existants, compétences disponibles, etc.) | * A-t-on bien modélisé le cadre d’utilisation avec une cartographie d’expérience ? * Ce que l’on souhaite réaliser est-il bien défini ? * Qu’est-ce qui est réalisable avec les moyens à disposition pour répondre au besoin ou désir ? * Pouvons-nous construire le produit ou la fonctionnalité évoquée ? Est-ce techniquement possible ? * Les équipes Légal, Sécurité, Qualité ou Compliance seront-elles d’accord avec ce que nous proposons ? |
Viabilité | * Sur quel axe la fonctionnalité ou le produit est censé apporter au business ? Image ? Revenu ? Notoriété ? Partenariats stratégiques ? * Connaît-on bien l’écosystème autour du produit qui faciliterait son adoption et sa distribution ? | * Devrions-nous construire le produit ou la fonctionnalité ? En connaissance de la désirabilité, l’utilisabilité et de la faisabilité, le développement abouti-t-il sur quelque chose de viable pour le business ? * Coût de réalisation + Coût de maintien + Service < Revenu dans un délai raisonable ? |
Ethique | * Connait-on les uses et coutumes des environnements dans lesquels on souhaite développer et distribuer/vendre le produit ou la fonctionalité ? | * Quelles données collectons-nous ? Comment les stocke-t-on ? Comment les utilisons-nous ? Les utilisateurs et clients seraient-ils d’accord ? * Ce que nous proposons est-il en accord avec les valeurs de l’entreprise ? L’impact est-il mesuré ? * A-t-on l’ensemble des informations qui permettent d’aboutir à l’évaluation de l’impact environnemental et fait-il le nécessaire pour le minimiser ? |
Une fois les hypothèses listées, certaines parties prenantes sont plus légitimes que d’autres pour apporter des réponses ou à minima des informations. En fonction de la structure de l’équipe, de la maturité de l’entreprise, etc. les informations et choix sont plus ou moins collégiaux.
Type d’hypothèse | Exemples de parties prenantes légitimes pour répondre |
---|---|
Désirabilité | * Sales * Marketing * Data Analyst |
Utilisabilité | * Designer * Data Analyst |
Faisabilité | * Tech Lead * Lead Dev * Developers * Operations * Architects * Security * Legal |
Viabilité | * Marketing et stratégie * Profils financiers : CFO, Contrôleur de gestion, etc. * Product Manager ou personne réalisant l’étude d’impacts et de risques |
Ethique | * Marketing * Product Managers * Sales |
Une fois les hypothèses listées, il est nécessaire de leur attribuer un test qui permet d’aboutir à la validation ou l’invalidation de celles-ci. Voici un exemple d’une hypothèse présente sur une fiche descriptive d’une fonctionnalité (Feature Product Requirement Document)
Titre | Type(s) de l’hypothèse | Description | Test et outil de test | Résultat du test |
---|---|---|---|---|
Les utilisateurs ont besoin de différentes langues | Utilisabilité, Désirabilité | Notre produit va être accessible au monde entier et nous devons avoir notre produit disponible dans un maximum de langues différentes | * Analyser les statistiques géographiques d’utilisation * Réaliser un sondage sur 25 de nos utilisateurs pour avoir un résultat représentatif | * Trois langues sont pratiquées par nos utilisateurs dans 90% des cas * 55% des utilisateurs ne parlent qu’une des trois langues * L’anglais est essentiel et est maitrisé par 75% de nos utilisateurs, en revanche l’adoption est facilitée lorsque l’utilisateur rencontre sa langue * Nous devons développer le produit de façon à ce qu’il soit compris par un utilisateur ne maitrisant qu’une seule langue, pour les trois langues |
Les 6 types de Discovery
Avec le recul et la pratique, on constate qu’il existe plusieurs types de Discovery. Nous en avons recensé six : Product Discovery, Management Discovery, Continuous Product Discovery, Product Ecosystem Discovery, Extended Product Ecosystem Discovery et Research. Chaque type de Discovery n’intervient pas au même moment dans la chronologie de création d’un produit.
Ces types de Discovery sont pour la plupart liés à des moments clés de la création d’un produit. A ce jour, nous en avons identifié quatre dont trois reviennent de façon cyclique : l’initialisation, les itérations de développement, le cool down et le scaling.
Techniquement, nous pourrions attribuer ces moments bien au delà du Discovery en introduisant le Delivery et les Opérations, mais nous nous concentrerons ici sur le Discovery.
A. Initialization
L’initialisation correspond au moment où le produit commence à être imaginé, jusqu’au moment où une vision est définie et où une première équipe débute son existence.
Tout projet a un début. Au départ, l’idée n’est pas forcément la bonne ou n’existe pas. Des rencontres sont nécessaires pour créer l’étincelle qui fera débuter un long parcours qui aboutira soit sur un produit réussi, soit à un échec formateur. Certains projets naissent tandis que les porteurs n’en sont même pas conscients !
Au fur et à mesure que le projet évolue et laisse apparaitre le bout du nez d’un produit, une équipe se forme. Cette équipe va découvrir les besoins en compétences et en temps nécessaires à la réussite du produit, et va se heurter aux problématiques de recrutement. Souvent même de séparation. L’équipe n’est pas forcément nommée comme telle car la relation peut-être de type partenariat pour constituer un réseau de valeur.
La découverte porte alors non seulement sur le produit, mais aussi sur l’équipe, les parties prenantes et la raison d’être du business (l’entreprise). La vision de long terme se construit tandis que les premières étapes théoriques se dessinent. Une planification est faite et guidera le continuous discovery et delivery. C’est pendant ce Product Discovery initial que le premier Product Requirement Document est rédigé.
B. Iterations
A partir du moment où l’approche agile est sélectionnée, alors il est dans l’idée que le produit mature au fur et à mesure qu’il est implémenté, testé et mis à disposition. L’agilité existe pour réduire le risque de l’incertitude qui faisait échouer de nombreux projets basés sur la conception et la planification détaillée. Ainsi, la découverte continue décrite dans l’ouvrage Continuous Discovery Habits de Teresa Torres est également à intégrer.
Dans cette phase se pose souvent la problématique de jusque où pousser la démarche de discovery avant la priorisation. En effet, la Discovery est un travail à part entière et plusieurs sujets peuvent être en concurrence dans les activités relatives. Tout d’abord, l’odre du dérisquage peut avoir son importance dans la quantité de travail à assurer. Le fait de commencer par se concentrer sur l’analyse du besoin client et utilisateur avant de débuter l’étude de faisabilité est une première façon de ne pas surinvestir.
Ensuite, si on se pose la question de la quantité de travail à réaliser pour être en mesure de prioriser simplement l’analyse du besoin client et utilisateur, alors la première chose à faire est de regarder les OKRs qui ont été créé pour l’entreprise et le produit. Ils sont un premier bon filtre avant d’aller vers des outils de mesure de l’intensité du besoin face à sa régularité, etc. La mise en perspective des besoins sur les mêmes deux axes intensités-régularité permet de mettre en perspective chaque besoin respectivement également. On peut aussi parfois décomposer le besoin en sous-besoins moins complexes, tout comme on peut découper les solutions en solutions moins complexes ou dégradées par rapport à une cible idéale.
C. Cool Down
L’idée qu’un produit est implémenté en continu tandis que la découverte est déroulée en parallèle a ses limites pour plusieurs raisons. L’équipe évolue en même temps que son produit, tous les profils ne sont pas disponibles de suite, de nouvelles contraintes techniques sont découvertes à mesure que le produit évolue, et de nombreuses dettes découlent de cette situation. Vous ne trouvez pas de profils QA et personne ne compense ? Vous générez une dette QA. Vous ne trouvez pas de Designer ? Vous générez une dette UX. Vous avez fait des choix technologiques répondants au premier problème que vous avez choisi d’adresser ? Vous générez une dette technique. Vous devez changer de langage car le recrutement sur celui que vous aviez sélectionné ne permet pas de recruter les profils abordables à votre échelle ? Vous avez créé une dette technique également. Vous avez atteint les limites de votre management et devez trouver des moyens de délégation ? Vous avez une dette managériale. Vous avez favoriser le développement de nouvelles fonctionnalités par rapport au traitement de bugs ? C’est une dette technique. Les dettes sont omniprésentes, et du recul est nécessaire pour les rembourser le plus régulièrement possible.
C’est pourquoi l’approche du Cool Down de la méthode Shape Up est intéressante. C’est un moment qui peut durer un, deux ou trois sprints (cycles de développement), pendant lesquels l’équipe prend le temps de traiter les différentes dettes, et surtout prend du recul sur la production passée et la pertinence du positionnement et des choix à venir, et éventuellement tester des choses qui n’ont pas pu l’être pour valider ou invalider des hypothèses.
D. Scaling & Pivot
Au fur et à mesure que le produit et l’entreprise se développent, des décisions doivent être prises. D’un côté, on peut se rendre compte que le produit serait plus profitable pour tout le monde s’il était redécoupé pour que chaque morceau se spécialise. Ou bien on identifie des produits complémentaires disponibles sur le marché et une stratégie est construite sur cette base, même potentiellement en termes d’achat d’entreprise. Ou encore on identifie un nouveau produit à développer pour répondre pleinement à des besoins non comblés par le produit actuel.
Ce que l’on vient de décrire concerne un produit pour lequel le chemin est tout tracé vers le succès. En revanche, il est nécessaire également de considérer les revirements stratégiques qui permettent tout simplement de transformer un produit avec peu de valeur en produit réussi. Pour cela, il y a les stratégies de Pivot décrites dans le Lean Startup.
Dans le Lean Start-up, Eric Ries définit dix types de pivots différents. Ces pivots sont appliqués par toute société qui se trouve face à un choix stratégique. Ils peuvent remettre en cause l’ADN de la société, ses clients courants, son mode de fonctionnement, etc. Il est beaucoup plus simple de les appliquer à petite échelle (projets, TPE, PME, etc.) qu’à grande échelle (grande entreprise industrielle, multinationale, communauté, etc.), c’est pour cela qu’Eric Ries les adresse surtout aux start-ups. Certaines grandes entreprises ont réussi à se structurer de façon à faciliter les pivots.
Voici les 10 pivots du Lean Start-up de Eric Ries.
Nom du pivot | Description |
---|---|
Zoom-in | Une des fonctions du bien ou service qui était développé devient le bien ou service lui-même. |
Zoom-out | Ce que l’on imaginait être un bien ou service à part entière devient la fonction d’un bien ou service plus complet. |
Customer Segment | Le bien ou service qui a été développé est plus adapté à un autre segment de population que celui auquel on s’est adressé. Il s’agit ici de passer de la population cible actuelle à la nouvelle. |
Customer Need | Le problème sur lequel on a choisi de se focaliser n’est pas vraiment important pour la population cible. Cependant, l’étude de la population cible a permis de déceler un besoin bien réel. Il est ici question de revoir en profondeur le bien ou service, quitte à le jeter pour en refaire un nouveau. |
Platform | Le bien ou service qui a été créé peut servir de base de travail ou base de distribution pour d’autres créateurs. Par exemple, un créateur de jeux vidéo peut devenir éditeur en offrant l’accès au site Internet sur lequel il réalise ses ventes. |
Business Architecture | C’est un changement de considération du marché. Eric Ries cite le passage du principe des grandes marges et petits volumes à celui des grands volumes et petites marges ; principes développés par Geoffrey Moore. |
Value Capture | On réalise ici un changement de façon de faire rentrer de l’argent dans les caisses de l’entreprise (ou de faire vivre l’entreprise). L’innovation paradigme est un bon exemple sur ce point. On peut prendre l’exemple des journaux qui sont passés du paiement par les lecteurs au paiement par les publicitaires. Ces journaux devenant gratuits, ils touchent potentiellement un plus grand public, ce qui est intéressant pour les marques qui souhaitent se faire connaître. |
Engine of Growth | C’est la reconsidération du modèle de développement de la société, pour atteindre un modèle plus durable. Eric Ries donne 3 modèles primaires : Viral (favoriser la diffusion), addictif (favoriser l’engagement) et payant. Les aspects viral et addictif sont évoqués dans les travaux de Robert Cialdini cités plus tôt à travers les leviers d’influence. |
Channel | C’est un changement de stratégie vis à vis de la chaine d’approvisionnement ou de la chaine de distribution. Par exemple, une société peut choisir de délivrer un bien ou service elle-même ou de faire appel à un réseau de distribution indépendant. Elle peut choisir de créer ses outils comme elle peut choisir de se fournir dans une société spécialisée. Le passage de la production au service est un changement de chaîne (Channel). |
Technology | Lorsqu’une société se rend compte qu’une autre technologie réalise une tâche souhaitée avec un meilleur rapport entre la qualité, le prix, et l’ADN de la société, elle peut choisir d’abandonner l’ancienne et d’adopter celle-ci. Les innovations disruptive et radicale fournissent d’excellents exemples. |
E. Long Terme
C’est sans doute le moment le plus oublié de tous : le long terme. C’est intéressant de partir d’un besoin client et d’aligner des solutions pour y répondre. Mais qu’en est-il de l’émergence de nouvelles technologies qui créeront la différence dans le futur ? Des technologies pour lesquelles il est parfois impossible d’imaginer les applications et bénéfices futurs ?
La recherche fondamentale et appliquée sont de grands contributeurs d’innovation. Qu’elle soit intégrée à une équipe produit, sous-traitée, surveillée ou partagée au sein d’une organisation. C’est ce que l’on a longtemps appelé R&D et qui a plus penché pour le D du développement que pour le R de la recherche.
Quand il s’agit de placer les différents types de Discovery dans ces différents moments, alors il ressort que l’initialisation, le cool down et le scaling vont permettre d’explorer de façon plus large le produit et étendant l’étude au management et à l’écosystème ; tandis qu’au moment des itérations, l’attention se portera beaucoup plus sur le produit et ses fonctionnalités directement.
Lorsque le produit évolue, grandit, et potentiellement donne lieu à un découpage plus précis ou à une intégration au milieu d’autres produits, alors on parle de Extended Product Ecosystem Discovery.
Pourquoi vient-on nourrir le Discovery d’une étude sur le management et l’écosystème ? Grâce à des ouvrages comme Team Topologies de Matthew Skelton et Manuel Pais, nous savons qu’un produit est intrinsèquement lié à l’équipe qui le construit grâce à la loi de Conway. Nous savons grâce à Michael Porter que le marché fait peser sur un produit une concurrence qui nécessite d’être très clair sur son positionnement au sein de l’écosystème également.
Ainsi, l’écosystème des produits ou modules existants sur le marché, ainsi que la population qui l’entoure pour le créer ou le soutenir sont des axes importants à explorer qui vont bien au delà d’interviews clients et utilisateurs. Ce travail de découverte est balancé entre le bloc de Vision & Strategy et la Discovery. Ainsi, avec le recul, nous pouvons maintenant donner quelques détails supplémentaires sur les différents types de Discovery.
1. Le Product Discovery
Le Discovery correspond à l’ensemble des mécaniques qui permettent de filtrer et d’affiner ce qui sera plus tard envoyé en Delivery. C’est le Discovery le plus évoqué dans la litérature en Product Management, et sa grande valeur est qu’il permet de limiter la production de fonctionnalités ou caractéristiques produit qui n’auraient que peu de valeur à la fois pour le client et pour le business.
Grâce au panel d’outils notamment décrit dans Inspired de Marty Cagan, il s’agit de répondre aux questions liées à la désirabilité, l’utilisabilité, la faisabilité, la viabilité et l’éthique.
2. Le Continuous Product Discovery
Le Continuous Product Discovery utilise les mêmes techniques que le Product Discovery, mais avec la contrainte de la régularité. La marche est la même que celle qui est franchie par le Delivery lorsque la décision est prise d’avoir des sprints de 2 semaines plutôt que des sprints de 2 mois : les objectifs ne peuvent plus être les mêmes, et le périmètre de travail se découpe pour se concentrer sur l’essentiel.
3. La Research
On nomme ici Research la recherche fondamentale et appliquée qui va un jour pouvoir alimenter le Discovery. Il s’agit d’une démarche de plus long terme qui peut passer par de nombreuses stratégies telles que le partenariat avec un laboratoire de recherche ou des écoles ou universités spécialisées, une mise en commun de la démarche de recherche au travers d’organismes tels que les CRITT en France, l’exploration des brevets mis à disposition par les SATT (clusters d’innovation), ou tout simplement l’intégration d’un groupe de recherche dans l’entreprise ou directement au sein de l’équipe produit.
4. Le Product Ecosystem Discovery
Il s’agit de la réflexion centrée sur le produit qui permet d’aboutir sur des choix de redécoupage du produit ou d’association avec d’autres produits existants ou à développer.
5. Le Management Discovery
C’est un Discovery axé sur la compréhension des capacités de l’équipe et de son organisation pour influencer la façon dont le produit va évoluer. Ce discovery est basé sur le principe de la loi de Conway qui édicte que la structure d’un produit est directement influencée par l’organisation de l’équipe qui le réalise.
6. L’Extended Product Ecosystem Discovery
C’est un Product Ecosystem Discovery qui va explorer plus largement l’existant sur le marché. Il est à la frontière avec l’étude qui est menée par le marketing pour construire la vision du marché, et fait appel notamment aux 5 forces de Porter.
Michael Porter, professeur à l’Université de Harvard, est célèbre pour ses travaux sur la stratégie d’entreprise axés entre autres sur les 5 forces de l’industrie, sur la chaine de valeur des entreprises, et sur sa vision particulière de la concurrence. Pour lui, il y a deux formes de compétition : la compétition pour être le meilleur, et la compétition pour être unique. La première forme encourage les concurrents à se copier mutuellement et à minimiser leurs prix au maximum. D’après Porter, ce type de compétition repris derrière la théorie de l’Océan Rouge, est destructeur et provoque ce qu’il appelle la competitive convergence ; c’est à dire l’élimination progressive des concurrents pour la survie d’un seul (selon son état de santé). En France, l’exemple le plus frappant de ces dernières années est celui des opérateurs téléphoniques qui, faute de différenciation, ont perdu progressivement leur force et se sont rachetés les uns les autres. Cette situation n’est ni bonne pour les concurrents qui s’autodétruisent, ni pour le consommateur.
La compétition pour être unique, reprise dans la théorie de l’Océan bleu, relève quant-à elle d’un bien meilleur recul vis-à-vis des marchés, et encourage les candidats à répondre à un même besoin avec des modèles différents. Ces modèles sont représentés sous la forme de chaines de valeur, étapes de l’élaboration d’un produit ou service qui doivent chacune ajouter de la valeur à ce qui sera présenté au futur client (nous développerons le concept de chaine de valeur plus tard). Ces chaines de valeur sont construites en considération des 5 forces définies par Porter, que nous additionnerons à celles de la législation en vigueur, et des normes et standards. Les cinq forces de Porter sont constituées de la rivalité existante entre les concurrents, du poids des fournisseurs, de la menace des nouveaux entrants, de la menace des produits et services de substitution, et du poids des acheteurs et utilisateurs.
Selon le modèle des Five Forces+2, chaque force n’a a priori pas de rapport direct avec les autres. Ainsi, sur un marché concurrentiel, chaque acteur du marché aura sa propre vision des évolutions d’un produit ou service. Deux acteurs peuvent avoir une représentation radicalement opposée du produit qu’ils analysent. Vis-à-vis des acheteurs et utilisateurs (représentés à droite sur la figure I.1), les concurrents ont pour objectif de différencier leurs produits ou services pour qu’ils soient uniques et attractifs, et pour qu’ils soient prêts à payer un prix plus élevé. Vis-à-vis des fournisseurs (représentés à gauche sur la figure I.1), les concurrents visent une réduction des coûts par une optimisation de leurs chaines de valeur. Quel que soit le point de vue adopté, chaque concurrent a pour mission d’augmenter le résultat de la soustraction du prix par le coût : la marge.
Le Sprint Design, un outil de Discovery ?
Le Design Sprint est une méthode de résolution rapide de problèmes et de validation d’idées, développée par Google Ventures. Elle est basée sur des séances de travail collaboratif pour résoudre un problème ou valider une idée en un temps limité. Les design sprints incluent plusieurs étapes, telles que la définition du problème, l’idéation, le prototypage et le test.