Beaucoup d’articles sur le produit partent encore du principe que les meilleures leçons viennent de l’échelle, du financement et d’équipes bien dotées en ressources.

Je ne pense pas que ce soit vrai.

Certaines des leçons produit les plus utiles que j’ai apprises sont venues du fait de construire dans un environnement où la marge d’erreur était très faible : budgets serrés, échéances mouvantes, processus manuels partout et conséquences qui apparaissaient rapidement lorsque l’ordre des opérations était incorrect.

C’est dans cet environnement que j’ai travaillé sur une plateforme de gestion universitaire au Nigeria.

Il ne s’agissait pas d’un produit où une priorité manquée signifiait un trimestre un peu plus faible ou une fonctionnalité retardée. Si les admissions n’étaient pas traitées à temps, des étudiants pouvaient perdre leur place. Si la collecte des frais n’était pas conçue avec précision, des revenus passaient à travers les mailles du filet. Si le reporting était ajouté plus tard, la direction devait prendre des décisions avec une visibilité partielle.

Et lorsque le COVID a perturbé les opérations en présentiel, le vrai test n’était pas de savoir si la plateforme était élégante. C’était de savoir si elle pouvait s’adapter assez vite pour maintenir l’institution en fonctionnement.

Cette expérience a conduit au modèle CAPE : Priorisation fondée d’abord sur la crise, Architecture comme incitation, Infrastructure de données parallèle et Extensibilité dès la conception.

Ce n’est pas une méthode universelle ni une formule parfaite. CAPE est une approche pratique pour les équipes qui travaillent sous pression, où le fait de prendre les décisions dans le bon ordre compte davantage qu’un plan parfait.

C – Priorisation fondée d’abord sur la crise

La plupart des équipes affirment prioriser en fonction de la valeur et de l’effort, ce qui fonctionne dans une certaine mesure. Mais cette logique commence à se fissurer lorsqu’une seule défaillance non résolue peut rendre tout le reste sans objet.

C’était le cas avec les admissions.

À l’époque, l’onboarding des nouveaux étudiants était en grande partie manuel. Les étudiants devaient passer par les admissions et l’inscription à l’aide de formulaires papier, de vérifications dispersées et de l’aide du personnel à presque chaque étape. Certains voyageaient de loin, et beaucoup faisaient face à des échéances serrées. Si le système ne supportait pas cette pression, des étudiants étaient écartés. L’onboarding est donc passé en premier.

Pas parce que c’était la partie la plus innovante de la plateforme. Pas parce que cela rendait le mieux sur une feuille de route. Mais parce que c’était le point de défaillance maximal. Si ce processus se rompait, le reste de la plateforme n’avait plus d’importance.

C’est le premier principe de CAPE : ne commencez pas par la plus grande opportunité. Commencez par la défaillance qui causerait le plus de dégâts si elle n’était pas corrigée immédiatement.

Cela paraît simple. Cela l’est rarement quand on y est confronté. Les équipes sont souvent tentées de répartir leurs efforts entre plusieurs besoins visibles, surtout lorsque les parties prenantes tirent dans des directions différentes. Mais sous contrainte, disperser l’attention peut devenir une forme d’évitement déguisée. Cela donne l’impression d’un bon équilibre. En général, cela affaiblit la livraison.

La contrainte imposait une question plus inconfortable : si nous ne résolvions correctement qu’une seule chose en premier, laquelle devait-ce être ?

Cette question reste pertinente même dans des environnements mieux financés. Les équipes qui y répondent honnêtement ont tendance à livrer des premières versions plus solides. Celles qui ne le font pas se retrouvent souvent avec des feuilles de route plus larges et des fondations plus fragiles.

Si la première version ne stabilise pas la défaillance la plus coûteuse, c’est probablement la mauvaise première version.

A – Architecture comme incitation

L’un des problèmes les plus persistants de l’université était le non-respect du paiement des frais, ce qui constituait un défaut de conception majeur.

Plutôt que de traiter le paiement comme une tâche administrative à côté du parcours académique, nous l’avons rendu structurel. Le paiement déverrouillait l’inscription. L’inscription déverrouillait l’éligibilité aux examens. Pas de paiement, pas de progression.

Simple. Mais porteur.

Cette décision a modifié la logique de la plateforme. L’accent est passé de l’incitation des personnes à se conformer vers le flux logique du système. Cette distinction est plus importante que beaucoup d’équipes ne le réalisent.

