🦊

Bonsoir à toutes et à tous, le sujet a été maintes fois évoqué, mais j’ai du mal à changer la culture de mon entreprise B2B très orientée “dates” pour rassurer des prospects. On arrive à une roadmap presque entièrement structurée par des deadlines qui est une retranscription d’exigences clients du type : feature A pour mi-novembre, feature B pour fin de l’année, amélioration A pour début janvier etc.. Ça me semble être contre-productif pour le futur (on perd la notion de stratégie produit) et éreintant pour l’équipe dev et produit qui se trouve parfois avec plusieurs deadlines qui se superposent...J’ai du mal à trouver les bons mots pour convaincre l’équipe sales qui a en face d’elle des clients qui souhaitent des projections...Est-ce qu’il s’agit d’arriver, côté produit avec une vraie stratégie et rassurer les sales en leur indiquant que la stratégie permettra de gagner des leads sur le moyen/long terme de sorte que les sales ne s’engagent sur aucune date, quitte à perdre des leads ? Ces leads étant importants pour la croissance de l’entreprise.

🐒

Aïe, 🦊, pour avoir vécu ça aussi, chez un éditeur Saas B2B, je ne peux que compatir !... et malheureusement je ne dois sans doute pas être le seul. Pour réussir à sortir de ce piège de la deadline à tout prix, il faudrait réussir à prouver que les utilisateurs finaux de ton produit (donc tes clients, si j'ai bien compris) sont plus soucieux de la qualité de ce qui est livré que du respect strict de la deadline. Souvent, pour pouvoir tenir une deadline qui est trop juste,  on finit par appauvrir une fonctionnalité au dernier moment. Si tu identifies ce pattern au bon moment, essaie de trouver un moyen de rassembler quelques clients finaux et de faire une petite étape de discovery à ce sujet : s'ils avaient le choix, est-ce qu'il préfèreraient avoir la feature A en temps et en heure, appauvrie de telle ou telle sous-fonctionnalité, ou seraient-ils prêt à patienter un ou deux sprints de plus pour avoir l'ensemble du scope ? Ma remarque est valable dans un contexte Saas ou le client s'attend à bénéficier d'une nouvelle version à une date définie. Mais elle marche aussi (et même encore mieux) dans le cas où le client a payé spécifiquement pour une évolution : il a payé pour la valeur produite par la feature, non pas pour la date à laquelle elle était livrée. (modifié)

🐨

Est-il possible pour toi de sortir des analyses d’adoption de ses fonctionnalités à dite date par les utilisateurs finaux? Si l’adoption est faible cela prouvera que la date importe peu - car le plus important est l’adoption de la fonctionnalité (et donc qu’elle resolve le problème)

🦧

Hello 🦊, je suis dans ce même contexte. Les roadmaps sont en fait des release plans qui sont exigées dans les AO. Avant toute chose, je crois que cela dépend des usages de ton secteur et de la façon dont ton marché fonctionne, mais de mon point de vue,  il y a beaucoup de pédagogie et de communication à faire sur deux types d’acteurs qui ne connaissent souvent rien à nos métiers : sales/operations et sur les clients. L’objectif sera donc de clarifier les contraintes et expliciter la manière dont on fait un (bon) produit, idéalement en amenant la preuve par l’exemple. Pour les premiers il faut arriver à montrer à quel point cette méthode est contre productive (via mesure du WIP, du temps de commute, etc), et bien leur faire comprendre que ce n’est pas juste une contrainte pour eux, mais aussi un levier pour créer potentiellement des opportunités de new business. Mais cela peut dépendre de plein de facteurs, notamment de ton cycle de vente, besoin de référencement ou pas, de la façon dont les deals se closent, etc. Pour les seconds, je crois qu’il faut arriver à leur montrer la valeur de ce qu’il se passe de vertueux quand on remonte au problème et bien leur expliquer ce qu’il se passe de négatif cette fois ci quand on doit faire rentrer 6 mois en 12. L’implication dans des phases de cadrage, de conception, ou a minima une communication claire et transparente sont vraiment importantes. Mais là aussi, cela peut dépendre à quel point tes projets sont “prescrits” par tes clients (Specs & co) et comment se passe la gouvernance projet côté maitrise d’ouvrage. Après il y a le sujet de la stratégie produit, on est en plein de dedans et clairement c’est très compliqué (et pourtant on se fait aider), je ne connais pas ton rôle dans ta boite, tu peux essayer pas mal de choses mais sur des sujets comme celui-ci, le mieux est quand même de partir du codir et de redescendre...

Enfin bon, il y aurait sans doute beaucoup d’autres choses à dire, n’hésite pas à DM si tu veux continuer la conversation

🦁

D’accord avec les réponses précédentes, évidemment l’éducation joue un grand rôle. Mon expérience cela dit, de ce qui a fonctionné le mieux jusqu’à présent, c’est de prévenir de manière très transparente que non, désolée, ça ne sera pas prêt le mois prochain, d’écouter les plaintes et de rester sur mes positions. On a tous des mauvais moments à passer, et une fois que la release a été faite et fonctionne merveilleusement bien, on oublie les 2 semaines de retard dans la foulée. Je vois déjà venir les « et quid des pénalités de retard etc » - si pour une raison X ou Y vos contrats contiennent ce genre de clause (mais a priori c’est assez rare dans le software en dehors des SLAs), alors peut-être qu’il faut faire des estimations client à 3x le vrai dev estimé. Dans un de mes projets précédents, en utilisant cette stratégie tout le monde est content : le client a son produit quand il l’attend, les devs produisent quelque chose de qualitatif et en général bonus - on a le temps de faire des petites améliorations qui en général ne passent jamais à cause des deadlines qui s’enchaînent. Ces solutions, cela dit, sont surtout à recommender si tu n’as pas réussi avec la communication. L’idéal reste bien sûr d’arriver à faire passer le message, mais je sais que ça peut être très compliqué surtout dans le monde des clients corporate.

🦎

Attention aussi à un “biais du produit” qui peut consister à se dire que fonctionner sur un mode full produit/discovery/quality first est l’unique voie à suivre. Dans un marché régi par des appels d’offre, qui plus est dans du secteur public à forte inertie (déjà vécu dans le transport en commun), c’est irréaliste de ne demander du changement qu’aux clients et stakeholders. Il ne faut pas oublier de se demander comment le département tech peut adapter son orga et ses process à la réalité du terrain. Là on n’est plus sur les chemins balisés des guidelines de la startup B2C, mais on se pose les bonnes questions !