Ah c'est une très bonne question Nicolas. Je pense que ça mériterait un épisode dédié car il peut y avoir des subtilités. Par exemple, un produit est-il une solution ? Est-il une (ou des) réponse(s) à des besoins ? Par exemple, je pense à une équipe qui à plusieurs types d'utilisateurs identifiés comme les pro et les perso. D'une certaine manière on pourrait se dire qu'elle a plusieurs produits. De même qu'une équipe devant gérer une version par plateforme (iOS, Android, Windows, Mac) ou une version d'un même produit mais point de vue utilisateurs vs administrateurs. Je pense donc qu'il faut essayer de voir comment on peut considérer "nos produits" comme "un produit à multiple facettes". Si ce n'est vraiment pas le cas, il peut être intéressant de se demander si cette organisation est pertinente. Qu'en dis-tu ? -- Constantin

@@ScrumLife j'aime beaucoup ces questions soulevées. Je pense qu'il n'y a jamais de réponse simple. J'ai habituellement vu des organisations avoir à convertir en mode produit qui ont beaucoup trop de projets pour le nombre d'équipes et qui regroupent les pans fonctionnels sous des équipes, sans trop de points communs autres que "X dans l'équipe Y a travaillé sur ça dans le temps alors maintenant c'est le "produit" de l'équipe Y puisqu'il en fait partie". J'imagine que la "best practice" pour découper les produits est par persona. On se spécialise dans cette équipe à répondre aux besoins de ce ou ces types d'utilisateurs. Malheureusement, le chemin pour convertir le legacy "4 produits dont l'équipe Y est propriétaire" à "les 4 personas dans le contexte Z dont l'équipe Y est spécialisée" me semble extrêmement difficile sans mettre le feu dans l'ancien pour partir à neuf. Ce qui est habituellement combattu à fond par les organisations pour une foule de raisons qui habituellement débutent avec le billet de coût investi. De quoi en faire un épisode en effet, je serais ravie ! Laissez-moi savoir si je peux aider !