Gran parte della scrittura di prodotto parte ancora dal presupposto che le lezioni migliori arrivino dalla scala, dai finanziamenti e da team ben dotati di risorse.

Io non credo che sia vero.

Alcune delle lezioni di prodotto più utili che ho imparato sono arrivate lavorando in contesti con pochissimo margine di errore: budget stretti, scadenze che cambiavano, processi manuali ovunque e conseguenze che si manifestavano rapidamente quando la sequenza era sbagliata.

Questo era l’ambiente in cui ho lavorato su una piattaforma di gestione universitaria in Nigeria.

Non era un prodotto in cui una priorità mancata significava un trimestre un po’ più debole o una funzionalità ritardata. Se le admissions non venivano gestite in tempo, gli studenti potevano perdere il proprio posto. Se la raccolta delle fee non era progettata in modo rigoroso, i ricavi sfuggivano tra le maglie del sistema. Se il reporting veniva aggiunto in un secondo momento, la leadership si ritrovava a prendere decisioni con una visibilità parziale.

E quando il COVID ha interrotto le attività in presenza, la vera prova non era se la piattaforma fosse elegante. Era se potesse adattarsi abbastanza rapidamente da mantenere in piedi l’istituzione.

Quell’esperienza ha portato al modello CAPE: Crisis-first prioritisation, Architecture as incentive, Parallel data infrastructure e Extensibility by design.

Non è un metodo universale né una formula perfetta. CAPE è un approccio pratico per team che lavorano sotto pressione, dove prendere decisioni nell’ordine giusto conta più di avere un piano perfetto.

C – Crisis-First Prioritisation

La maggior parte dei team sostiene di dare priorità in base a valore e sforzo, e fino a un certo punto funziona. Ma questa logica inizia a crollare quando un singolo fallimento irrisolto può rendere irrilevante tutto il resto.

Questa era la realtà delle admissions.

All’epoca, l’onboarding dei nuovi studenti era in gran parte manuale. Gli studenti dovevano passare attraverso admissions e registration usando moduli cartacei, controlli frammentati e l’aiuto del personale in quasi ogni fase. Alcuni viaggiavano da lontano, e molti affrontavano scadenze molto strette. Se il sistema non riusciva a reggere la pressione, gli studenti restavano esclusi. Per questo l’onboarding venne prima.

Non perché fosse la parte più innovativa della piattaforma. Non perché stesse meglio in una roadmap. Ma perché era il punto di massimo rischio di fallimento. Se quel processo si fosse rotto, il resto della piattaforma non avrebbe contato.

Questo è il primo principio CAPE: non iniziare con l’opportunità più grande. Inizia con il fallimento che causerebbe il danno maggiore se non venisse risolto subito.

Sembra semplice. Raramente lo è quando ci sei dentro. I team sono spesso tentati di distribuire lo sforzo su più esigenze visibili, soprattutto quando gli stakeholder tirano in direzioni diverse. Ma sotto vincolo, distribuire l’attenzione può diventare una forma mascherata di evitamento. Sembra equilibrato. Di solito indebolisce la delivery.

Il vincolo imponeva una domanda più scomoda: se risolviamo bene solo una cosa per prima, quale deve essere?

Questa domanda conta ancora anche in contesti meglio finanziati. I team che rispondono con onestà tendono a costruire release iniziali più solide. Quelli che non lo fanno finiscono spesso con roadmap più ampie e fondamenta più fragili.

Se la prima release non stabilizza il punto di fallimento più costoso, probabilmente è la release sbagliata.

A – Architecture as Incentive

Uno dei problemi più persistenti dell’università era la non conformità nel pagamento delle fee, che rappresentava un grave difetto di progettazione.

Invece di trattare il pagamento come un’attività amministrativa separata dal percorso accademico, lo abbiamo reso strutturale. Il pagamento sbloccava la registration. La registration sbloccava l’idoneità agli examination. Nessun pagamento, nessun avanzamento.

Semplice. Ma portante.

Quella decisione ha cambiato la logica della piattaforma. L’attenzione si è spostata dall’invitare le persone a conformarsi alla logica di flusso del sistema. Questa distinzione conta più di quanto molti team realizzino.

Molte decisioni di prodotto legate al comportamento vengono ancora gestite come problemi di messaggistica. Ma quando il comportamento è critico per il business, l’architettura di solito fa più della persuasione.

