Voici ma réponse à la question d'Alexis Gérôme : “Si vous étiez lancé sur un projet d'innovation partant de zéro, comment approcheriez-vous l'UXR ?” (je réponds dans un nouveau post car je ne suis pas convaincu que ça soit pratique avec le format de commentaires sous le post initial) : Plus que jamais, ma réponse à cette question serait “
ça dépend” 😂
En effet, au vu de l’hypothèse de départ : “
un dirigeant / C-level a une intuition”, mon premier réflexe serait d’aller interroger ce dirigeant / C-level pour
établir un brief plus complet : D’où vient cette intuition ? Une expérience personnelle ou d’un proche ? Quelque chose qu’il a lu / vu / entendu ? Qu’est-ce qui l’a amené à se dire que cette intuition ferait un bon produit ? Est-ce que ça relève d’un besoin ? D’une frustration ? Qui sont les cibles de ce futur “produit” ? Il doit avoir une petite idée, sûrement imprécise, des utilisateurs potentiels ? A-t-il identifié des concurrents potentiels ? (Si ça n’est pas évident) Pourquoi a-t-il créé une équipe avec cette composition ? Peut-être a-t-il plus qu’une intuition et déjà une idée, bonne ou mauvaise, de solution ? Peut-être est-il plus pertinent de monter une équipe orientée stratégie, recherche et marketing pour commencer puis de monter une équipe produit ensuite en fonction d’hypothèses plus précises ? Y a-t-il d’autres parties prenantes dans l’entreprise sur ce sujet ? Qui pourrait être moteur ? Qui serait plus réfractaire ? etc. Quelles sont les mesures de succès pour lui ? Quel budget et quelle timeline à ses yeux ? Est-ce qu’il imagine pouvoir lancer quelque chose dans l’année ou est-ce qu’il se dit que ça sera un sujet de longue haleine ?
Normalement, suite à ça, on devrait pouvoir établir un premier plan d’action avec une timeline et un budget pour avancer et aboutir à une
première stratégie produit.
Ce plan d’action va évidemment beaucoup dépendre des réponses, du contexte et des contraintes. En fonction de tout ça, on va donc pouvoir y intégrer différentes activités, certaines pouvant être menées en parallèle. Quelques exemples : Mener des interviews des parties prenantes pour mieux cerner le sujet Mener une étude de marché et de la concurrence éventuelle Lancer une enquête plus ou moins ciblée pour mieux cerner l’intérêt potentiel pour le sujet et pour initier des premiers personas (idéalement un premier buyer persona) Initier des premières interviews utilisateurs pour établir des premiers personas (idéalement un premier buyer persona) Lancer une étude de type journal de bord / diary study auprès de la population cible pour mieux cerner le besoin et initier les premiers personas (idéalement un premier buyer persona) Mener une étude technologique pour identifier les technos / solutions techniques permettant de répondre aux besoins Mener une étude des risques Préparer puis lancer un Design Sprint pour répondre à une question clef et valider (ou invalider) différentes hypothèses
La conclusion de cette phase serait donc une première stratégie produit claire sous forme de
Product Vision Board (Extended) et de
Product Vision Statement / Value Proposition avec une vision plus ou moins claire des utilisateurs cibles. Si on a des contraintes temporelles et budgétaires assez serrées, on n’aura pas forcément des personas ultra complets à ce stade. L’important sera alors de bien identifier ce qui est “validé” et ce qui reste des hypothèses.
Sur cette base, on va pouvoir initier une
roadmap produit pour aboutir à un premier MVP. Pour cela, on va à nouveau pouvoir mener différentes activités dans le but de définir le périmètre du MVP (et je le rappelle, en visant à apporter un maximum de valeur et pas des fonctionnalités) et éventuellement une première idée des étapes permettant d’arriver au périmètre complet du produit.
On rentrerait ensuite dans une première
phase de discovery pour commencer à concrétiser une solution et aboutir à un premier backlog de delivery. Puis on enchaine sur de la
discovery et de la delivery en parallèle en gardant bien évidemment sous
contrôle les métriques de succès afin d’itérer au niveau discovery / delivery mais aussi au niveau stratégique si nécessaire.
Voilà un premier jet qui vaut ce qu'il vaut (surtout la fin que j'ai énormément simplifié) vu que ça dépend beaucoup du contexte.
MÉTAPHORE 2: Le bourré qui cherche ses clés sous le lampadaire J'utilise cette métaphore surtout dans des situations où les équipes mentionnent que personne ne s'est plaint Les typiques: "On n'a jamais eu de feedback dessus. Pourquoi faire de la recherche ?" "Tout marche très bien" 
MÉTAPHORE 3: you don't know what you don't know A utiliser en combinaison des deux autres situations pour visualiser la connaissance lors d'un workshop, ou lorsque vous êtes dans des équipes un peu plus matures en research et qui commence à prendre confiance dans la research. (J'observe qu'après un certain niveau certaines équipes ne cherchent pus à apprendre et croient connaître) Donc lors d'un workshop j'utilise cela avec un tableau d'hypothèses priorisées par niveau de preuves déjà existantes. Dans un Figjam lorsque vous dezoomez cela permet de comparer entre ce que l'on connait et ne connait pas. Très efficace pour rester humble. 
