Le paradoxe de la roadmap produit : entre stratégie et réalité opérationnelle

Nous sommes lundi matin, et déjà le responsable produit se dirige vers une réunion angoissante : la revue de roadmap !

L'ordre du jour concerne la fonctionnalité d'optimisation des courses, qui doit traiter des cas particulièrement pointus. Tous ont préparé des arguments solides pour appuyer leurs estimations et ont peaufiné plusieurs scénarios de livraison. On sait que la confrontation sera rude.

Pourtant, la roadmap est l’outil idéal pour opérer la jonction entre la stratégie d’entreprise et sa déclinaison opérationnelle au sein des équipes produit. C’est censé être avant tout un support d’alignement stratégique au sein de l’organisation. Alors, pourquoi ces discussions tournent-elles à la confrontation ?

La roadmap produit classique représente sur une frise chronologique les fonctionnalités qui seront réalisées. Il s'agit avant tout de mettre en avant leur disponibilité espérée pour les clients.

Dans le cas des lignes de produit, des produits distincts peuvent interagir, traiter les mêmes données et souvent partager des composants internes. Cette frise peut alors s’étaler sur plusieurs lignes.

Il s’agit bien sûr de mettre en cohérence deux paramètres majeurs de la roadmap :

• La date cible de livraison d’une fonctionnalité, généralement dictée par des impératifs stratégiques
• L’estimation de la charge de travail nécessaire afin de concevoir, réaliser et livrer cette même fonctionnalité

C’est précisément de cette double contrainte que naît le paradoxe de la roadmap produit : elle est à la fois un outil de projection stratégique, pensé top-down, et un outil de planification opérationnelle, soumis aux réalités du terrain. Quand ces deux logiques entrent en tension, la promesse d’alignement s’efface au profit de la confrontation.

 

Quand la capacité pilote la roadmap

Pour les équipes de réalisation, l’exercice est simple : la date de livraison sera subordonnée aux estimations. À partir de là, il est simple de calculer une date estimative en prenant en compte la capacité de l’équipe.

Selon cette logique, la date de livraison est “subie”, subordonnée au plan de charge du delivery. Cette logique a certes le mérite du réalisme. Elle est aussi subie, car les imprévus peuvent remettre en cause les dates prévisionnelles. Et puisque cette logique est capacitaire, toutes les dates de livraison suivantes se trouvent impactées par un effet de domino.

Pour reprendre notre cas de la fonctionnalité d’optimisation des courses : si la prise en compte des contraintes horaires s’avère complexe, c’est toute la séquence de fonctionnalités suivantes — livraisons multiples, regroupements ou optimisation des trajets — qui sera mécaniquement retardée. La capacité de l’équipe agit ainsi comme une contrainte dure qui pilote la roadmap.

Ce mode de gestion est connu depuis longtemps, puisque c’est celui qui a donné naissance au diagramme de Gantt, il y a plus de 110 ans. Certes, la représentation visuelle d’une roadmap capacitaire diffère de celle d’un diagramme de Gantt, mais ce n’en est pas moins la même chose. La logique reste inchangée : une planification linéaire guidée par la charge et subie par les délais.

Malheureusement, les “jalons subis” ne sont pas du goût des garants du pilotage stratégique de l’organisation.

 

Quand la stratégie contraint la roadmap

Une organisation définit sa stratégie de produit et de services sur la base d’un positionnement de marché ; puis, à partir de là, sur la base d’une promesse de valeur adressée à ce segment de marché. Or la promesse de valeur portée par un produit ne s’exprime pas uniquement dans sa conception : elle se déploie dans le temps, au rythme du marché, d’attentes utilisateurs et de contraintes extérieures. Ce déploiement obéit à plusieurs dynamiques stratégiques que la roadmap doit refléter :

• Anticipation concurrentielle : certaines fonctionnalités doivent être mises à disposition avant que la concurrence ne s’en empare, afin de préserver un avantage différenciant ou renforcer la position sur un segment de marché.
• Rythmicité et impact utilisateur : conserver l’intérêt et l’engagement des clients suppose un flux régulier d’évolutions tangibles.
• Évènements structurants du marché : salons professionnels, lancements partenaires, pics saisonniers (tourisme, retail, jeux) imposent des jalons non négociables qui structurent le calendrier produit.
• Exigences réglementaires ou légales : le respect de nouvelles normes ou contraintes subordonne la livraison de fonctionnalités à une date fixe, sous peine de conséquences négatives lourdes.