Beaucoup de décisions produit liées au comportement sont encore traitées comme des problèmes de message. Mais lorsque le comportement est critique pour l’activité, l’architecture fait généralement plus que la persuasion ne le fera jamais.

C’est ce que j’entends par architecture comme incitation. Concevoir le système de manière à ce que le bon comportement soit intégré dans la séquence.

Le respect du paiement des frais s’est nettement amélioré une fois cette dépendance intégrée à la plateforme. Mais la leçon la plus importante était que, si un produit dépend d’un certain comportement, l’architecture doit en porter une partie de la charge.

Lorsque le comportement compte, supprimez l’optionnalité avant d’ajouter des rappels.

P – Infrastructure de données parallèle

C’est là que beaucoup de produits déçoivent la direction. Le workflow fonctionne, les utilisateurs accomplissent leurs tâches et les transactions passent. Mais l’institution ne peut toujours pas voir ce qui se passe réellement.

C’était la situation ici. Les parties prenantes n’avaient pas de vision unifiée de l’ensemble du processus.

Sous la pression de la livraison, il est facile de livrer d’abord le workflow et de repousser le reporting à plus tard. Cela semble efficace. Ce ne l’est pas. Les angles morts créés coûtent plus cher que le temps économisé.

Nous avons donc construit le reporting en parallèle des workflows.

Cela a changé la prise de décision. La direction pouvait voir plus clairement la position de revenus. Elle pouvait voir les inscriptions par programme et par niveau. Elle pouvait voir où les tendances de paiement et d’inscription évoluaient avant que ces évolutions ne se transforment en problèmes opérationnels.

C’est le troisième principe de CAPE : si un workflow compte sur le plan opérationnel, il doit compter en même temps sur le plan analytique.

Un produit qui ne peut pas être correctement observé pendant son fonctionnement crée un risque de second ordre. Les décisions commencent alors à être prises sur la base d’hypothèses en retard plutôt que d’éléments actuels. Ensuite, les équipes passent des mois à compenser une visibilité qu’elles auraient dû concevoir dès le départ.

Un workflow sans instrumentation est opérationnellement actif mais stratégiquement aveugle.

Construisez le workflow et le modèle de visibilité ensemble. Ne demandez pas à la direction de piloter à l’aveugle en promettant le tableau de bord plus tard.

E – Extensibilité dès la conception

Avec le temps, nous avons continué à développer la plateforme avec des fonctionnalités robustes, au point qu’elle était prête à gérer des tâches universitaires clés comme les admissions, le paiement des frais, l’inscription, les examens et les relevés de notes.

Puis le COVID est arrivé.

Presque du jour au lendemain, tout a changé. Les préoccupations concernant l’inscription, les examens, les frais et les processus associés sont devenues secondaires, car si les étudiants n’apprennaient pas, ils n’avaient pas besoin de ces fonctionnalités. Notre attention s’est déplacée vers la question de savoir si la plateforme pouvait s’adapter assez vite pour maintenir les opérations lorsque les cours et les activités en présentiel se sont arrêtés.

La plateforme prenait en charge les admissions, le paiement des frais, les examens et les relevés de notes, mais elle ne disposait d’aucune capacité d’apprentissage. Cette lacune est devenue notre point central. La question était immédiate : développer la capacité d’apprentissage à partir de zéro, ou intégrer rapidement un LMS pour permettre à l’université de continuer à fonctionner ?

Les étudiants étaient chez eux. L’enseignement s’était arrêté. Les revenus avaient chuté. L’institution n’avait pas besoin de la réponse parfaite. Elle avait besoin de la plus rapide viable.

Nous avons choisi l’intégration en raison d’un choix d’architecture antérieur : nous avions conçu la plateforme avec suffisamment de modularité pour absorber de nouvelles capacités sans tout reconstruire. Pas une flexibilité infinie. Juste assez d’ouverture pour rendre le prochain mouvement possible.

C’est cela, l’extensibilité, en pratique.

Cela ne signifie pas construire pour tous les futurs possibles ; cela conduit à la sur-ingénierie. L’extensibilité dès la conception consiste à laisser suffisamment d’espace pour le prochain changement réel, sans devoir reconstruire le cœur du système à chaque évolution.

C’est important parce que les équipes produit traitent souvent l’extensibilité comme une option jusqu’au jour où elle devient urgente. À ce moment-là, elle coûte cher.

L’intégration du LMS a été livrée en quatre mois. La continuité académique a repris. Les revenus se sont sensiblement rétablis au cours du même cycle. Mais la leçon la plus importante était architecturale : les systèmes qui survivent aux chocs externes ne sont pas toujours ceux qui les avaient prédits. Ce sont ceux qui n’ont pas été construits de manière trop rigide pour réagir.

