Développer de nouveaux produits que les gens aiment est difficile, surtout parce que c’est un processus complexe qui prend beaucoup de temps. Cela nous demande d’apprendre de nos erreurs dans un environnement où revenir en arrière pour les corriger n’est jamais bien accepté.
Pour faire quelque chose de grand, il faut à la fois de la créativité et de la discipline. De nombreux produits échouent parce que ces deux éléments ne s’entraident pas ; ils se limitent plutôt l’un l’autre.
Limiter la créativité avec un processus strict piloté par des managers se traduira par un produit ennuyeux et inutile. S’appuyer uniquement sur la créativité du développeur vous permettra d’atteindre 80 % du produit rapidement, mais vous ne serez jamais capable de mettre la touche finale aux détails importants.
Au fil des années, j’ai vu des produits échouer à cause de l’ego, de la castration créatrice et d’un manque de discipline. Le besoin de produits de qualité est aujourd’hui trop grand pour perdre du temps et de l’argent.
En développant des produits à Translated et à Memopal, et en observant tant de magnifiques startups, j’ai imaginé une méthode qui vise à équilibrer créativité et discipline, une façon rapide et préalablement validée de revenir en arrière et corriger les erreurs, et qui intègre deux éléments communs aux produits qui réussissent : vision et psychologie. L’équipe minimale comprend:
- Le chef de produit, qui a la tâche de diriger.
- L’utilisateur ou les utilisateurs, qui ont la tâche d’exprimer les points de douleur et leur importance. L’utilisateur est un adopteur précoce qui a manifesté un intérêt pour acheter ou utiliser votre produit.
- Le ou les développeurs, qui ont pour tâche de trouver des solutions aux points de douleur de l’utilisateur et d’en estimer les coûts.
Si vous êtes le seul fondateur, je vous suggère de jouer le rôle de chef de produit et, si possible, de trouver quelqu’un qui sera votre développeur. Les fondateurs individuels peuvent jouer le double rôle de chef de produit et de développeur, mais ce n’est pas idéal, car cela crée un besoin naturel de rester dans la zone de confort, ce que nous essayons d’éviter avec cette méthode.
La plupart des gens développent des produits sans intégrer l’utilisateur dans la boucle initiale. Je pense que c’est une mauvaise idée. Pour réussir sans l’utilisateur, vous aurez besoin de beaucoup de chance, et les utilisateurs se trouvent plus facilement que la chance.
Identifier les douleurs
Multiples réunions d’une heure. L’utilisateur exprimera sa douleur perçue. Le chef de produit posera des questions pour clarifier et approfondir jusqu’à ce que la vraie racine du point de douleur soit identifiée. Les développeurs seront des observateurs silencieux. C’est là que le talent du chef de produit entre en jeu : jusqu’où peut-il plonger dans les racines du point de douleur sans être considéré comme un imbécile ? L’utilisateur tentera généralement de faire plaisir au chef de produit, lui disant qu’il aimerait que ce problème soit résolu. Cependant, le chef de produit ne doit pas prendre en compte ce que les utilisateurs disent : il doit regarder ce qu’ils font. C’est pourquoi je suggère souvent d’imaginer qu’il existe déjà un produit qui résout le problème, qui s’appelle X et coûte Y. Je dirais alors : « Voulez-vous que je vous en apporte un, maintenant ? » Si l’utilisateur dit « oui », vous avez identifié une douleur perçue qui vaut la peine d’agir ; si l’utilisateur dit « non », ou commence à ajouter de nouvelles exigences qui compliquent les choses, vous devrez recommencer le processus. Le chef de produit convertira chaque point de douleur en une tâche.
Ajouter la vision
Multiples réunions d’une heure pour discuter de l’aspect idéal du produit dans le futur. Les participants doivent comprendre qu’on ne leur demande pas de créer un produit maintenant, mais qu’ils doivent imaginer ce qui sera possible de faire un jour. Le chef de produit demandera aux développeurs comment il serait possible de dépasser les attentes de l’utilisateur, en tenant compte de leurs douleurs perçues. Les développeurs parleront alors de ce que la technologie pourrait potentiellement faire. Le chef de produit devra demander à l’utilisateur la même chose et donnera son propre point de vue à la fin. Normalement, le chef de produit possède la vision, mais en intervenant en dernier, il s’assure qu’il peut tirer parti de la créativité des participants. La discussion devra se poursuivre jusqu’à ce que le chef de produit convienne que le futur produit sera techniquement faisable et aimé par l’utilisateur. Le chef de produit convertira les idées en tâches.
Ajouter le pathos
Les produits les plus réussis offrent aux utilisateurs quelque chose de plus que la seule solution à un problème perçu.
S’attaquer à la vanité, à la paresse et désirer quelque chose que nous ne pouvons pas avoir font partie des éléments que l’on retrouve chez tous les grands produits. Les réunions de ce module fonctionnent mieux si elles n’impliquent que le chef de produit, l’utilisateur et l’intimité d’une conversation. Le chef de produit devra encourager l’utilisateur à parler de son travail ou de sa vie, et ne pas penser au développement de son produit pendant un moment. Le chef de produit devra demander à l’utilisateur ce qui le rend meilleur que ses pairs, ce qui l’ennuie mais aussi ce qu’il veut et ne peut pas avoir. Tout cela sera traduit en tâches.
Définir les priorités et les versions
Toutes les tâches dérivées des points de douleur, de la vision et de la psychologie seront insérées dans un tableau comme celui ci-dessous :
| Tâche | Coût en $ | Impact en $ | Priorité |
|---|---|---|---|
| Permettre aux utilisateurs de faire un clic droit sur la photo pour la partager | 2.000 | 10.000 | 5,0 |
| Version 1 | |||
| Agrandir les photos | 1.500 | 5.000 | 3,3 |
| Compatible Android | 10.000 | 10.000 | 1,0 |
| Version 2 | |||
| Organisation automatique des photos | 50.000 | 25.000 | 0,5 |
| Mise en vedette automatique des meilleures photos | 20.000 | 5.000 | 0,2 |
| Version 3 | |||
Le coût est une estimation du coût total de la tâche ; il ne devra être renseigné que par les ingénieurs. L’impact associé à la tâche est un score ou une valeur économique. Il ne devra être donné que par les utilisateurs, probablement sans voir le coût. Le plus important, ce n’est pas le nombre lui-même, mais le ratio entre les tâches. Si une tâche a deux fois plus de valeur qu’une autre, son impact devra être deux fois plus important. Le chef de produit devra demander aux ingénieurs et à l’utilisateur de s’assurer que les estimations sont correctes. Le chef de produit calculera la priorité en impact/coût et classera les tâches par ordre de priorité décroissant. Le chef de produit, avec l’aide de l’utilisateur et des ingénieurs, dessinera des lignes horizontales pour organiser la création des différentes versions.
Le regroupement des tâches en versions par priorité garantit que le meilleur rapport qualité-prix est fourni dans la première version. C’est essentiel pour l’adéquation produit/marché. Si la proposition de valeur souhaitée n’est pas claire dans la première version, le chef de produit devra contester les chiffres précédents ou reconsidérer la proposition de valeur elle-même. Vous pouvez alors trouver que le point de douleur pris en compte ne vaut vraiment pas la peine de travailler dessus.
Passer en revue les différentes versions
Faites la version 1 du produit et demandez à l’utilisateur de l’utiliser. Demandez des pré-commandes à un prix équitable, puisqu’il s’agit d’une version alpha du produit. Si l’utilisateur pré-commande, passez à la version 2 et recommencez.
Si l’utilisateur ne pré-commande pas parce qu’il pense que le produit ne traite pas le point de douleur, revenez en arrière et identifiez à nouveau les points de douleur. Si, après quelques cycles, l’utilisateur ne pré-commande toujours pas, le maillon le plus faible entre utilisateur, développeur et chef de produit doit être remplacé et le cycle redémarré.
Au-delà de la créativité et de la discipline, si vous voulez créer de bons produits, vous devez être prêt à faire de gros sacrifices ou espérer avoir beaucoup de chance. Si vous voulez créer un grand produit, vous aurez besoin des deux.