TUTORIEL : Product owner chez YouTube

Comme mentionné dans mon post d’introduction de ce nouveau format, aujourd’hui je réalise un tutoriel product owner en me mettant dans la peau d’un PO qui bosse chez YouTube.

Pour rappel, je ne travaille pas chez YouTube.
L’idée est de faire un exercice pratique (et ULTRA SIMPLIFIÉ) pour comprendre la phase de conception d’une fonctionnalité.

Dans ce post, je simule la spécification d’une nouvelle fonctionnalité pour un produit que tout le monde connait déjà.

Bonne lecture, 

Préambule

Dans cet tutoriel, on va imaginer que je viens d’être embauché comme product owner chez YouTube et que ma mission est ultra claire.
Disons que tout le travail de définition du besoin à déjà été fait (si je dois décrire comment définir et trouver le besoin moi même, je vous pond un livre).

Voici le brief :

• Ma mission principale sera d’augmenter le taux d’abonnement des utilisateurs aux chaînes YouTube 
• Les analystes produits ont découvert qu’un utilisateur s’abonnait à une chaîne après avoir visionné au moins 3 vidéos du même YouTuber.
• Les UX researchers ont découvert une opportunité dans le maillage interne des vidéos.
  • La majorité des vidéos publiées référencent d’autres vidéos au cours de la lecture

• Opportunité : Si les utilisateurs cliquent sur ces liens et visionnent les vidéos suivantes, le taux d’abonnement à une chaîne à de grandes chances de grandir.
• Hypothèse : Augmentation de 10% d’abonnement par session utilisateur

Bon je sais, augmenter l’engagement chez YouTube c’est un peu comme essayer de rendre l’eau plus liquide.

On parle d’un des produits avec un taux d’engagement qui est déjà parmi les plus hauts du monde.

Néanmoins, le principe de ce « tutoriel product owner » n’est pas de juger de la pertinence de la mission. Je le rappelle C’EST UNE FICTION.

L’idée est de comprendre le travail d’un product owner en coulisse.

1ère étape : Comprendre le problème.

• Problème 1 : A l’heure actuelle, si un utilisateur clique sur un lien en cours de lecture, la vidéo s’interrompt.
  Cela provoque beaucoup de frustration
  
• Problème 2 : Si au contraire, l’utilisateur visionne la vidéo jusqu’au bout, dans 80% des cas, il ne visionnera pas les autres vidéos mentionnées car il va oublier.

2ème étape : Définir les cibles

Dans cet exemple, je vais concevoir une solution pour 1 seul type d’utilisateur.

• Les  utilisateurs qui vont au bout d’une vidéo et veulent voir plus de vidéos pertinentes à la fin de la lecture sans chercher et sans oublier.

(Je sais plus simple tu meurs…).

3ème étape : Détails de la solution

Pour la solution, je ne vais pas aller chercher bien loin, je vais m’inspirer de l’Autoplay de Netflix.

Si vous regardez des séries sur Netflix, vous avez remarqué qu’à la fin d’un épisode, l’épisode suivant se joue automatiquement au bout de quelques secondes. On vous laisse pas le temps de réfléchir.

De la même manière, à la fin de la vidéo visionnée, l’idée est de lancer automatiquement la lecture de la première vidéo mentionnée.

Si l’utilisateur a aimé la vidéo 1, il y a des chances qu’il aime la vidéo 2 du même YouTubeur qui est en lien avec la première vidéo.

4ème étape : Définition des ressources

Pour ce genre de petit projet, je vais faire simple.

Primo, afin de ne pas faire un post trop long, je vais me concentrer sur la plateforme web uniquement (oubliez le mobile).

Il va me falloir :

• Un développeur frontend (HTML 5)
• Un développeur Backend
• Un analyste produit ou Data scientist
• Un testeur

Restons simple encore une fois, pas besoin d’UX.

5ème étape : Organiser mes specs.

Pour m’organiser je vais utiliser Jira et je vais commencer par créer un Projet que je vais appeler tout simplement YouTube

Ensuite comme je vais arriver sur un backlog vide, avant de créer mes US, je vais créer une épic “Abonnement chaine”.

L’idée d’une épic est de pouvoir se repérer dans le backlog quand il commence à devenir dense et de pouvoir regrouper toutes les US ayant le même thème

NB: Ici je n’ai pas ce problème car je travaille sur un seul projet et mon backlog est vide.

Dans cette épic je vais regrouper toutes les US relatives au projet “Booster l’abonnement aux chaînes”

