Trois contraintes à considérer avant de construire

• Pour une idée de produit, imposer d’abord des contraintes réduit l’espace d’exploration et évite de dériver vers un résultat trop complexe ou sans identité
• Toute idée doit être résumée dans un one pager ; si elle n’y tient pas, c’est qu’elle nécessite encore davantage de recherche, de planification et de prototypes
• Il faut construire en parallèle une core tech capable de survivre indépendamment du produit, afin qu’elle reste un actif cumulatif même en cas de changement de direction
• Le produit doit avoir en son centre une defining constraint qui reste continuellement visible pour l’utilisateur, et cette contrainte définit naturellement le ressenti et l’identité du produit
• Si un seul de ces trois critères n’est pas rempli, mieux vaut ne pas construire : cette discipline est importante pour le contrôle du périmètre et l’obtention d’un levier à long terme

---

Les trois contraintes à imposer avant de construire

• Poser d’abord des contraintes avant de construire un produit réduit l’espace d’exploration et évite de dériver vers un résultat complexe ou sans identité
• En dix ans de création de plusieurs produits, les produits trop complexes ou sans identité ont mené à l’échec, et après ces tâtonnements, l’approche s’est condensée en trois critères

• Si cela dépasse une page, on ne le construit pas

  • Toute idée doit être résumée dans un one pager, qui sert de north star
  • Le one pager doit être non négociable, précis, ambitieux et sans fioritures
  • Le même document peut servir à communiquer avec des investisseurs, des contributeurs, des membres de l’équipe, des amis ou de la famille
  • En cas de désaccord pendant une collaboration, ce qui ne figure pas dans le one pager ne mérite pas de dispute ; si c’est vraiment important, il faut modifier le document pour l’y intégrer
  • Si l’on n’arrive pas à remplir une page, il ne faut pas gonfler artificiellement le contenu : cela signifie simplement qu’on n’est pas encore prêt à construire
  • Dans ce cas, il faut d’abord passer par de la recherche, de la planification et des prototypes, puis réécrire le one pager
  • Si cela dépasse une page, c’est trop complexe, donc on ne le construit pas

• La technologie fondamentale doit être séparée du produit

  • Indépendamment du produit lui-même, il faut construire une core tech qui le soutient
  • La core tech peut être une méthodologie, une technologie, un outil ou même un produit séparé, et elle doit pouvoir survivre même sans le produit actuel
  • Cette séparation évite de rester enfermé dans un seul produit et permet à l’accumulation de se poursuivre même en cas de pivot
  • Les produits changent souvent de direction, mais la core tech reste un actif durable et cumulatif
  • À long terme, ce type d’effort cumulatif peut produire des gains non linéaires
  • Parmi les exemples cités figurent git de Linus Torvalds, HCL de HashiCorp et Kubernetes de Google
  • Il n’est pas nécessaire d’avoir les ressources d’un grand groupe : une bibliothèque extraite d’une codebase ou une méthodologie continuellement affinée peuvent aussi convenir
  • La core tech doit être indépendante de la direction du produit, tout en restant alignée avec la vision de long terme de la personne ou de l’entreprise
  • Si une idée ne permet pas de faire émerger une core tech, elle n’offre pas un levier suffisant

• Une contrainte décisive doit définir le produit

  • Au centre du produit, il doit y avoir une defining constraint toujours visible pour l’utilisateur
  • Cette contrainte doit être un élément que l’utilisateur rencontre et avec lequel il interagit en permanence, afin de créer l’identité du produit
  • Une bonne contrainte façonne le feel du produit et imprègne l’ensemble de l’expérience utilisateur
  • Minecraft est composé uniquement de blocs, IKEA repose sur des meubles en kit à assembler soi-même : dans les deux cas, l’identité apparaît immédiatement à partir de la contrainte
  • Ce type de contrainte réduit l’espace de décision, limite le périmètre et aide à se concentrer sur les vrais problèmes importants
  • Ne pas choisir de contrainte, ou en choisir une mauvaise, fait dériver vers un produit hypertrophié qui essaie de tout faire
  • Lorsqu’une contrainte est bien conçue, le design du produit en découle naturellement
  • Cette contrainte doit elle aussi figurer tout en haut du one pager

Critère final

• Si une seule de ces trois contraintes n’est pas respectée, on ne le construit pas

[GN⁺]

Réactions sur Hacker News

