Le Product Kata, ou l’art d’éviter le principal échec du Product Owner

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). Enfin, vous vous apprêtez à mettre en production votre première version. Et là vous, vos clients, vos utilisateurs, votre marché, n’accrochent pas. Ils 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. Le product Kata peut peut-être vous aider.

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éelle valeur.

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éelle connaissance des problèmes de vos utilisateurs. En effet, vous pouvez construire un produit avec beaucoup de valeur. Cependant, celui-ci 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 avez du mal à 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 par des expérimentations. Par 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.
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.

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 scientifique : Observation, Hypothèse, Expérience, Résultat, Interprétation, Conclusion, qui coupe court à nos biais cognitifs 

Cette combinaison de kata aboutit au Product Kata. Ce dernier 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.

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 répétez à 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 de celui-ci. Il démarre 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 irré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.

Un article rédigé par 

David Beck

Coach Agile chez Aneo

Profil Linkedin ⋅ Site internet