Vous inquiétez pas, rien de bien méchant, juste un pauvre fou qui pense tout haut :
(Attention, cet opinion n’est basé que sur un ressenti et ne s’appuie sur aucune donnée statistique tangible)
Je viens de lire le message d’une personne qui pose une question plus que pertinente sur le forum ( Ateliers métiers et feedback utilisateur ) et je me fais la remarque que la communauté Scrum de manière générale est très pauvre non seulement en ressources sur le sujet, mais surtout en construction de communautés transverses sur le sujet.
Que ce soit à travers les réseaux sociaux, les forums, les conférences (un peu moins) ou les chaines Youtube ( 20 vidéos depuis le dernier sujet connexe avec la très bonne vidéo featuring
Albane Veyron ), les ponts et connexions entre le domaine de l’ingénierie sociale (Scrum) et de la recherche utilisateur, de l’ergonomie, de la sociologie, … sont faibles.
Je rappelle, encore une fois, que je ne me base sur aucunes données statistiques vis à vis de ce que j’avance. Mais l’impression que la communauté prêche « le feedback utilisateur est essentiel et indispensable » sans donner les outils pour aller chercher ce feedback de manière efficace me laisse perplexe.
Je partage un peu ce constat. Quand j’ai (re)découvert le product management, je me suis fait la remarque que le monde Agile, pas seulement Scrum, avait peu à offrir en termes de Discovery.
Avec Cynefin, je me suis même dit que les méthodes agiles sont peu utiles pour mener des explorations avant d’avoir le product market fit. Dave Snowden parle de techniques « pre-scrum ». Chaque contexte ses méthodes, chaque méthode son contexte.
Les communautés Scrum sont très pauvres sur le sujet, je suis d’accord.
Mais c’est normal : ce n’est pas l’objet de Scrum.
Obtenir et organiser ce feedback utilisateur est le cœur de la mission du PO.
C’est lui l’expert en la matière, appuyez-vous sur les PO pour ça.
Le fond du problème, c’est qu’on entend à tort et à travers un peu partout que « le PO doit être un expert métier ». Honnêtement, je doute que les gens qui propagent cette croyance aient vraiment déjà fait des projets avec des PO qui soient de véritables experts métier. Pour ma part j’en ai fait plusieurs, c’est loin d’être mes meilleurs souvenirs. Ne me faites pas dire ce que je n’ai pas dit : oui, un PO doit comprendre le métier dans lequel son produit évolue. Comme tout chef de produit.
Mais le cœur de son expertise, c’est le marketing.
Et en marketing, le feedback utilisateur c’est la vie. Au point que des grosses entreprises payent des sommes considérables pour que des centres d’appels téléphoniques entiers passent leur temps à appeler de gens au hasard dans l’annuaire pour leur poser des questions. Au point d’être prêtes à offrir un voyage tout frais payés et même quelques goodies à des inconnus pour qu’ils viennent passer un journée à dire ce qu’ils pensent de leurs produits (existants ou en amont d’une mise sur le marché).
Alors si le PO n’a pas une bonne compétence en marketing, forcément, on part mal. Mais tout n’est pas perdu, on trouve aujourd’hui d’excellentes initiations gratuites au marketing. Il suffit de savoir un peu quoi chercher. Il y a une littérature considérable sur ces sujets. Il suffit d’aller sur google et rechercher « comment faire une étude de marché ? ». Il y a aussi une littérature très abondante sur l’UX design. Là encore « UX design techniques » sur google donne d’excellents résultats. Et pour les grands débutants, il y a même des cours d’initiation très complets et gratuits. Mais par contre, oui, c’est pas des contenus étiquetés « Scrum » ni même « PO ».
Le plus difficile, c’est peut-être d’admettre qu’il faut former les PO au marketing …
Dans les entreprises que j’ai pu faire, cette responsabilité direct n’était donne à l’équipe. Il faut croire que cette partie la est trop « metier » pour la laisser en autonomie. C’est une des raisons pour lesquelles, on peut penser que ce sujets n’est pas assez traités.
Néanmoins il est possible de contourner cette présupposé responsabilité. Dans la tete de non sachant, le terme de retour (feedback) ne se fait seulement en face à face ou avec à l’aide d’un questionnaire. Or en mesurant l’utilisation de notre produit on obtient bien plus de retour qu’à travers des retours directs
Je partage aussi ce constat… Ce n’est qu’une impression aussi, et je peux me douter que c’est parce que ce sont des développeurs / architectes / leaders qui ont créé ce mouvement, plutôt que les Product Managers qui eux se sont intéressés au Discovery. Donc c’est logique que le mouvement Agile se soit mis sur sa partie.
Et je pense que s’il faut attendre que ce soit les POs qui se mettent tous à faire du marketing, c’est le serpent qui se mord la queue : attendons que ce soit les autres qui s’y mettent ! …
Les agilistes devraient, s’ils veulent s’adapter à un avenir complexe et chaotique, se mettre réellement aux techniques de Discovery. Tout du moins c’est ma conviction personnelle. Et personnellement je les encourage ! Sortons de notre cocon
Après, dans les grands groupes, qu’ils fassent déjà tourner une CI (voire CD, oula) correcte, on verra plus tard pour de l’innovation et du pivot /troll
Ce que je décris c’est plutôt le métier qui n’a pas d’autonomie.
Enfin c’est plutôt qu’ils ne peuvent pas. Éventuellement, ils font un rôle de BA. Mais sans faire de marketing. Parce que faire du marketing c’est décider d’aller prioriser telle ou telle feature sur les autres. Donc c’est prendre une décision. Donc c’est pas un « métier » qui fait ça.
C’est le management …
Alors j’ai aucun problème avec le fait que ça serait bien que les devs comprennent aussi un peu de marketing et de product management / discovery et qu’on arrête de trop segmenter.
Mais par contre, dans ce cas là, ton PO … euh, à quoi il sert ?
A prendre des décisions sur le produit, pour accélérer la prise de décision sur la partie business et utilisateur.
A aider à gérer les parties prenantes.
A aider les devs à pouvoir accéder aux utilisateurs.
A communiquer sur le produit.
Et s’il veut même pas apprendre le marketing : il sert à rien. Voilà. Non sérieux, si même pas un peu de marketing, c’est pas un PO.
Et des POs comme ça, il y en a à la pelle : ça s’appelle des chefs de projets technique ou fonctionnel. Et la réalité du terrain, c’est ça : il y en a pleins.
Il y en a pleins qui ne savent pas où commencer, j’en accompagne une en ce moment, et c’est important en tant qu’agiliste d’être là pour mentorer. On est là pour aider celles et ceux qui le demandent. Evitons encore une fois le serpent qui se mort la queue : attendons que les managers prennent des formations pour les POs en marketing… Je l’ai jamais vu.
Et « faire du marketing c’est décider d’aller prioriser telle feature » c’est faux. Le marketing, c’est de l’analyse des besoins. Si je me faisais l’avocat du diable, c’est aussi créer le besoin.
Tu peux prendre une décision sans comprendre le besoin. C’est sûrement une bêtise, mais ne t’inquiète pas, ça arrive tous les jours dans beaucoup d’entreprises, et c’est au moins dans les scale ups pour ça que le PMM (Product Marketing Manager) commence à arriver pour épauler les PO=PM qui ont trop de taff à cause de la complexité grandissante de leur entreprise et de leur produit.
J’ai envie d’aller plus loin… C’est pas « créer le besoin », c’est s’imaginer que le monde dans sa plus simple expression peut s’expliquer par de l’offre, de la demande et un prix entre les deux. Même pour de l’interne. Même pour des personnes sans moyens. Même sans concurrence.
Oui je suis en accord avec les réponses de benjamin et adrien.
Ce que je trouve difficile avec cet d’accompagnement c’est de réussir à les faire sortir de leur schéma de penser qui as pendant longtemps été imposé
J’ai eu la même impression à propos de « l’excellence technique ».
Scrum (et l’agilité en général) l’évoque sans donner de solution.
Je l’ai longtemps regretté mais je réalise maintenant que cette attente n’est pas légitime.
Scrum est un cadre.
« Scrum ne vous dit pas comment résoudre vos problèmes, il ne fait que les révéler ».
Après, chaque contributeur doit, dans on domaine d’expertise, aller chercher « ailleurs » les solutions.
L’état de l’art pour chaque membre de l’équipe est à trouver dans les communautés « métier ».
La communauté Scrum va regorger de conseils pour les ScrumMaster
Mais en aura moins pour les PO, les développeurs, les UX Designer…
Chacun doit aller chercher dans les communautés des pratiques pour lesquelles ils ont des expériences/appétences (Crafter…)
), les ponts et connexions entre le domaine de l’ingénierie sociale (Scrum) et de la recherche utilisateur, de l’ergonomie, de la sociologie, … sont faibles.
/troll