• J’ai toujours appelé ça des product primitives
  Comme les blocks de Notion, les messages/conversations de Telegram, les frames/layers de Figma, les tweets de Twitter, les cells/sheets d’Excel, les tools/layers de Photoshop, ou les commands d’une CLI

  À mon avis, un bon design produit apparaît quand le nombre de ces primitives est vraiment réduit
  Un mauvais produit, soit ne sait même pas quelles sont ses primitives, soit en a tellement que tous les éléments du produit donnent l’impression de partir chacun dans leur direction
  L’utilisateur doit alors apprendre une foule de concepts de haut niveau différents, ce qui le déroute, l’intimide et rend aussi l’enseignement du produit plus difficile
  Idéalement, une, deux ou trois primitives centrales suffisent

  La complexité et la puissance d’une app viennent du choix de primitives profondes et combinables
  Comme avec un block de Notion, une cell d’Excel, une command CLI ou un block de Minecraft, il faut pouvoir faire beaucoup avec peu d’unités

  • Ça ressemble à l’Alexandrian Pattern Language, mais en pratique c’est peut-être plus proche des Centers dont Alexander a parlé plus tard que de ses patterns

    Si j’ai bien compris, l’industrie du logiciel a largement repris ses patterns, mais à la fin de sa vie Alexander considérait que l’unité ultime d’un système était le Center
    Des choses comme une cour lumineuse, une place près de la fenêtre, une cheminée : des points de focalisation locale, utiles et cohésifs
    Un center fort est naturellement combinable, résout des tensions locales, se compose de centers plus petits et sert de bloc de construction pour créer un center plus grand

    Si un produit devient confus et boursouflé, ce n’est généralement pas par mauvaise intention
    Les besoins utilisateurs sont relativement observables empiriquement, mais la vraie structure centrale capable de les absorber avec élégance est extrêmement subtile et difficile à découvrir
    Du coup, pour chaque besoin immédiat, le chemin le plus facile consiste toujours à ajouter une interface spécifique et rigide
    Trouver la primitive centrale qui absorbe naturellement ce type de besoin demande un vrai travail d’architecture en profondeur

    C’est peut-être pour ça qu’on finit sans cesse par fabriquer des faster horses

  • Avant, j’appelais ça le concept count
    En général, il vaut mieux minimiser le nombre de concepts fondamentaux qui composent un produit, et on parlait aussi des nouns and verbs du produit

  • Cette philosophie me semble un peu trop simplifiée
    Tana n’a en pratique que deux primitives, bullets et supertags, et pourtant c’est si complexe à utiliser qu’il faut regarder des tutoriels de plusieurs heures pour accomplir la moindre tâche simple
    À l’inverse, Google Maps a pas mal de primitives, mais pour 90 % des cas d’usage, l’UX est très bien tenue

  • J’utilisais un critère similaire pour évaluer les langages de programmation
    Même si un langage est vaste, s’il reste petit conceptuellement, une fois appris le reste suit avec l’expérience ; les langages conceptuellement gros, eux, avaient une barrière d’entrée bien plus élevée
    Le cas où je l’ai ressenti le plus fortement, c’était perl

  • Il faut que ce soit petit, mais pas trop petit non plus
    L’exemple typique, c’est le shell script (POSIX shell, bash) : même le scripting y a été modélisé comme une command afin d’éviter d’introduire de nouveaux concepts, et le résultat a été, comme on le sait tous, un mélange brûlant, lent et chaotique

• J’aime bien les trois contraintes, mais je pense que le document d’une page doit varier selon la complexité du projet
  Pour un projet de petite à moyenne taille, une page suffit probablement, mais pour un logiciel de contrôle de vol martien, on pourrait avoir besoin d’un one-pager renvoyant par hyperliens à de très nombreuses sous-spécifications avant de commencer l’implémentation

  La séparation entre technologie et produit est vraiment judicieuse
  Si on prend Skype par exemple, il y avait d’un côté la technologie de communication P2P du backend et de l’autre l’application d’appel en frontend, et les fondateurs malins avaient placé les deux dans des sociétés distinctes
  Ainsi, même après la vente de Skype, l’app frontend, à Microsoft, ils pouvaient continuer à conserver séparément la société détenant l’IP centrale et la technologie backend P2P

  L’idée de centrer le projet sur une seule contrainte se défend aussi, mais il me semble parfois préférable d’avoir plusieurs contraintes, ou une liste de priorités
  Si le principe suprême est difficile à monétiser, le traiter comme un dogme immuable peut conduire l’entreprise à la faillite
  Et si quelqu’un dans l’équipe a une idée permettant un gros pivot vers une direction bien plus vendable, cela peut ouvrir une voie de survie, même si elle s’éloigne assez fortement de l’idée d’origine
  Twitter aussi visait autre chose au départ, et les public status updates sont sortis d’un projet annexe

