Introduire le PRD : anatomie du Pitch Produit

Le pitch est un outil essentiel de l'arsenal du Product Owner, dans sa communication avec les parties prenantes. Pour ma part, il m'a surtout aidé à convaincre...
Introduire le PRD : anatomie du Pitch Produit

Si vous vous souvenez de la conclusion de mon premier article sur le PRD, nous avons brièvement évoqué la vocation du Pitch, comme synthèse de notre compréhension du besoin, et outil pour convaincre que c’est une opportunité à traiter dans notre feuille de route.

Ici, l’intention est d’explorer des pistes concrètes à exploiter pour réussir un bon pitch produit.

À qui s’adresse le Pitch Produit

Lorsque nous explorons la littérature, nous voyons principalement deux cibles majeures remonter : des cibles internes à l’entreprise, mais aussi externes.

« L’idée ici est de pitcher l’idée de solution de la manière la plus rapide et la plus légère possible pour faire passer le message. »Escaping the build trap, de Melissa Perri.

En interne, pour l’alignement

Le pitch sert à aligner l’équipe de réalisation, les parties prenantes (stakeholders) et la direction sur une vision commune. Comme le souligne Marty Cagan, c’est aussi un outil de recrutement interne pour motiver les gens à travailler sur quelque chose de significatif : « Les personnes fortes en technologie sont attirées par une vision inspirante — elles veulent travailler sur quelque chose de significatif. »

En externe, pour convaincre

Il s’adresse aux investisseurs pour sécuriser des capitaux, car les équipes doivent « pitcher les investisseurs sur leur vision (…) pour prouver que la vision sera viable et rentable sur le marché. » (Melissa Perri).

Il s’adresse également aux clients potentiels pour valider la demande ou la proposition de valeur avant le développement complet.

Le rôle du pitch

Pour Marty Cagan, le Pitch est là pour « aider les gens à imaginer le futur et les inciter à contribuer à la création de ce futur. » Il doit communiquer la vision du produit ou du service qu’on veut mettre en place, dans le but d’embarquer l’interlocuteur dans notre aventure, qu’il s’agisse des clients, des investisseurs, de la direction, … ou de l’équipe elle-même.

Ainsi, pour Jeff Patton, nous parlons de l’outil d’alignement. Il nous le présente sous la forme d’un « Elevator Pitch », un format par lequel « l’équipe décrit ce qu’elle aimerait lire sur son produit dans un article de revue spécialisée. »

Ce pitch doit être co-construit avec l’équipe, car le but affirmé par Jeff Patton, est de « savoir si l’équipe a une vision commune de l’orientation générale, ou si elle devra investir dans des recherches supplémentaires. » Si l’équipe n’arrive pas à se mettre d’accord sur cette description du produit, c’est que les données sur le besoin, ou les résultats de démonstrations de prototype sont encore insuffisants pour que l’objectif à atteindre soit clair dans l’esprit de chacun.

Ainsi, nous construisons le Pitch sur la base des données empiriques du terrain (échanges avec les utilisateurs, activités sur le produit, etc.), en collaboration avec l’équipe pour garantir l’alignement de tous, et in fine pour convaincre les parties prenantes.

Le Pitch nous évite également un écueil : celui de sauter directement aux fonctionnalités (ce que nous appelons l’output). Il force l’équipe à se concentrer sur les résultats (l’Outcome, par opposition à l’output) et les bénéfices réels pour le client, plutôt que sur une liste de caractéristiques techniques.

Enfin, le Pitch permet de valider les hypothèses à moindre coût : il permet de tester si notre idée interpelle les parties prenantes, si elle leur donne envie… avant d’investir plusieurs mois de développement dans un produit qui pourrait ne pas être validé.

Ce que les pros conseillent pour rédiger le Pitch

La technique du Communiqué de Presse (Amazon), par Marty Cagan

Cette méthode consiste à écrire un communiqué de presse imaginaire décrivant le produit comme s’il venait d’être lancé. Il doit montrer comment notre produit améliore la vie des clients, quels sont les bénéfices réels qu’ils vont en tirer. Et si le lecteur de notre communiqué factice ne voit pas la valeur, le Product Owner doit revoir sa copie.

Marty Cagan propose également une variante originale, la « Lettre au Client ». Elle consiste à rédiger une lettre du point de vue d’un utilisateur très satisfait. Celui-ci explique au PDG pourquoi il est heureux et comment le produit a changé sa vie… La lettre inclut aussi une réponse imaginée du PDG félicitant l’équipe pour le succès business.

L’Elevator Pitch de Jeff Patton

Nous l’avons déjà évoqué lorsque nous parlions du rôle du Pitch. Souvent utilisé pour définir la proposition de valeur de manière concise, il doit clarifier :

  • À qui s’adresse le produit, c’est-à-dire le client cible.
  • Quel problème nous voulons traiter, le besoin insatisfait (ou la gêne, comme dirait Mises).
  • Quelle solution nous envisageons de proposer… Non pas dans les détails de sa spécification, mais son nom, sa catégorie,… les grandes lignes.
  • Quels sont les bénéfices clés que doit apporter notre produit, ou plus concrètement, dans quelle mesure la gêne de l’utilisateur sera résolue.
  • Et parce-ce que nous n’évoluons pas en vase clos, mais sur un marché, avec des concurrent : quelle différence apportera notre solution par rapport aux alternatives.