Questo è ciò che intendo per architecture as incentive. Progettare il sistema in modo che il comportamento corretto sia incorporato nella sequenza.

La conformità nei pagamenti è migliorata in modo significativo una volta che quella dipendenza è stata integrata nella piattaforma. Ma la lezione più importante era che, se un prodotto dipende da un certo comportamento, l’architettura dovrebbe assumerne una parte del peso.

Quando il comportamento conta, rimuovi l’opzionalità prima di aggiungere promemoria.

P – Parallel Data Infrastructure

È qui che molti prodotti deludono la leadership. Il workflow funziona, gli utenti completano i propri compiti e le transazioni passano. Ma l’istituzione continua a non vedere davvero cosa stia accadendo.

Questa era la situazione qui. Gli stakeholder non avevano una visione unificata dell’intero processo.

Sotto pressione di delivery, è facile rilasciare prima il workflow e rimandare il reporting. Sembra efficiente. Non lo è. I punti ciechi che crea costano più del tempo che ha fatto risparmiare.

Perciò abbiamo costruito il reporting insieme ai workflow.

Questo ha cambiato il processo decisionale. La leadership poteva vedere più chiaramente la posizione dei ricavi. Poteva vedere le registrations per programme e level. Poteva vedere dove i pattern di payment e enrolment stavano cambiando prima che quei cambiamenti si consolidassero in problemi operativi.

Questo è il terzo principio CAPE: se un workflow è importante operativamente, dovrebbe esserlo anche dal punto di vista analitico nello stesso momento.

Un prodotto che non può essere osservato correttamente mentre è in esecuzione crea un rischio di secondo ordine. Le decisioni iniziano a essere prese sulla base di ipotesi in ritardo, invece che su evidenze attuali. Poi i team passano mesi a compensare una visibilità che avrebbero dovuto progettare fin dall’inizio.

Un workflow senza strumentazione è operativo, ma strategicamente cieco.

Costruisci insieme il workflow e il modello di visibilità. Non chiedere alla leadership di guidare al buio promettendo la dashboard più tardi.

E – Extensibility by Design

Col passare del tempo, abbiamo continuato a sviluppare la piattaforma con funzionalità solide, fino a configurarla per gestire attività universitarie chiave come admissions, fee payments, registration, examinations e transcripts.

Poi è arrivato il COVID.

Quasi dall’oggi al domani, tutto è cambiato. Le preoccupazioni su registration, examinations, fees e processi correlati sono diventate secondarie, perché se gli studenti non stavano imparando, allora non avevano bisogno di quelle funzionalità. La nostra attenzione si è spostata su un’altra domanda: la piattaforma poteva adattarsi abbastanza rapidamente da mantenere tutto in funzione quando le lezioni e le attività in presenza si sono fermate?

La piattaforma supportava admissions, fee payments, examinations e transcripts, ma non aveva alcuna capacità di learning. Quella lacuna è diventata il nostro punto focale. La domanda era immediata: costruire da zero la capacità di learning, oppure integrare rapidamente un LMS per mantenere operativa l’università?

Gli studenti erano a casa. La didattica si era fermata. I ricavi erano calati. L’istituzione non aveva bisogno della risposta perfetta. Aveva bisogno della più veloce possibile che fosse ancora valida.

Abbiamo scelto l’integrazione grazie a una decisione architetturale precedente: avevamo costruito con abbastanza modularità da assorbire nuove capacità senza dover rifare tutto da capo. Non flessibilità infinita. Solo abbastanza apertura da rendere possibile la mossa successiva.

Questo è ciò che significa extensibility in pratica.

Non significa costruire per ogni possibile futuro; quello porta all’overengineering. L’extensibility by design consiste nel lasciare abbastanza spazio per il prossimo cambiamento reale, senza dover ricostruire il core ogni volta che le cose cambiano.

Questo conta perché i team di prodotto spesso considerano l’estensibilità come opzionale fino al giorno in cui diventa urgente. A quel punto, è costosa.

L’integrazione dell’LMS è stata consegnata in quattro mesi. La continuità accademica è ripresa. I ricavi si sono ripresi in modo sostanziale nello stesso ciclo. Ma la lezione più importante è stata architetturale: i sistemi che sopravvivono agli shock esterni non sono sempre quelli che li avevano previsti. Sono quelli che non sono stati costruiti in modo troppo rigido per rispondere.

