Stratégie Produit : votre backlog sert-il votre vision ?

Dans beaucoup d’organisations, la vision Produit existe. Une stratégie a été définie. Une roadmap est partagée et le backlog est régulièrement priorisé. Sur le papier, tout est là. Mais lorsqu’on regarde les sujets sur lesquels les équipes travaillent réellement, il n’est pas toujours évident de comprendre en quoi ils contribuent à la stratégie Produit et, plus largement, à la vision que l’on cherche à atteindre.
Pourtant, vision, stratégie, roadmap et backlog ne sont pas des exercices indépendants. Ils doivent fonctionner ensemble, comme un même système.

Comme le résume Roman Pichler, expert international en gestion de produit, auteur et coach reconnu, “Great products […] aren’t built by separating strategy from execution. They’re created by connecting them.”

De la vision au backlog : une logique de cascade

La vision donne le cap : elle porte le "WHY", la raison d'être fondamentale du produit. Elle décrit le changement que le produit cherche à créer sur le long terme et doit être suffisamment inspirante pour mobiliser les équipes, fédérer les parties prenantes et inviter au changement.
La stratégie précise ensuite la manière d’avancer dans cette direction. Pour Pichler, elle doit notamment clarifier les besoins utilisateurs et clients adressés, le segment de marché ciblé, les objectifs business et les éléments qui permettent au produit de se différencier. Cela suppose de faire des choix, car une stratégie Produit n’est pas une liste de tout ce que l’on pourrait faire. Elle permet justement de décider où concentrer les efforts.
Néanmoins, ces décisions reposent nécessairement sur des hypothèses. Et ces dernières doivent être confrontées à la réalité pour être validées ou infirmées : recherche utilisateur, données, prototypes, expérimentations, etc.

On distingue ainsi la discovery, qui permet de construire et dé-risquer une stratégie, du continuous strategizing, qui permet ensuite de la faire évoluer dans le temps. 
Une première bonne pratique consiste donc à identifier les hypothèses les plus risquées de la stratégie et à chercher à les valider avant d’investir davantage.

La roadmap doit traduire la stratégie, pas le backlog

Vient ensuite la roadmap. Son rôle n’est pas simplement de donner de la visibilité sur les fonctionnalités qui seront développées dans les prochains mois. 
Elle doit d’abord être orientée vers des objectifs produits (Product Goals) et des résultats tangibles (outcomes). Autrement dit : quel impact cherche-t-on à obtenir, pour répondre à quel besoin et servir quel objectif business ? Les fonctionnalités arrivent ensuite comme des moyens possibles d’atteindre ce résultat.

Les métriques et KPIs prennent donc une place importante. Livrer une fonctionnalité ne suffit pas à dire qu’un objectif est atteint.
La roadmap sert également à arbitrer entre les objectifs, les échéances et les coûts ainsi que les éventuelles dépendances avec d’autres produits. Lorsque plusieurs produits contribuent à une même proposition de valeur, une portfolio roadmap peut aussi permettre de garder cette cohérence globale.

La logique devient donc :
Vision → Stratégie → Roadmap → Backlog

Puis le backlog précise ce qui doit réellement être fait pour atteindre le prochain objectif Produit.
C’est simple sur le papier. Dans la réalité de beaucoup d’équipes, cette logique a tendance à s’inverser assez vite.

Quand le backlog finit par piloter la roadmap

Le backlog reçoit en permanence de nouveaux sujets : demandes utilisateurs, besoins métiers, contraintes techniques ou réglementaires, demandes commerciales, améliorations UX… Et la plupart de ces sujets sont parfaitement légitimes.
Le risque est plutôt d’accumuler des demandes qui ont toutes du sens individuellement, sans vérifier régulièrement qu’elles contribuent encore aux objectifs de la roadmap.
La priorisation devient alors essentiellement un arbitrage entre demandes.
Quelques réflexes peuvent éviter cette dérive :

