Product Development : Ca vous dirait pas un peu d’entrainement ?

Vous voulez comprendre ou apprendre des compétences en développement produit ? Ce post est le chapeau d’une série de 5 posts d’exercices. Le développement produit, c’est une discipline qui vise à apporter de nouveaux produits sur le marché avec comme maitres mots innovation et incertitude.

Je les ai découpé en 5 parties Comprendre, Explorer, Décider, Construire, Valider qui correspondent peu ou prou au design sprint de google ventures. Je vais utiliser le fil rouge de la vente en ligne de produits frais avec comme exemple Auchan Direct.

Voici un résumé des différentes étapes :

• Comprendre pour créer une compréhension commune du problème auquel on pourrait répondre
• Explorer pour s’ouvrir le champ des possibles
• Décider pour se focaliser sur ce qui semble faire le plus de sens
• Construire parce qu’à l’arrivée il y a un client
• Valider car rien ne vaut le feedback client

C’est super ton truc, mais à quoi ça sert ? Tu ne vas pas m’apprendre à faire des spécifications. C’est le style de remarque que j’entends assez souvent et ma réponse est simple : j’explique des concepts qui s’appliquent dans le paradigme des systèmes complexes. On y croit ou pas, je ne débats pas des avantages et inconvénients d’une approche par rapport à une autre. Je présente une façon de voir les choses.

Je me lance dans une courte explication du modèle Cynefin pour expliquer dans quel cadre je me positionne. Cynefin est un modèle d’aide de prise de décision qui classe les situations dans 4 domaines :

• Simple : la relation de cause à effet est simple et connue par tous. Je veux du pain, je cherche un magasin de la catégorie ‘boulangerie’
• Chaotique : la relation entre cause et effet est inconnue et elle le sera toujours. Agis et réagis, c’est tout ce que tu peux faire.
• Compliqué : après analyse, on peut faire le lien de cause à effet. Je suis dans l’analytique et le cartésianisme. Le futur est la répétition du passé. Je construis une voiture, cela n’est pas simple. Mais une fois que je l’ai fait une fois, je peux le répéter à l’envie. Pour parler IT, nous sommes dans le monde des méthodes prédictives.
• Complexe : la relation de cause à effet peut être déterminée après coup. Je vais devoir fonctionner par expérimentation et voir ce qui marche et ce qui ne marche pas. Nous sommes dans le monde des méthodes adaptatives comme l’agile et le développement produit. Je peux tenter de tout analyser, cela ne me permettra pas de déterminer à coup sûr le résultat. Est-ce que dans le développement informatique, on écrit deux fois le même code ? J’y crois moyen et donc nous sommes plus dans la découverte permanente.

Les exercices qui suivent dans les 4 posts ont été écrits avec pour cible les maîtrises d’ouvrage qui veulent se former à des pratiques adaptées aux systèmes complexes. Il n’y a, par contre, pas de prérequis et ils sont donc accessibles à un public plus large. Et pourquoi pas les appliquer directement sur des cas réels ? Je pars du principe qu’il est préférable de s’entraîner avant de jouer un match de compétition. C’est pour cela qu’on les appelle des katas, c’est par la répétition de gestes (pratiques) que l’on acquiert des réflexes.

Je suis preneur de feed-backs pour les améliorer, donc n’hésitez pas à me pinger sur LinkedIn.

Début

Il est temps de passer aux exercices avec le premier post ‘comment créer une compréhension commune’.