Blog

Conférence, Digital, Innovation

La Product Conf 2018 : illustrations concrètes sur l’agilité et l’UX

Par Cyril Oukhtomsky, Product Owner / Coach Agile chez Backelite

21 juin 2018, la Chesnaie du Roy, Vincennes. Autour de moi : on navigue autour de la trentaine, on est plutôt barbe et baskets que cravate et cheveux blancs. J’entends d’une oreille une discussion : “On est au dernier sprint avant une release, le PO ne va pas changer tout le parcours client maintenant, ça attendra la prochaine itération.” Pendant l’introduction, je note les mots-clés “communauté”, “partage”, “numérique”.

Pas de doute, je suis bien à La Product Conf #3, la plus grande conférence en Europe autour du Produit, avec les 530 Product Managers rassemblés ici par Thiga.

Pendant cette journée, j’ai assisté à des présentations d’intervenants qui avaient pris le temps de prendre du recul sur leur façon de travailler et qui savaient communiquer leur enthousiasme :

“Être la voix de l’utilisateur : créer un produit pour les sourds”
– par Barbara Vogel et Olivier Jeannel de RogerVoice
– appli mobile avec speech-to-text et synthèse vocale pour permettre aux sourds de passer des appels téléphoniques

“Piloter des équipes produit par l’impact”
– par Christopher Parola et Nicolas Baron de Meilleurs Agents
– mise en relation de particuliers ayant un projet immobilier avec des agents immobiliers
– après deux ans de pratique de l’agile, mise en place d’une organisation en “impact teams”

“Des produits qui bousculent une culture : le freefloating”
– par Vincent Chavoutier ex-GobeeBike et Alban Sayag ex-Obike
– services de vélos en libre service sans borne
– GobeeBike a fermé son service en Europe à cause des vols et dégradations

“Construire un produit d’IA pour des humains”
– par Martin Boutges de Clustree
– outil de recommandation basé sur une IA, pour les RH de clients type CAC 40 : reco de postes aux employés, reco de candidats internes aux RH

“Faire un produit sexy sur un marché qui ne l’est pas”
– par Léa Mendes de Everoad
– mise en relation entre expéditeurs de marchandises et transporteurs routiers, pour limiter le nombre de camions roulant à vide

Dans ces conférences, j’ai retrouvé des points de vue partagés chez Backelite, et déjà appliqués sur les projets que nous menons pour nos clients. Je partage dans cet article des exemples d’outils, de pratiques, d’illustrations concrètes mentionnés par les intervenants, ainsi que certaines spécificités de leurs secteurs d’activité respectifs.

Comprendre les utilisateurs

C’est aujourd’hui une évidence pour tout Product Manager : une approche UX est nécessaire pour comprendre les utilisateurs, leur contexte, leurs aspirations, leurs contraintes, leurs parcours, leurs émotions.

RogerVoice nous incite à ne pas nous perdre dans la technique et le “quoi” et à garder en vue le “pourquoi”, le problème auquel on veut répondre, dans leur cas : trouver une solution pour que les sourds puissent passer des appels. Mais sur ce type de service, l’empathie a ses limites et l’équipe produit n’a pas pu anticiper toutes les attentes, par exemple : dans la synthèse vocale, proposer seulement une voix de femme s’est révélé problématique pour les utilisateurs hommes  ; l’ajout d’une annonce en début d’appel pour recommander à l’interlocuteur d’articuler pour faciliter le speech-to-text ; la nécessité de retranscrire les émotions qui passent par l’intonation, etc.

De son côté, Everoad intervient sur un marché confronté à des évolutions radicales (bientôt le camion autonome), un marché atomisé où de très petites structures travaillent avec des process surannés (on parle ici de fax, voire de mails imprimés, annotés et renvoyés par courrier postal…) Une approche UX a permis à Everoad d’identifier un des besoins primaires de ces petites structures : “je veux être payé à temps pour ne pas mettre en danger ma trésorerie” et également d’identifier dans ses personae un homme (plus sujet au daltonisme), dans la cinquantaine (vraisemblablement presbyte), à qui on évitera donc de proposer une interface avec un fond vert, une type grise et un faible contraste.

Deux points d’attention soulevés par GobeeBike et Obike. Difficile d’imaginer a priori l’impact que mon produit aura sur les non-utilisateurs : des centaines de vélos placés dans les rues auront forcément un impact sur la circulation, ce qui nécessitera de travailler avec les pouvoirs publics. Et sur ce marché impliquant une maintenance coûteuse, ne pas négliger les outils backoffice dans la définition du “produit” : une interface performante pour la gestion de la flotte et des réparations permettra de limiter les coûts (390 des 400 vélos déposés à Reims avaient été vandalisés…)

Enfin Martin Boutges évoque sa vie précédente chez Blablacar et un algorithme pour aider les conducteurs à fixer le prix de leur trajet, algorithme confronté aux arguments irrationnels de certains utilisateurs : “ma voiture est plus propre que les autres” ou “j’ai toujours fait payer 15€”. Il nous rappelle qu’un produit avec une IA aujourd’hui sera forcément décevant pour des utilisateurs qui s’attendent à un résultat quasi-magique et qui tolèrent bien moins facilement une erreur chez un algorithme que chez un humain.

