Product mindset vs Project mindset : une différence fondamentale

Il y a une confusion qui traverse beaucoup d’équipes de développement. On parle de « product team », on emploie des « product managers », on utilise des outils de gestion de produit - et pourtant, dans la pratique, on travaille comme si chaque trimestre était un projet à livrer.

Ce n’est pas un problème de vocabulaire. C’est un problème de ce qu’on optimise. Et ça a des conséquences directes sur la qualité de ce qu’on livre, sur la satisfaction des utilisateurs, et sur la capacité d’une équipe à apprendre et s’améliorer.

Ce que signifie le project mindset

Le project mindset est une façon de penser héritée de l’ingénierie classique et du bâtiment. Un projet a :

• Un périmètre défini à l’avance
• Un budget alloué
• Une date de début et une date de fin
• Des jalons intermédiaires
• Un critère de succès simple : a-t-on livré dans les temps et dans le budget ?

Cette logique fonctionne bien pour construire un pont ou rénover un immeuble. Le cahier des charges change peu entre le début et la fin. Les besoins sont connus. Le succès se mesure à la livraison.

En développement logiciel, ce cadre est problématique pour une raison simple : les besoins changent en cours de route. Ce qu’on pensait nécessaire en début de projet n’est souvent plus prioritaire six mois plus tard. Ce que les utilisateurs veulent vraiment n’est parfois visible qu’après qu’on leur a mis quelque chose entre les mains.

Le project mindset répond à ça en ignorant ce signal, ou en le reportant « au prochain projet ». La priorité est de livrer le périmètre défini.

Ce que signifie le product mindset

Le product mindset part d’une prémisse différente : on ne sait pas à l’avance tout ce dont les utilisateurs ont besoin. On a des hypothèses. On les teste. On apprend. On ajuste.

Dans ce cadre, la livraison n’est pas la fin. C’est le début d’un cycle d’apprentissage. Une fonctionnalité livrée qui n’est pas utilisée est un échec, même si elle a été livrée dans les temps et dans le budget. Une fonctionnalité imparfaite qui résout un vrai problème pour les utilisateurs est un succès, même si elle a pris plus de temps que prévu.

Le critère de succès n’est pas « a-t-on livré ? » mais « est-ce que ça crée de la valeur pour les utilisateurs ? »

Cette différence change tout : la façon de planifier, de prioriser, de mesurer, et de décider quoi faire ensuite.

Pourquoi des équipes produit opèrent en mode projet

La confusion est courante parce qu’elle vient de pressions organisationnelles réelles.

Les budgets annuels imposent un cadre projet. Dans beaucoup d’organisations, le budget est alloué une fois par an, par projet ou par initiative. L’équipe doit justifier ce qu’elle va livrer pour obtenir le financement. Ce mécanisme crée naturellement un périmètre figé et une logique de livraison.

Les jalons rassure le management. Un roadmap avec des dates et des fonctionnalités nommées est plus facile à présenter à la direction qu’un horizon glissant basé sur des paris à tester. La certitude apparente du périmètre fixe est rassurante, même si elle est illusoire.

La culture de la livraison prime sur la culture de la valeur. Dans beaucoup d’équipes, ce qu’on fête, ce qu’on mesure, ce qui est visible dans les rétrospectives, c’est ce qui a été livré. Pas ce qui a fonctionné. Pas ce qui a été appris. Pas ce qui a changé pour les utilisateurs.

Le résultat : des équipes qui utilisent le vocabulaire du produit (sprints, backlogs, product owners) mais qui opèrent avec la logique du projet (périmètre figé, deadline sacrée, pas de feedback loop après la livraison).

Les conséquences concrètes

Cette confusion n’est pas abstraite. Elle produit des résultats prévisibles et coûteux.

Fonctionnalités livrées mais non utilisées. Des études répétées sur les bases de code matures montrent qu’une large part des fonctionnalités développées sont peu ou pas utilisées. Ces fonctionnalités ont coûté du temps, de l’effort, et de la complexité au code. Elles ont été livrées parce qu’elles étaient dans le périmètre, pas parce qu’elles répondaient à un besoin validé.

Pas de feedback loop. Quand la logique est de livrer puis de passer au prochain projet, personne ne revient mesurer l’impact de ce qui a été livré. L’équipe n’apprend pas si ses hypothèses étaient bonnes. Elle ne peut pas affiner son jugement sur ce qui fonctionne.