La logique de la stratégie fonctionne à l’inverse de celle du delivery : on fixe des jalons par rapport aux nécessités de la mise en œuvre de la stratégie, le reste n’est que du rétroplanning. Ainsi, si l’entreprise prévoit de présenter sa solution lors du salon du transport et de la logistique en septembre, il faudra disposer d’une première version opérationnelle de l’optimisation des courses avant cette échéance, quitte à limiter le périmètre fonctionnel. Le tempo est piloté par l’impératif stratégique.

Dans le meilleur des mondes, c’est bien la logique de la stratégie, fondée sur le sens, la valeur et les enjeux business, qui devrait guider la construction de la roadmap produit. Mais, si aucun mécanisme d’arbitrage n’est mis en place, ces deux logiques antagonistes arrivent en collision frontale. Et cette collision se manifeste par la revue de roadmap que nous avons évoquée au début.

De l’autre côté, si l’on n’adresse pas clairement ce paradoxe, ce sera bien la logique de la delivery qui prévaudra, car après tout, ce sont eux qui réalisent le produit.

Mais cette situation n’est pas une fatalité. Il est possible de construire un véritable alignement stratégique, à condition d’aménager un espace de manœuvre suffisant. Ce qu’il faut, c’est créer la latitude nécessaire pour réconcilier les deux dynamiques.

 

La nécessité de donner de la latitude n’est pas non plus nouvelle. Elle n’a pas attendu l’agilité. Elle remonterait même aux années 50, peut-être même avant !

Le triangle de fer : un outil encore d’actualité

Le triangle de fer est l’approche classique pour adresser l’ajustement des projets. Il s’appuie sur trois paramètres interdépendants (le périmètre, le coût et le délai), mais dont seuls deux peuvent être véritablement maîtrisés simultanément. Le quatrième paramètre, la qualité, n’est pas pilotable directement : il résulte des choix opérés sur les trois autres. C’était vrai hier, ça l’est encore aujourd’hui.

 

• Le périmètre : du point de vue fonctionnel, il définit l’ensemble des fonctionnalités ou des éléments que doit contenir le produit.
• Le coût : il correspond aux ressources mobilisées pour le projet, en premier lieu la taille de l’équipe. Renforcer celle-ci avec du renfort externe n’est pertinent que dans une perspective de long terme, car il faut prendre en compte la montée en compétence de ces nouvelles personnes. Un renfort interne à l’organisation sera opérationnel plus rapidement, mais au détriment d’un autre produit ou d’autres projets de l’organisation.
• Le délai : Nous l'avons vu précédemment, dans l'approche capacitaire, c'est le paramètre par défaut privilégié par les équipes produits, faute de pouvoir négocier les deux autres la plupart du temps.

L’approche agile choisit résolument la négociation sur le périmètre, jusqu’à une adaptation permanente de celui-ci. Plutôt que de figer d’emblée l’ensemble des fonctionnalités, on accepte d’adapter en continu le contenu du produit pour maximiser la valeur livrée, au regard des retours utilisateurs et de la capacité de l’équipe. Dans des environnements incertains, la plasticité de l’approche la rend particulièrement pertinente. Mais, prise au pied de la lettre, elle devient incompatible avec le pilotage d’une roadmap, puisque la notion de jalon disparaît. La communication et l’alignement organisationnel perdent alors en consistance.

Du point de vue du pilotage stratégique, cette logique de négociation permanente sur le périmètre est perçue comme une succession de renoncements. Les discussions autour de la roadmap deviennent difficiles, car elles s’installent sur un terrain où la flexibilité opérationnelle est vécue comme une remise en cause des engagements stratégiques.

On a donc besoin d’une voie médiane, combinant maîtrise des jalons et flexibilité sur le périmètre, sans rentrer dans une logique de renoncements !

 

L’approche design-to-cost : arbitrer sans renoncer

Pour y parvenir, il est nécessaire d’introduire une logique budgétaire. Cela permet de piloter la roadmap en contrôlant les jalons. L’approche classique qui met en pratique ce principe est le Design to Cost. Le principe consiste à fixer un cadre économique, puis concevoir et ajuster les fonctionnalités de manière à rester dans ce budget tout en respectant les échéances.

Ce principe est pratiqué depuis longtemps dans l’aéronautique, où la conception d’un avion s’appuie sur des “budget poids” accordés à ses différents sous-ensembles. Don Reinertsen s’en est directement inspiré pour les principes économiques de son Product Development Flow.