• Rattacher les sujets majeurs du backlog à un objectif du produit ;
• Expliciter le résultat attendu avant de discuter de la solution ;
• Définir les métriques qui permettent de vérifier ce résultat ;
• Questionner les sujets qui ne peuvent être reliés à aucun objectif ;
• Garder suffisamment de flexibilité pour faire évoluer la solution lorsque les apprentissages le nécessitent.La roadmap doit donc donner un cadre au backlog. Pas être reconstruite après coup à partir de ce qu’il contient déjà.

Une cascade, mais aussi des vases communicants

Attention, cette cascade ne doit pas fonctionner uniquement du haut vers le bas.
Comme Pichler le formule : “All Connections are Bidirectional.” 
Une fonctionnalité moins utilisée que prévu, un KPI qui n’évolue pas, un retour utilisateur ou l’apparition d’un nouveau concurrent peuvent conduire à revoir le backlog. Mais aussi la roadmap et, lorsque c’est nécessaire, certains choix de stratégie.

C’est là que l’image des vases communicants prend tout son sens.
Vision → Stratégie → Roadmap → Backlog
mais également :
Résultats et apprentissages → Backlog → Roadmap → Stratégie
Tous ces niveaux n’ont évidemment pas vocation à changer au même rythme.

Le backlog évolue régulièrement. La roadmap et la stratégie ont besoin de davantage de stabilité. Mais elles ne peuvent pas non plus être figées.

Pichler parle ainsi de continuous strategizing, c’est-à-dire d’une stratégie envisagée comme “an ongoing process rather than periodical work”.

Une bonne pratique est notamment de prévoir de vrais temps de revue de stratégie, en regardant les KPIs mais aussi le marché, la concurrence, les nouvelles technologies et les retours des équipes. Associer les principales parties prenantes et des représentants de l’équipe de développement à ces revues permet aussi de remonter les signaux. 

Collaborer ne signifie pas pour autant décider de tout par consensus. L’équipe Produit doit rester suffisamment autonome pour prendre les décisions dont elle est responsable.

Et avec l’IA ?

L’IA rend cette réflexion encore plus importante. Elle peut déjà faciliter certaines activités : analyser des retours utilisateurs, consolider de l’information marché, identifier des tendances, prototyper ou explorer des solutions beaucoup plus rapidement.
Elle peut donc soutenir la discovery comme le continuous strategizing. Mais elle ne remplace pas le travail stratégique : Plus il devient facile de produire et de tester, plus le nombre de choses qu’une équipe pourrait faire augmente. Et c’est justement là que la stratégie garde toute sa valeur : choisir ce qui mérite réellement d’être fait.

Finalement, l’enjeu n’est pas uniquement d’avoir une vision, une stratégie, une roadmap et un backlog bien formalisés. Il faut surtout maintenir le lien entre eux dans le temps.
La vision donne le cap. La stratégie permet de faire des choix. La roadmap traduit ces choix en objectifs mesurables. Le backlog permet de travailler concrètement à leur atteinte. Puis les résultats et les apprentissages doivent pouvoir repartir dans l’autre sens.

L’objectif n’est donc pas seulement d’aller plus vite, mais de vérifier régulièrement que l’on avance toujours dans la bonne direction.

Pour aller plus loin

L'intégration de l'intelligence artificielle redéfinit en profondeur le rôle des équipes Produit et la conduite de la stratégie. Pour explorer ces transformations et découvrir des cas d'usage concrets, nous vous invitons à consulter nos deux publications de référence réalisées avec mc2i et Essensei :

• Product Owner et IA : comment en faire un usage éclairé ? - Une analyse détaillée sur l'impact de l'IA au quotidien et les clés pour booster l'efficacité sans perdre le cap stratégique. 
• L'équipe produit sans Product Owner - Une réflexion prospective sur la réorganisation des rôles au sein des équipes Produit à l'ère de l'automatisation.