Il y a aura des US pour le FrontEnd, des US pour le Backend et même des US pour l’analyste produit (si si je vous explique après).

Afin de différencier les US par type de technologie, je vais ajouter un Label spécifique aux US pour chaque Expertise.

• Si l’US s’adresse à l’analyste produit, je vais mettre le label DATA
• Pour le développeur backend, je vais mettre le label BCK
• Pour développeur frontend, je vais mettre le label FRT

6ème étape : Comment je découpe ça en user stories ?

La difficulté ?

Il faut juste penser à bien mapper toutes les possibilités et SURTOUT penser à tout tracker.

US 1 : Utilisateur non connecté.

TITRE DE LA USER STORY :

Autoplay recommandation vidéo pour utilisateur non connecté

APERÇU :

L’utilisateur non connecté YT qui visionne une vidéo en entier veut voir les vidéos recommandées par le créateur de la chaîne automatiquement afin de s’immerger dans l’univers de la chaîne. 

CRITÈRES D’ACCEPTANCE :

Assigné au développeur back-end

• Si l’utilisateur visionne entièrement une vidéo avec 2 recommandations, l’autoplay déclenchera la 1ère recommendation
• S’il visionne encore entièrement la seconde vidéo alors l’autoplay déclenchera la 2ème recommandation de la vidéo 1.
• Si la vidéo 2 a elle même une autre recommandation, elle viendra s’ajouter à la file d’attente des recommendations de la vidéo 1
• Ainsi de suite.

Si chaque vidéo dispose de recommandations alors cela vient agrandir la file d’attente et forcément augmenter potentiellement l’engagement de l’utilisateur.

Attention, si une vidéo est recommandée dans plusieurs vidéos ou à déjà été visionnée (ce qui est très probable avec un maillage interne) alors :

• Il faut éliminer la vidéo de la file d’attente et passer à la suivante.

COMPORTEMENT UX

• Déclencher la vidéo suivante sous 3 secondes maximum
• Pendant les 3 secondes, afficher le loading traditionnel (icone play)

Bénéfices
Evidemment, il y a peu de chances que l’utilisateur visionne toutes les vidéos, mais cela lui permet d’engager plus longuement avec une chaîne et augmenter les chances qu’il s’y abonne.

SOUS TACHE 1 : Tracking Google Analytics :

Assigné au développeur Front-end

Tracker les événements autoplay dans Google analytics

Evénement 1 

Category-action-label  =  Titre-video_play_autoplay

Ajouter une value = IDToken

Evénement 2 

Category-action-label  =  Titre-video_subscribe_autoplay

Ajouter une value = IDToken

SOUS TACHE 2 : Entonnoir de conversion dans Google Analytics :

Assigné au PO ou au chef de projet marketing.

Bâtir un tunnel de conversion en utilisant les événements 1 et 2 de la sous tâche 1.

• Nommer l’entonnoir de conversion : Autoplay Tracking for visitor
• Description : Tracker l’engagement visiteurs via fonction autoplay
• Événement 1 : titre-video_play_autoplay_idtoken
• Objectif de conversion : titre-video_subscribe_autoplay_idtoken
  

US 2 : Utilisateur connecté.

Bon là je passe, c’est exactement la même US que la précédente, les seules 2 vraies différence sont :

• Au niveau du tracking, je vais utilisé la value profileID au lieu de la value tokenID car c’est un utilisateur connecté.
  Du coup je vais bâtir un autre entonnoir de conversion pour comparer les performances entre les utilisateurs connectés et non connectés.
• Au niveau de l’abandon, si un utilisateur quitte le tunnel autoplay à un moment donné sans s’être abonné à la chaîne, je suis tenté d’ajouter les vidéos de recommandations sur sa page d’accueil lors de ses 2 prochaines visites pour réactiver l’intérêt.

Pour que ce tutoriel product owner soit facile à comprendre, je ne vais pas trop aller dans les détails et ne pas ajouter trop de complexités.

US 3 : Mise en place A/B test

C’est pas tout de tracker l’usage mais on va quand même pas exposer cette nouvelle fonctionnalité à tout le monde. Imaginez que c’est un Flop.
On va assurer ses arrières et faire un test A/B

Il y a 100 façons de faire un test A/B mais dans cet exemple, je vais tenter un test A/B opéré via le backend (j’imagine que c’est ce que YouTube fait).

TITRE DE LA USER STORY :

Test AB pour la fonctionnalité autoplay

APERÇU :