Construisez pour le prochain vrai défi, pas pour tous les scénarios possibles.

CAPE n’est pas utile parce que son nom sonne bien. Il est utile parce que la séquence tient.

Chaque produit à forte croissance rencontre sa propre version des admissions : un point de défaillance qui fait échouer la feuille de route s’il n’est pas résolu en premier, et tout le reste devient négociable en comparaison. Chaque produit dont le comportement est critique pour les revenus rencontre sa propre version du verrou de paiement : quelque chose dont l’entreprise dépend et qui est soit intégré à l’architecture, soit poursuivi indéfiniment à coups de rappels.

Chaque équipe rencontre sa propre version du problème du reporting : la direction avance à l’aveugle parce que la visibilité a été repoussée au profit de la livraison du workflow. Et chaque produit finit par rencontrer son propre COVID : le choc que personne n’avait prévu, qui teste si ce que vous avez construit peut se plier ou se casser.

C’est pour cela que CAPE est transférable. La contrainte ne concerne pas vraiment le budget. Elle concerne le rapport entre ce qui doit être vrai et ce que vous pouvez vous permettre de rater. Ce rapport apparaît lors d’un tour de financement serré, d’une échéance réglementaire contraignante, d’une petite équipe interne d’outils ou d’une startup avec six mois de trésorerie. Pression différente. Même discipline requise.

Si je suis honnête, le principe le plus difficile à appliquer est l’Architecture comme incitation. La priorisation fondée d’abord sur la crise est une décision que l’on prend une fois, au départ. L’extensibilité est une habitude que l’on peut intégrer progressivement à ses standards. L’architecture comme incitation demande quelque chose de plus difficile : une conviction suffisante pour rendre un comportement non négociable dans le produit lui-même, au lieu de le résoudre en aval par une relance ou une campagne.

C’est une conversation difficile à avoir avec des parties prenantes qui préfèrent demander gentiment aux utilisateurs plutôt que de leur retirer des options. C’est aussi le principe le plus susceptible d’être dilué lors d’une revue de conception, parce que « ajoutons juste un rappel » semble toujours être le choix le plus confortable. C’est rarement le bon.

Si vous construisez déjà avec sobriété, à Lagos, en Afrique de l’Ouest, sur un marché où « nous n’avions pas le budget pour faire autrement » n’est pas un slogan mais un mardi ordinaire, je ne vous dis pas que la contrainte est bonne pour vous. Vous le savez déjà.

Ce que j’avance est plus précis, et je pense plus utile. La contrainte ne produit pas à elle seule de la discipline. Elle produit de la pression. Ce que vous faites de cette pression est une autre question, et il est tout à fait possible de construire sous une vraie contrainte tout en se trompant dans l’ordre des étapes, parce que la plupart des conseils destinés aux équipes légères n’ont pas été écrits pour des équipes légères. Ils ont été écrits par des gens qui avaient une marge, pour des gens qui avaient une marge.

« Livrez vite, ajoutez la conformité plus tard » n’est pas un mauvais conseil. C’est un conseil pour quelqu’un qui peut se permettre le coût du plus tard. Reportez la même décision sans tour de financement en attente derrière elle, et plus tard veut généralement dire jamais, ou cela veut dire une urgence qui coûte dix fois le coût initial de la décision.

Chaque décision reportée dans cet article — traiter le paiement comme optionnel, construire le reporting plus tard, ignorer la modularité nécessaire à l’extensibilité — relève exactement de ce type de conseil emprunté. Cela paraît efficace jusqu’au moment où il n’y a plus de budget ultérieur pour absorber le coût du report.

CAPE est ma tentative de nommer, délibérément, ce que la plupart d’entre nous apprennent par accident sous la pression des délais. Ce n’est pas une affirmation que la contrainte forge le caractère. C’est une manière de vérifier, avant de livrer, si vous avez discrètement emprunté une décision de séquencement qui n’a de sens que pour le bilan de quelqu’un d’autre.

Cette discipline mérite d’être conservée même lorsque la contrainte s’atténue. La plupart d’entre nous ne cherchent pas à échapper à la contrainte pour enfin cesser de penser de cette manière. Si le financement arrive, l’objectif n’est pas de perdre les réflexes qui vous ont amené jusqu’ici.

À lire aussi : FUTA honours alumnus-turned-cybersecurity-entrepreneur as university hosts landmark international computing conference