Comprendre la valeur pour mieux la maximiser

Référence:

• https://www.meetup.com/fr-FR/NightClazz-By-ZenikaGrenoble/events/284968347/
• https://docs.google.com/presentation/d/1v5PvaF5JDFsIpzeIVECVKcERG8ythWvVAaByvSlSePU/edit#slide=id.g11fbf692181_0_0
• https://www.linkedin.com/video/event/urn:li:ugcPost:7003279774181675008/
• https://maximusd.medium.com/metrics-in-product-development-803734c11817

Le sujet est abordé sous l’angle de l’Agile. L’idée est de comprendre la valeur d’usage et la valeur “business” d’un produit ou d’un service, selon quels critères, et comment la mesurer.

La notion de valeur est assez complexe. L’approche présentée représente le point de vue personnel des présentateurs, basé sur leurs expériences et lectures.

Comprendre la notion de valeur

La valeur est mentionnée dans les cadres de l’agile (manifesto, le modern afile, etc.).

Le bénéfice

C’est une notion liée à un bénéfice :

• pour l’utilisateur, et le client, donc la valeur d’usage, et
• l’organisation, donc la valeur business.

L’idée est que les gens achètent un produit non pas pour le produit, mais pour ce qu’il leur apporte. Le produit, en lui-même, les importent peu : les utilisateurs et clients veulent qu’il leur apporte une progression. Il faut donc comprendre en quoi notre produit va leur permettre de progresser.

En fonction du niveau d’engagement

Le niveau d’engagement de nos utilisateurs va également nous permettre de savoir dans quel mesure nous pouvons les valoriser. Pour cela, nous adaptons notre façon d’interagir avec lui en fonction de son engagement avec nous.

• Utilisateurs sporadiques et décrocheurs : ces utilisateurs ont un besoin particulier, et le produit leur à permit d’y remédier. Cependant, ils n’ont pas accroché, pour diverses raisons (problèmes ponctuels, pas ergonomique à leur goût, etc.). Ils peuvent être une bonne source de retours (en analysant leur parcours, etc.). Ainsi, nous pourrons identifier quelle valeur nous pourrons leur apporter, pour faire évoluer le produit et essayer de les convertir en “Acquis”.
• Acquis : c’est la majorité des utilisateurs. Ils ont adopté le produit, mais sans plus. Nous chercherons alors à maximiser leur implication dans le produit, pour en faire des promoteurs. Ainsi, nous devons accroître la valeur que nous leur apportons… jusqu’à ce qu’ils soient à leur tour source de valeur pour notre produit.
• Promoteurs de la marque : ceux-ci sont déjà impliqués à fond sur notre produit. Ce sont les mieux placé pour toucher de nouvelles personnes, mais aussi comme cible pour la monétisation, car ils sont déjà impliqué dans le produit (Remarque : de part leur promotion, ils peuvent déjà être source de monétisation, suivant le modèle économique choisi). Un utilisateur devenu promoteur devient ainsi une source de valeur pour notre produit.

Savoir dans quelle proportion sont représentées ces catégories d’utilisateur permet d’orienter la stratégie pour notre produit sur la façon d’engager nos utilisateurs, ou d’exploiter leur engagement (i.e. pour la communication).

Identifier les points de friction, c’est-à-dire ce qui les ralentis, ou les bloques, dans leur utilisation du produit, est également une stratégie payante pour augmenter l’acquisition de notre produit.

Ainsi, on observe qu’accroître la valeur apportée à l’usage du produit permet d’accroitre l’engagement des utilisateurs, jusqu’à ce qu’ils deviennent à leur tour source de valeur pour l’entreprise.

Les deux sont ainsi liés, car on produit de la valeur business à partir de la valeur d’usage.

De l’organisation de l’équipe : de la feature factory à l’équipe produit

Si l’équipe ne maîtrise que le développement de la solution, elle n’aura la main que sur ce qu’on appelle l’output, c’est-à-dire la cadence de production, ou au mieux la qualité technique, de leur produit. Pas la qualité fonctionnelle, et encore moins la valeur apportée aux utilisateurs. Il est donc important de permettre à cette équipe de mûrir, et d’avoir accès aux besoins des utilisateurs, pour comprendre comment leur apporter cette valeur …

Processus de maturité

Souvent, l’entreprise évolue à partir d’une organisation dite “waterfall”, ou “cycle en V”, où chaque étape du processus d’élaboration du produit est isolée de la précédente et de la suivante. Une première évolution apportée par l’agile est la capacité à intégrer les tests, puis la livraison du produit au cycle de développement. On parlera ensuite de DevOps lorsque l’équipe sera capable de pousser les fonctionnalités jusqu’au déploiement en production.

