INSPIRED, How To Create Tech Products Customers Love - Marty Cagan

Couverture du livre

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:\

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 :

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

L’équipe Produit

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

  1. 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é:

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

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:

La planification

L’idéation

Les prototypes

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

Le processus Produit

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:

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.

billet publié dans les rubriques readings, gestion-produit le