Comment déterminer s'il est nécessaire de développer une nouvelle fonctionnalité.
En 2021, je suis passé de travailler comme designer produit dans une grande entreprise à faire partie de l'équipe de démarrage - Logto.
Ici, je m'occupe à la fois du produit et du design. Ce nouveau rôle est un départ marqué de mon expérience précédente dans une entreprise bien structurée avec des processus clairs et des méthodes de collaboration. De plus, j'ai perdu mon collaborateur le plus proche, un chef de produit. Par conséquent, j'ai dû assumer plusieurs rôles, y compris le produit, le design, la recherche, le marketing et même l'auto-gestion de projet.
Mon équipe et moi nous retrouvons souvent plongés dans les discussions les plus difficiles, souvent centrées sur la question de savoir s'il faut mettre en œuvre certaines fonctionnalités du produit et définir leur portée.
Dans ces situations, nous devenons tous passionnément impliqués, exprimant nos opinions, avec passion et une attitude obstinée. Les points de vue semblent être un mélange généré par une machine complexe - contrairement à ce qui est écrit dans les documents, ils manquent d'organisation et de discipline.
C'est parce que "l'intuition" apparaît souvent avant l'expression structurée, entraînant des tas de discussions décousues, menant à des batailles philosophiques.
La motivation derrière l'écriture de cet article est d'organiser les principes directeurs de la prise de décision. Ces principes découlent de mes expériences personnelles et réflexions travaillant dans l'environnement de démarrage, et ils ne sont pas une sorte de solution miracle. J'espère fournir une inspiration et des perspectives aux entrepreneurs ou à ceux qui travaillent dans le produit, l'ingénierie ou le design.
Cet article est très intéressant si vous êtes dans la situation suivante...
✅ Construire une équipe de démarrage pour développer des produits de 0 à 1, ainsi que des stratégies GTM (Go-To-Market), particulièrement pour l'expansion internationale.
✅ L'expansion des produits de 10 à 100 nécessite l'établissement d'une feuille de route du produit.
✅ Les responsables de produits ou les rôles avec des responsabilités de planification apprennent à identifier les opportunités rapidement.
✅ ICs apprend à conduire de nouvelles initiatives au sein de grandes organisations.
Cet article n'est PAS génial pour lire si vous êtes dans la situation suivante...
❌ Projets flous initiés par le haut par les responsables ou les cadres.
❌ Projets éloignés des objectifs commerciaux visant à valider l'impact individuel ou autonome de l'équipe.
❌ Des demandes de produits hautement personnalisées axées principalement sur les grands clients.
D'un point de vue, je considère même le fait de rester concentré comme du bon sens, quelle que soit la taille de l'organisation, car les ressources sont limitées.
Les ressources ici ne se réfèrent pas seulement aux ressources financières, mais aussi au temps : en termes de temps, les équipes de démarrage et les grandes entreprises sont sur un pied d'égalité.
Dans la plupart des cas, nous devrions nous concentrer sur la création de fonctionnalités escalables et essentielles qui correspondent aux besoins de nos utilisateurs cibles et aux personnages des clients. Le produit devrait être un "tueur de douleur" plutôt qu'une "vitamine".
En gardant la focalisation, il devient plus facile et plus naturel de maintenir une proposition de valeur de produit claire et d'améliorer la compréhension du client. Le produit progresse régulièrement vers sa vision, élargissant progressivement l'espace du problème auquel il s'adresse de manière saine, favorisant la croissance organique.
Nous n'avons pas à résoudre tous les problèmes ; nous devrions maintenir notre perspective et être assez courageux pour dire non.
Alors, laissez-moi écrire sur différents types de "signaux" pour savoir si "cette fonctionnalité vaut la peine d'être développée".
Ce concept, "signaux de surface", représente des signaux superficiels qui peuvent servir de références mais ont encore un long chemin à parcourir avant de prendre des décisions.
Bien que je prenne récemment plaisir à étudier la science politique, faire des comparaisons est une méthode qui ressemble à l'analyse politique, visant à gagner des "possibilités". Avoir cette perspective plus large peut offrir des idées, donc, dans notre contexte actuel, il est utile d'étudier divers produits.
Cependant, si nous nous appuyons trop sur l'analyse des concurrents, cela a tendance à conduire à des décisions de produits qui manquent de réflexion stratégique. Il est essentiel de se demander pourquoi un concurrent n'a pas mis en œuvre une fonctionnalité - cela ne correspond-il pas à leurs valeurs, aux utilisateurs cibles, aux priorités stratégiques ou aux ressources ?
Ainsi, l'analyse des concurrents devrait fournir des informations plutôt que des décisions absolues. Ce n'est qu'une partie du processus de collecte d'informations pour prendre des décisions.
Les gens du produit qui sont doués pour comprendre les perspectives des utilisateurs et utiliser la déduction de scénario peuvent rapidement vérifier ou découvrir de nouveaux scénarios. Cependant, cela n'est qu'une hypothèse et nécessite un travail supplémentaire dans un environnement réel de mise sur le marché.
Bien que déduire des scénarios plausibles soit précieux, se fier uniquement à cette approche peut conduire à la création d'un produit "tout-en-un" ou encombrant avant d'atteindre l'adéquation produit-marché, rendant les itérations et ajustements ultérieurs difficiles.
Une analogie simple consiste à traiter chaque scénario d'utilisateur déduit comme un projet de démarrage 0-1, en considérant les mini stratégies de mise sur le marché, en apportant des perspectives de marketing et en posant des questions difficiles. Cette évaluation multidimensionnelle va au-delà des besoins et de l'expérience des utilisateurs.
Fréquemment, les retours d'information des utilisateurs de haute fréquence deviennent un principe directeur pour le développement de fonctionnalités et la conception de produits. Cependant, ce principe directeur peut parfois être un piège. En vieillissant et en travaillant plus de projets, j'établis ce genre de cadre pour s'attaquer et gérer les retours d'information des utilisateurs,
Définir le problème et le reformuler follement et régulièrement
Ce processus impliquera beaucoup de délibération, d'aller-retour, et de débats, nécessitant un certain temps et des efforts. Ne pensez pas que ce processus est inutile, car à travers les discussions, il divergera et déterrera certains problèmes "d'iceberg sous-jacent". Mon équipe et moi avaient l'habitude d'arguer sans fin sur le bien et le mal de quelque chose et des solutions potentielles, ce qui n'est pas bon. Maintenant, nous sommes plus en phase pour identifier où chacun de nous ressent les problèmes et se concentre sur la résolution de problèmes. Ce processus est très précieux.
Obstiné vs. Non obstiné
Il est super nécessaire de définir si cette fonctionnalité/scénario devrait aller avec une approche obstinée ou non obstinée. Par exemple, Notion est un produit obstiné ; Google Docs est un peu obstiné ; Microsoft Word n'est pas obstiné. En tant que constructeur de SaaS qui vise à innover l'ancien paradigme, il est préférable d'aller avec une approche obstinée. Les produits obstinés divisent et filtrent les utilisateurs, et ceux qui sont d'accord avec eux sont enthousiastes à l'idée d'exprimer leur soutien. C'est extrêmement utile pour aider le produit en phase de démarrage à trouver des utilisateurs de semences et à créer une narration facile à comprendre.
Si vous optez pour une approche obstinée, essayez de résoudre le problème avec une seule solution par scénario. Si une solution alternative se présente (Solution B pour un Scénario A donné), considérez si la Solution A adresse réellement les points de douleur. Si ce n'est pas le cas, revenons à la Solution A plutôt que de simplement introduire une autre solution.
Les principes de produit d'Intercom ont inspiré cette approche : "Construire un produit qui est par défaut obstiné mais flexible sous le capot."
Reconnaître que les utilisateurs pourraient suggérer des travaux avancés à faire
Certains utilisateurs pourraient proposer d'utiliser une fonctionnalité destinée au Scénario A pour résoudre le Scénario B. Identifier ces pièges est crucial ; n'investissez pas trop d'énergie dans des problèmes non méritants.
La seule situation méritant attention est lorsque la Solution B indique un besoin réel, pas seulement une alternative à la Solution A. Cela signifie que la Solution B aborde un "problème nouvellement né" étroitement lié à la vision et à la mission du produit. Ce signal est précieux lorsque l'entreprise veut grandir davantage et découvrir sa prochaine phase de grande expansion.
Éviter de compliquer un produit ne consiste pas à ignorer la résolution de problèmes difficiles, mais c'est un rappel que la réconciliation d'un produit "complexe, tout compris" avec une expérience "simple, conviviale" est irréaliste dans le monde réel. Si vous ignorez comment tout fonctionne ensemble (pensée systémique) et vous vous concentrez uniquement sur la résolution de problèmes d'expérience utilisateur fragmentés, le résultat est un produit mal conçu.
Les produits complexes déclenchent une réaction en chaîne, rendant le service autonome difficile et prolongeant le temps nécessaire pour voir la valeur dans le produit.
La conception d'outils pour les entreprises (2B) est un peu philosophique : elle implique de créer des modèles mentaux en tandem avec les utilisateurs et d'établir une structure qui peut anticiper le comportement des utilisateurs. La complexité provient souvent d'architectures inconsistants et non structurés, essayant de satisfaire les demandes en assemblant des interactions, ce qui donne des produits qui sont des "survivalistes" plutôt que de fournir d'excellents parcours utilisateur.
Les fonctionnalités qui rendent un produit complexe, de l'exigence à la solution, sont tous de mauvais signaux.
Bien que cela peut ne pas vous aider définitivement à dire non, c'est un point crucial qui exige des compromis clairs.
En d'autres termes, créer des fonctionnalités qui ne correspondent pas au positionnement d'un produit endommage et brouille l'image du produit. Par exemple, Logto est un outil de développement qui se concentre sur la gestion de l'identité à ce jour. Si je dis, construisons une fonctionnalité d'outil de marketing, c'est une mauvaise stratégie.
Cette perspective provient de l'objectif commercial d'une entreprise ou d'une organisation. J'ai vu beaucoup d'activités réalisées dans un environnement d'entreprise ou de grande entreprise, telles que :
Dans un état de fonctionnement relativement stable, ces scénarios sont précieux et devraient être encouragés et soutenus. Pourtant, dans des environnements de démarrage difficiles, de tels projets nécessitent des ressources significatives et du temps pour valider la valeur, témoignant d'un engagement envers la poursuite professionnelle plutôt que la réussite commerciale. Ce point souligne un conflit entre les poursuites personnelles, les convictions de carrière et les objectifs commerciaux.
Bien qu'initier des projets de manière proactive soit admirable, il est également important de reconnaître qu'un dévouement excessif à quelque chose pourrait ne pas apporter de retours valables : employer mon marteau pour trouver des clous, puis utiliser une règle pour mesurer à quelle profondeur mes trous sont et combien mon rayon est grand - cela pourrait ne pas être crucial dans le schéma général des choses. En réalité, la personne qui m'a embauché pour planter des clous a juste besoin d'une manière d'accrocher une photo, et je n'ai pas besoin de prouver à quel point je suis doué pour planter des clous.
Ce point abstrait mais vital peut être évalué de manière concrète : lors de la considération d'une fonctionnalité, demandez si les utilisateurs seraient significativement déçus si le produit ne l'a pas, ce qui pourrait les amener à partir. Par exemple, considérez notre produit Logto en position actuelle pour résoudre les problèmes d'authentification, d'autorisation et de gestion des utilisateurs/organisations. Plus une fonctionnalité est étroitement liée à ces aspects, plus sa priorité est élevée. Si Logto manquait d'une fonctionnalité particulière, à quel point nos utilisateurs seraient-ils déçus ? Si la réponse est oui, cela suggère que la priorité est élevée et que c'est notre mission de fournir une excellente expérience de développeur à ce problème.
La Silicon Valley met souvent l'accent sur la recherche utilisateur et la taille des opportunités pour leur praticité et leur rigueur. Ces deux aspects indiquent qu'une fonctionnalité vaut la peine d'être explorée et développée quand ils fournissent des idées positives.
Ce concept implique les fruits à portée de main qui apportent une énorme quantité de joie et d'avantages sans effort, en faisant une partie de la personnalité et de la marque du produit.
Au milieu de toute l'analyse, la pensée rationnelle est essentielle, mais laisser de l'espace pour l'intuition est également crucial. Si vous êtes convaincu qu'une fonctionnalité est l'avenir malgré le manque de données rationnelles ou de validation de marché, cela vaut la peine d'explorer.
Pour les autres fonctionnalités peu claires, laissez-les se développer et nous pouvons observer les “signaux” au fil du temps naturellement.
Tout au long du développement du produit, de l'entrepreneuriat, et des interviews sur le travail du produit, vous pourriez rencontrer beaucoup de questions qui font réfléchir, particulièrement dans la Silicon Valley, comme le sujet que j'ai mentionné ci-dessus, devrions-nous construire cette fonctionnalité ?
Bien que ce genre de questions ne puisse pas avoir de principes universels, ils requièrent une exécution réfléchie et une délibération dans des situations concrètes. Cependant, décomposer des questions grandioses et vagues en réponses tangibles est une compétence que les constructeurs affinent tout au long de leur carrière et un super pouvoir pour construire de grands produits.
J'espère que les connaissances fournies peuvent inspirer votre approche de la pensée produit dans une startup. Chez Logto, nous apprécions beaucoup la construction de produits que les développeurs aiment. Nous sommes heureux de discuter et de partager nos perspectives sur des sujets similaires.