Produit

Ce que nous avons choisi de ne pas construire

La plupart des décisions produit portent sur ce qu'il faut ajouter. Les décisions qui ont défini Max portent sur ce qui a été retiré, et sur le prix qu'il faut être prêt à payer pour tenir un refus dans la durée.

Il y a, dans la conception d'un produit sérieux, un type particulier de décision dont on ne parle presque jamais en public. Ce sont les décisions de refus. Pas une fonctionnalité qu'on choisit d'ajouter, mais une fonctionnalité que tout le monde attend, qui paraît évidente, qui se vend bien, et qu'on choisit délibérément de ne pas construire. Ces décisions, par définition, ne se voient pas dans le produit fini. Elles laissent un vide qu'on ne remarque pas, parce qu'il n'y a rien à remarquer. Et pourtant, ce sont elles, souvent, qui définissent le produit plus fortement que tout ce qu'on a effectivement construit.

Pour Max, la décision de refus qui a tout dessiné se laisse résumer en une phrase. Nous avons choisi de ne pas construire d'interface. Pas d'application Max à ouvrir. Pas de plateforme Max à apprendre. Pas de nouvel endroit où aller. Cette décision paraît anecdotique quand on la lit, et elle est, en réalité, le choix le plus lourd que nous ayons fait. Tout ce qui suit dans Max, l'architecture, la position vis-à-vis des cabinets, le modèle économique, et même la confidentialité, découle de ce refus initial.

La pression dans le sens contraire

Pour comprendre pourquoi ce refus était difficile, il faut voir à quel point la pression dans le sens contraire est forte quand on construit un produit d'IA juridique. La voie de moindre résistance, et c'est celle qu'à peu près tous nos concurrents ont prise, est de construire une application visible. Une plateforme. Un nouvel endroit que les avocats ouvrent, où ils se connectent, qu'ils apprennent et qu'ils adoptent.

Il y a d'excellentes raisons commerciales de le faire, et elles ne sont pas mauvaises. Une application visible est facile à démontrer, parce qu'il y a quelque chose à montrer. Elle est facile à vendre, parce qu'il y a quelque chose à pointer pendant le pitch. Elle est facile à habiller d'un logo, facile à commercialiser, facile à faire ressembler à un produit. Elle a un nom que l'utilisateur retient, une icône qu'il voit dans son dock, une interface qu'il peut critiquer ou louer. Tout ce que l'industrie de l'enterprise software a appris à faire en quarante ans tire dans cette direction, et tirer dans cette direction est un choix par défaut qu'il faut un effort conscient pour défaire.

Si nous avions construit une interface, Max aurait été plus facile à présenter, plus facile à vendre, plus facile à faire grandir en chiffre d'affaires sur les douze premiers mois. Il y a un coût à l'avoir refusée, et nous le payons tous les jours, dans la difficulté d'expliquer un produit qu'on ne peut pas montrer en démo. Mais ce coût est volontaire, parce que la décision était délibérée, et parce que ce qu'elle coûte à court terme, elle le rend, multiplié, à long terme.

La chose la plus facile à construire est un endroit où les gens vont. La chose la plus difficile à construire est un produit où ils n'ont jamais à aller.

L'autre voie, et ce qu'elle exige

Max a pris l'autre voie. Il n'y a pas d'interface Max à ouvrir, pas d'application Max à apprendre, pas de nouvelle destination, pas d'onglet supplémentaire que l'avocat doive penser à rejoindre. Max vit à l'intérieur des outils que les avocats utilisent déjà, et il opère depuis l'intérieur. L'utilisateur ne visite pas Max. Max arrive là où l'utilisateur est déjà, fait son travail, et repart sans avoir demandé d'attention. Le produit, au sens le plus littéral, ne demande rien.

Cela sonne comme moins. C'est, en réalité, considérablement plus, et considérablement plus difficile. Construire un produit que l'utilisateur n'a pas à remarquer n'est pas une question de cacher une interface. C'est une question de construire tout ce qui permet au travail de se faire sans interface : l'orchestration qui coordonne ce qui serait sinon des outils séparés, la mémoire qui porte le dossier d'une interaction à la suivante, la méthodologie qui encode comment un bon travail juridique se fait réellement, et la gouvernance qui rend tout cela imputable. Aucune de ces choses ne se voit. Toutes sont indispensables pour que le produit fonctionne.

L'invisibilité, dans un produit d'enterprise software, n'est pas l'absence d'ingénierie. C'est le résultat d'une ingénierie considérable, qui a accepté de ne pas se montrer. Pour qu'un utilisateur n'ait pas à apprendre Max, il faut que Max ait appris l'utilisateur. Pour qu'un avocat n'ait pas à se demander où ses données vont, il faut qu'elles n'aillent nulle part. Pour qu'un cabinet n'ait pas à organiser le déploiement d'une nouvelle plateforme, il faut que Max se loge dans la pile existante sans la perturber. Chacune de ces conditions a un coût d'ingénierie significatif, et c'est ce coût qui rend l'invisibilité possible.

Retirer le besoin pour l'utilisateur de remarquer le système est de l'architecture, pas de la décoration. Cela coûte plus, pas moins.

La décision avait une seconde conséquence, que nous n'avions pas pleinement anticipée

Quand nous avons décidé que Max n'aurait pas de plateforme séparée, nous avons aussi, sans le réaliser pleinement au début, décidé quelque chose au sujet de la confidentialité. Parce qu'il n'y a pas de destination Max vers laquelle le travail doit voyager, les données n'ont pas à quitter l'environnement du cabinet pour être utiles. Ce qui rend Max invisible pour l'utilisateur et ce qui rend Max sûr pour le cabinet se révèlent être la même décision, vue sous deux angles.