L’idée sous-jacente est l’intégration progressive de l’ensemble des parties prenantes concernées par l’élaboration du produit dans le cycle agile (cela nous renvoi au Continuous Discovery, où la découverte d’opportunité se fait également de façon agile).

Orienté fonctionnalité

La feature factory est une équipe produit qui a pris la main sur tout le processus d’élaboration de son produit, depuis la conception des fonctionnalités, jusqu’à leur mise en production, généralement en suivant un cycle agile.

Le cap décisif se trouve alors dans la sélection des opportunités, le choix de la solution, et la plannification de ses solutions, qui restent encore entre les mains de la direction.

Dépasser ce cap implique de surmonter un blocage : la valeur est encore associée à la notion de fonctionnalité (“feature”), alors qu’elles ne sont pas systématiquement utilisées (ou appréciées) par les utilisateurs.

Au final, cela renvoi au problème output vs outcome (l’output étant la fameuse “feature”). Les symptômes permettant de reconnaître une équipe bloquée en production de fonctionnalité sont les suivants :

• l’équipe reste bloquée sur le “quoi” et le “comment”, mais ne passe peu ou pas de temps à travailler sur le “pourquoi”;
• se voit également par les entreprises qui maîtrisent mal le cycle de vie de leur produit, voir qui ont du mal à tuer un produit qui ne rencontre pas son public.

Passer le cap de la valeur

Passer le cap permet d’ailleurs de donner du sens au travail des équipes techniques : comprendre la valeur apportée à l’utilisateur est une source de motivation en soi.

C’est également un moyen pour donner de l’autonomie à l’équipe produit, notamment dans l’élaboration de leur roadmap. L’équipe conçoit ainsi la feuille de route de son produit, et au besoin, elle se reposera sur une feuille de route de plus haut niveau, soumise par la direction (cf. la stratégie).

Lorsque la direction veut encore apporter ses propres idées sur les solutions à mettre en place, l’équipe produit peut les intégrer à leur processus de recherche comme d’autres solutions identifiées par l’équipe produit. On a ainsi des exemples, comme celle de Spotify, qui fonctionnent sur un mode hybride “feature-produit”. Dans ces cas là, l’apport des solutions par la direction doit être justifiée par l’analyse du marché et des besoins clients.

Passer le cap nécessite de remonter à l’origine des opportunités :

• explorer le segment de marché sur lequel se positionne notre produit, et
• être capable de collecter les retours au plus près du client, afin d’identifier leurs besoins et les intégrer directement dans l’analyse des opportunités.

Enfin, cette analyse des opportunités doit être elle-même intégrée au travail de l’équipe produit. De la sorte, le processus agile s’est propagé sur l’ensemble du cycle de vie du produit.

L’équipe produit a alors la main pour définir la valeur propre à son produit, et aux fonctionnalités qui y seront intégrées.

Clés pour définir la valeur

Identifier le besoin

L’utilisateur a un travail qu’il souhaite faire aboutir (par exemple, Mario doit sauver Peach; se débarrasser des ennemis plus facilement, c’est juste un bénéfice pour atteindre plus facilement son objectif).

Il faut identifier en priorité le travail de notre utilisateur, et ses besoins. Cela nous conduit à construire des solutions pour répondre à ces besoins. On pourra ensuite générer des bénéfices pour l’organisation : la valeur business. Cette valeur business permettra ensuite d’investir, pour explorer de nouveaux besoins d’utilisateur. Ainsi, la boucle (agile) est bouclée.

Les besoins fondamentaux des utilisateurs n’ont pas de changements, du moins, les problèmes de fond restent les mêmes (comme le besoin de se déplacer). Ce sont les moyens proposés qui évoluent avec le temps (la marche, le cheval, la voiture, etc.).

L’exploration qualitative

Elle permet d’identifier les besoins fondamentaux.

• Se mettre en immersion pour observer (customer journey).
• Enquêtes, sondages, etc.
• Cartographie et analyse des besoins.

La Job Map

L’analyse des besoins peut être explorée avec la “Job Map” :

• Job To Be Done
• Définir le processus déroulé actuellement pour résoudre le besoin.
• Identifier le bénéfice que l’on peut apporter (réduction du temps d’attente, etc.).
• Définir un périmètre sur lequel notre solution peut apporter un bénéfice.
• Définir l‘“outcome”, ce sur quoi on apporte du bénéfice.
• Confronter l’importance et la satisfaction, avant / après, via une échelle (par exemple, de 1 à 5).

Avec la “Job Map”, on peut quantifier la valeur, par exemple : valeur = importance + max(importance - satisfaction, 0).

