Il 2 Giugno Learnn ha compiuto 6 anni. 🎉
Se penso a quello che abbiamo costruito in questi sei anni sono veramente soddisfatto, e ancora non ci credo. Guardando indietro, spesso ci fermiamo troppo poco a osservare quello che abbiamo costruito. Sono soddisfatto soprattutto di quello che ho imparato dagli errori, alcuni dei quali sono proprio il tema di questo articolo.
Questa foto è di me nel 2020 mentre lavoro al primo MVP di Learnn. Quello che non si vede è che il computer è appoggiato su uno stendino. Sì, uno stendino da bucato.
Viva l’ergonomia 🤣
Nell’articolo precedente ho raccontato le 5 decisioni prese nel 2020 per costruire il primo MVP di Learnn che oggi rifarei identiche. Se te lo sei perso, lo trovi qui.
Questo è il rovescio della medaglia: le 5 che non rifarei.
Sono più difficili da scrivere. Raccontare cosa ha funzionato è facile, raccontare gli errori richiede di ammettere che con le informazioni di allora hai preso decisioni che oggi cambieresti. Ma è anche la parte più utile, perché gli errori si ripetono e vederli documentati può aiutare qualcuno a non rifarli.
Sono le raccomandazioni che farei all’Omar del passato, con gli strumenti e la consapevolezza che ho oggi.
Mighty Networks ci ha permesso di validare: WordPress, Chargebee, Mighty Networks e Vimeo ci hanno fatto lanciare con poche centinaia di euro al mese e ottenere 4.500 iscritti in pochi giorni.
Ma oggi non la sceglierei nemmeno come piattaforma iniziale.
Non si tratta solo di esserci rimasti troppo a lungo. È proprio la scelta dello strumento che cambierei. Oggi probabilmente costruirei un piccolo MVP con l’aiuto dell’AI, oppure andrei comunque su un “buy” ma diverso: il mercato è pieno di servizi che nel 2020 non esistevano.
Ma il vero limite di Mighty Networks era un altro: non ci dava abbastanza dati. In una fase di validazione i dati di prodotto sono fondamentali: capire come gli utenti si muovono, dove si bloccano, cosa funziona e cosa no. Con Mighty Networks avevamo pochissima visibilità sul comportamento reale degli utenti.
Oggi sceglierei fin da subito uno strumento che mi permetta di misurare, perché in quella fase i dati valgono più di qualsiasi feature.
Nella tesi (cap. 2.1) racconto che la prima roadmap di Learnn seguiva un approccio Waterfall: fasi sequenziali con date fisse distribuite su 4 mesi.
Era irrealistico. Le stime erano sbagliate per inesperienza, e il modello stesso era il problema: un approccio a cascata su 4 mesi presuppone che tu sappia esattamente cosa costruire e quanto tempo serve. In una startup all’inizio non lo sai. Ogni imprevisto faceva slittare tutto il resto a catena.
Il passaggio ad Agile con sprint settimanali ci ha salvato, e infatti è tra le scelte che rifarei perché ci ha permesso di rilasciare la prima versione dell’app mobile in 45 giorni.
Una precisazione importante: oggi abbiamo di nuovo una pianificazione più a lungo termine, ma è una cosa completamente diversa in una fase completamente diversa. Partiamo dai goal di quarter con degli OKR, e da lì tiriamo fuori le attività dei vari team che impattano le metriche legate agli OKR. C’è molto più controllo, perché parti dal risultato che vuoi e costruisci a ritroso. Ma questa è una fase diversa da quella iniziale: nel 2020, pianificare 4 mesi in Waterfall era solo una falsa sensazione di controllo.
Quando abbiamo deciso di costruire la piattaforma proprietaria, abbiamo iniziato dall’app mobile. La logica era ambiziosa: volevamo cambiare il modo in cui gli utenti si formavano, puntare sull’apprendimento in mobilità, sulla fruizione ovunque.
Con il senno di poi partirei dalla web app.
Già allora sapevamo che l’adozione sarebbe stata difficile e che l’app si portava dietro una serie di problemi di manutenzione. E così è stato. Se iOS ha sempre funzionato molto bene, su Android abbiamo dovuto ricorrere più volte a fix dedicati, perché l’ecosistema Android è molto più frammentato. Avere un’app che funzioni bene su tutte le piattaforme è costosissimo da manutenere.
Ancora oggi dedichiamo slot di lavoro alla manutenzione dell’app, e non raggiungeremo mai la perfezione assoluta, anche perché non abbiamo un’app nativa Android. Su questo siamo in contatto con i maintainer di alcuni moduli come React Native Video, che ci stanno supportando.
Saremmo partiti molto più semplicemente con la web app: più semplice da sviluppare, più semplice da rilasciare, nessun problema con gli store, più facile da iterare e molto meno costosa da manutenere. Avrei validato l’esperienza di fruizione sul web e costruito l’app mobile solo dopo, una volta consolidato il prodotto.
Lo streaming era una funzionalità core, e volevamo il controllo. Lo abbiamo costruito su AWS: S3, MediaConvert, Media Package, CloudFront, HLS con adaptive bitrate.
La scelta era sensata nel 2020 perché, nel momento in cui abbiamo iniziato a costruire la piattaforma proprietaria non esistevano alternative valide. Ma oggi non partirei custom.
Userei un servizio esterno come Mux, avrebbe semplificato enormemente il lavoro: il player già pronto per entrambe le piattaforme, l’encoding e la distribuzione fuori dalle nostre mani.
Per darti un’idea di quanto lavoro abbia richiesto la strada custom: la parte di DRM e protezione dei contenuti ce la siamo costruita completamente da soli. Ha richiesto un grosso lavoro anche sul player dell’applicazione. In cambio ci ha permesso di sviluppare funzionalità come il download offline integrando tool esterni. Con un servizio gestito, tutta questa complessità sarebbe stata risolta out of the box.
I costi di sviluppo sarebbero stati molto più bassi. Probabilmente nel lungo termine avremmo pagato di più in costi economici, e probabilmente saremmo passati comunque a un’infrastruttura custom su AWS col tempo. Oggi abbiamo pieno controllo ed è quello che ci serve a questo stadio. Ma partire con un servizio gestito ci avrebbe fatto risparmiare mesi nella fase iniziale, quando ogni settimana contava. Avremmo migrato al custom quando il controllo è diventato davvero necessario, non prima.
È lo stesso principio dell’articolo precedente, applicato a una scelta che allora andò diversamente: in fase iniziale, buy batte make. Lo streaming era l’eccezione obbligata del 2020. Oggi non lo sarebbe più.
Questa non è un errore conclamato. È un rischio che corriamo costantemente e di cui siamo molto consapevoli.
Il team tech di Learnn ha una velocity e una capacità di esecuzione fuori dal comune, e questo era vero anche prima dell’AI. Riusciamo a rilasciare in produzione nuove funzionalità praticamente ogni settimana. E questo, paradossalmente, è un pericolo.
Quando esci con così tante feature di continuo, il rischio è di non sapere nemmeno dove collocarle nel prodotto, di non presentarle bene agli utenti, e gli utenti, lo sappiamo, sono resistenti al cambiamento. Vedono il prodotto trasformarsi continuamente e faticano a trovare i loro punti di riferimento. La quantità diventa rumore invece che valore.
Con l’AI questa velocità sta aumentando ancora, e quindi il rischio cresce con lei. Il pericolo di diventare una feature factory, costruire tanto senza chiedersi se serve davvero, non è mai stato così concreto.
Quello che facciamo, e che portiamo avanti da tempo, è l’opposto: pulire per creare chiarezza. Rimuovere, semplificare, consolidare. Partire dagli outcome che vogliamo ottenere e solo dopo pensare agli output necessari per arrivarci.
PostHog ha scritto un ottimo articolo proprio su questo tema, su come la velocità abilitata dall’AI renda ancora più importante concentrarsi sul valore invece che sul volume. Vale la pena leggerlo.
Questa non riguarda Learnn nello specifico, ma il modo in cui pensavo al lavoro.
Per anni ho avuto la convinzione che per costruire qualcosa di grande servisse un team tech grande. Più persone, più team, più domini coperti, una struttura organizzativa complessa. Era l’obiettivo verso cui pensavo si dovesse tendere.
Oggi la penso esattamente all’opposto.
Meno persone, se hanno ownership reale e way of working solida, possono fare un lavoro incredibile. Nel team tech di Learnn portiamo avanti contemporaneamente:
un’applicazione mobile
un’applicazione web
un’estensione Chrome
un’infrastruttura con più di 16 microservizi
tutta la parte di streaming
il supporto agli utenti
Caricamento in corso...
Siamo pochi, piccoli, ma estremamente efficaci.
L’AI ha accelerato ancora di più questa convinzione. Quello che prima richiedeva più mani oggi lo fai con meno persone e gli strumenti giusti. La leva non è più il numero di sviluppatori, è quanto ogni sviluppatore può fare.
Il futuro non è team più grandi. È team più piccoli, più autonomi, con più leva.
Nell’articolo precedente il filo conduttore delle scelte giuste era: andare veloci accettando tradeoff consapevoli.
Qui il filo conduttore degli errori è simile ma rovesciato: abbiamo sbagliato quando abbiamo confuso il mezzo con il fine.
La lezione che mi porto dietro è sempre la stessa: parti dal problema reale e dall’outcome che vuoi, poi scegli il mezzo più semplice per arrivarci.
Tutto il resto è complessità che ti fa sentire al sicuro mentre ti rallenta.
Omar
Se questo articolo ti è stato utile, condividi Omar.log() con qualcuno a cui potrebbe servire 👇
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.