Avant qu’une équipe SaaS n’engage le budget de son MVP, une question détermine si cet argent est bien dépensé : le client pour lequel elle prévoit de développer paiera-t-il vraiment ? La découverte produit y répond d’abord, grâce à des entretiens avec les parties prenantes, une cartographie du parcours client et des prototypes légers qui valident le problème et un acheteur précis avant qu’une seule ligne de code de production ne soit écrite. Elle dure généralement de 2 à 6 semaines.
La décision revient le plus souvent à un responsable produit qui cadre un nouveau module, ou à un fondateur disposant d’une idée financée et d’une date de lancement. Se lancer directement dans le développement semble plus rapide, surtout maintenant que le développement assisté par l’IA peut produire rapidement une première version fonctionnelle. Mais un développement rapide n’apporte rien à une idée non validée : un produit SaaS peut être bien conçu techniquement et échouer malgré tout s’il a été construit pour un profil client que personne n’a testé. La découverte le détecte au stade du prototype, où un changement de cap coûte quelques jours de travail de conception.
Ce que recouvre réellement la découverte produit
La découverte produit répond à deux questions, dans cet ordre. D’abord, le problème est-il assez douloureux pour que quelqu’un paie pour le résoudre ? Ensuite, quel est le plus petit produit qui le résout pour un acheteur précis ? Redwerk traite ces deux questions comme des étapes distinctes, car une équipe qui saute la première finit par concevoir une solution à un problème qu’elle a seulement supposé.
Entretiens avec les parties prenantes
Il s’agit de conversations avec les personnes qui subissent le problème, celles qui paieraient pour le résoudre, et les parties prenantes internes qui devront vendre, assurer le support ou intégrer le produit. Dans le SaaS B2B du marché intermédiaire, ce sont rarement les mêmes personnes : un responsable des opérations ressent la douleur, un directeur financier signe le contrat et la DSI décide si l’intégration est autorisée.
L’objectif est d’obtenir des preuves d’intention d’achat, et le piège habituel consiste à la confondre avec l’intérêt. L’intention se manifeste par des comportements, par exemple lorsqu’un prospect indique ce que lui coûte sa solution de contournement actuelle, présente le détenteur du budget ou accepte un pilote payant.
Cartographie du parcours client
Une cartographie du parcours décrit, étape par étape, comment le client cible gère le problème aujourd’hui : les outils qu’il utilise, les passages de relais entre les personnes, et les endroits où se perdent le temps et où naissent les erreurs. Pour un produit SaaS, cette cartographie détermine à quoi le produit doit se connecter (le CRM, le système de facturation, le tableur qui fait tourner la moitié du processus). Elle montre aussi l’étape où le logiciel fait gagner le plus d’effort, et cette étape devient le cœur du MVP.
Prototypes légers
Des wireframes cliquables ou une maquette interactive simple sont présentés aux personnes qui ont été interrogées. Un prototype vérifie si le flux de travail proposé a du sens pour l’utilisateur avant que quiconque n’écrive du code backend, et le modifier coûte quelques jours de conception. Modifier ce même flux après la sortie du MVP oblige à retravailler la base de données, l’API et l’interface.
Méthodes de validation d'idée SaaS qui distinguent l'intérêt de l'intention d'achat
La validation d’idée SaaS est la partie de la découverte qui transforme les entretiens en preuves sur lesquelles un détenteur de budget peut s’appuyer. Les mêmes méthodes fonctionnent pour un nouveau module au sein d’une plateforme établie comme pour les idées de micro SaaS qu’une petite équipe peut lancer seule. Voici celles qui tiennent le mieux en SaaS B2B :
- Des entretiens sur le problème avant de présenter la solution. Demandez comment le client gère le problème aujourd’hui et ce qu’il lui coûte en heures, en effectifs ou en chiffre d’affaires perdu. Ne décrivez le produit qu’à la fin, voire pas du tout.
- Des tests d’engagement. Une lettre d’intention, un pilote payant, un accord de partenaire de conception ou une prévente à prix réduit constituent des preuves plus solides qu’une longue liste d’entretiens enthousiastes.
- Des audits des solutions de contournement. Si le client paie déjà pour une solution partielle, ou a bâti un processus sur tableur autour du problème, la douleur est réelle et dispose déjà d’un budget.
- Des démonstrations du prototype avec le véritable profil utilisateur. Observez la personne qui utiliserait le produit au quotidien essayer le parcours cliquable. Les endroits où elle hésite sont ceux où le périmètre du MVP doit être retravaillé.
- Un filtre sur un seul profil. Chaque constat est confronté à un seul profil de client cible. Les retours extérieurs à ce profil sont consignés et mis de côté pour plus tard.
Ce qui détermine la durée et l'effort d'un processus de découverte
Le travail initial se divise en deux étapes, la validation du problème et la forme de la solution, les deux premières des sept étapes du développement de produit SaaS. La forme de la solution est le cœur du processus de découverte, avec ses entretiens avec les parties prenantes, sa cartographie du parcours et ses prototypes légers, et l’équipe est réduite : le fondateur (ou, au sein d’une entreprise établie, le product owner), un stratège produit ou business analyst, et un responsable UX. La plupart des missions de phase de découverte de Redwerk durent de 2 à 6 semaines, selon la complexité du produit, les intégrations et le niveau de validation dont l’idée a encore besoin.
Validation du problème
Un problème confirmé que quelqu’un paiera pour résoudre
Fondateur et 1 à 2 conseillers experts du domaine
L’intérêt est pris pour une intention d’achat
Forme de la solution (découverte)
Une hypothèse de valeur avec un acheteur identifié
Fondateur, stratège produit ou business analyst, responsable UX
Le produit tente de servir plusieurs profils de clients à la fois
Périmètre et développement du MVP
Une tranche de produit constructible et testable
Product owner, 2 à 4 développeurs, un ingénieur QA, un designer
La surcharge de fonctionnalités allonge le calendrier avant le lancement
La position d’un projet de découverte dans cette fourchette de 2 à 6 semaines dépend de quatre facteurs :
- le nombre de segments de clientèle interrogés (un seul coûte moins cher, et donne de meilleurs résultats, comme l’explique la section suivante)
- le niveau de finition attendu des prototypes
- le nombre de systèmes existants avec lesquels le produit doit s’intégrer
- la présence ou non de code existant à auditer avant de concevoir quoi que ce soit de nouveau
Si la découverte montre que l’acheteur choisi ne paiera pas, l’équipe a consacré quelques semaines d’une petite équipe à l’apprendre. Apprendre la même chose après le lancement signifie que le budget du MVP est dépensé et que le produit doit changer de direction.
L'erreur la plus fréquente en découverte produit
L’échec le plus fréquent à ce stade consiste à vouloir répondre à trois profils de clients différents à la fois. Cela paraît commercialement judicieux, puisque davantage d’acheteurs potentiels semblent promettre davantage de revenus, mais le résultat est un produit médiocre pour tout le monde.
Viser trop large nuit à la validation de trois façons :
- Le signal des entretiens est moyenné. Trois profils décrivent trois douleurs différentes, et les exigences qui en sont synthétisées ne correspondent exactement à aucune des trois.
- Les retours sur le prototype deviennent tièdes. Chaque groupe trouve le parcours en partie pertinent, ce qu’il est facile de prendre à tort pour une validation modérée.
- Le périmètre du MVP s’élargit. Couvrir les fonctionnalités indispensables de chaque profil fait grimper le budget de développement et retarde le lancement.
Pour choisir le profil à valider en premier, recherchez :
- la douleur la plus aiguë et la plus fréquente
- un détenteur de budget que vous pouvez réellement joindre pendant les entretiens
- un segment assez étroit pour que vous puissiez citer les dix premières entreprises auxquelles vous vendriez
Se restreindre donne l’impression de réduire le marché, mais c’est une décision de séquençage : un produit qui s’impose sur un segment peut s’étendre aux segments voisins une fois que la rétention prouve que le cœur fonctionne.
Comment la découverte produit accélère le développement SaaS
Les fondateurs et les responsables produit voient souvent la découverte comme des semaines passées avant que le vrai travail ne commence. Ce temps est regagné pendant le développement. Les services de développement SaaS de Redwerk commencent par une phase de découverte qui couvre l’analyse métier, l’architecture, les user stories, le design initial et le périmètre du MVP, de sorte que le développement avance plus vite et que la première version reste ciblée et rentable.
La découverte retire du développement le type de travail le plus lent, à savoir les décisions prises en plein sprint :
- Des choix d’architecture arrêtés tôt. Le multi-tenant, l’isolation des données et le modèle de facturation coûtent cher à modifier une fois les premiers clients sur la plateforme. La découverte les tranche tant qu’ils ne sont encore qu’un schéma.
- Des user stories que les développeurs peuvent estimer. Une équipe qui démarre avec des stories priorisées et un périmètre de MVP validé peut fournir des fourchettes d’effort qui tiennent.
- Moins d’écrans à refaire. Un problème de parcours repéré dans un prototype cliquable coûte une révision de design, alors que le même problème repéré après la sortie coûte un sprint.
- Des surprises d’intégration repérées sur le papier. La découverte cartographie les API et les systèmes dont dépend le produit avant que l’équipe ne s’engage sur un calendrier.
Vous n’avez pas non plus besoin d’un cahier des charges complet pour commencer. La plupart des équipes qui viennent chez Redwerk pour une découverte arrivent avec une idée, un marché cible et une échéance, et le cahier des charges fait partie de ce que produit la découverte.
Quand raccourcir ou ignorer la découverte
Une phase de découverte complète de 2 à 6 semaines n’est pas le bon choix dans certaines situations :
- Vous avez déjà des clients payants qui demandent une fonctionnalité ou un module précis, et il s’agit d’en définir le périmètre.
- Le produit est un outil interne destiné à un groupe d’utilisateurs connu, auquel vous pouvez parler n’importe quel jour.
- Une prévente ou un pilote payant a déjà validé l’acheteur, et ce qui manque, c’est la conception technique.
Dans ces cas, un court atelier de cadrage et une revue d’architecture couvrent le risque. Une découverte complète justifie son coût lorsque l’acheteur, le problème ou la forme de la solution relèvent encore de l’hypothèse.
De la découverte produit au MVP
Un processus de découverte achevé remet à l’équipe de développement un ensemble de livrables, et leur qualité détermine la vitesse d’avancement du MVP. Chez Redwerk, il comprend généralement :
- un profil de client cible clairement identifié et une hypothèse de valeur testée auprès de lui
- un périmètre de MVP priorisé
- une esquisse d’architecture et des choix technologiques
- des notes d’intégration pour chaque système externe avec lequel le produit interagit
- un prototype cliquable validé auprès de vrais utilisateurs
- une feuille de route avec des fourchettes d’effort pour le développement
Pour un examen plus détaillé de chacun de ces documents et de la façon dont ils raccourcissent les délais, consultez notre article sur les livrables de la phase de découverte qui réduisent le temps de développement.
Il arrive que la découverte laisse une question technique ouverte, par exemple savoir si une API tierce peut supporter la charge prévue ou si une fonctionnalité d’IA est assez précise pour être mise en production. Une courte preuve de concept y répond avant le début du développement du MVP, de sorte que l’équipe s’engage sur le plan de développement en sachant que la partie la plus risquée fonctionne.
L’étape suivante consiste à transformer ce périmètre en une première version. Notre guide du MVP SaaS explique comment construire le produit minimum viable et le faire évoluer vers une plateforme complète.
Comment Redwerk mène la découverte produit pour le SaaS
La découverte est l’étape du développement de produit SaaS où se tromper coûte le moins cher. Redwerk la mène comme la première étape du développement de produit SaaS, avec son propre périmètre, sa propre équipe et son propre budget, et a réalisé plus de 250 projets de découverte. Un business analyst ou un stratège produit travaille aux côtés d’un responsable UX, vous êtes tenu informé des enseignements des entretiens et des retours sur le prototype tout au long de la mission, et celle-ci se termine par un plan de développement que votre direction peut approuver.
Si vous avez une idée SaaS et souhaitez savoir si elle tient la route avant d’engager le budget de développement, parlez à Redwerk d’une phase de découverte.
FAQ
Qu'est-ce que la découverte produit ?
La découverte produit est l’étape qui précède le développement, au cours de laquelle une équipe confirme qu’un problème mérite d’être résolu, choisit un client cible et teste une forme de solution avec ce client. Elle comprend généralement des entretiens avec les parties prenantes, une cartographie du parcours client et des prototypes légers, et se termine par un périmètre de MVP priorisé.
Combien de temps dure la découverte produit pour un produit SaaS ?
La plupart des phases de découverte durent de 2 à 6 semaines. La durée dépend de la complexité du produit, du nombre d’intégrations à cartographier et du niveau de validation dont l’idée a encore besoin.
Le développement assisté par l'IA rend-il la découverte produit inutile ?
Non. Les outils de codage basés sur l’IA accélèrent le développement, mais ils ne peuvent pas vous dire si un client paiera. Un développement plus rapide met plus tôt sur le marché une idée non validée, ce qui rend la découverte encore plus utile.
Quelle est la différence entre la découverte produit et un MVP ?
La découverte valide le problème, l’acheteur et la forme de la solution à l’aide d’entretiens et de prototypes, sans code de production. Un MVP est le premier produit fonctionnel, construit à partir du périmètre issu de la découverte et mis entre les mains de vrais clients.
Faut-il un cahier des charges détaillé avant de commencer la découverte produit ?
Non. C’est la découverte qui produit le cahier des charges. Les équipes démarrent généralement avec une idée, un marché cible et un ensemble d’hypothèses, et terminent avec des user stories, une esquisse d’architecture et un périmètre de MVP.
Découvrez comment nous avons aidé AWE Learning à migrer de l'infrastructure sur site vers le cloud, et à atteindre des utilisateurs au-delà des États-Unis grâce à une solution SaaS évolutive