Exemple d’outcomes :

• plus de rapidité;
• plus de fiabilité;
• plus de connaissance;
• plus de liberté;
• etc.

Clés pour estimer la valeur

Valeur d’usage

On peut associer un niveau de priorité à la valeur trouvée grâce à la Job Map.

Une solution est que chaque partie prenante réfléchisse à la valeur qu’il donnerait à chaque fonctionnalité envisagée, puis de les classer sur une grille en fonction de la valeur obtenue.

NB : Il est important d’impliquer les personnes amenées à travailler sur ces fonctionalités.

Une seconde passe permettra de réajuster les estimations de chacun en fonction des résultats de la confrontation.

C’est bien beau, mais ce n’est pas si évident que ça : la valeur perçue peut être très différente de la valeur réelle. Adresser la dimension fonctionnelle d’un job n’est pas toujours suffisant, car il faut aussi prendre en compte les dimensions émotionnelle et sociale.

Par exemple, l’utilisateur peut chercher un créneau horaire d’un rendez-vous en situation de stress (émotionnel). On peut aussi parler de la façon dont la personne espère être perçue, en s’achetant le produit (c’est le marketing, avec l’exemple typique des produits Apple).

La valeur d’une solution évolue aussi en permanence, en fonction :

• du marché, de la concurrence;
• de l’environnement et de ses contraintes;

Il faut donc reconsidérer régulièrement la valeur de la solution sur laquelle nous travaillons.

Valeur business

5 types de valeur :

• marché (gagner des parts de marché, acquérir de nouveaux clients);
• rétention (fidéliser, que le client reste sur notre solution : fortement lié à la satisfaction);
• efficience (diminuer nos coûts et délais, de conception, de déploiement, la facilité de maintenance, etc.);
• anticipation (réduire les risques, en déterminant la facilité d’évolution et d’adaptation de notre produit);
• financière (augmenter les revenus et profits, combien le client est prêt à payer).

Ici aussi, nous ferons intervenir un collectif de parties prenantes. On part du besoin, pour estimer en quoi le réaliser va contribuer à notre valeur business. Ce sera ensuite les fonctionnalités développées qui disposeront d’une valeur business.

Clés pour en faire usage

Quels sont les bénéfices

Il faut également faire vivre la stratégie produit sur la base de la valeur que le produit apporte.

Il faut établir une priorité sur la base d’un ROI sur deux niveaux.

Au niveau startégique : portfolio / roadmap, epics, la valeur apportée (outcome et valeur business).

Au niveau opérationnel : product backlog (éléments plus techniques), fonctionnalités, etc.

Garder le focus

• Identifier les nouveaux besoins et fonctionnalités.
• Éviter le “produit touche-à-tout”, qui perdra rapidement sa valeur, autant d’usage que business.
• Savoir dire “non” (un sujet de meetup à part entière).
• Les petits changements n’existent pas.

ACID Test

C’est une série de questions fermées pour déterminer si on prend la fonctionnalité.

• Est-ce en ligne avec notre vision et proposition de valeur ?
• Le ratio valeur / effort est-il suffisant ?
• Cela aura-t-il toujours de l’importance dans x années ?
• Avons nous les compétences disponibles pour la développer ?
• etc. (la liste dépend de notre contexte d’entreprise)

Mesurer la valeur

La valeur est une hypothèse, jusqu’à ce que la solution soit déployée, et mesurée. Cette estimation se fera au moyen de quelques KPI pertinents (fréquence d’utilisation, la satisfaction, etc.) : qualitatif et quantitatif. Ces indicateurs permettent d’être plus objectif sur le bénéfice final (NB : “quelques”, moins de dix; au delà, ça signifie qu’ils ne sont pas pertinent).

Si la valeur décroche, il faut analyser le pourquoi, et investiguer comment on peut rattraper le coup. Cette analyse pourra nécessiter d’impliquer le Product Manager, car les raisons peuvent dépasser le cadre de la solution seule (par exemple, la communication sur le produit). Elle peut nécessiter d’aller auprès des clients. Le Product Manager peut également être la personne devant prendre les décisions sur la direction à prendre (on peut imaginer des répercussions sur la stratégie, par exemple).

Conclusion

valeur d’un produit

• Notion complexe.
• Subjective et changeante.
• Compliquée à estimer.

Facteurs clés de succès

• Equipe produit, en pleine possession de son produit, orientée outcome.
• Rendre explicite les hypothèses business (sur la base du collectif).
• Générer des conversations constructives.
• Mesurer, analyser et adapter pour transformer les hyopthèses en certitudes.
• Savoir dire non pour éviter de dériver de nos objectifs d’entreprise.