L’équipe produit veut réaliser un test A/B sur la fonctionnalité autoplay afin de mesurer l’impact sur les taux de souscription des abonnements aux chaînes par utilisateur.

CRITÈRES D’ACCEPTANCE :

Assigné au développeur back-end

Format du test A/B 

• Former des groupes d’utilisateurs en fonction du dernier nombre du profile ID ou du tokenID
• Normalement il doit y avoir 10 groupes profile ID  = 0,1,2,3,4,5,6,7,8 ou 9
• Et 10 groupes token ID = 0,1,2,3,4,5,6,7,8 ou 9

Dans la première phase de ce test A/B, nous allons tester la nouvelle fonctionnalité sur 20% des utilisateurs.

• A = 0,2,3,4,5,6,7,9
• B = 1 et 8 (j’ai pris ça au hasard)

Par conséquent A = control group 

et B = utilisateurs étant exposés à la nouvelle fonctionnalité Autoplay

US 4 : Dashboard test A/B

Tout le monde fait différemment mais comme j’aime bien utiliser un seul outil pour tout le monde, j’écris souvent des US pour les analystes produit ou data scientists sur Jira.

C’est plus facile pour piloter le projet de bout en bout et tout le monde comprends Jira (en principe).

Dans cette US, comme j’ai opéré un test A/B via le backend, j’ai besoin d’un outil pour visualiser les résultats et la progression du tests.
Il y a plein d’outils pour ça sur le marché : Chartio, Tableau etc… 

Encore une fois, il y a des solutions sur le marché tout en un pour réaliser des tests A/B.
Néanmoins, une boite performante a toujours son propre outil pour aller beaucoup plus loin dans la personnalisation du test.

TITRE DE LA USER STORY :

Création du dashboard Autoplay

APERÇU

L’équipe produit souhaite disposer d’un tableau personnalisé afin de suivre l’évolution du test A/B de la nouvelle fonctionnalité Autoplay.

CRITÈRES D’ACCEPTANCE :

Assigné au product analyst (ou n’importe qui qui gère le python coté data)

TACHE 1 : Créer un tableau utilisateurs non connecté

A = control group

B = Autoplay group

Données à visualiser : 

• Total Nombre utilisateur A 
• Total Nombre utilisateur B 
• Taux de significance
• Définition point de départ : get_function (videoview)
• Définition conversion : get_function (subscribe)
• Représenter ratio video vues / abonnement entre A et B
  • Subdiviser par total depuis démarrage test A/B
  • Subdiviser par jour (UTC time comme repère)
• Ajout de filtres 
  • Zone géo
  • Langues

Avec ça, je devrais avoir un petit tableau me permettant de comparer la différence entre le taux d’abonnement par chaîne entre A et B et mesurer l’impact de la fonctionnalité autoplay.

En fonction des résultats et du taux de significance, je pourrais piloter le test A/B et décider de l’arrêter ou d’augmenter la valeur de B.

TACHE 2 : Créer un tableau utilisateurs connectés

Idem que la tâche 1.

Dernière étape : On perd pas de temps

Une fois toutes ces étapes de recherches et de conception, je vais  pouvoir rentrer dans la phase de chiffrage (backlog grooming), et planification (sprint planning) avec mon équipe afin d’aborder les phases de fabrication, testing et livraisons.

J’enfonce encore une porte ouverte, mais surtout je n’oublie pas d’embarquer mon testeur dans le grooming pour qu’il puisse préparer ses scénarios de tests avant le sprint planning.

Si tout le monde est OK et comprend l’objectif, c’est parti, il n’y a plus qu’à.

Dans quelques semaines, la fonctionnalité Autoplay sera sur le marché et j’observerais les résultats (10 fois par jour) pour voir si cette fonctionnalité est un succès ou un flop.

Conclusion :

Voilà à tous les POs en herbe, j’espère que ce petit tutoriel product owner fictif vous est utile pour comprendre un peu le cheminement d’une spécification d’une fonctionnalité.

J’ai fait simple, seulement 4 US et 2 sous tâches. 

Si vous devez retenir qu’un seul truc c’est que le plus dur n’est pas de concevoir.

J’ai aussi pas mal oublié de détails par ci par là mais écrire une fonctionnalité et la commenter en même temps, ça demande d’écrire beaucoup et en faisant plus compliqué j’ai eu (très) peur d’en perdre certains.

La prochaine fois,  je changerai de plateforme et de technologie, on fera du mobile.

Si possible, j’essaierais de me concentrer sur des US plus orientées interface design UX / UI.

A toute,