Costruisci per la prossima sfida reale, non per ogni scenario possibile.

CAPE non è utile perché suona bene. È utile perché la sequenza regge.

Ogni prodotto in rapida crescita incontra una propria versione delle admissions: un punto di fallimento che fa saltare la roadmap se non viene risolto per primo, e tutto il resto diventa negoziabile per confronto. Ogni prodotto con un comportamento critico per i ricavi incontra una propria versione del payment gate: qualcosa da cui il business dipende e che viene incorporato nell’architettura oppure inseguito per sempre con i promemoria.

Ogni team incontra una propria versione del problema del reporting: la leadership che vola alla cieca perché la visibilità è stata rimandata a favore del rilascio del workflow. E ogni prodotto, prima o poi, incontra il proprio COVID: lo shock che nessuno aveva previsto e che mette alla prova se ciò che hai costruito può piegarsi o se si rompe.

Ecco perché CAPE è trasferibile. Il vincolo non riguarda davvero il budget. Riguarda il rapporto tra ciò che deve essere vero e ciò che ti puoi permettere di sbagliare. Quel rapporto emerge in un round di finanziamento stretto, in una scadenza regolatoria severa, in un piccolo team interno di tool, o in una startup che vive di sei mesi di runway. Pressioni diverse. Stessa disciplina richiesta.

Se devo essere onesto, il principio più difficile da applicare davvero è Architecture as Incentive. La Crisis-first prioritisation è una decisione che prendi una volta, all’inizio. L’Extensibility è un’abitudine che puoi incorporare nei tuoi standard nel tempo. Architecture as incentive richiede qualcosa di più difficile: abbastanza convinzione da rendere un comportamento non negoziabile nel prodotto stesso, invece di risolverlo a valle con un incentivo o una campagna.

È una conversazione difficile da avere con gli stakeholder che trovano più facile chiedere gentilmente agli utenti di fare qualcosa piuttosto che togliere loro le opzioni. È anche il principio più facile da diluire in una design review, perché “aggiungiamo solo un promemoria” suona sempre come la scelta più comoda. Raramente è quella giusta.

Se stai già costruendo in modo lean, a Lagos, in West Africa, in un mercato in cui “non avevamo il budget per farlo diversamente” non è uno slogan ma un martedì qualunque, non ti sto dicendo che il vincolo sia una cosa buona. Lo sai già.

Quello che sto sostenendo è più circoscritto, e credo più utile. Il vincolo da solo non produce disciplina. Produce pressione. Ciò che fai con quella pressione è una questione separata, ed è del tutto possibile costruire sotto un vincolo reale e comunque sbagliare la sequenza, perché la maggior parte dei consigli disponibili per i team lean non è stata scritta per team lean. È stata scritta da persone con un cuscinetto, per persone con un cuscinetto.

“Rilascia in fretta, aggiungi la conformità più tardi” non è un cattivo consiglio. È un consiglio per chi può permettersi ciò che il più tardi costa. Rinvia la stessa decisione senza un round di finanziamento in attesa dietro di essa, e “più tardi” di solito significa mai, oppure significa un’emergenza che costa dieci volte il costo della decisione la prima volta.

Ogni decisione rinviata in questo articolo — trattare il pagamento come opzionale, costruire il reporting più tardi, saltare la modularità necessaria per l’estensibilità — è esattamente questo tipo di consiglio preso in prestito. Sembra efficiente fino al momento in cui non esiste più un budget successivo pronto ad assorbire il costo del rinvio.

CAPE è il mio tentativo di nominare, in modo deliberato, ciò che molti di noi imparano per caso sotto pressione di scadenza. Non è un’affermazione che il vincolo costruisca il carattere. È un modo per verificare, prima del rilascio, se hai inconsapevolmente preso in prestito una decisione di sequenza che ha senso solo per il bilancio di qualcun altro.

Quella disciplina vale la pena conservarla anche quando il vincolo si allenta. La maggior parte di noi non cerca di sfuggire al vincolo per smettere finalmente di pensare in questo modo. Se arrivano i finanziamenti, l’obiettivo non è perdere gli istinti che ti hanno portato fin qui.

Leggi anche: FUTA honours alumnus-turned-cybersecurity-entrepreneur as university hosts landmark international computing conference