Comment on décide de quoi construire ensuite
Un petit studio ne peut pas tout construire ; « quoi construire ensuite » est donc notre décision la plus déterminante. Le processus brouillon et assumé derrière la feuille de route.
Quand tu es un petit studio, la décision de quoi construire ensuite n’est pas une décision parmi d’autres. C’est LA décision. Vise mal et tu passes trois mois et l’essentiel de ta trésorerie sur quelque chose que personne ne voulait. Vise juste et une seule fonctionnalité tire tout le produit vers l’avant. Les grandes boîtes peuvent se permettre d’étaler leurs paris sur une douzaine d’initiatives. Nous, on a quelques coups par an, et chacun doit compter.
Les gens supposent qu’il doit y avoir un cadre bien propre derrière un produit concentré. Il n’y en a pas. Il y a un processus brouillon, assumé, délibérément inconfortable, et je préfère le décrire honnêtement plutôt que de prétendre qu’on a un joli tableur de scoring.
On part de la douleur, pas des idées
Les idées sont gratuites et infinies. Tout le monde en a, nous compris, et la plupart sont d’absurdes séductions. On ne lance pas un chantier à partir d’une idée. On part d’une douleur qu’on a vue revenir, dans notre propre usage ou dans la façon dont les gens parlent du produit.
La discipline, c’est de continuer à demander ce qui fait mal, pas ce qui serait cool. Les fonctionnalités cool, c’est ainsi que les studios font faillite en se sentant occupés. Les problèmes douloureux, c’est là que vit la vraie disposition à payer. Si je ne peux pas nommer le moment précis de frustration qu’une fonctionnalité soulage, elle n’est pas prête à figurer sur la feuille de route.
On ne livre pas des fonctionnalités. On retire des douleurs.
Le signal auquel on se fie le plus est répété et spontané
Tous les retours ne se valent pas. Une fonctionnalité que quelqu’un réclame dans un sondage est un signal faible. Une frustration que le même type d’utilisateur soulève sans cesse, sans qu’on le sollicite, avec ses propres mots, est un signal fort. On pondère le spontané au-dessus du sollicité, à chaque fois.
- Le spontané bat le sollicité. S’il a fallu demander, la douleur est probablement légère.
- Le répété bat le bruyant. Un utilisateur furieux est un point de données. Cinq mentions calmes du même manque, c’est un motif.
- Le comportement bat les mots. Là où les gens décrochent, ce qu’ils réessaient, ce qu’ils capturent en screenshot, tout ça en dit plus que ce qu’ils nous racontent.
On dimensionne par le coût de l’erreur
Une fois qu’on a un candidat, la question n’est pas seulement quelle est l’ampleur du gain potentiel, mais à quel point l’erreur coûterait cher. Certains paris sont peu coûteux à tester et peu coûteux à défaire. D’autres nous engagent discrètement pour des mois. On préfère nettement le genre réversible.
C’est là qu’être petit est un avantage. On peut livrer une version brute d’une fonctionnalité à une tranche d’utilisateurs, regarder ce qui se passe, et la tuer sans cérémonie si elle fait un flop. Une équipe plus grande aurait besoin d’un plan de lancement et d’une réunion de parties prenantes pour faire la même chose. Nous, on essaie et on lit les données.
On le confronte à la règle de l’unique chose
Chaque candidat est confronté à la promesse centrale de l’app. MyoScore promet un score musculaire honnête. PrettyType promet une lecture honnête de la façon dont tu te présentes. Si une fonctionnalité n’affûte pas cette promesse, elle doit franchir une barre bien plus haute, parce qu’ajouter des fonctionnalités hors promesse, c’est ainsi que les apps concentrées se transforment lentement en apps boursouflées.
La plupart des meilleures décisions qu’on a prises étaient des décisions de ne pas construire. La feuille de route est autant une liste de refus qu’une liste de plans. Dire non à une bonne idée pour qu’une excellente ait de la place, c’est tout le métier.
On protège du temps pour le non-évident
Si tu ne construis jamais que ce que les utilisateurs réclament, tu feras une version incrémentalement meilleure de ce qui existe déjà, et tu ne feras jamais le saut que les utilisateurs n’auraient pas pu imaginer. Le cheval plus rapide d’Henry Ford est un cliché parce que c’est vrai.
Alors on réserve délibérément une part de notre effort à des paris qui viennent de notre propre conviction plutôt que d’une demande explicite. L’approche de notation honnête dans MyoScore est née de ce genre de pari, pas d’une demande de fonctionnalité. Ces coups de batte sont plus risqués, et ce sont aussi le seul moyen pour un petit studio de bâtir quelque chose de réellement neuf plutôt que simplement correct.
La décision n’est jamais terminée
La dernière chose que je dirai, c’est que quoi construire ensuite n’est pas une question à laquelle tu réponds une fois par trimestre dans un rituel de planif. C’est une question que tu tiens en continu, affûtée par chaque conversation, chaque décrochage dans l’entonnoir, chaque instant où tu te surprends à être frustré par ton propre produit. Les studios qui gagnent ne sont pas ceux qui ont le meilleur cadre. Ce sont ceux qui prêtent l’attention la plus soutenue.
Commentaires 2
« On ne livre pas des fonctionnalités, on retire des douleurs » va sur le mur. J’ai passé des années à optimiser pour le cool et tu as raison, ça nous donnait juste l’impression d’être occupés pendant que les chiffres stagnaient.
La grille de la réversibilité a changé ma façon de piloter notre feuille de route. On se demande maintenant explicitement « à quel point peut-on défaire ça à moindre coût » avant que quoi que ce soit n’atterrisse au tableau. Ça tue tôt beaucoup d’idées séduisantes mais lourdes.