Notes de lecture du livre INSPIRED, How To Create Tech Products Customers Love de Marty Cagan

Ce n’est pas souvent que je lis des ouvrages sur le métier ou le secteur dans lequel j’exerce. Ce n’est pas par manque de curiosité, la diversité des lectures dont je parle ici sur ce blog atteste du contraire. Je suis toujours un peu méfiant sur ce genre de livres qui promeut la solution magique à tous vos problèmes. J’ai l’impression qu’il y a une forme de biais du survivant: une compagnie qui réussit avec une méthode, elle en parle sur son blog, on en écrit un livre et après il y a tout un commerce qui prend vie avec des conférences, des formations etc. Ce n’est pas le cas ici, j’ai beaucoup appris à sa lecture, ce n’est pas un livre de recette magique.

La thèse du livre - les leçons de Marty Cagan

Les concepts Agile et Lean sont maintenant très répandus dans les organisations technologiques. On peut dire que leur pratique a amélioré la façon de livrer un produit technologique. Mais la frontière avec le reste de la compagnie laisse encore à désirer, notamment dans les processus en amont de la livraison comme la “découverte du produit”.

C’est l’objet du livre Marty Cagan. Il place l’échec dans le divorce entre le côté itératif de la livraison qui permet beaucoup de souplesse et le processus encore très raide (“waterfall”) des spécifications, de l’écoute client.

On retrouve justement ce divorce dans la séparation des rôles avec le Product Owner, le PO (propriétaire de produit en français) d’un côté, souvent très proche de l’équipe de développement technologique et le reste de l’organisation Produit. Les idées et opportunités d’affaire proviennent d’une équipe, puis elles sont transformées en feuille de route et après seulement on a un carnet de produit (backlog) qui prend forme.

Cette approche ne favorise pas les meilleures pratiques que l’on peut résumer en 3 points:\

• Lever les risques les plus dangereux en premier
• Travailler en livraison continue rapide au lieu d’avoir de longues activités séquentielles
• Résoudre les problèmes (des clients) au lieu de livrer un ensemble de fonctionnalités

Pourquoi cela arrive? Les étapes d’analyse produit en amont sont faites avec des hypothèses de coûts et revenus très imprécises et donc on invente des chiffres, parfois farfelus.

Cela nous empêche pas d’en déduire une feuille de route qu’on découpe en carnet de produit et qu’on implémente sans se rappeler que les prémisses ne sont que des hypothèses. On ne retient que l’engagement qu’est la feuille de route.

L’auteur résume sa vision d’une meilleure approche qui prend la forme d’une phase de découverte alimentée par des objectifs (avec des OKR par exemple) eux-même définis avec une stratégie dans le cadre d’une vision.

Cela peut paraître flou mais il détaille très bien après comme la mettre en pratique en commençant par l’organisation.

La bonne équipe “Produit”

Pour résumer, la découverte et la livraison devraient être gérées par une équipe intégrée qui collabore durant toutes les phases du produit. Cela nécessite que cette équipe soit proche et construite dans la durée surtout si le produit requiert une expertise dans un domaine particulier.

Au centre il y a le gestionnaire de produit. Il doit connaître les clients, les données du produit (au sens métriques en tout genre), le mode de fonctionnement de l’entreprise et le marché dans lequel le produit évolue. C’est cette personne qui participe à toutes les activités avec des acteurs différents, mais il reste le fil conducteur.

On retrouve autour :

• un concepteur de produit (product designer) qui s’occupe de l’expérience client. Il ne faut pas tomber dans le travers qui est de le prendre comme une agence interne. Il est avec l’équipe dès le premier jour.
• Un « gestionnaire marketing » (product marketer) qui aide dans le positionnement et la mise en place des canaux de vente ou dans la stratégie de marketing pour un produit grand public avec pubs, campagne Google AdWords etc.
• L’équipe de développement qui participe à toutes les activités, de la découverte à la livraison. Son avis est un des plus importants pour le produit.

Il y a d’autres rôles qui sont souvent partagés entre plusieurs équipes Produit:

