Episode 2 – Le cadrage d’un nouveau produit stratégique est l’occasion de créer un written narrative

Vous allez découvrir dans cette série de 3 articles comment une Product Owner (PO) relève un défi de taille concernant le création d’un nouveau produit

Dans l’épisode précédent que vous pouvez (re)découvrir ici , vous avez pu découvrir l’histoire de Pia, une Product Owner qui décide de relever un défi de taille que la PDG d’ACME Corp lui a confié il y a quelques jours seulement.

Ce défi consiste en la création d’un MVP de veille réglementaire utilisant du machine learning dédié au segment de marché des ETIs

Après avoir identifié en interne une équipé dédiée pour mener à bien cette mission, Pia va faire un cadrage pour bien commencer la construction de ce produit. Très rapidement, elle va s’apercevoir que le written narrative deviendra utile pour synthétiser la matière collectée. 

Les personnages de cette histoire : 

  • Pia, la Product Owner
  • Demba, le Designer
  • Salma, la Scrum Master
  • Hiromi, le Directeur des ventes
  • Thomas, le Tech lead 

Semaine 1 – Rencontre avec les prospects

Pour s’immerger dans la vie des utilisateurs, Pia décide d’organiser avec Demba le Designer des rencontres avec les prospects. Après plusieurs discussions et observations terrains, Pia est désormais en mesure de dresser un portrait de la cible prioritaire et d’établir un véritable persona qui confirme les irritants évoqués dans l’épisode précédent. 

Bonne nouvelle: les prospects sont également prêts à participer régulièrement à des tests utilisateurs lors des 3 prochains mois.

Cadrage pour ce nouveau produit 

Parce que Pia est une adepte du Blog OCTO, elle sait que pour bien commencer ce produit, il sera pertinent de réaliser un cadrage 360° avec l’équipe de dev. Pour ceux qui souhaitent revoir à quoi ressemble un cadrage 360°, nous vous invitons à (re)découvrir cet article.

Cadrage 360

Semaine 2 – Bilan du cadrage et tests utilisateurs

Ce cadrage permet à Pia d’embarquer dès le départ l’équipe de dev autour d’une vision partagée du produit cible. Cet exercice collectif lui donne également l’occasion d’affiner les premières hypothèses de l’équipe concernant la faisabilité, la viabilité, la désirabilité du produit cible. 

Cependant la Product Owner ne sait pas si le produit sera “utilisable” par les prospects… Hiromi, le Directeur des ventes, dans ses échanges amonts avec les prospects, avait insisté lourdement dans son pitch sur ”l’expérience utilisateur intuitive de la solution cible”. 

Demba le Designer, a toujours plus d’un tour dans son sac et suggère à Pia la méthode Google Design Sprint, sur un format condensé de 2 jours pour construire et tester un ou deux prototypes sur Marvel app de quelques écrans clés dans l’optique d’obtenir du feedback utilisateurs avant que l’équipe ne développe la moindre ligne de code. Cela permettrait de savoir si les premières hypothèses issues du cadrage sont crédibles ou non. Dans la logique de la méthode Google Design Sprint, 2 prospects n’étaient pas suffisants, du coup Hiromi a fouillé dans son CRM favori pour inviter 3 autres prospects intéressés pour faire le test du prototype. 

La suggestion de Demba d’utiliser cette méthode de prototypage rapide a été déterminante pour toute l’équipe. Les tests utilisateurs se sont en effet révélés riches d’enseignements pour valider certaines hypothèses, notamment sur les besoins de personnalisation du produit par les utilisateurs : les prospects ont bel et bien besoin d’être guidés pas à pas pour personnaliser les filtres de veille réglementaire. Le prototype a également permis d’invalider d’autres hypothèses, notamment sur le fait que les utilisateurs ont besoin d’avoir beaucoup plus la main sur la fréquence des remontés d’alertes et n’apprécient pas avoir des settings “par défaut”. En synthèse, beaucoup d’informations ont été collectées sur des paperboards (en présentiel), des boards Miro/Mural (à distance). 