Cette équivalence n'était pas le motif initial du refus. Nous n'avions pas, en posant la décision, en tête de résoudre par cette voie la question de la confidentialité. C'est en avançant dans la construction que nous avons réalisé que les deux propriétés découlaient l'une de l'autre. Pas d'interface signifie pas de destination. Pas de destination signifie pas de transit. Pas de transit signifie pas d'exposition. Et pas d'exposition signifie une confidentialité qui n'a pas besoin d'être promise au-dessus du produit, parce qu'elle tombe naturellement de son architecture. Nous avons ajouté la confidentialité comme une fonctionnalité au-dessus du produit, dans la communication ; mais en vérité, elle était déjà là, intégrée dans la décision de refus initiale.

L'invisibilité et la confidentialité ne sont pas deux fonctionnalités. Ce sont une seule décision architecturale, vue sous deux angles.

Pourquoi cette décision dure

La décision de construire Max de cette manière n'était pas un instinct marketing, et elle n'était pas non plus un coup d'audace. Elle était la conséquence de trente ans à observer ce qui fait durer un logiciel d'entreprise et ce qui le fait disparaître. Le schéma est constant et un peu brutal. Les outils qui exigent de l'attention finissent par entrer en compétition pour elle, et l'attention est la ressource la plus rare dans la journée d'un professionnel. Ils la gagnent un temps, puis la perdent au profit du prochain outil qui l'exige plus fort, plus visiblement, avec une interface plus brillante. Les couches qui disparaissent dans le travail, à l'inverse, ne sont jamais dans cette compétition. Elles deviennent simplement une partie de la manière dont le travail se fait, et elles survivent aux cycles qui les ont produites.

Ce schéma se voit dans l'histoire de l'enterprise software, vague après vague. Les outils qui ont disparu sont presque toujours ceux qui réclamaient le plus d'attention pendant leur âge d'or. Les couches qui ont duré sont celles qui se sont logées sous les usages, sous les interfaces, sous l'attention. La couche sémantique de Business Objects, qui a inspiré nos choix, est invisible pour 99 % de ceux qui en bénéficient chaque jour. C'est précisément ce qui explique qu'elle existe encore. Une couche qu'on ne voit pas est une couche qu'on ne remplace pas, parce qu'il n'y a rien à voir qu'on puisse vouloir remplacer.

C'est le test auquel nous nous sommes tenus. Pas de savoir si Max serait impressionnant le jour de son lancement, mais s'il serait encore là, discrètement porteur, longtemps après que l'enthousiasme pour tel modèle ou telle interface se soit estompé. Construire pour ce test impose des renoncements qu'il aurait été plus simple de ne pas faire. Renoncer à l'interface. Renoncer à la démo qui éblouit. Renoncer à la métrique d'engagement qu'on aurait pu présenter aux investisseurs. Chacun de ces renoncements a un coût immédiat. Aucun n'a un coût durable.

La manière de passer ce test n'était pas d'ajouter le plus. C'était de demander le moins. Et nous avons fait ce pari, en sachant qu'il rendait Max moins facile à raconter, parce que nous étions convaincus qu'il le rendait plus difficile à remplacer.

Le bon design n'est pas ce qui a été ajouté. C'est ce qui n'a plus besoin d'être là.

Ce que ce refus signifie pour le cabinet qui choisit Max

Jusqu'ici, nous avons parlé du refus du point de vue de celui qui le porte, c'est-à-dire nous. Il y a une seconde perspective, plus importante encore, qui est celle du cabinet qui choisit Max. Pour lui, ce refus se traduit en propriétés concrètes qu'aucun produit construit autrement ne peut offrir, et il vaut la peine de les énumérer.

Premièrement, le cabinet n'a pas de déploiement de plateforme à organiser. Il n'y a pas de migration de données, pas de formation utilisateur sur une nouvelle interface, pas de période de transition pendant laquelle deux outils coexistent et se concurrencent. Max se loge dans l'environnement existant et opère depuis l'intérieur. La courbe d'adoption qui pèse habituellement plusieurs mois sur la productivité des équipes n'existe simplement pas.

Deuxièmement, le cabinet ne dépend pas de la longévité commerciale d'une plateforme tierce. Quand un éditeur dont la plateforme est devenue centrale au travail change de modèle économique, est racheté, ou ferme, les conséquences pour le cabinet client sont sévères. Max ne crée pas cette dépendance, parce qu'il ne possède pas de plateforme dont la disparition pourrait emporter une partie du travail.

Troisièmement, et c'est peut-être le point le plus profond, le cabinet ne paie pas, dans son travail quotidien, le coût attentionnel d'un outil supplémentaire qui demande à être appris, ouvert, et géré. Cette économie est invisible dans les premières semaines, et elle devient considérable dans la durée. Un avocat dont l'environnement de travail accumule huit interfaces consacre une part non négligeable de son énergie à passer de l'une à l'autre. Max retire cette ligne du compte sans rien lui demander en échange.

Le coût d'un outil ne se mesure pas à son abonnement. Il se mesure à ce qu'il prend dans la journée de celui qui s'en sert.

Ces trois propriétés, mises bout à bout, dessinent une asymétrie de coût qui ne se voit pas au moment de la décision d'achat, parce que la décision d'achat regarde les fonctionnalités et la démo. Elle se voit dans la durée, dans les trois ou quatre années qui suivent, quand le cabinet qui a choisi Max réalise qu'il a gardé son indépendance vis-à-vis d'un éditeur, économisé un déploiement coûteux, et préservé l'attention de ses équipes pour le travail juridique. Le refus initial, vu sous cet angle, n'est plus un renoncement de notre part. C'est un cadeau structurel au cabinet qui en bénéficie.