• User researcher: comme le concepteur de produit, on ne doit pas le traiter comme un fournisseur interne qui dresse un rapport en fin d’étude. Le gestionnaire de produit doit être activement engagé dans les activités même si il se fait aider.
• Analyste de données
• Assurance-Qualité
• Delivery Manager: quand la partie livraison prend trop de temps, on a besoin de quelqu’un de dédié pour lever les obstacles ou coordonner des équipes différentes. Souvent le Scrum master joue ce rôle.

Toute une partie du livre discute aussi de l’évolution de cette organisation quand l’entreprise grandit. Je ne rentre pas dans les détails mais on retrouve le même principe que dans les équipes technologique avec des postes de Lead, Principal ou Group Manager pour gérer des grosses équipes Produit ou servir de référant.

Le bon “Produit”

Pourquoi les feuilles de route ne marchent pas?

Marty Cagan voit 2 principaux problèmes:

1. La moitité des idées initiales qui se retrouvent sur une feuille de route ne marchent pas quand livrées car:

Usuability is not there

or Value is not there

or Feasibility is not there

or Business viability is not there

2. Cela prend plusieurs itérations pour arriver à un produit qui surmonte les 4 problèmes et qui raccourcit le time to money. La découverte Produit est la plus importante des capacités et cela se fait en jours/semaines et non en mois.

Le problème de la feuille de route n’est tant pas la liste mais le fait qu’une fois dressée, tout le monde la prend pour une liste d’engagements fermes. Quand l’échec survient, on repart dans un autre processus laborieux d’élaboration d’une autre feuille de route. On a besoin d’échéances mais cela se réfère plus à un high-integrity commitment qui arrive après une première étape de découverte du produit.

L’alternative à la feuille de route

Cette alternative doit répondre aux besoins derrière toute feuille de route: travailler sur les besoins d’affaire les plus prioritaires et avoir une date de livraison.

Pour cela on peut donner des objectifs d’affaires associés à des mesures et laisser l’équipe trouver le moyen (les fonctionnalités) de les atteindre . Par exemple : « Réduire drastiquement le temps de on-boarding d’un client » et la mesure est « moins de 3 heures ». On retrouve ici le concept d’OKR.

On va essayer des fonctionnalités pour servir cet objectif, certaines ne font pas marcher etc. On parle alors de feuille de route basée sur des résultas attendus (outcome-based roadmap) et non une liste de fonctionnalités.

Pour alimenter ces objectifs il faut une vison et une stratégie produit.

La vision Produit imagine le futur qu’on essaie de créer. Elle doit être plus concrète que la mission de l’entreprise. Elle décrit où on veut être dans 2 à 5 ans. On peut avoir un prototype qui illustre cette vision, un visontype.

La stratégie Produit décrit le chemin pour réaliser cette vision sous forme de séquence de livraisons par marché géographique, segment de clientèle ou les étapes dans les données acquises etc.

Le bon processus “Produit”, la découverte Produit et ses techniques

Ici l’auteur survole les techniques de découverte qui nous aident à surmonter les 4 risques à chaque fois que l’on veut évaluer une opportunité:

• la valeur: est-ce que les clients vont l’acheter?
• la convivialité: est-ce que les clients vont aimer l’utiliser?
• la faisabilité: est-ce techniquement possible?
• la viabilité commerciale: est-ce viable pour l’entreprise?

Pour cela on a tout un catalogue de techniques qui couvre:

• Le positionnement (framing)
• la planification
• L’idéation
• Les prototypes
• les tests de la faisabilité, convivialité, valeur client et viabilité commerciale

Je vais passer rapidement sur chacune d’entre elles.

Le positionnement

On veut d’abord être sûr que tout le monde s’accorde sur les objectifs à atteindre.

D’autre part, souvent on s’attaque aux risques secondaires, ceux avec lesquels on est le plus confortable comme les risques de faisabilité technique pour une équipe de développeurs ou de convivialité pour un designer. Avec ces techniques, on veut faire aussi émerger les risques plus fondamentaux comme ceux liés à la valeur, aux finances, etc.

Trois techniques:

• l’évaluation d’opportunité qui prend la forme de 4 questions :

  • Quel est l’objectif d’affaire servi?
  • Comment va-t-on mesurer la résussite?
  • Quel est le problème-client qu’on adresse?
  • Quel type de client on vise?

• La lettre du client (ou la version communiqué de presse d’Amazon) avec un faux client qui écrit au CEO en expliquant pourquoi c’est un super produit, quel problème il a résolu.

