Concevoir l'interview d'un problème
Auteur : Yann Gensollen
Source : Lean Startup Adventure, day 5: Designing a Problem Interview
Date : 27/01/2016
Traducteur : Fabrice Aimetti
Date : 13/11/2022
Traduction :
Dans le billet précédent de cette série, François a analysé notre Business Model pour y rechercher spécifiquement les risques. La partie la plus risquée du canevas, pour nous, est le segment de clientèle et l'acquisition.
Les clients que nous avons identifiés rencontrent-ils réellement le Problème que nous avons défini ?
Interview du Problème
Pour le savoir, le moyen le plus économique et le plus rapide de vérifier nos hypothèses est de rencontrer des clients potentiels et de voir comment ils réagissent au problème.
Cet interview du problème est décrit dans le livre Running Lean d'Ash Maurya. C'est la toute première étape pour valider les risques importants liés aux nombreuses hypothèses que nous formulons lorsque nous remplissons le Lean Canvas. Cet exercice vise à questionner le couple Problème-Client.
C'est un outil d'apprentissage : en fonction de ce que disent les futurs clients, nous pourrons affiner notre Business Model. Il est donc important de faire abstraction de la Solution à ce stade, et de se concentrer uniquement sur ce que nous sommes en train de résoudre, qui est la concurrence, et qui souffre.
Ce que nous voulons valider
Une interview problème est censée vérifier des hypothèses pouvant être contredites. Sur la base de notre analyse des risques, nous formulons les hypothèses suivantes :
- La tâche "Gestion des données" est identifiée comme faisant partie de la description de poste d'une personne dans l'entreprise.
- Les outils d'administration des données, qu'ils soient généraux ou spécialisés, présentent de nombreuses lacunes (faible convivialité, trop d'outils, absence de connexion).
- L'utilisation de ces outils conduit à une gestion des données non optimale.
- La perte / le retard causé par un mauvais backend d'administration peut être évalué.
Scénario de l'interview problème
Sur la base de la structure de l'interview d'Ash Maurya, nous rédigeons un script que nous utiliserons pendant nos entretiens. Voici notre première ébauche :
1. Bienvenue - 2 minutes
Merci de nous recevoir. Nous sommes ici pour avoir votre avis sur un produit web que nous sommes en train de construire. Chez marmelab, tout comme vous probablement, nous gérons beaucoup de données pour nos activités. Nous avons développé plusieurs outils d'administration backend pour créer, modifier et récupérer ces données. Aujourd'hui, nous réfléchissons à l'opportunité de transformer ces outils en un produit web, ouvert à de nouveaux clients. Nous aimerions partager cette idée avec vous et recueillir vos commentaires. Nous sommes à un stade très précoce ; nous avons besoin de remettre en question nos hypothèses grâce à votre expertise. Vos remarques et critiques sur notre vision seront très précieuses pour nous. Elles nous aideront à valider que nous sommes sur la bonne voie, et à aligner le futur produit sur les besoins réels des clients.
2. Collecte des données démographiques ( test du segment de clientèle) - 2 minutes
C'est ici que nous essayons de comprendre qui est ce client - fait-il partie du segment que nous ciblons ? est-il un adopteur précoce ?
Le slogan de votre entreprise est "XXX". Pouvez-vous nous en dire plus sur votre activité principale ? Nous avons fait des recherches sur la taille de votre entreprise. Pouvez-vous confirmer nos chiffres concernant vos revenus et le nombre d'employés ? Qui sont vos clients ? Utilisez-vous l'un des services SaaS suivants ? - Trello, - KissMetrics - Basecamp - WordPress hébergé - Autre service SaaS Utilisez-vous l'un des logiciels suivants ? - Drupal - Magento - Excel - SharePoint - Autres logiciels spécifiques au domaine Quelles sont les données que vous collectez, stockez et modifiez dans le cadre de votre activité ? Par exemple, une société de commerce électronique stocke les clients, les produits et les commandes ; un média stocke les articles, les images et les publicités.
3. Racontez une histoire - 2 minutes
C'est ici que nous montrons notre intérêt pour les clients, que nous ouvrons la porte au partage de leurs préoccupations et que nous montrons notre compréhension du problème. Nous choisissons de raconter deux histoires différentes, selon le segment auquel appartient le client que nous interrogeons.
Histoire de la start-up
Nous avons travaillé avec plusieurs startups qui s'attachent à recueillir rapidement les commentaires des clients, afin de valider leurs hypothèses initiales. Par exemple, l'une des startups pour laquelle nous avons travaillé, a initialement lancé une page d'accueil simple, un workflow d'enregistrement soutenu par des pages statiques, et des analyses partout. Les fonctionnalités d'administration des données ont été reportées à un stade ultérieur. Dans l'intervalle, l'équipe de la startup a géré ses données à la main, en utilisant une approche de type concierge pour mieux comprendre les préoccupations des premiers utilisateurs. Le concierge a géré les abonnements, les demandes des clients et les données de tarification du cloud (leur cœur de métier) à l'aide d'outils primitifs comme un navigateur de base de données (phpMyAdmin). En fait, la plupart de l'administration des données réelles se faisait hors ligne, à l'aide d'Excel, et n'était copiée sur phpMyAdmin qu'une fois les données prêtes. Très vite, ils ont eu des difficultés à importer/exporter des données entre des outils conviviaux mais hors ligne (Excel) et des outils difficiles à utiliser mais en ligne (comme phpMyAdmin).
Histoire de la PME
Beaucoup de nos clients ne développent pas une seule, mais plusieurs applications. Par exemple, le système utilisé par l'un de nos clients, un service en ligne de réservation de restaurants, est divisé par domaine : une application pour la gestion des utilisateurs, une autre pour la configuration du restaurant, une autre encore pour les réservations, etc. Chaque application dispose de son propre outil d'administration backend. Le problème est qu'un grand nombre de tâches quotidiennes effectuées par les employés de cette entreprise font appel à plus d'un outil. Par exemple, pour ajouter un nouveau restaurant, il faut d'abord ajouter un nouvel utilisateur. Parfois, ils doivent saisir deux fois les mêmes données dans deux outils différents. Parfois, ils doivent passer d'une interface à l'autre pour vérifier la cohérence des données. Plus une entreprise se développe, plus elle utilise d'applications, plus ce problème devient une source de perte de temps (pour dupliquer les données, pour vérifier les erreurs et les corriger), et une source de dépenses (pour former les employés à plusieurs outils, pour développer de nouveaux outils backend).