Dans le domaine logiciel, on peut remonter à la méthode EVO de Tom Gilb (1976). EVO accorde un budget aux fonctionnalités, et la conception doit se livrer à une série d’arbitrages sur les propriétés du système pour rester dans ce budget : fonctionnalités, prise en compte des cas aux limites, performance, scalabilité, ergonomie.

Cela nécessite bien sûr que la hiérarchie des compromis possibles entre ces propriétés soit claire et partagée.

Dans notre exemple d’optimisation des courses, si le budget alloué est contraint, l’équipe pourra décider de privilégier la performance des calculs, ou encore de simplifier l’ergonomie pour concentrer l’effort sur la scalabilité.

Malgré tout, cette approche reste difficile. Elle suppose à la fois de disposer d’options concrètes pour ajuster les coûts, et de s’assurer que les compromis réalisés demeurent acceptables en termes de valeur et de qualité.

L’alternative, qui s’inscrit toujours dans le principe du Design to cost, est de s’appuyer sur nos savoir-faire agiles que nous avons écartés en premier lieu, mais en les utilisant dans un cadre bien spécifique.

 

Passer de la construction à la progression de valeur

La vision traditionnelle de l’élaboration d’un produit repose sur une logique de construction : le produit ou la fonctionnalité est décomposé en briques constitutives. Pour qu’une fonctionnalité soit opérationnelle, il faut que l’ensemble de ses briques constitutives soit réalisé et assemblé. Cette logique donne peu de marge de manœuvre : tant qu’on n’a pas tout, on n'a rien ! Cette approche reste le paradigme dominant, y compris sur de nombreux projets qui se prétendent agiles.

La démarche agile nous propose un paradigme alternatif : faire grandir la fonctionnalité en tranches fonctionnelles fines, partant du cas le plus simple et allant progressivement vers des cas plus complexes.

Pour notre fonctionnalité d’optimisation des courses, nous commencerons par des courses avec un seul point de livraison sans contrainte horaire, puis nous introduirons progressivement les livraisons multiples, groupés, les fenêtres horaires de livraison, etc.

La construction de la séquence de tranches fonctionnelles (vous pouvez les appeler User Stories) reflète la progression de valeur discutée entre le client et l’équipe produit.

Il y a un lot minimum de tranches à réaliser pour que la fonctionnalité soit opérationnelle en production, ce que Mark Denne et Jane Cleland-Huang appellent le MMF pour Minimum Marketable Feature. Ce sera le budget minimum sous lequel on ne pourra pas descendre.

Les tranches suivantes représentent la progression de valeur au sein de la fonctionnalité : plus on pourra en embarquer en restant dans le budget, plus importante sera la valeur !

Cette approche combine la flexibilité avec un choix délibéré sur la valeur. Elle nous ouvre aussi la voie sur des approches de roadmap en rupture avec le focus sur la fonctionnalité.

Lors d’une présentation TED restée célèbre “Start with why”, Simon Sinek nous confie qu’il faut subordonner l’action et le produit au pourquoi, ce qu’il illustre avec le “golden circle”.

La roadmap produit centrée sur la fonctionnalité nous éloigne de ce pourquoi, tout en nous enfermant dans une solution pour laquelle les marges de manœuvre sont limitées.

D’autres types de roadmaps produit existent qui remontent à ce pourquoi, permettant d’explorer différentes solutions compatibles avec le budget alloué :

• Les roadmap orientées but : elles expriment ce que le produit doit permettre de faire, sans préjuger de la fonctionnalité elle-même.
• La roadmap narrative : elle met en avant l’impact recherché auprès de l’utilisateur et inscrit le changement recherché dans un contexte plus large où le produit peut n’être qu’une partie de la solution.

Notre panorama des différents types de roadmaps sera publié très prochainement !

 

• The Principles of Product Development Flow – Donald G. Reinertsen – Celeritas Publishing 2009 – ISBN : 978 1 935401 00 1 (voir page 31)
• Software by Numbers, Low-risk High-return development – Mark Denne & Jane Cleland-Huang – Prentice Hall / Sun Microsystems 2004 – ISBN : 978 0 131 407282 (voir p. 30)
• Competitive Engineering – Tom Gilb – Elsevier 2005 – ISBN : 9780750665070 (voir p. 170)
• Start with Why – Simon Sinek – Portfolio Penguin 2009 – ISBN : 978 1 59184 644 4 (voir p. 37)
• Start with Why - Simon Sinek - TED Talks