• Startup canvas dans le cas où on crée une nouvelle compagnie ou un nouveau produit.

La planification

• Le story mapping: je ne reviens pas dessus, c’est une technique connue dans le monde Agile.
• Customer discovery program: très lourd à mettre en place mais il amène un très bon retour sur investissement. On prend 6 clients potentiels et on construit un produit pour eux autour de leurs problématiques. Toutefois cela ne doit pas être du développement spécifique pour leur environnement. Ils paient mais cela permet d’itérer rapidement et ils deviendront de potentiels référents après.

L’idéation

• Entretien avec des clients: 2 à 3 heures par semaine avec un product designer qui conduit l’entrevue et un développeur.
• Concierge: le gestionnaire de produit prend la place du client et fait son boulot.
• Client qui utilise “mal” le produit: un client utilise d’une façon détournée le produit pour résoudre un problème bien spécifique mais qui n’était prévu par les concepteurs. Cela me fait penser à l’utilisation d’Excel ou même d’Access par des personnes en-dehors des départements IT pour répondre à des lacunes des applications qu’ils utilisent tous les jours.
• Hack days: dirigés ou non dirigés, pour faire surgir des idées par les équipes technologiques.

Les prototypes

• Prototype sur la faisabilité: pour lever les risques techniques, là aussi c’est une technique connue (spike).
• Prototype utilisateur: maquette interactive plus ou moins avancée graphiquement.
• Live-data: produit déployé mais sans tous les requis habituels (tests, sécurité, etc) et qui permet de collecter des données sur son utilisation.
• Hydride ou wizard of oz. C’est une maquette qui ressemble beaucoup au produit final mais derrière c’est un traitement manuel qui est fait.

Tester la faisabilité, la convivialité, la valeur client et la viabilité commerciale

• Évaluer la convivialité: il existe beaucoup de techniques très répandues autour de l’évaluation de l’expérience utilisateur. Je ne rentre pas dans les détails.
• Évaluer la valeur
  • en testant la demande: technique de la fake door i.e. un site dont le bouton “acheter” ne mène pas à un paiement mais sonde l’intention de passer à l’acte. Cela peut-être fait aussi au niveau de la fonctionnalité avec un faux bouton.
  • test qualitatif de la valeur: entrevues avec des clients sous forme de tests de l’expérience utilisateur car cela est un préalable pour poser des questions après sur la valeur. Mais le test ultime pour voir si la personne n’est pas simplement gentille avec vous: lui demander de payer ou partager sur les réseaux sociaux le produit.
  • test quantitatif de la valeur: live-data prototype, A/B testing, test sur invitation auprès de 1%, 10% des clients.
  • test de la faisabilité: un ou deux jours pour se faire une idée si techniquement c’est réaliste.
  • viabilité commerciale: est-ce que le produit ou fonction peut être supporté par le reste des processus de la compagnie sur les aspects financiers, légals, marketing, etc.

La bonne culture “Produit”

La dernière partie est consacrée à définir la culture propice au succès d’un produit. Il est difficile de résumer sans tomber dans la caricature mais voici quelques éléments:

• des équipes de missionnaires plutôt que des mercenaires.
• des équipes qui observent continuellement les difficultés rencontrées par leurs clients plutôt que de rassembler des besoins.
• des développeurs engagés à toutes les étapes
• Une forte innovation qui prend la forme d’expérimentations avec une ouverture d’esprit et une diversité de compétences.

Il y a bien d’autres aspects comme la culture “client” mais j’ai rassemblé ici les points qui me semblaient importants.

Conclusion

C’est un livre court mais qui va droit au but en abordant pas mal de sujets. Ce billet n’est pas exhaustif car il me servira en premier lieu comme aide-mémoire (comme beaucoup de mes fiches de lecture), mais aussi comme point de départ pour trouver d’autres sources d’information sur les techniques évoquées.

Pour résumer, l’équipe produit utilise des prototypes pour conduire des expérimentations rapides dans la phase de découverte puis on construit un produit dans l’espoir de trouver son marché (product/market fit) qui est l’étape essentielle dans la réalisation de la vison produit.

Il est parfois bon de revenir à l’essentiel et cet ouvrage est exactement ce qu’il faut pour avoir un résumé de ce qu’est la bonne gestion de produit.