Et les titres provocateurs… Dans ce nouvel article je vous propose un point de vue léger sur un sujet très sérieux; l’approche produit.

Par essence chez CACD2, nous sommes amenés à gérer des projets pour les entités clientes. Pour ce faire, notre démarche repose sur l’intégration des approches agiles dans nos modes de développement. Il faut toutefois être conscient que l’agilité ne vise pas uniquement à optimiser les développements. L’enjeu c’est aussi et avant tout d’apporter de la valeur aux utilisateurs et à l’organisation en accélérant la boucle de feedback et d’apprentissage. Il s’agit d’une démarche humble. On prend conscience que l’environnement mouvant et complexe dans lequel nous évoluons nous oblige à reconnaître que nous n’avons pas toutes les réponses.

Démonstration.

Pour répondre à un objectif business donné ou pour adresser des attentes utilisateurs, il convient donc de faire des hypothèses qui vont se traduire en produits ou fonctionnalités que nous essaierons de mettre rapidement à disposition des utilisateurs ou des clients. Ce faisant, on obtient des feedbacks et on sait si l’on a visé juste ou pas.  On obtient aussi des pistes d’amélioration. Ce sont les concepts de MVP (produit minimum viable) et de fonctionnalité minimale dont vous avez peut-être entendu parler.

Vous comprendrez que ce processus prend du temps et c’est pour cela que je défends les avantages d’une approche produit par opposition à l’approche projet. Avec l’approche projet on a une date de début, une date de fin, un budget, un périmètre sur lequel on se met d’accord assez en amont. Dans cette approche, on considère que l’on a les bonnes réponses des semaines voire des mois avant que le produit ou la fonctionnalité ne soit disponible. On considère aussi que l’on connait tous les éléments extérieurs [à notre organisation] qui pourraient impacter le succès de notre produit (nouveaux usages, nouveaux produits, nouveaux acteurs sur le marché, technologies inaccessibles devenues moins coûteuses…). Bref, l’approche projet laisse peu de place à l’amélioration mais aussi et surtout à l’erreur car lorsqu’on se rend compte que le produit ne marche pas le projet est terminé. Finalement, c’est avoir une approche prédictive plutôt qu’empirique. Pour ma part, je ne prédis pas encore le futur 🙂

Dans le domaine du développement digital, l’enjeu de l’approche produit c’est bel et bien de se laisser le temps d’apprendre; apprendre sur nos enjeux, sur nos clients/utilisateurs, sur nos concurrents, sur les technologies. Un autre enjeu, c’est l’amélioration continue. Les sprints permettent l’amélioration du fonctionnement des équipes.  L’approche produit permet l’amélioration des connaissances, de la pertinence du produit et de l’organisation dans son ensemble. Rome ne s’est pas faite en un jour… Facebook, Amazon, Google ou BlablaCar non plus !

Si vous êtes arrivé jusque là,  vous cherchez peut-être le lien avec le titre de cet article et son contenu.

Love the problem, not your solution Article d’Ash Maurya

Cette phrase illustre parfaitement  la démarche que je décris plus haut et l’état d’esprit qu’il faut avoir selon moi pour l’initier. L’approche produit se concentre sur le problème client/utilisateur/organisationnel à résoudre; l’identifier, le définir précisément, le résoudre. L’approche projet se concentre sur le fait de très bien construire une solution pour un problème qui parfois n’existe pas. C’est en cela, que je vous incite à initier sur vos produits digitaux une démarche produit à plus long terme.

Initialement adressée aux innovateurs et aux créateurs de start-ups, il me semble que cette phrase résume assez bien ce qui devrait tous nous animer dans le digital. En effet, ne devrions-nous pas tous être un peu innovateurs ?