Comment communiquer notre Pitch ?

Pour « vendre le rêve », Marty Cagan recommande d’utiliser un prototype, car il permet de concrétiser ce que le produit apportera, ou « un dessin vaut mieux que mille mots » comme on dit.

Au travers de ce prototype, nous devons mettre en évidence quel est le problème client que nous cherchons à résoudre, et comment notre solution contribue à le résoudre.

Enfin, le Pitch doit montrer que notre proposition n’est pas isolée du reste du produit, ou de la stratégie de l’entreprise, mais qu’elle s’insère dans sa vision à long terme.

Mon expérience personnelle : le format court

Je n’ai pas eu l’occasion de pousser l’exercice aussi loin que dans la littérature. J’ai été en général dans des situations, où je devais proposer une évolution sur le produit, faire valider une opportunité auprès du management, planifier,… avant d’amorcer la Discovery (l’exploration du besoin à proprement parler). Je travaillais dans un contexte où celui-ci avait déjà été identifié par les commerciaux… parmi d’autres. Je devais donc débroussailler un minimum la compréhension de ce besoin, savoir expliquer en quoi nous devions le traiter pour notre produit, et déterminer l’urgence de sa résolution. Toutes ces informations devaient transparaître dans mon pitch.

Pour cela, je disposais d’une session courte au cours de laquelle je devais être suffisamment clair, concis, et surtout convaincant. Ensuite, mon pitch se retrouvait en tête du PRD, comme nous l’avons évoqué dans mes précédents articles. Le but était alors de permettre au lecteur de saisir en moins d’une minute quel était le sujet et le but du PRD.

Pour cela, je disposais donc : des données que les commerciaux m’avaient fournies, les retours de mon exploration personnelle, et parfois des données d’analyse du produit (des logs ou des données de supervision du produit).

À partir de toutes ces données, je construisais mon pitch sous la forme de 2 ou 3 phrases claires, grâce auxquelles j’étais en mesure de faire comprendre la situation et aboutir à une validation rapide d’une série de sujets à intégrer à la roadmap (parce que je soumettais plusieurs pitchs dans la même session).

Mon résultat final : là où l’IA me délia d’une gêne

Consolider toute la matière accumulée est en soi assez fastidieux, mais une fois que j’ai su quelle forme donner au résultat, je me suis appuyé sur l’IA. L’instruction était alors relativement simple :

« En pièce jointe se trouvent toutes les données dont je dispose sur le sujet de (description en quelques mots). Donne-moi un Pitch produit synthétisé en 3 points clairs, précis, et succincts. »

Le format a naturellement émergé lorsque j’ai demandé à l’IA de me fournir une réponse courte :

  • Le constat : situation actuelle, présenté parfois sous la forme d’une opportunité à exploiter.
  • Une description du problème, parfois sous la forme d’un historique à traiter ou d’un impact (par exemple quand il s’agissait d’un problème de dette technique).
  • Une proposition, claire et concise, basée sur mes analyses personnelles.

Ainsi, l’IA m’a permis de résoudre un double problème : un gain de temps considérable, et l’exercice fastidieux du travail de synthèse.

Sources

  • Escaping the Build Trap, de Melissa Perri
  • Inspired : How to Create Tech Products Customers Love, de Marty Cagan
  • User Story Mapping: Discover the Whole Story, Build the Right Product, de Jeff Patton

Annexe – Exemple de Pitch

Pour vous donner un exemple concret de ce que l’IA m’a fourni, j’ai eu l’occasion de lui soumettre un sujet technique, mais avec un bénéfice potentiel pour les utilisateurs : un système de pagination par token. Concrètement, l’interface s’appuyait sur des données renvoyées par page, mais sans avoir le numéro de page. Le « token » ici est un repère qui permet de charger une nouvelle série de lignes d’un tableau venant à la suite du précédent.

Le point d’entrée était donc une opportunité apportée par une « contrainte » technique, qui nous empêchait d’optimiser nos tableaux tels que nous les avions pensés, mais que nous pouvions exploiter pour améliorer l’expérience utilisateur, d’une autre façon…

Voici ce que mon agent du moment m’avait proposé :

| - L’Opportunité : Basculer les API de lecture (Read) sur un système de pagination par token (cursor-based) pour réduire drastiquement les temps de chargement et permettre un filtrage performant directement côté serveur (au lieu du côté client).\n- La Contrainte : Ce modèle technique ne renvoie pas le nombre total d’éléments, ce qui rend impossible l’affichage d’une pagination classique numérotée (ex: “Page 1 sur 50”).\n- La Proposition : Lancer une étude UX pour adapter les tableaux de la console à ce nouveau modèle, en explorant le passage à un « Infinite Loading » (défilement infini) ou un bouton « Charger la suite », tout en validant que la perte du compteur total n’est pas bloquante pour les processus métier des clients. |

Avec ça, j’ai pu pousser une exploration sur un changement dans l’interface qui apportait un compromis entre expérience utilisateur et performance de chargement des tableaux de notre fameuse console.


Write a comment
No comments yet.