Résultat, entre le cadrage 360°, les entretiens avec les prospects, le lean canva et les retours des prospects sur les prototypes, il y a beaucoup de contenu. Comment réussir à transformer toutes ces données plus ou moins brutes en informations et en décisions sur le produit ? Et il y a aussi la demande de la PDG qui est en toile de fond de toutes vos réflexions: “Il faudra convaincre et répondre aux objections de certains membres du Top management”… 

Il lui faut décidément une approche différente.

L’occasion est idéale pour se repencher sur cette méthode: le Written Narrative. 

Le Written Narrative : Prendre le temps nécessaire pour aller plus loin

Pourquoi utiliser un Written Narrative plutôt que Powerpoint

Pia pourrait tout à fait synthétiser les informations-clés des échanges et ateliers, compactées dans une présentation PowerPoint. Elle pourrait montrer au Top management quelques chiffres et tendances agrégés en diagrammes, accompagnés de phrases courtes et impactantes en police de taille 24, saupoudrer le tout de photos émotionnellement intelligentes, et de bien renforcer les messages-clefs avec les nuances dans sa voix et ses gestes. Après tout, pourquoi pas ? 

La plupart des organisations utilisent PowerPoint depuis dés années. La Product Owner est une adepte de Guy Kawazaki, et de L’art du pitch. Cependant les dernières lectures de Pia lui démontrent que les personnes retirent très peu d’informations via des slides. 

Avec le recul, l’exercice du PowerPoint est un exercice relativement facile pour le présentateur mais parfois difficile pour les personnes qui sont dans la pièce. Et puis, que se passe-t-il une fois qu’elle n’est plus là pour pitcher le slide deck et qu’il manque les sous titres pour embarquer les personnes qui découvriront ce support de façon asynchrone ? 

Qu’est ce que le Written Narrative

Grâce au livre Empowered et des posts sur le written narrative, Pia apprend que cette technique est pratiquée chez Amazon, et qu’elle a acquis sa réputation d’efficience.

Le Written Narrative, c’est un document de 6 pages qui permet de : 

  • Définir le problème que l’équipe souhaite résoudre pour une cible
  • Démontrer pourquoi la solution envisagée sera utile pour la cible et pour votre organisation
  • Présenter sa stratégie pour résoudre le problème avec objectifs précis
  • Introduire les principes directeurs de la solution proposée
  • Présenter l’état du business
  • Introduire les derniers apprentissages concernant le produit
  • Préciser les priorités stratégiques du produit envisagé dans le détail

Pia découvre en ligne un exemple réel de Written Narrative qui s’avère très utile pour l’inspirer.

En quoi le Written Narrative lui sera-t-il utile ? 

Pia est tout à fait consciente du fait que la rédaction de ce written narrative est un exercice long et nécessite – tout comme la création du produit par les équipes de dev – un travail itératif et incrémental. En effet, il faut aboutir à un contenu logique, cohérent et inspirant, contrairement à ce que l’on attend d’une liste de bullet points où l’indentation fait office de catégorisation sémantique.

Cependant, ce travail lui permettra d’argumenter plus en profondeur les décisions qu’elle prendra avec l’équipe dans les prochaines semaines et mois. 

La Product Owner pourra aussi y anticiper les objections à cette nouvelle initiative. Comme elle le sait, les détracteurs de ce produit au niveau du top management sont nombreux : Pia souhaite être prête lorsque les SCUDs arriveront.

Prendre le temps d’identifier clairement les objections, qui arriveront tôt ou tard, lui permettra également de trouver des réponses claires et précises à formuler et de les tester auprès des différentes personnes afin de savoir quelles sont les réponses qui fonctionnent et celles qui doivent être retravaillées. 

Contrairement à une présentation PowerPoint qui est très rapidement obsolète, le Written narrative va servir au Top management pour accéder à tout moment à la vision la plus complète, à jour, et synthétique possible du produit en cours de développement. Un wiki partagé par tous est l’endroit idéal. Ça tombe bien : Salma, la Scrum Master avait déjà créé l’espace pour l’équipe de développement il y a quelques jours. 

Dans le prochain épisode, vous découvrirez comment Pia la Product Owner rédigera chaque étape du written narrative et l’introduira auprès des différentes parties prenantes de l’organisation. 

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *


Ce formulaire est protégé par Google Recaptcha