Optimisation de la vitesse plutôt que de la direction. Une équipe en mode projet optimise pour « aller vite vers le périmètre défini ». Une équipe en mode produit optimise pour « aller dans la bonne direction ». Ces deux optimisations peuvent mener à des décisions opposées sur quoi faire et dans quel ordre.

Résistance aux changements légitimes. Quand le périmètre est sacré et que la deadline approche, tout signal qui devrait faire changer les priorités est perçu comme une menace. « On ne peut pas changer maintenant, on est en pleine livraison. » Ce qui est souvent une réponse rationnelle dans un projet est une réponse dysfonctionnelle dans un produit.

Les marqueurs du product mindset en pratique

Comment reconnaître qu’une équipe opère vraiment en mode produit ?

Elle mesure l’impact après la livraison. Deux semaines, un mois, un trimestre après qu’une fonctionnalité est en prod : est-ce qu’elle est utilisée ? Est-ce qu’elle a changé quelque chose pour les utilisateurs ? Ces questions sont posées et les réponses influencent les décisions suivantes.

Elle est à l’aise avec l’incertitude du périmètre. Le roadmap dit « on pense que ça vaut la peine de travailler sur X ce trimestre ». Pas « on va livrer exactement X, Y, et Z avant le 30 septembre ». La différence est subtile dans les mots, mais énorme dans la réalité.

Elle peut annuler ou pivoter sans que ce soit un échec. Décider de ne pas aller au bout d’une fonctionnalité parce que des signaux indiquent qu’elle ne répond pas au bon problème est un succès dans la logique produit. Dans la logique projet, c’est un échec.

Elle apprend et intègre ce qu’elle apprend. Les décisions du trimestre suivant sont influencées par ce qui a fonctionné et ce qui n’a pas fonctionné au trimestre précédent. L’équipe a une mémoire collective de ses apprentissages.

Passer du projet au produit

La transition n’est pas qu’un changement de processus. C’est un changement de ce qu’on considère comme du succès.

Quelques leviers concrets :

Séparer les horizons de planification. Vision à long terme (où on veut aller), priorités à moyen terme (sur quoi on mise), travail concret à court terme (ce qu’on fait cette semaine). Chaque horizon a sa propre logique et son propre niveau de certitude.

Mesurer la valeur, pas le périmètre. Définir avant de commencer : comment saurons-nous que ça a fonctionné ? Quel signal cherchons-nous dans les données d’usage, dans les retours utilisateurs, dans les métriques business ?

Créer des cycles d’apprentissage courts. Livrer quelque chose d’incomplet mais utilisable plus tôt pour avoir des signaux réels. Ajuster. Recommencer. La vérité est dans l’usage, pas dans les spécifications.

Nommer les hypothèses. Expliciter « on pense que les utilisateurs ont besoin de X parce que Y » avant de développer. Ça crée la possibilité d’apprendre si l’hypothèse était juste.

Ce que Sinra construit pour ce mode de travail

Sinra est conçu pour fonctionner dans une logique produit, pas projet.

Les releases successives permettent de livrer par incréments et de mesurer l’impact de chaque incrément avant de décider de la suite. Les cycles organisent le travail dans des périodes définies sans figer le périmètre global. Les capabilities dans les projects donnent une vision long terme des intentions sans créer des engagements rigides sur le contenu exact.

Cette structure reflète une philosophie : on ne sait pas tout à l’avance. On fait des paris, on livre, on apprend, on ajuste. Ce n’est pas de l’improvisation. C’est de la rigueur appliquée à l’incertitude réelle du développement logiciel.

Le project mindset n’est pas mauvais en soi. Il y a des contextes où il est parfaitement adapté : une migration technique bien délimitée, une refonte d’infrastructure avec un scope connu, un projet réglementaire avec des contraintes fixes.

Mais pour un produit logiciel qui évolue avec ses utilisateurs, la logique projet est un handicap. Elle optimise pour la mauvaise chose et rend difficile l’apprentissage qui permettrait de s’améliorer.

La question n’est pas « est-on en mode projet ou en mode produit ? » La question est : « est-ce qu’on optimise pour livrer le périmètre, ou pour créer de la valeur ? » Ces deux objectifs ne mènent pas au même endroit.