Produit : quelle signification ?

Tout le monde en parle mais, finalement, un produit qu’est-ce que c’est ?

A quel moment un assemblage de produits devient-il un système à part entière ?

Tous les produits peuvent-ils être conçus en mode agile ?

Un produit c’est quoi ?

Les différentes définitions d’un produit, que ce soit au sens production de la nature, au sens économique, chimique ou encore mathématique impliquent, toutes, une idée de transformation pour aboutir au produit et une notion d’évolution.

Un produit au sens large peut, aussi bien désigner, un objet matériel, qu’un service dont le but est de satisfaire un besoin identifié d’un utilisateur ou un consommateur.

La seule constante entre tous les produits est qu’ils ont été imaginés dans l’objectif de plaire, de convenir à des utilisateurs/des clients. Pourtant, malgré cette intention, tous les produits ne conquièrent pas le cœur des clients… N’oublions pas que l’utilisateur/le client ne sait que rarement ce qu’il veut exactement au moment ou une équipe, une start-up, imagine un nouveau produit. Le besoin de tester et de recueillir les avis/retours des utilisateurs, et ce, aussi fréquemment que possible, pour faire évoluer le produit est une stratégie indispensable pour trouver la meilleure route vers le succès.

Les limites du produit

A quel moment un produit n’est-il plus un produit ?

A quel moment une suite de produit devient-il un système ?

Ce qui borne les contours d’un produit tient dans son utilisateur et l’usage qu’il en fait.

Prenons l’exemple d’un stylo bille : c’est un produit pour chaque utilisateur qui a besoin d’écrire.

Les composants de ce stylo, exemple la bille ou le tube d’encre, sont des produits dont l’utilisateur est l’objet lui même.

Nous pouvons aller plus loin, et parler du conditionnement de ce stylo. Emballé seul ou en paquet de 5, il sert un besoin différent, de mise en rayon par exemple.

Est ce que pour autant un stylo emballé ou non est un produit différent ? La finalité de son usage reste identique. De la même façon qu’un carton rempli de paquet de stylo peut-être vu comme un produit pour le transporteur

C’est la même chose coté IT. Un site e-commerce est-il un produit pour le client qui achète sur ce site ? Finalement, ce produit (le site web) est composé d’une multitude d’autres produits. Doit-on alors commencer à parler de système ?

Les points d’attention pour construire un produit en mode agile

Le but de l’agilité (sur un produit IT ou pas) est d’adapter le produit en fonction de son contexte. La création de valeur est une conséquence de la résolution d’un problème et de la bonne prise en compte des retours utilisateurs.

Le concept de produit est central dans la culture agile. Il est au cœur de chaque feature team qui est responsable de son produit et qui cherche à l’améliorer en permanence grâce aux retours de leurs utilisateurs.

La vision produit met en valeur l’objectif global et la raison d’être associée au produit. Elle mobilise les troupes et leur donne une bonne raison de s’engager chaque jour.

Il ne s’agit pas ici d’une checklist exhaustive mais plutôt de certains points qui nous semblent clés.

1 – Collecter et prendre en compte le retour utilisateur

Pour que votre produit soit construit de façon agile, il est indispensable de récolter le retour de vos utilisateurs. Sans feedback des utilisateurs, on ne pourra pas adapter le produit en fonction de leur besoin.

Si finalement le feedback utilisateurs est fréquemment pris en compte, est-ce que tous les produits (IT ou non) peuvent être développés en agile ?

2- La capacité à faire évoluer produit

Selon le feedback récupéré il faut être en mesure de pouvoir traiter et d’améliorer le produit : cela requiert de l’autonomie et de la flexibilité dans les budgets et les organisations.

Le concept de triangle de fer illustre très bien ce propos et les difficultés à faire évoluer un produit quand le scope, le budget et les délais sont figés.

Attention également à certaines typologies d’utilisateurs qui sont peu enclins au changement.

3 – S’assurer que le scope s’y prête

Prenons l’exemple d’un produit voué à faire respecter une loi ou garantir la sécurité d’un utilisateur. Nous restons sur un produit, qui, dans sa vision, sert l’intérêt de l’utilisateur en le protégeant et en lui garantissant le respect de la législation.

Les débats sur la valeur utilisateur de cette évolution restent possibles : certains points peuvent-ils être délibérément ignorés si il est estimé que les sanctions de non respect sont plus acceptables que les coûts de mise en application pour l’entreprise ?

Des features de mise en respect des différents points à appliquer peuvent être réalisées et déployées de façon itérative. Le feedback utilisateurs peut tout de même être collecté et analysé.

Dans ces situations, que ce soit l’application d’un texte de loi ou la mise en place de normes de sécurité, ce n’est pas le feedback utilisateur qui fait évoluer le produit mais bien l’obligation légale ou sécuritaire.

4 – Disposer d’autonomie dans la réalisation ou l’évolution du produit

Quand un produit dépend d’un écosystème complexe, et qu’il est composé d’une dizaine (voire plus) d’autres produits pour exister lui-même, l’agilité devient beaucoup plus complexe à mettre en œuvre. Il peut s’agir d’un produit IT mais également concerner un produit, qui, pour être manufacturé nécessite des dizaines de composants de fournisseurs différents.

Même avec les meilleures intentions du monde ainsi que de la collecte ou de l’analyse du feedback clients, des blocages sont inévitables. Chaque produit en adhérence avec les autres peut servir une gamme d’utilisateurs différents, avoir une roadmap produit différente et des axes de génération de valeur différents.

Nous abordons là, une vraie complexité qui rend laborieux le fait de pouvoir déployer des features répondant aux problèmes des utilisateurs… Ce qui est gagné par le feedback client est perdu par la difficulté à y réagir.

Conclusion

La définition d’un produit versus un système peut rester flou et elle est dépendante de votre écosystème organisationnel.

Nous avons échangé sur l’importance de l’utilisateur dans la définition du produit mais pour aller plus loin nous vous proposons d’autres axes de questionnements. N’hésitez pas à nous faire part de votre avis pour enrichir notre réflexion 🙂

• une œuvre d’art, chez un particulier est elle encore un produit puisque qu’elle n’a qu’un utilisateur ?

• quid des produits dont l’utilisateur final n’est finalement pas la personne qui va acheter le produit (ex : les croquettes pour chiens, les couches pour bébés…) ?

• un langage de programmation est il un produit ? ou une ressource équivalente à du coton pour fabriquer un tee shirt ?