Nel panorama dello sviluppo software, costellato di metodologie complesse, certificazioni e processi rigidi, il libro “Getting real” di 37signals (ora Basecamp) emerge non come un manuale tecnico ma come un manifesto filosofico. Pubblicato originariamente nel 2006, propone un approccio radicalmente diverso per costruire applicazioni web di successo: un metodo definito “più intelligente, veloce e facile”. La sua tesi centrale non risiede nell’adozione di un nuovo framework procedurale, ma in un cambiamento di mentalità che sfida le convenzioni consolidate del settore.
Il libro si posiziona come una reazione diretta a ciò che gli autori identificano come il “vecchio modo di fare software”: un processo lungo, burocratico e orientato a coprire le proprie responsabilità, il cui risultato tipico è un “software gonfio, dimenticabile e intriso di mediocrità”.
Vengono presi di mira gli artefatti tradizionali come le lunghe timeline, le specifiche funzionali dettagliate, le infinite riunioni e le grandi strutture gerarchiche: “Getting real” propone di eliminarli tutti.
Io per primo, ho un pensiero forte orientato all’eliminazione totale delle specifiche funzionali dettagliate ante-iniziolavori, uno strumento che oggi funge da scudo a un’infinita schiera di wannabe manager che pur di rimandare il momento in cui debbano lavorare davvero e quindi affrontare dei problemi preferiscono chiedere ai propri sottoposti di dettagliare ulteriormente le specifiche sulla scorta del “così si fa”.
Il cuore della sua filosofia di questa “evoluzione di mentalità orientata al prodotto” risiede in un paradosso potente: il successo non si ottiene accumulando risorse – più denaro, più persone, più tempo, più funzionalità – ma attraverso la loro deliberata e strategica riduzione. Si tratta di eliminare tutto ciò che non è essenziale, perché, come sostengono gli autori, “la maggior parte di ciò che pensi sia essenziale in realtà non lo è”.
Questo articolo analizzerà in profondità i principi di “Getting real”, capitolo per capitolo, dimostrando come non si tratti semplicemente di una metodologia Agile come Scrum o Kanban, ma piuttosto della precondizione culturale e filosofica su cui tali metodologie possono realmente prosperare. Mentre i framework agili si concentrano sul come lavorare in cicli brevi e iterativi, “Getting real” si focalizza sul perché e sul cosa: perché rimanere piccoli, perché costruire meno, e cosa è veramente essenziale per il cliente. I suoi principi non riguardano la gestione dei task, ma le decisioni strategiche e di identità del prodotto. Adottare questa filosofia non sostituisce un processo di lavoro, ma fornisce al team una “stella polare” decisionale che rende qualsiasi processo più efficace, perché il team sa già cosa non fare e, soprattutto, perché non farlo.
I pilastri della filosofia “Real” (questi paragrafi sono oro)
La filosofia di “Getting real” si fonda su tre pilastri interconnessi:
- un minimalismo strategico che privilegia la riduzione rispetto all’addizione,
- una cultura ossessionata dalla velocità di esecuzione e di adattamento,
- un pragmatismo radicale che fa della realtà tangibile l’unica fonte di verità (testare vale più che ipotizzare).
Il manifesto del “meno”: ridurre per amplificare
Il principio più controintuitivo e fondamentale di “Getting real” è il minimalismo strategico. L’idea non è semplicemente “fare meno” ma fare meno per ottenere di più: più focus, più qualità, più agilità e, in ultima analisi, più successo.
Il capitolo del “build less”, introduce il concetto di “underdo your competition” (fare meno della concorrenza). La saggezza convenzionale suggerisce che per battere un concorrente bisogna superarlo in numero di funzionalità. “Getting real” definisce questa mentalità da “Guerra Fredda” come un vicolo cieco costoso e paranoico che porta le aziende a seguire invece che a guidare. La vera strategia offensiva è fare meno: risolvere i problemi semplici e lasciare quelli complessi e intricati agli altri. Si tratta di una scelta deliberata di “one-downing” invece che di “one-upping“.
Parentesi dovuta: questo paradigma è ovviamente opinabile quando si provi a stravolgere un settore, in cui l’apporto di nuove dinamiche (e quindi nuove feature) è intrinsecamente compreso nel grande progetto finale.
Tornando alla filosfia “Real”, questo approccio è strettamente legato al concetto di “less mass” (meno massa). La massa di un’azienda o di un progetto è tutto ciò che ne aumenta l’inerzia e rende difficile cambiare direzione: contratti a lungo termine, personale in eccesso, decisioni permanenti, processi burocratici e dipendenze tecnologiche. Ridurre questa massa è essenziale perché, nel mondo delle applicazioni web, il cambiamento deve essere facile e a basso costo. Un’azienda snella, con meno massa, può reagire ed evolversi come un motoscafo, mentre un’azienda massiccia si muove con la lentezza di una portaerei.
La traduzione pratica di questa filosofia si trova nel capitolo che menziona il concetto di “half, not half-assed” (metà, non fatto male). Il monito è di evitare l’approccio “tutto compreso”, che porta inevitabilmente a un prodotto intero ma mediocre. È molto meglio costruire metà di un prodotto che sia eccellente. L’esempio fondante di Basecamp è emblematico: il team iniziò sviluppando solo la sezione dei messaggi, il cuore dell’applicazione, ignorando inizialmente milestone, to-do list e altre funzionalità. Questo ha permesso loro di costruire su una base solida e di basare le decisioni future sull’uso reale del prodotto, non su congetture.
Esaminando più a fondo, si comprende che il principio del “meno” non è solo una strategia di prodotto, ma un modello di business sostenibile, un sistema che si auto-rinforza. Il punto di partenza è “fund yourself” (finanziati da solo), che sconsiglia di ricorrere a finanziamenti esterni per evitare di dover rispondere a investitori le cui priorità (come ad esempio un rapido ritorno economico, a quel punto lecito) potrebbero entrare in conflitto con la costruzione di un prodotto di qualità. L’autofinanziamento impone vincoli di risorse naturali. Questi vincoli, a loro volta, non sono visti come un limite ma come un catalizzatore di creatività e focus, come spiegato ampiamente dal concetto di “embrace constraints” (abbraccia e accogli i vincoli). È proprio questa scarsità di risorse che costringe il team ad adottare i principi di “build less” e “half, not half-assed“, perché non c’è semplicemente la capacità di fare altrimenti. Costruire meno software (“less software“) porta a una base di codice più piccola e pulita, che riduce drasticamente i costi di manutenzione e supporto. Questo rende il business più redditizio e più facile da gestire per un team piccolo, in linea con il principio “hire less and hire later” (assumi meno e assumi dopo). La maggiore redditività, infine, permette al team di rimanere autofinanziato, chiudendo il cerchio. Il “meno” non è quindi una mera scelta di design ma il motore economico che rende l’intera filosofia sostenibile.
Velocità come vantaggio competitivo
Se il “meno” è il motore, la velocità è il carburante che alimenta il vantaggio competitivo secondo “Getting real”. Non si tratta di una velocità affrettata e caotica, ma di una velocità coltivata attivamente attraverso processi e decisioni che eliminano l’attrito e massimizzano lo slancio.
Il principio cardine è quello del “fix time and budget, flex scope” (fissa tempo e budget, rendi flessibile l’ambito). Il libro demolisce il mito secondo cui si può lanciare un progetto in tempo, rispettando il budget e l’ambito prefissato. Invece di aumentare il tempo o il denaro quando si incontrano difficoltà, la soluzione è ridurre l’ambito. Questo approccio ha un doppio vantaggio: garantisce che il prodotto venga lanciato entro i vincoli stabiliti e, soprattutto, costringe il team a una prioritizzazione spietata, separando ciò che è “essenziale” da ciò che è “bello avere”.
La capacità di fare questi tagli è legata al concetto di “lower your cost of change” (abbassa il tuo costo del cambiamento). Il costo del cambiamento è il nemico principale dell’agilità. Essere piccoli, avere meno massa e meno codice, conferisce un’agilità che nessuna grande azienda può comprare. Questa flessibilità è l’arma segreta dei piccoli team. Per mantenere basso questo costo, è fondamentale evitare stime a lungo termine, altro fondamento di aziende super-strutturate che viene smontato nel paragrafo del libro “shrink your time” (riduci il tuo tempo), che definisce queste proiezioni “fantasie”. Invece di un progetto di 12 settimane, si dovrebbe pensare a 12 progetti di una settimana. I compiti che superano le 30 ore vanno scomposti in blocchi più piccoli e gestibili da 6-10 ore. Questo non solo rende le stime più realistiche, ma crea un ritmo costante di piccole vittorie che mantengono alta la motivazione del team.
L’approccio “flex scope” rappresenta una trasformazione fondamentale della gestione del progetto: da un esercizio di predizione a un esercizio di scoperta. Il modello tradizionale, che cerca di fissare tempo, budget e ambito, presuppone una conoscenza quasi perfetta del futuro, un’ipotesi irrealistica nello sviluppo software. Fissando tempo e budget, “Getting real” accetta l’incertezza come una costante del processo. L’ambito diventa la variabile negoziabile, il terreno di un dialogo continuo tra il team e gli stakeholder. Questo dialogo non si basa su un documento iniziale scritto mesi prima ma sull’esperienza reale di costruzione del prodotto. Di conseguenza, il prodotto finale non è quello che era stato immaginato all’inizio ma quello che si è scoperto essere il più valido e realizzabile durante il percorso, nel rispetto dei vincoli dati.
Pragmatismo radicale: la realtà batte la teoria (da stampare e affiggere)
Il terzo pilastro è un pragmatismo inflessibile che privilegia sempre il tangibile sull’astratto, il reale sul teorico. La filosofia “Getting real” si basa sull’idea che la vera conoscenza emerge solo dall’interazione con qualcosa di concreto.
La parte del libro che si rifà al concetto “there’s nothing functional about a functional spec“, è una critica feroce alle specifiche funzionali. Questi documenti sono definiti “fantasie”, “un’illusione di accordo” e, peggio ancora, un meccanismo che costringe a prendere le decisioni più importanti nel momento in cui si hanno meno informazioni, ovvero all’inizio del progetto. Anche se più persone firmano un documento, ognuna ha in mente una versione diversa del prodotto, portando a inevitabili conflitti futuri. L’alternativa proposta è l’ “interfaccia reale”, un concetto che assume il proprio compimento nel paragrafo “race to running software” (corsa al software funzionante) in cui si evince come la priorità numero uno, fin dal primo giorno, sia avere qualcosa di funzionante il più rapidamente possibile, non importa se è incompleto o grezzo. Un software funzionante, anche solo un prototipo HTML cliccabile, è reale. Le persone possono usarlo, vederlo, sentirlo. E le cose reali portano a reazioni reali, che è l’unico modo per raggiungere una vera comprensione e un vero accordo.
Questo pragmatismo si estende anche alla gestione dei problemi futuri. “It’s a problem when it’s a problem“, introduce l’approccio “just wing it” (improvvisa). Invece di perdere tempo a risolvere problemi ipotetici, come la scalabilità per milioni di utenti, è meglio concentrarsi sui problemi attuali. L’esempio del lancio di Basecamp senza un sistema di fatturazione è emblematico: il team sapeva di avere 30 giorni di tempo prima della scadenza del primo ciclo di fatturazione e ha usato quel tempo per risolvere problemi più urgenti, costruendo il sistema di pagamento solo quando è diventato un problema reale.
Il rifiuto dei “dead documents” (documenti morti) non è solo una questione di efficienza. È una strategia deliberata per minimizzare i bias cognitivi che affliggono i team di sviluppo, in particolare il “confirmation bias” e la “sunk cost fallacy“. Un documento di specifiche dettagliato, una volta scritto e approvato, crea un forte impegno psicologico. Il team si sente obbligato a seguirlo, anche quando emergono prove che alcune idee sono sbagliate. Questo porta a ignorare i feedback negativi che contraddicono il piano (confirmation bias) e a continuare a investire tempo e risorse in una funzionalità fallimentare solo perché “è nel documento e ci abbiamo già lavorato tanto” (sunk cost fallacy). L’approccio “Getting real”, basando le decisioni su un’interfaccia funzionante e testata “in the wild” (sul campo), costringe il team a confrontarsi con la realtà oggettiva dell’esperienza utente e non con l’interpretazione soggettiva di un testo. Questo rende più facile e meno costoso, sia economicamente che psicologicamente, ammettere un errore e cambiare rotta.
Creare un prodotto con un’anima
Un prodotto costruito secondo i principi di “Getting real” non è un semplice assemblaggio di funzionalità. È uno strumento con una personalità, una visione del mondo e un’anima. Questo carattere distintivo non emerge per caso, ma è il risultato di un processo deliberato che mette l’identità e l’esperienza utente al centro di ogni decisione.
L’importanza di avere un’opinione
In un mercato affollato, l’anonimato è un fallimento. “Getting real” sostiene che il software non debba essere agnostico o cercare di accontentare tutti. Al contrario, deve avere un’opinione forte e prendere posizione.
Il capitolo “have an enemy” (avere un nemico), spiega come definire un “nemico” sia un modo potente per forgiare l’identità del proprio prodotto. Per Basecamp, il nemico era Microsoft Project e la filosofia di project management dittatoriale che rappresentava, basata su diagrammi di Gantt e controllo centralizzato. Posizionando Basecamp come “l’anti-project“, il team ha potuto chiarire immediatamente cosa il prodotto non doveva essere, focalizzandosi sulla comunicazione e la collaborazione democratica. Avere un nemico non solo fornisce una guida interna ma crea anche un potente messaggio di marketing basato sul conflitto, una narrazione che le persone comprendono e in cui amano schierarsi.
Questo concetto viene approfondito tramite l’argomentazione “make opinionated software” (creare software con un’opinione) in cui gli autori rifiutano l’idea che il software debba essere il più flessibile possibile. Sostengono che “il miglior software ha una visione, il miglior software prende posizione”. Quando un utente sceglie un prodotto, non cerca solo un elenco di funzionalità ma un approccio, una filosofia di lavoro. L’obiettivo non è inseguire i clienti che non saranno mai felici con la propria visione ma attrarre quelli che la condividono. La frase chiave è emblematica: “o sei sull’autobus o sei fuori dall’autobus”.
Per rendere questa personalità tangibile, “personify your product” è il capitolo che suggerisce di pensare al prodotto come a una persona. Che tipo di persona è? Educata? Severa? Divertente? Formale? Una volta definiti questi tratti, essi devono guidare ogni aspetto della creazione, dal tone of voice (in ambito copywriting) al design dell’interfaccia, fino alla selezione delle funzionalità. Ogni modifica deve essere valutata chiedendosi: “questa scelta è in linea con la personalità del nostro prodotto?”.
La creazione di un “software con un’opinione” è molto più di una scelta di design; è una strategia di marketing intrinseca che trasforma gli utenti in evangelisti. Un software agnostico, che cerca di accontentare tutti, non ispira nessuno. È un semplice bene di consumo, facilmente sostituibile. Al contrario, un software con una visione forte costringe l’utente a una scelta consapevole: “sono d’accordo con questo modo di lavorare?”. Coloro che rispondono affermativamente non stanno semplicemente adottando uno strumento, ma stanno aderendo a un’ideologia. Si sentono parte di una tribù che “la pensa nel modo giusto”. Questa identificazione ideologica è un legame molto più forte della semplice soddisfazione funzionale. Trasforma gli utenti da semplici consumatori a sostenitori attivi, perché promuovere il prodotto significa promuovere la propria visione del mondo.
Il processo guidato dall’interfaccia
Se l’anima del prodotto è la sua opinione, il suo corpo è l’interfaccia. “Getting real” ribalta il processo di sviluppo tradizionale, mettendo l’esperienza utente, incarnata dalle schermate reali, al primo posto.
“Interface first” stabilisce una regola fondamentale: si progetta l’interfaccia prima di iniziare a programmare. La programmazione è la componente più “pesante” di un’applicazione, ovvero la più costosa e difficile da modificare. Partire dal codice significa erigere muri che limitano la flessibilità. Il design, al contrario, è “leggero”: uno schizzo su carta o un prototipo HTML/CSS (ora c’è Figma in ulteriore soccorso) è economico e facile da cambiare o buttare via. Progettare prima mantiene il processo flessibile. Inoltre, l’interfaccia è il prodotto. È ciò che gli utenti vedono e usano. Trattarla come un’aggiunta finale è una ricetta per il fallimento.
Per progettare l’interfaccia in modo efficace, si introduce il concetto di “epicenter design“. Invece di iniziare dalla cornice della pagina (navigazione, header, footer), si parte dal suo cuore, dall’elemento più importante e indispensabile: l’epicentro. Ad esempio, in una pagina che mostra un post di un blog, l’epicentro è il post stesso. Solo dopo aver perfezionato questo nucleo si costruisce verso l’esterno, aggiungendo gli elementi secondari. Questo approccio capovolge il modello tradizionale che versa il contenuto in uno spazio residuo, garantendo invece che la funzione principale della pagina riceva la massima attenzione fin dal primo giorno.
L’interfaccia non è fatta solo di elementi visivi, ma anche di parole. “Copywriting is interface design“, sottolinea che le migliori interfacce sono ben scritte. Ogni lettera conta tanto quanto ogni pixel. La scelta di una singola parola su un pulsante (“submit” vs “save” vs “create“) può cambiare radicalmente la percezione e l’usabilità di una funzione. Il testo deve essere chiaro, conciso e parlare la lingua dell’utente, non il gergo tecnico degli sviluppatori o dei progettisti. La buona scrittura è un segno di pensiero chiaro, e il pensiero chiaro è il fondamento di un buon design.
L’approccio “interface first” non è solo una scelta di processo, ma un potente strumento di comunicazione e allineamento per il team. Come evidenziato nella critica alle specifiche funzionali, i documenti testuali sono intrinsecamente ambigui e portano a un’ “illusione di accordo”. Un’interfaccia cliccabile, anche se non ancora funzionante, è un artefatto concreto e inequivocabile. Un flusso di passaggi è intuitivo o confuso. Discutere su un’interfaccia reale costringe designer, sviluppatori e stakeholder a parlare della stessa identica cosa, eliminando le discussioni astratte e le costose incomprensioni che, in un processo tradizionale, emergerebbero solo dopo settimane di programmazione, quando il costo del cambiamento è già diventato proibitivo.
La gestione delle funzionalità come filtro strategico
Un prodotto con un’anima è definito tanto da ciò che fa quanto da ciò che non fa. L’arte di dire “no” è una competenza strategica fondamentale nel mondo di “Getting real”, un filtro che protegge il prodotto dalla mediocrità e dal “bloatware“.
Il principio guida è “start with no” (partire con un no): ogni nuova idea o richiesta di funzionalità viene accolta con un “no” di default. Non si tratta di un rifiuto definitivo, ma di un test di resistenza. Una funzionalità deve “lottare per essere implementata”, dimostrando il suo valore nel tempo. Gli autori usano una metafora potente: dire “sì” a una funzionalità è come “adottare un figlio”. Bisogna prendersene cura per sempre, attraverso la progettazione, l’implementazione, i test, la manutenzione e il supporto. È un impegno a lungo termine, da non prendere alla leggera.
Ma come si decide a quali funzionalità dire “sì”? La risposta è nel capitolo “forget feature requests” (dimentica le richieste di funzionalità). Invece di creare complessi backlog o sistemi di tracciamento, il libro propone un metodo radicale: leggere le richieste, buttarle via e dimenticarle. Quelle veramente importanti torneranno a galla, ripetute da più utenti nel tempo. “Lascia che i tuoi clienti siano la tua memoria”: questo approccio trasforma il feedback da un flusso di dati da gestire a un segnale che emerge naturalmente dal rumore.
Prima di implementare qualsiasi cosa, è cruciale considerare gli “hidden costs“. Una funzionalità apparentemente semplice può innescare una valanga di lavoro nascosto: modifiche alla documentazione di aiuto, aggiornamento degli screenshot promozionali, revisione dei termini di servizio, test aggiuntivi e potenziale impatto sulla struttura dei prezzi. Riconoscere questi costi nascosti è un altro potente filtro contro l’aggiunta indiscriminata di funzionalità.
Questo sistema di gestione delle funzionalità è, in effetti, un meccanismo di filtraggio passivo e basato sui dati, molto più efficace di qualsiasi sistema attivo di prioritizzazione. Un backlog tradizionale richiede un lavoro costante di gestione: stima, discussione, riordino. È un’attività che consuma tempo e può essere facilmente influenzata da bias interni, come la “voce più alta nella stanza” o le preferenze personali del product manager. L’approccio di 37signals, invece, è passivo e delega il lavoro di prioritizzazione al mercato. Una richiesta che emerge una sola volta è probabilmente un caso limite o il desiderio di un singolo utente; un backlog la manterrebbe visibile, creando rumore decisionale. Buttandola via, si elimina il rumore. Al contrario, una richiesta ripetuta da decine di utenti diversi nel tempo non è un’opinione ma un dato. È un segnale forte e validato dal mercato che indica un problema diffuso. Questo sistema, quindi, filtra automaticamente il rumore e fa emergere solo i segnali più forti, riducendo il carico cognitivo del team e basando le decisioni su dati reali e persistenti.
L’organizzazione agile e la cultura del lavoro
La filosofia “Getting real” non si applica solo al prodotto, ma permea profondamente l’organizzazione che lo costruisce. La struttura del team, le pratiche di comunicazione e i criteri di assunzione sono tutti progettati per supportare i pilastri di minimalismo, velocità e pragmatismo.
Piccoli team, grande impatto
L’efficacia, secondo “Getting real”, è inversamente proporzionale alla dimensione del team e alla quantità di processi formali. La snellezza organizzativa è la chiave per un grande impatto.
“The three musketeers” è la parte del libro che definisce la dimensione ideale del team per la prima versione di un’applicazione: tre persone. Un designer, uno sviluppatore e uno “sweeper“, una figura ibrida in grado di muoversi tra i due mondi. Questa restrizione dimensionale non è un limite, ma un vantaggio: forza la prioritizzazione, semplifica drasticamente la comunicazione e permette al team di rimanere agile. Se non si riesce a costruire la versione 1.0 con tre persone, il problema non è il team, ma l’eccessiva ambizione della versione iniziale.
Per proteggere la produttività di questi piccoli team, è essenziale eliminare le interruzioni e di qui il concetto di “meetings are toxic” che chiaramente descrive le riunioni come l’antitesi della produttività. Esse frammentano la giornata lavorativa, interrompono il flusso di lavoro, si concentrano su concetti astratti invece che su artefatti reali e sono terribilmente inefficienti nel trasmettere informazioni. Le riunioni vanno evitate a ogni costo. Se sono assolutamente indispensabili, devono seguire regole ferree: un timer di 30 minuti, il minor numero possibile di partecipanti e un’agenda chiara e concisa.
Il motivo per cui le riunioni sono così dannose è spiegato nel capitolo “alone time“. Il lavoro reale, profondo e creativo avviene in periodi di tempo ininterrotto, quando si entra “nella zona” (concetto rubato allo sport). Il libro paragona questo stato al sonno REM: richiede tempo per essere raggiunto e ogni interruzione costringe a ricominciare il processo da capo. La “zona” è dove avviene la vera magia dello sviluppo, e l’organizzazione ha il dovere di proteggerla, ad esempio istituendo periodi della giornata in cui ogni forma di comunicazione è bandita.
Questa filosofia anti-riunioni e pro-alone time non è una semplice preferenza di stile di lavoro, ma un riconoscimento fondamentale della natura del lavoro creativo e tecnico. Rivela una profonda comprensione del concetto psicologico di “flow state” e del costo del “context switching“. Il lavoro di programmazione e design non è un’attività lineare come quella di una catena di montaggio; richiede la costruzione di complessi modelli mentali all’interno della mente dello sviluppatore o del designer. Un’interruzione, anche breve, può distruggere questo delicato costrutto mentale. Ricostruirlo ha un costo significativo in termini di tempo ed energia. Pertanto, definire le riunioni “tossiche” non è un’iperbole, ma una valutazione accurata del loro impatto distruttivo sulla risorsa più preziosa e fragile di un team di sviluppo: la concentrazione profonda e ininterrotta.
Principi di assunzione e collaborazione (privilegiare chi “scrive bene”)
La costruzione di un team “real” segue principi non convenzionali, privilegiando la versatilità e le capacità di comunicazione rispetto a specializzazioni rigide e credenziali formali.
La regola d’oro è “hire less and hire later“: l’assunzione non è la soluzione di default a un aumento del carico di lavoro. La prima domanda da porsi è: questo lavoro è davvero necessario? Può essere eliminato, automatizzato con del software o risolto con un cambiamento di processo? L’assunzione è l’ultima risorsa, da considerare solo quando il dolore causato dalla mancanza di una persona è chiaramente identificato e insopportabile. Non si ha bisogno di tante persone quante si pensa.
Quando si assume bisogna concentrarsi sul concetto di “get well rounded individuals” (cerca individui a tutto tondo), evitando gli specialisti iper-verticali. In un team piccolo non c’è spazio per chi sa fare una sola cosa. Servono generalisti, persone che possono indossare più cappelli: designer che sanno scrivere un testo efficace, programmatori che hanno sensibilità per il design e persone che sono disposte a imparare e adattarsi rapidamente a nuove sfide.
Forse il principio di assunzione più sorprendente e significativo è quello del capitolo “wordsmiths” (artigiani della parola). A parità di altre condizioni, si deve sempre assumere chi scrive meglio, indipendentemente dal ruolo. La motivazione è profonda: la buona scrittura non è solo una questione di grammatica ma è sintomo di un pensiero chiaro, di una mente organizzata e di una forte capacità di comunicazione. Le persone che scrivono bene sanno come rendere le cose facili da capire, sanno cosa omettere e sanno mettersi nei panni degli altri. Queste sono le qualità fondamentali per il successo in qualsiasi ruolo all’interno di un’organizzazione snella.
L’enfasi sull’assumere wordsmiths è, in realtà, la chiave per poter scalare la cultura “Getting real” senza dover ricorrere a processi formali e burocratici. Questa filosofia elimina la documentazione pesante come le specifiche funzionali. In assenza di questi documenti, la comunicazione e l’allineamento del team avvengono principalmente attraverso canali asincroni come email e chat. Se i membri del team sono scrittori chiari e concisi, questa comunicazione diventa estremamente efficiente. Le idee vengono espresse senza ambiguità, le decisioni vengono documentate implicitamente nelle conversazioni scritte e la necessità di indire riunioni “per chiarire le cose” diminuisce drasticamente. Assumere buoni scrittori non è quindi un vezzo, ma un requisito infrastrutturale per un’organizzazione che vuole operare senza la “stampella” della burocrazia formale, mantenendo velocità e agilità.
Dalla promozione all’evoluzione continua
Il lancio di un prodotto non è il traguardo ma l’inizio di un dialogo continuo con il mercato. Le strategie di marketing, supporto ed evoluzione post-lancio in “Getting real” sono coerenti con la filosofia generale: autenticità, trasparenza e una disciplina costante nel resistere alla complessità.
Marketing e support basati sull’autenticità
Le strategie di “Getting real” per raggiungere e servire i clienti rifuggono le tattiche aggressive e impersonali, preferendo costruire relazioni basate sulla fiducia e sul valore reciproco.
Il capitolo “promote through education” delinea un approccio al marketing che si basa sulla condivisione della conoscenza. Invece di una vendita aggressiva, si creano contenuti di valore – articoli di blog, guide, workshop – che aiutano la comunità. Questo non solo posiziona l’azienda come un’autorità nel suo campo, ma attira clienti in modo organico, persone che sono già allineate con la filosofia dell’azienda. È un marketing che dà prima di chiedere.
L’autenticità richiede trasparenza, specialmente quando le cose vanno male. “publicize your screwups” (pubblicizza i tuoi errori) è la filosofia che consiglia di comunicare apertamente qualsiasi problema o errore, anche se i clienti non se ne sono accorti. Ad esempio, dopo un downtime notturno di Basecamp, il team ha pubblicato un post sul blog per spiegare l’accaduto. Questo approccio onesto e diretto costruisce una fiducia a lungo termine che nessuna campagna di marketing può comprare.
Questa connessione diretta con i clienti è fondamentale anche per il supporto. Il capitolo “feel the pain” è un monito contro l’esternalizzazione del servizio clienti. L’intero team, inclusi designer e sviluppatori, deve essere esposto ai problemi e alle frustrazioni degli utenti. Solo sentendo il loro “dolore” in prima persona è possibile capire veramente i punti deboli del prodotto e avere la motivazione per migliorarlo. Il supporto non è un costo da minimizzare ma la più preziosa fonte di feedback. L’obiettivo finale del prodotto dovrebbe essere, come suggerisce il libro in “zero training“, un prodotto che non richiede un manuale. Dovrebbe essere così semplice e intuitivo che l’aiuto è necessario solo in punti specifici, integrato direttamente nell’interfaccia dove e quando serve.
La strategia di “pubblicizzare i propri errori” può essere vista come una forma di “Jiu-Jitsu reputazionale”. La reazione istintiva della maggior parte delle aziende di fronte a un errore è nasconderlo per paura di perdere la fiducia dei clienti. Tuttavia, in un mondo iperconnesso, gli errori vengono spesso scoperti comunque, e il tentativo di occultamento causa un danno reputazionale molto maggiore dell’errore stesso. Comunicando il problema in modo proattivo, l’azienda prende il controllo della narrazione. L’atto di ammettere la colpa, spiegare cosa è successo e descrivere le contromisure è così inaspettato e contrario al comportamento aziendale standard che spesso genera un’ondata di rispetto e simpatia. I clienti si sentono trattati come partner intelligenti, non come consumatori da gestire. Di conseguenza, un evento potenzialmente negativo si trasforma in un’opportunità per rafforzare la relazione con il cliente, aumentando la sua lealtà a lungo termine.
Dopo il lancio: evoluzione e disciplina
La gestione di un prodotto maturo presenta nuove sfide, in particolare la tentazione di aggiungere complessità. “Getting real” propone un approccio basato su un’evoluzione misurata e una disciplina ferrea nel proteggere la semplicità originale del prodotto.
Per mantenere lo slancio dopo il lancio, il capitolo “one month tuneup” raccomanda di rilasciare un aggiornamento significativo circa 30 giorni dopo il lancio iniziale. Questo ha molteplici benefici: dimostra che l’azienda sta ascoltando il feedback dei primi utenti, mostra che il prodotto è vivo e in attiva evoluzione, e infine può generare una seconda ondata di interesse e copertura mediatica.
Con il passare del tempo, la minaccia più grande diventa la complessità. “Beware the bloat monster” avverte che maturità non deve significare complicazione. Esiste la tentazione di continuare ad aggiungere funzionalità solo per dimostrare che il prodotto stia “migliorando”. Questo è un problema endemico del software desktop tradizionale, dove le aziende devono giustificare l’acquisto di nuove versioni (es. da 1.0 a 2.0) aggiungendo sempre più opzioni, che spesso portano al “bloatware“. Il modello a sottoscrizione delle applicazioni web, invece, non ha questa necessità. Il valore risiede nel servizio continuo, non nel numero di funzionalità. È quindi possibile e auspicabile resistere attivamente al “bloat“.
Questa disciplina si applica anche alla gestione dei problemi tecnici in “all bugs are not created equal” (non tutti i bug sono creati uguali) che promuove un approccio pragmatico. Non tutti i bug richiedono una soluzione immediata: è necessario prioritizzare in base a quanti utenti sono interessati e alla gravità del problema. A volte, aggiungere una nuova funzionalità richiesta da molti può avere un impatto maggiore per il business che risolvere un bug minore che affligge pochi utenti. Non bisogna creare una cultura della paura intorno ai bug, ma gestirli in modo aperto e razionale.
Il concetto di “beware the bloat monster” implica un’idea radicale per il settore tecnologico, ossessionato dalla crescita continua: un prodotto può raggiungere uno stato di “completezza”. A un certo punto, il lavoro principale del team può e deve spostarsi dal “costruire il nuovo” al “curare l’esistente”, concentrandosi sul raffinamento, la stabilità e la manutenzione della semplicità che ha decretato il successo iniziale del prodotto. Questa è una visione matura del ciclo di vita del prodotto che privilegia la sostenibilità e la qualità dell’esperienza a lungo termine rispetto alla crescita delle funzionalità fine a se stessa, un approccio perfettamente allineato con la natura continua e basata sul servizio del modello di business SaaS.
Confronto tra sviluppo tradizionale e approccio “Getting real”
La tabella seguente sintetizza le differenze filosofiche e operative tra l’approccio convenzionale allo sviluppo software e i principi di “Getting real”.
| Parametro | Approccio tradizionale (“cover your ass”) | Approccio “Getting real” |
| Pianificazione | Roadmap a lungo termine, predittiva | Cicli brevi, adattiva, “just-in-time” |
| Documentazione | Specifiche funzionali dettagliate (FSD) | Brevi storie, prototipi di interfaccia |
| Team | Grandi, specializzati, divisi in silos | Piccoli (3 persone), generalisti, integrati |
| Gestione feature | Guidata da FSD e comitati | Guidata da feedback reali; “no” di default |
| Processo | Lineare (waterfall) o burocratico | Iterativo, “race to running software” |
| Decisioni | Prese all’inizio (con meno informazioni) | Prese durante il processo (con più informazioni) |
| Comunicazione | Riunioni formali, documenti | Chat, email, comunicazione diretta e asincrona |
| Rischio | Gestito tramite documentazione e processi | Gestito tramite velocità e basso costo del cambiamento |
| Obiettivo finale | Rispettare il piano e lo scope iniziale | Lanciare un prodotto utile e di qualità in tempo e budget |
Parallelismo con “Shape up”: un altro testo di 37signals
“Getting real” e “Shape up” sono due manifestazioni della stessa filosofia di base di 37signals, ma rispondono a esigenze diverse e sono stati scritti in momenti molto diversi della storia dell’azienda.
Possiamo vederli in questo modo: “Getting real” è il manifesto filosofico (il “perché”), mentre “Shape up” è il manuale operativo (il “come”).
Punti di contatto: la filosofia comune
Entrambi i libri condividono lo stesso DNA e la stessa avversione per la complessità inutile e la burocrazia aziendale. I principi fondamentali che li legano sono:
- pragmatismo e semplicità: l’obiettivo è creare software utile e funzionante. Entrambi i libri predicano l’eliminazione del superfluo (“less is more“);
- avversione allo spreco: rifiutano processi “pesanti” (come l’Agile più burocratico), lunghe riunioni di pianificazione, stime dettagliate (che sono viste come spreco di tempo) e backlog infiniti;
- focus sul prodotto reale: l’unica vera misura del progresso è il software funzionante;
- autonomia e fiducia: entrambi promuovono l’idea di team piccoli, autonomi e responsabili, a cui viene data fiducia per portare a termine il lavoro;
- prendere decisioni: la filosofia di 37signals si basa sul fare “scommesse” (bets) e accettare i trade-off, piuttosto che cercare di pianificare tutto alla perfezione.
Differenze: filosofia vs. metodologia
La differenza principale risiede nel loro scopo e nel livello di dettaglio. “Getting real” è stato scritto nel 2006, quando 37signals era una piccola startup; “Shape up” è del 2019 e riflette l’evoluzione di quei principi per gestire un team e un prodotto più maturi.
Ecco un confronto diretto:
| Aspetto | 📘 Getting real (2006) | 📗 Shape up (2019) |
| Scopo Principale | È un manifesto filosofico. Una raccolta di idee controcorrente su business, design e sviluppo. | È una metodologia operativa. Un manuale dettagliato su come gestire lo sviluppo del prodotto. |
| Cosa offre | Principi generali e “massime” (es. “build less”, “fix time, not scope”, “no functional specifications”). | Un processo strutturato in fasi precise (shaping, betting, building) e concetti specifici. |
| Focus | Ampio: copre business, design, programmazione, marketing. È il “sistema di pensiero” generale. | Specifico: è focalizzato al 100% sul processo di sviluppo del prodotto e product management. |
| Il problema che risolve | “Come posso lanciare un prodotto web in modo snello, veloce e intelligente, senza fondi esterni?” | “Come possiamo, come team maturo, decidere su cosa lavorare e spedire progetti significativi in modo calmo e ripetibile, senza bruciarci?” |
| Concetti chiave | * Costruisci meno * “The epicenter” (trova il cuore della feature) * Meno riunioni, meno astrazione * Lanciare velocemente | * Cicli fissi (6 settimane + 2 di cooldown) * Shaping (definire il lavoro prima) * Appetite (budget di tempo) * Betting Table (sostituisce il backlog) * Fixed time, variable scope (principio chiave) |
| Livello di dettaglio | Alto a livello filosofico, basso a livello prescrittivo. Ti dice cosa pensare. | Basso a livello filosofico (dà per scontata la filosofia di “Getting real”), alto a livello prescrittivo. Ti dice cosa fare. |
In sintesi
“Getting real” è il libro da leggere per capire la mentalità di 37signals. È ispirazionale e aiuta a mettere in discussione le pratiche comuni di business e sviluppo.
“Shape up” è l’evoluzione di quella mentalità. È la risposta pratica a come applicare i principi di “Getting real” su un prodotto maturo con un team stabile. Prende l’idea filosofica di “Fix time, not scope” e la trasforma in un sistema concreto di cicli di 6 settimane, “appetite” e “scope hammering” (riduzione attiva dello scope per rispettare la scadenza).
Non avremmo “Shape up” senza la fondazione filosofica posta da “Getting Real”.
Personalmente, nel momento in cui scrivo questo articolo e queste considerazioni sul libro di 37signals
Considerazioni finali: applicare “Getting real” nel contesto attuale
“Getting real” è più di una raccolta di tattiche; è una filosofia coesa che offre un potente antidoto alla complessità e alla burocrazia che affliggono molti progetti software. La sua forza risiede nella sua semplicità e nel suo focus incessante sulla creazione di valore tangibile.
Punti di forza e limiti
I vantaggi di questo approccio sono evidenti: velocità, focus, efficienza dei costi e un perfetto allineamento con i moderni modelli di business SaaS basati su sottoscrizione. Promuove una cultura del fare, della responsabilità e della connessione diretta con il cliente. Tuttavia, come gli stessi autori ammettono, questa filosofia ha dei limiti: è meno adatta per sistemi mission-critical o life-critical (come sistemi di controllo nucleare o software medicali), dove la tolleranza ai fallimenti è zero e la documentazione rigorosa è un requisito legale e di sicurezza. Può anche essere difficile da implementare in grandi organizzazioni enterprise o in contesti altamente regolamentati, dove i processi formali, le approvazioni a più livelli e la pianificazione a lungo termine sono requisiti non negoziabili.
Contesti di applicazione ideali secondo gli autori
L’approccio “Getting real” prospera in contesti caratterizzati da alta incertezza e dove la velocità di apprendimento dal mercato è il fattore critico di successo. È ideale per:
- Startup e PMI: dove le risorse sono limitate e la velocità di arrivare sul mercato è tutto.
- Team di innovazione (“skunkworks“): piccoli gruppi all’interno di grandi aziende incaricati di esplorare nuove idee, liberi dai vincoli burocratici della casa madre.
- Lancio di nuovi prodotti (v1.0): quando il prodotto è ancora in fase di definizione e il feedback rapido degli utenti è essenziale per trovare il product-market fit.
- Progetti autofinanziati: dove la disciplina di costo e l’efficienza sono intrinseche al modello di business.
Insight attuabili per leader e sviluppatori
Anche senza adottare la filosofia nella sua interezza, è possibile integrare i suoi principi più potenti in qualsiasi organizzazione:
- Adotta il “no” come filtro: inizia a trattare ogni nuova richiesta di funzionalità con un “no” iniziale. Mettila in quarantena e osserva se sopravvive alla prova del tempo e alla ripetizione da parte di più utenti.
- “Uccidi” una riunione: identifica una riunione settimanale ricorrente e, come esperimento, sostituiscila con una comunicazione asincrona (es. un thread di discussione dettagliato) per un mese. Misura l’impatto sulla produttività e sulla chiarezza delle decisioni.
- Progetta un’interfaccia prima di scrivere codice: per la prossima funzionalità importante, dedica del tempo a creare un prototipo cliccabile. Usa questo prototipo come base per tutte le discussioni interne prima che venga scritta una sola riga di codice.
- Senti il “dolore del cliente”: istituisci una rotazione in cui ogni membro del team di sviluppo, inclusi i senior, deve dedicare alcune ore al mese a rispondere direttamente ai ticket di supporto dei clienti.
L’eredità di “Getting real”
A distanza di anni dalla sua pubblicazione, l’influenza di “Getting real” è innegabile. Molti dei suoi concetti hanno anticipato e plasmato il movimento Lean Startup e le moderne pratiche di product management, come l’enfasi sul Minimum Viable Product (MVP), il ciclo build-measure-learn e la validazione continua sul mercato. In un’epoca in cui molte aziende, anche quelle che si definiscono “agili”, sono diventate “feature factory” che sfornano funzionalità senza una chiara visione, la sua rilevanza è forse ancora maggiore. “Getting real” rimane un richiamo essenziale e senza tempo all’essenza della creazione di prodotti: risolvere problemi reali per persone reali, nel modo più semplice, diretto ed onesto possibile.
