Votre vue du monde

Pensez à ce qui fait fonctionner un bon magazine.

Ce n’est pas parce qu’il couvre plus de sujets que ses concurrents. L'Actualité et Wired pourraient tous les deux publier un article sur l'IA, ce ne serait pas du tout la même chose. Même sujet, mais une vision du monde complètement différente. On peut lire un magazine pour son contenu, mais on s'y abonne pour son point de vue.

C'est ce que la plupart des gens oublient dans les produits éditoriaux. Ce n'est pas juste le contenu. C'est la voix. Les mots choisis. Les sujets traités comme évidentes qu'une autre publication aurait passé trois paragraphes à expliquer. L'opinion, discrètement intégrée dans chaque phrase, sur ce qui compte et ce qui ne compte pas.

Les meilleurs logiciels fonctionnent exactement de la même façon.

Jira vs. Linear

Prenons les outils de gestion de projet: un de mes exemples préférés dans ce journal.

Jira rend tous les workflows possibles. On peut le configurer pour correspondre à presque n'importe quel processus, n'importe quelle structure d'équipe, n'importe quelle méthodologie. C'est de l'ingénierie impressionnante au service d'une flexibilité totale.

Linear a pris la position inverse. Un seul workflow. Leur opinion, imposée à tous. Pas de menus de configuration, pas de statuts personnalisés qui deviennent un chaos, pas de "adaptez-le à votre situation spécifique". Juste: voilà comment les équipes logicielles devraient travailler, et on a construit l'outil autour de cette conviction.

Linear n'a pas gagné parce qu'il a de meilleures fonctionnalités. Il a gagné parce qu'il a un point de vue. Les développeurs n'ont pas acheté un outil de gestion de projet. Ils ont acheté une opinion sur ce à quoi ça devrait ressembler bien faire du développement.

C'est ça, le changement. Les gens n'achètent plus votre logiciel. Ils achètent votre point de vue.

À quoi ça ressemble en pratique

J'ai été dans la salle quand ça déraille. Une équipe produit, six mois dans un projet, assise autour d'une table à essayer de répondre à un ticket de support. Un utilisateur a demandé une fonctionnalité qui semble tout à fait raisonnable. La moitié de l'équipe pense qu'elle fait du sens. L'autre moitié pense que non. Personne ne peut trancher, parce que personne n'a jamais réfléchi aux convictions du produit. Alors on vote, ou celui qui a le plus de capital politique cette semaine-là gagne. Peu importe, le produit devient un peu plus incohérent.

Cette réunion arrive dans la plupart des entreprises. Éventuellement, le produit est techniquement capable, généralement correct, et complètement oubliable. Personne ne peut vous dire à quoi il sert. Personne ne le défend. Il fonctionne, et il ne signifie rien.

J'ai passé les quatre premières heures de mon dernier projet à m'assurer que cette réunion ne puisse jamais arriver.

Pas de code. Pas de design. Pas de roadmap. Juste des fichiers markdown: ce qu'est ce produit, pour qui il est, ce qu'il refuse de faire, et pourquoi. Le projet est une application de gestion de patrimoine pour les petits family office de première génération (des entrepreneurs qui viennent d'avoir un événement de liquidité et gèrent une somme d'argent sérieuse pour la première fois). L'espace est saturé. Chaque grande banque a une app. Il y a des robo-conseillers, des trackers de portefeuille, des tableaux de bord financiers de toutes les formes.

Le premier document que j'ai écrit ne parlait pas des choses à construire. C'était une liste de ce qu'on ne construira jamais.

Pas de notifications déclenchées par des mouvements de marché. Pas de valeur nette comme métrique principale de l'écran d'accueil. Pas de "vous êtes sur la bonne voie". Pas de comparaison avec le S&P 500. Aucune gamification. Aucune fonctionnalité qui génère des revenus quand l'utilisateur fait une transaction.

Chacun de ces choix, c'est une décision que la plupart des produits concurrents ont prise différemment. Et chacun reflète une conviction: l'industrie financière est structurellement incitée à garder les utilisateurs anxieux et actifs, et qu'un produit construit sur la prémisse inverse (conçu pour être consulté moins souvent, pas plus) est une chose fondamentalement différente.

Cette liste n'est pas une contrainte. C'est la vision du monde du produit, rendue opérationnelle. N'importe quel ingénieur, designer ou collaborateur qui travaille sur le projet peut ouvrir ce document et répondre à la question "est-ce que ça a sa place ici?" sans avoir à me demander.

Le problème éditorial

Le SaaS n'est pas mort. Le SaaS indifférencié, lui, est mort. Les produits qui compétitionnent sur l'étendue des fonctionnalités, qui essaient d'être suffisamment configurables pour servir tout le monde, qui n'ont aucune opinion réelle sur ce que "bon" ressemble pour leur utilisateur: ceux-là sont en difficulté. Ce n'est pas un problème de modèle d'affaires. C'est un problème éditorial.

La solution n'est pas un nouveau modèle de tarification. C'est une chose plus difficile: décider ce en quoi vous croyez à propos du problème/solution, comment vous en parlez, quels mots vous utilisez, ce que vous refusez de faire, et avoir la discipline de tenir cette ligne quand un utilisateur raisonnable demande quelque chose qui n'a pas sa place.

Ça a toujours été le travail. La plupart des équipes l'ont évité parce que la course aux fonctionnalités leur donnait une alternative facile, mais moins efficace.

La vraie question n'est pas ce que vous construisez. C’est est-ce que quelqu'un peut lire votre produit (le texte, les états vides, les messages d'erreur, les fonctionnalités absentes) et comprendre vos convictions. Votre point de vue éditorial.

Si ce n'est pas le cas, vous ne gérez pas un produit. Vous gérez un backlog.