La taille du backlog est inversement proportionnelle à la fréquence des échanges avec les clients

• Plus les échanges avec les clients sont fréquents, plus la taille du backlog diminue
• Il est important de remplacer le temps passé à planifier par des échanges avec les clients
• Plus il y a d’intermédiaires entre les développeurs et les clients, moins le produit répond aux besoins des clients
• Un backlog volumineux signifie qu’il contient beaucoup d’hypothèses non vérifiées et qu’il a peu de chances de créer de la valeur pour les clients

Se concentrer sur la conception des composants techniques plutôt que sur le design UI

• Il ne faut pas consacrer trop de temps au design UI ; il est important de lancer rapidement une UI de base, puis de l’améliorer grâce aux retours des clients
• Il faut maintenir une dette technique faible afin de pouvoir effectuer rapidement les changements dont les clients ont besoin

La manière dont les gens pensent utiliser une application diffère de son usage réel

• Il est important d’observer les clients lorsqu’ils utilisent l’application
• L’observation directe du comportement des utilisateurs permet d’obtenir des insights impossibles à déduire des seuls indicateurs quantitatifs

Mise en place de l’account spoofing

• Investir dans une fonctionnalité d’account spoofing est important pour comprendre exactement quel écran un client donné voit réellement
  • Account spoofing : fonctionnalité permettant à un administrateur d’utiliser l’application comme s’il était un utilisateur de production spécifique
• Cela permet de diagnostiquer efficacement les problèmes et de réduire la dépendance aux données de test

L’importance de la première page

• Il faut présenter de manière concise les informations les plus pertinentes aux clients qui accèdent à l’application pour la première fois
• Chercher à mettre trop d’informations sur la première page augmente la charge cognitive des utilisateurs

Le client est le marketeur le plus important

• Le NPS (Net Promoter Score) est un bon indicateur pour savoir si les clients apprécient suffisamment le produit pour le recommander
• Il est possible de dépenser en publicité, mais commencer par des clients satisfaits est une stratégie marketing efficace

Un MVP n’a pas de sens sans itérations d’amélioration

• Un MVP ne doit pas simplement servir de prétexte pour offrir une expérience client de faible qualité sous la pression des délais
• Un MVP aide à déterminer si des itérations supplémentaires sont nécessaires et, si oui, quels points doivent être améliorés

L’avis de GN⁺

• Le point le plus important de cet article est l’importance de développer des produits qui reflètent les besoins réels des utilisateurs grâce à un dialogue continu avec les clients
• Il souligne l’importance d’un design UI flexible et de composants techniques capables d’intégrer rapidement les retours des clients
• Il montre qu’au-delà du MVP, améliorer continuellement le produit et accroître la satisfaction des clients peut mener à un succès à long terme
• Cet article partage des leçons tirées de la vie en startup et offre des insights concrets aux fondateurs et aux développeurs

[GN⁺]

Avis Hacker News

• Avis sur la manière d’organiser les fonctionnalités/améliorations

  • D’après l’expérience, la stratégie consistant à transformer toutes les idées en tickets est inefficace. Cela crée une « icebox » remplie d’idées qui ne seront jamais utilisées.
  • Même lorsqu’une idée présente dans l’icebox est nécessaire pour conclure un deal important, on ne se souvient pas qu’elle existe et on crée un nouveau ticket.
  • Préférence pour les tickets réalisables à court ou moyen terme, tandis que les autres idées sont conservées séparément.
  • L’équipe d’ingénierie maintient une liste de la dette technique qu’elle veut résoudre, et les PM maintiennent une liste des améliorations possibles par projet.
  • Pour les nouvelles fonctionnalités/produits, on rédige un PRD, mais on ne le transforme pas immédiatement en tickets.
  • Un énorme backlog qui ne sera presque jamais traité est le signe d’un PM faible qui a peur de dire « non ».

• Relation entre la taille du backlog et le taux de rotation des PM

  • La taille du backlog est inversement proportionnelle au taux de rotation des PM.
  • Pour un PM en poste depuis longtemps, le backlog sert d’aide-mémoire des anciennes conversations produit.
  • Un nouveau PM regarde le backlog, s’y perd et essaie de nettoyer ce qu’il ne comprend pas.

• Avis opposé au maintien d’un backlog fondé sur les clients

  • Les équipes qui maintiennent un backlog le tirent généralement de leurs clients.
  • « Trouver une fonctionnalité qui améliore la vie du client et en faire la prochaine fonctionnalité » n’est pas si simple.
  • Que faire lorsqu’il y a plusieurs clients et que les fonctionnalités susceptibles d’améliorer leur vie sont sans rapport entre elles et complexes ?
  • Il faut toujours écouter les demandes des clients, mais il ne faut presque jamais construire exactement ce qu’ils demandent.
  • Les clients demandent des fonctionnalités qui révèlent non seulement une implémentation UX, mais aussi le problème sous-jacent et le processus métier qu’ils utilisent actuellement.
  • Il faut identifier le problème métier, puis écarter l’idée d’implémentation UX et les spécificités du processus.
  • Il faut construire, de manière économique, la fonctionnalité minimale qui résout le problème métier, avec une bonne UX et de la cohérence.

