Une approche orientée produit : Melissa Perri, Escaping the build trap
Qui n’a pas entendu parler, au moins de loin, de l’approche orientée produit ? Après la méthode Agile, elle apparaît comme la nouvelle révolution intellectuelle du secteur. Quelle est cette méthode, quels sont ces principes et les problèmes auxquels elle clame répondre ?
Lorsque j’ai démarré en tant que Product Owner, j’avais faim de structure dans ce nouveau métier que j’apprenais sur le tas. J’ai eu la chance de croiser un collègue plus expérimenté qui m’a suggéré plusieurs lectures. Elles tournent autour de l’enjeu très actuel du produit et de l’organisation du travail en informatique. A la lecture de ces ouvrages, j’en retire un certain apaisement et une direction à tenir dans mon rôle. Comme elles m’ont été très utiles, je vous restitue ici une version résumé de ma lecture de l’ouvrage : Escaping the build trap, how effective Product Management creates real value de Melissa Perri édité pour la première fois en 2018.
Si la méthode Agile permet, grâce à sa boucle de feedback rapide, de s’assurer que l’équipe développe un produit qui satisfait le client et les utilisateurs sans impliquer de changement dans les coûts et les délais, elle s’applique durant la phase de delivery. La méthode Agile n’adresse pas le postulat de départ que l’entreprise développe le bon produit pour répondre à ses enjeux stratégiques. La phase d’investigation sur cette adéquation du market-fit se fait usuellement en amont et n’est plus challengée par la suite. Pour Melissa Perri, à toutes les étapes du développement, il faut s’assurer que le produit développé est en adéquation avec la vision stratégique de l’entreprise et son positionnement marketing au même titre qu’il réponde à un besoin ou une envie des utilisateurs. Pour ce faire, c’est toute l’organisation de l’entreprise qu’il faut revoir. L’auteure propose une méthode pour répondre à cet enjeu. Ainsi, elle revient sur le rôle du product manager, l’établissement de la stratégie d’entreprise, l’organisation des développements et enfin l’organisation en elle-même de l’entreprise.
Comme cet ouvrage est fait de plein de préconisations, j’ai choisi de vous les résumer sous le format Do’s and Don’t pour rapidement mettre en valeur les problèmes auxquelles ses méthodes sont supposées répondre.
Définition du Product Manager
Intitulé de carrière à distinguer de l’usage SAFe du terme. Dans le chemin de carrière dessiné par Melissa Perri, le Product Manager commence par endosser le rôle de Product Owner dans une Scrum Team avant d’évoluer toujours dans du Product Management jusqu’à Chief Product Officer (CPO)
| Do’s | Don’t |
|---|---|
| Il est chargé du “pourquoi”. Dans quel but l’équipe travaille ? Quels sont les problèmes auxquels elle doit répondre ? | Il se concentre sur le “quoi” au lieu de le partager avec l’équipe au même titre que le “comment”. Cela ne le met pas dans la posture où il doit identifier les problèmes auxquels son produit doit répondre. |
| Il investigue les zones de flou et réduit le champ d’inconnu lors de l’exploration d’une solution envisagée pour résoudre le problème ou répondre au besoin / envie. | Reprend les idées de solutions des stakeholders au risque de développer un produit qui leur plaît à eux mais pas à ses utilisateurs finaux. |
| Il se concentre sur le problème posé à l’équipe. Il sait interroger son client sur le problème. | Il se concentre sur la solution proposée par le client lui-même. Il risque de travailler sur une solution qui ne répond à aucun problème. |
| Il utilise des solutions rapides, simples ou bien identifiées si elles n’apportent pas grand-chose à la chaîne de valeur. | Il passe du temps sur des solutions sophistiquées et uniques sur des éléments qui ne sont pas au cœur de la chaîne de valeur. Il fait de la sur-qualité. |
Les bonnes questions à se poser en tant que Product Manager face à une fonctionnalité :
|- Quel est le but ?
- Où en sommes-nous maintenant par rapport à ce but ?
- Quel est le plus gros problème ou obstacle m'empêchant d’atteindre ce but ?
- Comment est-ce que j’essaye de résoudre ce problème ?
- Qu’est-ce que j’espère qu’il va arriver (hypothèse) ?
- Que s’est-il effectivement passé et qu’en avons-nous appris ?
|
Méthode du Kata Produit
Méthode qui permet de se concentrer sur l’identification des bons enjeux et problèmes auxquels le produit doit répondre. Le Kata produit est une méthode simple qui permet de gagner en impact en s’obligeant sans cesse à se remémorer le contexte dans lequel les développements sont réalisés. Sans jamais perdre de vue l’objectif stratégique global**, établi par la direction, il faut prendre en compte l’état courant du produit pour se donner un objectif aligné avec tous ces éléments. Le développement va permettre de faire avancer le produit dans une direction et il est toujours important, à l’issu de ce dernier, de revenir à la vision stratégique pour s’assurer que le produit développé est aligné avec la vision globale. 
Les métriques
Les métriques sont des hypothèses mesurables qui vont nous permettre d’identifier si les développements ont permis d’atteindre l’objectif fixé. Ex : augmentation du taux de rétention sur l’application de 10% des utilisateurs. Certaines métriques sont non pertinentes (vanity metrics) car elles ne permettent pas de vérifier une hypothèse. Une bonne métrique permet de répondre à une question que l’on s’est posée sur les fonctionnalités livrées.
| Do’s | Don’t |
|---|---|
| Se concentre sur des mesures permettant d’identifier le succès en production de l’objectif des fonctionnalités livrées. Le succès n’est atteint que si la fonctionnalité résout un problème, répond à un besoin ou à une envie du client. | Se concentre sur les résultats (le nombre de fonctionnalités livrées en production par exemple) : ce sont des vanity metrics qui n’ouvrent pas sur des questionnements mais seulement sur la satisfaction du travail réalisé. Mais ce travail a-t-il permis de résoudre un problème ? |
| La rétention est une mesure cruciale pour vérifier une adoption pérenne du produit par les utilisateurs finaux | Se concentre uniquement sur l’adhésion sans se soucier si le produit, une fois pris en main, convainc dans la durée les utilisateurs. |
L’organisation
Dans une entreprise orientée produit, toute sa structure est adaptée à à cette démarche autant au niveau de l’équipe que de l’entreprise elle-même. Ainsi, le travail d’une équipe est mesuré sur des résultats et non sur de la quantité. L’entreprise récompense ses employés sur la base de leur apprentissage et leur atteinte d’objectifs et non toujours sur des quantités livrées ou vendues. Les équipes produits sont encouragées à se rapprocher de leur utilisateurs et le Product Manager est vu comme un pilier essentiel qui permet d'accroître le business.
Organisation d’équipe
La manière dont le travail est réparti dans les équipes va permettre de diffuser la connaissance mais aussi éviter la sur-qualité ou non-responsabilisation.
| Do’s | Don’t |
|---|---|
| Le périmètre de l’équipe doit être déterminé par un macro-objectif à remplir. La ou les équipes sont chargées de déployer l’ensemble des fonctionnalités (hypothèses) nécessaires pour relever le défi. Elle doit s’assurer jusqu’en production que les fonctionnalités permettent d’atteindre cet objectif. Une fois l’objectif rempli, elles changent de périmètre. | - Limiter le périmètre de l’équipe à une ou plusieurs fonctionnalités : l’équipe se concentre pour les livrer et développer toujours plus de chose autour de ces fonctionnalités sans reprendre en compte l’objectif global du produit - Donner une partie des briques applicatives du produit : l’équipe n’optimise pas son développement dans une perspective métier mais technique. - Dans les 2 cas : l’équipe continue à travailler alors que les enjeux ont déjà été relevés : il y a un risque de faire de la sur-qualité |
Organisation d’entreprise
L’organisation de l’entreprise au global va permettre le développement ou non de ces phases exploratoires (culture d’entreprise, liberté et autonomie, droit à l’échec).
| Do’s | Don’t |
|---|---|
| L’entreprise a une stratégie claire et ne développe que les produits en phase avec celle-ci. Elle abandonne les autres. | Elle développe coûte que coûte des (bons) produits alors qu’ils ne sont pas en phase avec la stratégie. Cela crée de la dispersion de l’effort et un flou autour de la stratégie de l’entreprise. Elle ne tue pas un produit parce que son développement est trop avancé alors qu’il n’est pas aligné avec sa stratégie. |
| L’intention stratégique de l’entreprise est clairement communiquée aux équipes pour qu’elles soient autonomes dans l’ensemble de leurs actions (investigations, réalisations) pour atteindre les objectifs. | Elle ne communique pas clairement aux équipes son intention stratégique. De ce fait, les équipes ne sont pas capables de prendre des décisions alignées avec celle-ci et elles perdent en autonomie et responsabilité. |
| La roadmap est une explication de la stratégie et de l’état actuel du produit autour des 4 stades de développement du produit : - l’expérimentation (exploratoire, aucun code de production, permet de tester très rapidement des hypothèses), - le stade Alpha (code robuste de production) - Beta (mise à l’échelle) - la généralisation | La roadmap est un diagramme de Gantt avec des jalons de livraisons à atteindre. Les équipes se concentrent davantage sur le fait d’atteindre ces jalons que sur le produit et s’il est suffisamment mûr/pertinent pour continuer d’évoluer. |
| Les intéressements et rémunérations des membres de l’équipe produit sont liés à l’apprentissage et la résolution de problèmes. Cela encourage les phases exploratoires y compris quand elles n’aboutissent pas sur un produit fini. On peut conclure que le produit n’est pas pertinent pour l’entreprise. | Les intéressements et rémunérations sont liés à la capacité à livrer des fonctionnalités et produits. L’effort des salariés se fera sur le fait de livrer des fonctionnalités coûte que coûte et non sur leur alignement avec les objectifs de l’entreprise. |
| Le financement du développement d’un produit est un capital-risque (à l’image du fonctionnement des start-up) : cela permet de prévoir des fonds pour la recherche de nouvelles opportunités. Tout le budget est lié au fait de faire passer des produits à des stades différents | Le budget est annualisé et n’est pas flexible par rapport à l’exploration de nouvelles opportunités. Cela rend difficile voire impossible les phases exploratoires et donc la vérification d’hypothèse. |
En conclusion, la pierre angulaire de l’approche de Melissa Perri se résume de la manière suivante :
- L’entreprise doit prévoir, organiser et permettre à l’équipe d’explorer des hypothèses de solution en phase avec sa stratégie d’entreprise.
- L’équipe valide ou invalide le plus rapidement possible leurs hypothèses tout en optimisant le ratio valeur / coût avant de passer dans des phases de fiabilisation de la solution.
Pour cela :
- Le product manager tâche de récupérer toutes les données quantitatives et qualitatives possibles pour valider et surtout invalider toute hypothèse de solution le plus rapidement possible. Son rôle est le plus souvent celui de dire non.
- L’équipe envisage des solutions simples et rapides à mettre à place pour rapidement récupérer du feedback sur les solutions qui ont été envisagées
L’on peut s’en douter, si j’ai choisi de vous résumer l’ouvrage de Melissa Perri, c’est que j’y ai trouvé un intérêt dans ma pratique du Product Ownership. Cela me rappelle l’importance :
- d’être proche de ses utilisateurs et de bien identifier leurs problématiques
- de savoir dire “non” à des features
- de bien choisir ses métriques
- de ne jamais oublier qu’une feature n'est qu'une hypothèse qu’il nous appartient de vérifier à sa mise en production.
Cela m’a également permis de me rendre compte que tous les éléments n’étaient pas en ma possession pour véritablement adopter une approche produit bout-en-bout.
Si l’on est convaincu de l’intérêt de la démarche proposée par Melissa Perri et que l’on souhaite opter pour cette orientation produit, ce n’est pas seulement en formant les Product Owner ou Product Manager, bien que pilier de cette démarche, que nous pouvons aboutir à un véritable changement. Ces derniers doivent être imprégnés de cette culture produit et être acteurs de l’évolution mais il ne s’opère véritablement qu’avec le soutien de toute l’entreprise. Cette méthode Produit doit opérer le même coup de force que celui de la méthode Agile, en pénétrant les organisations jusque dans leur squelette. Et c’est dans un commun effort qu’une entreprise peut véritablement basculer dans une approche orientée produit où toute cette dernière est garante de se poser éternellement la question : “Est-ce que le produit que je suis en train de développer, aussi bon soit-il, est le bon pour mon entreprise ?”