D’où l’importance de la pédagogie auprès des utilisateurs : a minima indiquer la présence d’un algorithme, ou, mieux, expliquer cet algorithme, quitte à le vulgariser. Par exemple sur Clustree : expliquer à un employé pourquoi on lui suggère tel poste, expliquer à un RH pourquoi on lui propose tel candidat. Et l’importance au lancement d’un projet avec un nouveau client d’évaluer la qualité de données en entrée et de travailler avec ce client pour optimiser la phase d’apprentissage.

Impliquer les équipes techniques

Là aussi, c’est aujourd’hui une évidence : quand Backelite organise son événement BKJam (trois jours de service design), des tech lead sont intégrés aux équipes.

MeilleurAgents nous rappelle que le temps est passé où les équipes techniques étaient exclues de la réflexion et cantonnées à l’exécution en bout de chaîne : aujourd’hui on partage la vision produit, les objectifs, le “pourquoi” avant le “comment”. Parallèlement, lorsque le Codir fixe des objectifs, ce sont des objectifs macro ; les objectifs micro, le détails des fonctionnalités, les parti-pris techniques étant laissé à l’appréciation des équipes.

Clustree a un discours similaire concernant les data scientists, qui doivent, de concert avec le product manager faire des choix fonctionnels et techniques qui sont très liés : sur l’interface utilisateur, passer une échelle de recommandation de plusieurs niveaux (vert, jaune, orange) à un seul niveau (montrer ou pas un item) permet de simplifier considérablement l’algorithme ; suivant la complexité de la fonctionnalité et les efforts de développement, les data scientists pourront aiguiller le product manager vers un jeu de règles métiers simples ou vers un algorithme.

“Discover” puis “deliver”

Encore un point maintenant bien accepté : il est risqué de se lancer dans le développement sans avoir validé les fonctionnalités auprès des utilisateurs. Everoad en a fait les frais : après 3 mois de développement, une appli mobile MVP est lancée… qui ne rencontre pas son public, les fonctionnalités ne correspondant pas aux usages. Everoad a depuis changé son fusil d’épaule et alterne les phases “discover” et “deliver” : validation d’hypothèses (par exemple sur la base de maquettes animées) puis développement des hypothèses validées, afin de minimiser les déchets.

L’interface de MeilleursAgents est déjà bien en place, mais les évolutions fonctionnelles se font sur ce même principe. Toute nouvelle idée est formalisée : un fait chiffré + une hypothèse à tester + un process de test (indicateur, outil de mesure). Les idées pertinentes sont développées sous forme d’un POC. Une fois le POC déployé, on mesure le résultat et seules les fonctionnalités avec un impact probant sont développées de manière industrielle.

Ce mode de fonctionnement est bien accepté par les équipes car il a donné lieu à un contrat : pour le POC, on accepte d’écrire du code “quick and dirty” (parfois en une semaine), car on prendra le temps de (ré-)écrire du code propre pour la partie industrielle (parfois plusieurs mois).

Un bémol soulevé par RogerVoice : cette approche s’applique bien à leur frontend, mais la complexité de leur backend, notamment la connexion avec les systèmes télécoms a forcé une approche “tout ou rien”, difficile de commencer petit et d’améliorer de manière itérative…

 

Product management et stratégie d’entreprise

Dernier point : ne négligeons pas les interactions entre le product management et les autres enjeux de l’entreprise : organisation, business model, communication, contraintes techniques.

Par exemple, Léa Mendes mentionne un impact de l’organisation sur le produit, rencontré dans son passé chez Prestashop. Des silos étanches entre les directions responsables des différents outils à destination des clients, donc des chartes graphiques très différentes entre le backoffice de gestion et le store de modules complémentaires, donc des utilisateurs qui ne comprenaient pas que le store était bien géré par Prestashop, et pas par des éditeurs externes !

Chez Everoad, un des rôles des CDO (design) et CPO (product) est justement d’assurer la cohérence de l’expérience client de bout en bout.

Chez MeilleursAgents, pour pouvoir déployer une organisation en impact teams, inspirée par le framework OKR, ce sont plusieurs prérequis techniques qu’il a fallu mettre en place : tests automatisés (la ceinture de sécurité), déploiement continu (plusieurs fois par jour si nécessaire), plateforme d’A/B testing (pour mesurer les impacts). D’autre part, un gros effort de communication interne a été nécessaire pour éviter de donner une impression d’autonomie des équipes plutôt que d’anarchie.

Au-delà de l’organisation, ça peut être la stratégie d’entreprise qui influe sur le produit. Chez GobeeBike le pari sur un marché “winner takes all” a incité à déployer un produit pas encore idéal, mais la réalité du marché a montré que les utilisateurs zappaient entre plusieurs applis concurrentes, choisissant le meilleur service à l’instant t : pas de prime au premier entrant, mais au meilleur produit.

Dans l’autre sens, le business model initial de RogerVoice était centré sur le B2C, afin de répondre au “pourquoi” : faciliter la vie des personnes sourdes. Avec la mise en application en octobre 2018 du pan accessibilité de la loi pour une République numérique, RogerVoice a vu une opportunité dans le B2B, le produit a évolué et s’est déportalisé sous forme de widgets sur le sites de clients.

 

En guise de conclusion

Si vous avez lu cet article jusqu’ici, j’imagine que vous partagez ces principes agiles et UX. Et vous, en voyez-vous des implications concrètes sur vos projets ?

 

Crédits photos : La Product Conférence