La stratégie produit est l’étape clé pour réussir un projet de produit numérique. Il est important de comprendre les enjeux pour créer une stratégie efficace, en se basant sur des données objectives et en mettant les utilisateurs au centre de la démarche. Il est important de définir l’ambition, la vision, la mission, la stratégie, l’objectif et le projet, ainsi que les KPI et les risques associés sans se focaliser sur les croyances et biais que notre expérience a pu nous apporter. Il est également important de prendre en compte les aspects qualitatifs, tels que la satisfaction des utilisateurs, pour maximiser les chances de succès.

L’important ici est de comprendre que nous ne sommes pas nos utilisateurs. Les placer au centre de la conception de notre stratégie est donc essentiel. 

Ici, nous allons vous présenter la méthode que nous utilisons pour accompagner nos clients dans la définition de leur stratégie produit. Pouvant aller de la définition de l’ambition du projet jusqu’à la création d’un prototype UX/UI le plus proche possible du comportement réel du futur produit.  

Cette première étape va consister à définir les grandes orientations de notre produit. Pour cela, nous allons définir les éléments suivants : 

La vision > la mission > la stratégie > l’objectif > le projet 

L’impact que l’on cherche à atteindre

Le ou les risque.s que nous sommes prêts à prendre

Le temps et le budget que l’on souhaite allouer au projet

La plupart du temps, il s’agit d’éléments que nous définissons lors de la phase d’avant-vente ou lors d’ateliers avec nos clients. Ces derniers ont l’avantage de réunir l’ensemble des parties prenantes autour de la table, afin de s’accorder sur la stratégie à mettre en place. 

Comme évoqué dans l’introduction de cette page, cette étape de recherche utilisateur est indispensable. Elle permet en effet de baser notre analyse sur des données objectives. Qu’elles soient qualitatives ou quantitatives, ces données nous permettront de mieux comprendre, soit le comportement de nos utilisateurs vis-à-vis d’un produit existant, soit les besoins ou points de douleurs que nos futurs utilisateurs et clients cherchent actuellement à contourner, sans avoir de produit correspondant. 

De nombreux moyens sont à notre disposition pour obtenir des données provenant de nos utilisateurs. 

Des moyens quantitatifs : 

Des moyens qualitatifs : 

Cette étape consiste à définir la granularité la plus fine (et la plus large) de nos différents types d’utilisateurs. Généralement traitée lors d’un atelier avec nos clients, nous allons chercher à lister l’ensemble typologies d’utilisateurs que notre produit sera amené à adresser. 

3 niveaux de granularité : 

La définition de l’ensemble de nos persona et des critères de différenciation qu’ils ont les un avec les autres vont nous permettre de mieux appréhender notre produit. Hiérarchiser ces persona vis-à-vis de notre stratégie va également nous aider à prioriser nos fonctionnalités et user stories, une fois le backlog posé. 

Une fois nos persona définis, nous allons définir l’ensemble de leur parcours, de la première à la dernière étape. Ici, nous allons nous projeter dans l’ensemble des actions et interactions qu’ils auront avec le produit. 

On va donc lister les différents canaux d’entrées ainsi que les fonctionnalités auxquels nos utilisateurs seront exposés. Sous forme d’un parcours (ou user flow), nous allons cartographier les actions qui leur sont disponibles. 

À noter : ces user flows vont de plus nous permettre de définir les canaux à prioriser en ce qui concerne l’onboarding de nos utilisateurs. Nos persona ayant des besoins et craintes spécifiques, nous allons ici pouvoir y répondre au moment (et à l’endroit) les plus opportuns de leur parcours. 

Définir les objectifs quantitatifs et les indicateurs de performance associés va nous permettre de répondre à cette question. 

À cette étape, il est encore un peu tôt pour définir le plan de taggage (ou plan de tracking) définitif. En effet, les écrans n’étant pas encore traités en UX/UI, nous ne pouvons pas savoir précisément par quel moyen ou trigger, nous pourrons déclencher les évènements dans notre Google ou Matomo Analytics. 

Par contre, nous pouvons déjà définir les objectifs que notre produit et l’ensemble des fonctionnalités serviront à atteindre. 

Encore une fois, plus tôt, nous définissons ces éléments, plus notre conception produit sera orientée vers de la performance. En effet, si les objectifs sont clairs, les moyens pour les atteindre en UX/UI seront plus concrets et donc plus simples à mettre en place. 

