Eviter le principal échec du Product Owner

Les Temps Modernes – Charlie Chaplin

Vous construisez une application, vous êtes dans les temps (mettez ce que vous voulez derrière cette expression), en Scrum (mettez aussi ce que vous voulez derrière ça) et vous vous apprêtez à mettre en production votre première version.

Et là vous, vos clients, vos utilisateurs, votre marché, n’accrochent pas, sont déçus, bref il y a de forte chance pour que vous ayez oublié une ou deux choses importantes en route et que votre produit se dirige clairement vers la case fiasco.

Quel est le problème ?

Peut-être connaissez-vous ce dessin de Henrik Kniberg qui montre l’opposition entre une démarche d’accumulation de fonctionnalités et une démarche de choix, parmi toutes les potentielles fonctionnalités, de celles qui apportent une rélle valeur.

Maximize Value, not output – Henrik Kniberg

C’est une première amélioration dans le chemin d’un responsable produit, pourtant ce n’est pas celle qui est capital.

Avant même l’apport de valeur, il est encore plus important de porter votre attention à votre réélle connaissance des problèmes de vos utilisateurs. Vous pouvez construire un produit avec beaucoup de valeur mais qui ne répond pas vraiment aux problèmes de vos utilisateurs.

Vos utilisateurs ne veulent pas une app, ils veulent résoudre leurs problèmes

Savez-vous pourquoi vous construisez ce produit ? Quels sont les problèmes rencontrés par vos utilisateurs cherchez-vous à résoudre ? Quels sont les résultats que vous cherchez à obtenir avec ce produit ? Comment savez-vous que ce que vous avez construit va permettre d’atteindre ces résultats ?

Si vous galerez à répondre à ces questions, il est temps de step up votre ranking en product ownership avec un outil que j’ai découvert chez Melissa Perri : le product Kata.

Démarche scientifique du produit

Vous avez oublié pendant que vous vous efforciez de construire votre produit de confirmer ou infirmer toutes vos hypothèses et vos biais de perception (exemple : ce qui me parait être bon pour moi, l’est pour mes clients / ce que je vois est la réalité absolue et c’est donc la réalité de mes clients / etc. ) par des expérimentations. Ca tombe bien la science nous a donné une démarche d’expérimentation qui fonctionne depuis des siècles 🙂 , nous allons voir comment Melissa Perri utilise cette démarche pour le produit.

Melissa Perri a d’abord piqué l’idée générale de Toyota Kata, mélange d’un kata d’amélioration et d’un kata de coaching. Kata d’amélioration – Toyota Kata

Elle a aussi repris l’idée de Mike Rother qui a adapté le kata à Kanban.

Dans tous ces katas, on retrouve les principaux ingrédients d’une démarche scientique : Observation, Hypothèse, Expérience, Résultat, Interprétation, Conclusion, qui coupe court à nos biais cognitifs 🙂

Cette combinaison de kata aboutit au Product Kata qui va chercher à améliorer le produit en continu et réduire l’incertitude autour de celui-ci par l’expérimentation et l’apprentissage.

Le Product Kata

Melissa Perri part aussi du postulat que de répondre à un problème utilisateur n’est pas simple et qu’au début nous ne savons absolument rien ni du problème, ni de comment y répondre, ni de la bonne façon d’y répondre.

Product Kata – Melissa Perri

C’est en itérant avec ce kata que nous pourrons lever les incertitudes et produire le bon produit.

Ce kata est une succession de 4 étapes que vous repetez à l’infini jusqu’à atteindre l’objectif final. A chaque fois que vous démarrez une action en lien avec votre produit, utilisez ces 4 étapes :

• Comprendre la direction que l’on prend. Quelle est la stratégie de l’entreprise, quels sont les grands objectifs business, etc.
• Analyser la situation actuelle. Où en sommes-nous en ce moment de nos connaissances et de notre produit en comparaison de la vision ?
• Décomposer et déterminer quel est le prochain objectif à atteindre.
• Choisir l’étape approprié dans le process produit (exploration du problème, exploration des solutions, optimisation de la solution)

En utilisant ce kata, on s’aperçoit aussi que le rôle du responsable produit ne démarre pas le jour où l’on démarre la réalisation du celui-ci mais bien en amont avec l’étape de découverte et d’exploration (Discovery).

Enfin si vous faites parti des Product Owner bloqué dans le delivery par un management ou un client directif et omniscient, cette démarche pourrait aussi vous servir 🙂 Quoi de mieux pour casser des idées reçues ou des demandes iréalistes que de demander à ce que ce soit basé sur des faits ? Peut-être même qu’il vous remerciera d’avoir redresser la barre juste à temps.