• Cet article résume vraiment très bien la manière dont je construisais une entreprise autrefois avec mon mentor de recherche

  Nous commencions d’abord par les deux derniers points, à savoir la technologie centrale et les contraintes
  La technologie centrale était un sampler permettant un modèle de graphe bayésien hiérarchique arbitraire pour des données sparse, et la contrainte était que le calcul devait être faisable en CPU-bound
  Ce qui nous a pris le plus de temps, c’est de comprendre que le produit final devait être séparé de la technologie sous-jacente

  J’avais reçu ce même conseil de plusieurs personnes dès le départ, mais certaines leçons ne s’ancrent qu’après les avoir vécues soi-même

  • Il faut tenets, pas tenants

• L’idée du one-pager est vraiment excellente
  Si on n’arrive même pas à prendre le temps d’écrire clairement les contraintes sur une seule page, on finira forcément par les découvrir dans la panique en avançant
  Et là, ce ne sera pas un bug, mais un défaut d’un autre ordre : on était tout simplement en train de construire la mauvaise chose

  Je ne peux pas le prouver par les données, mais d’après mon expérience, les projets où tout le monde est conceptuellement sur la même longueur d’onde réussissent bien plus souvent
  Même un document très synthétique d’une page, au niveau macro, a un gros effet s’il clarifie ce qu’on fait et ce qu’on ne fait pas
  À l’inverse, les projets menés à l’arrache finissent par décevoir absolument tout le monde, y compris ceux qui n’avaient jamais exprimé clairement leur pensée

• J’aurais aimé que l’auteur montre un exemple complet où les contraintes fonctionnent réellement
  En particulier, je vois mal à quoi ressemble concrètement le troisième point

  • Ça donne aussi un peu l’impression d’un hook fabriqué
    Au final, on a l’impression qu’il faut quand même trouver soi-même quelque chose
    J’aime bien une idée comme everything's a file sous Linux
    Avec un concept fort comme celui-là, on peut déjà aller assez loin

• Les contraintes sont sous-estimées

  Les solutions les plus élégantes ne naissent généralement pas d’une liberté infinie, mais du fait de construire à l’intérieur de contraintes claires
  Et cela rejoint aussi le premier point
  Le processus même d’écriture du one-pager aide à définir ces contraintes

• Si Google possède Kubernetes, c’est surtout, semble-t-il, pour neutraliser ses concurrents

• Pour un solo SaaS, la contrainte que j’ajouterais serait : est-ce que je peux trouver un bêta-testeur cette semaine ?
  Même si le temps, le périmètre et la technologie paraissent solides sur le one-pager, si personne ne vient, le projet meurt tel quel
  En ajoutant dès le départ une contrainte de distribution/go-to-market, j’ai donc été poussé à valider la demande avant de creuser trop profondément les fonctionnalités

  • À strictement parler, ça ressemble davantage à un objectif ou à un indicateur qu’à une contrainte

• Je me demande si le fait de dire que la technologie centrale doit pouvoir être séparée du produit ne pousse pas à une abstraction prématurée et à l’abus de design patterns

  Bien sûr, séparer les responsabilités et distinguer proprement la couche domaine des éléments comme la persistance, le réseau ou l’UI, c’est pertinent
  Mais la couche domaine, au final, ne peut qu’être très fortement liée au produit
  Je ne pense pas qu’on puisse y échapper

  • Cela veut peut-être dire qu’il y a une surface visible qui attire les acheteurs, tandis que ce qui fait réellement tourner l’intérieur n’est pas leur sujet de préoccupation

    Il peut y avoir quelques concepts servant d’interface entre les deux couches, mais l’idée semble être que l’évolution de l’intérieur doit rester découplée de la couche produit externe

• Je suis en train de concevoir la rénovation de ma cuisine, et je me dis que ces trois contraintes pourraient aussi être très utiles pour des travaux de design bien plus généraux que le logiciel

  Je vais essayer ça tout de suite moi aussi

  • On pourrait par exemple partir sur everything's a space, avec des espaces pour les personnes, le rangement et le travail
    Ça paraît peut-être trop simpliste, mais ça devient plus intéressant si on pense en termes d’espace et de flux
    On peut réfléchir au flux des personnes, de la lumière, de la nourriture, aux transitions, etc., et c’est assez stimulant