Ne pas avoir les écrans sous les yeux n’empêche cependant pas de se projeter sur la manière dont nous voulons déclencher les évènements. Par exemple, cela pourra aider à prioriser le fait de développer des pages de remerciements en fin de formulaire, de manière à tracker précisément nos ventes ou notre génération de leads. 

Le premier réflexe lorsqu’on fait un benchmark est de vouloir copier les concurrents ou acteurs du marché qui ont des solutions qui nous semblent sexy. Encore une fois, nous ne sommes pas nos utilisateurs ! 

Ce qui nous parait sexy peut n’avoir qu’un intérêt très faible auprès des utilisateurs finaux. Il faut ainsi avoir une idée précise des objectifs que nous allons chercher à atteindre avec notre produit, pour bien orienter notre benchmark. 

Lors des étapes précédentes de notre méthode, nous avons défini ces objectifs. Nous avons les idées claires sur ce que notre produit devra atteindre. Nous pouvons donc ouvrir notre benchmark à un réseau beaucoup plus grand que celui des concurrents directs. En effet, de nombreuses autres entreprises rencontrent les mêmes problématiques que celles que nous allons rencontrer sur le projet. 

Prenons l’exemple d’un module de planification type agenda : ici, les acteurs les plus performants ne sont pas nécessairement ceux qui appartiennent au même secteur que le nôtre. En effet, d’autres types de produits comme des CRM ou des e-commerces peuvent avoir des solutions beaucoup plus évoluées. 

Connaître les grandes briques qui vont constituer notre produit nous permet d’orienter notre benchmark sur les briques en elles-mêmes plutôt que sur les concurrents directs. 

Souvent à cette étape, nous commençons à avoir une idée plutôt claire de ce à quoi notre produit devrait ressembler. Sauf que nous n’avons pas encore vérifié que la totalité de nos idées étaient réalisables. 

Ici, nous allons donc parler des éléments suivants : 

Répondre à ces questions va nous permettre de définir le socle technique de notre produit. De plus, la connaissance de notre socle technique nous permettra de définir le framework sur lequel nous allons travailler. Une fois le framework défini, nous pourrons ainsi choisir le Design system et la librairie de composants les plus adaptés. 

Basé sur les user flows décrits précédemment, le backlog va regrouper toutes les fonctionnalités et user stories que nous avons définis lors de la phase de Discovery du projet. 

Sous forme de listing, nous allons décrire le plus précisément possible la manière dont nos utilisateurs vont interagir avec le produit. Cela permettra dans un premier temps de concevoir l’UX/UI, puis dans un second temps d’appuyer les maquettes et prototypes avec des spécifications fonctionnelles livrées aux développeurs. 

Le backlog est un également un outil utilisé dans la priorisation des fonctionnalités. Sur certains projets de conception, nous recommandons fortement à nos clients de commencer par développer un MVP pour rapidement confronter le produit à son marché. Cela sous-entend par contre un fort enjeu de priorisation.

Ici, le backlog nous permettra de définir nos critères de priorisation et ainsi de confronter chacune des fonctionnalités et user stories à nos critères de priorisation. 

Définition Wikipédia de la roadmap : “Une roadmap est une représentation graphique simplifiée permettant de communiquer et de partager efficacement une intention stratégique afin de mobiliser, d’aligner et de coordonner les efforts des parties prenantes pour atteindre un ou plusieurs objectifs.”

La roadmap va donc reprendre le contenu de notre backlog en regroupant, par sprints de développements, des ensembles de fonctionnalités et user stories. 

Les éléments définis comme prioritaires (must have selon la méthode MOSCOW) constituent donc le ou les premiers sprints de développements. Viendront ensuite, les fonctionnalités nice to have et enfin les could have. 

Notre roadmap sera donc un affichage en mode planning de nos différents sprints. Elle nous permettra de connaître les actions à mener à court, moyen et long terme. Elle permettra également d’avoir une vision claire sur l’état des lieux des développements en cours. 

Tout comme le backlog, la roadmap est un outil flexible qui est voué à évoluer régulièrement. En effet, à l’échelle d’une entreprise, les critères de priorisation peuvent être amenés à changer. Notre roadmap pourra donc s’adapter en fonction des besoins et opportunités que rencontrent nos clients.