• Le besoin, pour les PM, d’un endroit où enregistrer les exigences client

  • Les PM ont besoin d’un endroit où consigner les exigences des clients.
  • Sans outil dédié, ces exigences finissent le plus souvent en tickets Jira.
  • Il existe deux approches : ProductBoard et Jira Product Discovery.
  • ProductBoard adopte une approche de type CRM, en enregistrant toutes les interactions client, puis en les décomposant plus tard en exigences et en souhaits.
  • Jira Product Discovery part des idées et oblige à décomposer immédiatement tout ce qu’on entend des clients en une longue liste d’exigences et de souhaits.
  • L’avantage de Jira Product Discovery est de séparer la liste d’idées du backlog des développeurs, mais cela crée une autre longue liste.
  • Pour analyser les priorités produit à partir des conversations client, ProductBoard est un meilleur outil de product discovery.

• L’importance d’un backlog affiné par le feedback client

  • Comme les conversations avec les clients ont lieu presque tous les jours, le backlog contient des fonctionnalités et améliorations directement informées et affinées par leurs retours.
  • Il y a toujours beaucoup à faire, mais la différence se joue sur le fait que le backlog soit ou non nourri et affiné par le feedback client.

• Gestion du backlog via des conversations quotidiennes avec les clients

  • En tant que profil technique, parler chaque jour avec les clients est séduisant en théorie, mais pose quelques problèmes.
  • Biais de récence et coût d’opportunité : il faut continuer à collecter des retours sur des espaces de problèmes qu’on choisit délibérément de ne pas traiter à cause de priorités plus élevées.
  • Développement réactif : si l’on saute l’étape de journalisation du feedback, on finit par se concentrer sur les tâches les plus récentes et les plus accessibles, en négligeant les problèmes plus anciens.
  • Base de connaissances de l’équipe : s’il n’y a qu’un seul responsable chargé de recueillir le feedback et de proposer des solutions, l’argument de l’OP peut tenir.
  • Si l’équipe est impliquée, il faut une base de données partagée permettant d’enregistrer et de retrouver des points de données de manière asynchrone.
  • Le backlog peut grossir rapidement, mais gérer des systèmes et des personnes complexes s’accompagne forcément de difficultés.
  • Pour une équipe bien organisée, une bonne gestion du backlog est nécessaire : archiver les tâches non pertinentes, supprimer les doublons, reprioriser régulièrement et exploiter au mieux les outils.
  • Gérer le backlog est plus important que l’outil lui-même, et il peut être nécessaire d’avoir une « façade » au-dessus du backlog qui fasse remonter les informations utiles, avec la possibilité d’approfondir si besoin.

• L’importance d’observer les utilisateurs de l’app

  • Il est important d’observer les clients utiliser l’app.
  • On peut suivre toutes les métriques, mais voir un utilisateur faire défiler l’écran pour chercher quelque chose, appuyer sur le bouton retour ou essayer de cliquer sur un élément non cliquable est une expérience très concrète.
  • J’aimerais que toutes les entreprises, comme Apple, Google et les autres, observent des utilisateurs plusieurs fois par jour.

• L’inutilité des gros backlogs

  • Les gros backlogs reposent sur beaucoup d’hypothèses incertaines et ont une faible probabilité de créer de la valeur pour le client.
  • On s’est souvent trompé en supposant qu’une chose avait de la valeur, alors que personne ne s’en souciait.
  • Un gros backlog reflète une faible fréquence de conversation avec les clients et doit donc être considéré avec un très grand scepticisme.

• Mise en garde concernant l’implémentation de l’usurpation de compte

  • L’usurpation de compte est un moyen simple de tester des problèmes en production, mais les équipes support et développement ont besoin de pouvoir faire confiance aux données de production.
  • Dans certains secteurs, cela peut poser de gros problèmes aux clients.
  • La dernière startup dans laquelle j’ai travaillé interdisait totalement aux développeurs l’accès aux données de production.
  • Cela devrait être considéré comme un dernier recours du point de vue de la sécurité, et il vaut mieux travailler en partant du principe qu’on ne peut pas accéder aux données client.

• La structure arborescente de la planification produit

  • La planification produit devrait toujours avoir une structure en arbre.
  • Le nœud de plus haut niveau correspond aux objectifs business, en dessous se trouve le produit, puis les problèmes client, puis les éléments du backlog.
  • Avoir trop d’éléments dans le backlog peut signifier qu’aucune structure appropriée n’est en place et qu’il n’existe pas de liste d’objectifs business priorisés.
  • « Parler aux clients » est utile pour comprendre leurs problèmes, mais il faut d’abord connaître les objectifs business. Sinon, on perd du temps à collecter du feedback sur des domaines sur lesquels on ne travaillera de toute façon pas.