C'è un motivo se questo Build in Public arriva dopo mesi di silenzio, ed è il migliore che potessi sperare: è nato Gabriele, il mio secondogenito. È arrivato un po' prima del previsto e ci ha fatto preoccupare più di quanto mi piaccia ammettere; poi, per fortuna, tutto si è sistemato. Ora siamo a casa, sta bene, e per qualche settimana tutto il resto è giustamente passato in secondo piano.
Eppure, sotto la superficie, questi sono stati alcuni dei mesi più densi da quando ho iniziato questo percorso. Mentre la vita rallentava tutto, ho finalmente capito quale direzione dare a quello che stavo costruendo. Meno tempo disponibile mi ha reso più selettivo; più selettività mi ha dato più chiarezza. Su questo contrasto tornerò alla fine, perché è la vera lezione di questi mesi.
Un dato di contesto, prima di andare avanti: in poco tempo sono passato da tre applicazioni attive a sei app in lavorazione. Ma il numero, vedrai, non è la storia. È solo l'effetto visibile di qualcosa che è cambiato più in profondità.
Il constraint si è spostato
Per anni la domanda che mi guidava era una sola: come faccio a costruire più velocemente? Negli ultimi mesi mi sono accorto che, nel mio sistema, quella domanda ha smesso di essere quella importante.
Con il mio background di developer, Head of Product e CPTO, e con gli strumenti AI di oggi, alcune parti dell'execution si sono compresse abbastanza da non essere più il constraint dominante. Riesco a progettare, sviluppare e far crescere un prodotto da solo, a una velocità che due anni fa mi sembrava fantascienza. Attenzione: non sto dicendo che costruire software sia diventato facile in assoluto. Sto dicendo qualcosa di più circoscritto e, credo, più interessante:
Nel mio sistema, costruire non è più il principale collo di bottiglia.
Quando l'execution si comprime, il constraint non sparisce. Si sposta. Diventano relativamente più importanti le cose che l'AI non fa al posto tuo: scegliere i problemi giusti, giudicare cosa merita tempo, distribuire quello che costruisci, guadagnare fiducia, tenere in piedi le operations.
E così anche la domanda è cambiata. Non più come faccio a costruire più velocemente?, ma:
Come faccio a trasformare questa capacità in un sistema che produce risultati?
La direzione ha un nome: @creators
Il lavoro con Virginia su Anapana mi ha portato dritto qui. Lavorando insieme ho osservato una combinazione che funzionava: io portavo product, design, engineering e un'execution amplificata dall'AI; lei portava una community, la fiducia di quella community e la vicinanza quotidiana ai suoi problemi. Da quella osservazione è nata un'ipotesi:
Cosa succede se building e distribuzione si incontrano fin dall'origine del prodotto, invece che dopo il lancio?
È così che è nato @creators, il modello con cui costruisco prodotti digitali insieme ai creator. Molti creator oggi monetizzano principalmente attraverso modelli legati alla produzione continua di contenuti; un prodotto può creare una forma diversa di leverage, qualcosa che continua a lavorare anche quando non stai pubblicando.
Dentro @creators ci sono tre modalità di collaborazione: il co-founding, in cui costruiamo insieme la soluzione a un problema della community del creator; l'affiliate, per creator con audience più piccole che portano conversioni alle app già nel programma; e il consulting, in cui quello che imparo sul campo va a beneficio dei prodotti che un creator ha già. Non le racconto per venderle: le racconto perché descrivono come funziona il modello.
Prima la community, poi il prodotto
Il principio più importante di @creators non riguarda i creator. Riguarda le loro community.
Il punto di partenza non è mai "questo creator è famoso, inventiamo qualcosa da vendergli". La sequenza è l'opposto: si parte dalla community, si osservano i problemi con cui convive davvero, si individua un'opportunità, si costruisce il prodotto giusto per risolverla, e solo a quel punto il creator diventa il partner naturale di distribuzione. Prima il valore per le persone; la revenue per tutti gli altri arriva dopo.
È lo stesso approccio product che uso da sempre, applicato a un contesto nuovo. E finora è la parte del modello di cui sono più convinto.
Non sto costruendo sei app
Qui arriva la frase che riassume meglio questi mesi:
Non sto più costruendo app. Sto costruendo il sistema che le produce e le fa migliorare a vicenda.
"Sistema" è una parola che rischia di restare astratta, quindi provo a renderla concreta. Nel mio caso significa quattro cose che si incastrano:
- Build system: research, spec, design, development, release.
- Product system: analytics, feedback, monetizzazione, iterazione.
- Distribution system: ASO, Apple Search Ads, distribuzione via creator e, dove ha senso, SEO.
- Portfolio system: quello che imparo sul prodotto A viene applicato a B, C e D.
Per tenere insieme tutto questo da solo sto costruendo molta automazione: development, design, ASO, Apple Search Ads, SEO dove serve. Ma l'automazione non è la protagonista. Ogni automazione esiste per un solo motivo: ridurre il costo marginale di mantenere e migliorare il portfolio. Se non risolve un bottleneck reale, non la costruisco.
Il Portfolio Flywheel
La parte che mi entusiasma di più è quello che chiamo il Portfolio Flywheel. Ogni app che lancio nasce con tutte le competenze imparate dalle precedenti; ogni app live fa emergere dinamiche, strategie e growth loop nuovi; e ogni scoperta viene implementata su tutto il portfolio, che così cresce ancora.
Concretamente, tra un prodotto e l'altro viaggiano pattern di design e sviluppo, meccaniche di onboarding e monetizzazione, quello che imparo su ASO e Apple Search Ads, le automazioni, e soprattutto i pattern di decisione: cosa ha funzionato, cosa no, e perché.
È per questo che "da tre a sei app" non è l'achievement. Sei app indipendenti sarebbero solo sei volte il lavoro. Il valore sta nel fatto che non sono indipendenti:
Ogni prodotto dovrebbe rendere più facile costruire e far crescere quello successivo.
Cosa c'è nel laboratorio
Uno sguardo veloce a cosa sta facendo ogni prodotto dentro questo sistema. Non un changelog: il ruolo che ognuno gioca nel laboratorio.
Anapana resta l'app principale, quella su cui investo più tempo. Ed è anche l'origine del modello: prima ancora che il co-founding avesse un nome, con Virginia stavamo già facendo esattamente questo. Un builder e una persona vicina alla sua community che costruiscono insieme: Anapana ha dimostrato che la combinazione funzionava prima che io le dessi un'etichetta.
Coco Ear Training è il mio laboratorio di distribuzione. La sto facendo crescere solo attraverso gli store: posizionamento ASO, investimento in Apple Search Ads, zero social e zero content nel test che sto facendo. È un ambiente controllato per capire come funziona davvero la distribuzione negli store, e tutto quello che imparo qui viaggia verso le altre app. Il flywheel, di nuovo, visto in azione.
HeyDoctor finora è stata solo una web application, eppure ha già oltre 300 utenti registrati, diversi dei quali giocano quasi ogni giorno. È il segnale che aspettavo: utenti organici che tornano vuol dire che c'è abbastanza engagement da giustificare altro investimento. Per questo la sto convertendo in app mobile. Evidence, poi decisione: è così che vorrei prendere ogni scelta del portfolio.
Finance Interview Prep, costruita con Marco Lecchi, è il primo prodotto nato fin dal primo giorno dentro il modello @creators: community esistente, un partner che porta domain knowledge e distribuzione, io sul product building. È l'esperimento che dirà se il modello regge anche quando è intenzionale e non, come con Anapana, scoperto a posteriori. Con Andrea Passador, intanto, stiamo per lanciare il prossimo.
Il numero che ho deciso di cambiare
Questa volta voglio essere ancora più chiaro del solito, perché ci sono due numeri e non vanno mai confusi.
Ammesso.it: exit da €220.000. È il capitolo prima di tutto questo, la vendita del mio primo side project nel 2021. Lo racconto come contesto, ma esce dal counter del goal: è un'exit, non revenue del portfolio. Sono due fenomeni economici diversi, e sommarli renderebbe il numero più grande ma meno leggibile. Meglio un numero più piccolo e leggibile che uno più grande e ambiguo.
One Million Goal oggi
One Million Goal: €310.491. È il numero che misura il progresso verso il milione: la revenue aggregata di tutte le app del portfolio, sommato da ottobre a oggi (la metodologia completa è nella pagina di One Million Goal). L'ultimo aggiornamento che avevi visto diceva €220.069; il salto è così netto non perché sia successo tutto in un mese, ma perché il counter ora contiene l'aggregato di ogni app, mese dopo mese, da ottobre in avanti. È un cambio di scope.
Non è il milione. Ma per la prima volta non è una singola app a crescere: è il sistema.
Meno tempo, migliori constraint
Ho sempre avuto un motto: family first. Da quando è arrivato Gabriele lavoro da casa ogni giorno, ho tagliato le ore e sfoltito tutto quello che si poteva sfoltire, questi articoli compresi. Chi di voi è genitore lo sa: due bambini piccoli a casa in agosto, con ogni asilo chiuso, non è una passeggiata.
La parte strana è che meno ore mi hanno reso più lucido. Non credo alla morale facile del "lavorare meno rende più produttivi"; quello che ho visto è qualcosa di diverso: quando il tempo diventa un forte constraint, il costo delle cattive priorità esplode. Così ho smesso di inseguire ogni idea e ho iniziato a costruire il sistema che continua a lavorare mentre io sono con i miei figli: meno esperimenti casuali, più automazione, più focus. Forse è proprio per questo che la direzione è diventata chiara.
Nell'ultimo Build in Public la lezione era stata: non devo inseguire tutto ciò che posso costruire. Questa è il passo successivo: se non posso fare tutto, devo costruire un sistema capace di comporre ciò che funziona.
Quello che sto iniziando a capire
C'è una tensione, in questo articolo, che non voglio nascondere. Da una parte dico che posso costruire da solo; dall'altra dico che ho bisogno dei creator per la distribuzione. Non è una contraddizione da sistemare: è la scoperta.
L'esperimento "One Million Goal" era partito da una domanda: quanto può fare una persona sola? La risposta che sta emergendo è più sofisticata di quella che mi aspettavo: molto più di prima, ma non tutto ha senso che venga fatto dalla stessa persona. La domanda interessante non è quante persone posso sostituire; è qual è la più piccola unità capace di produrre questo risultato.
Nei prossimi articoli entrerò nei dettagli di alcuni pezzi di questo sistema, dai numeri di Anapana a come faccio ASO e Apple Search Ads. Se questo percorso ti interessa, il posto giusto per seguirlo è la pagina di One Million Goal: ogni cosa che condivido qui è successa davvero.
Marco
