Vai al contenuto principale
Come Funziona Questo Corso - immagine ufficiale della lezione su GinnyTech, creata da AD

'First principles: come ragiona un analista forte'

First principles: come ragiona un analista forte. Lezione core del modulo Panoramica del Corso e Metodo di Studio per Data Work con problema reale, modello concettuale, formalizzazione rigorosa, caso applicato, lab a 3 livelli e checkpoint finale.

AD
Creato da Andrii Dyshkantiuk
Lezione 2 / 216 Livello: Base Durata: 18 min Prerequisiti: 1

Cosa imparerai

  • Comprendere il problema analitico e il contesto decisionale
  • Applicare esempi, metriche e controlli a casi reali

First principles: come ragiona un analista forte

Sei in una riunione e il grafico principale è rosso. Qualcuno propone di aumentare il budget marketing, qualcun altro vuole cambiare onboarding, un terzo chiede una dashboard più dettagliata. Tutti sembrano avere una risposta, ma nessuno ha ancora chiarito la domanda.

Una scena da cui partire

Il first principles thinking serve proprio in quel momento: quando il rumore operativo spinge tutti verso soluzioni veloci e tu devi riportare il problema alla sua struttura essenziale.

Non è una frase da usare per sembrare brillante. È una disciplina pratica: togliere abitudini, gergo, pressioni e precedenti fino a trovare ciò che deve essere vero perché una decisione sia sensata. Prima capisci la scelta. Poi formuli l’ipotesi. Solo dopo apri i dati.

Cosa significa pensare per primi principi

Il concetto di «first principles» risale ad Aristotele. Nella Metafisica, il filosofo definiva i primi principi come «la prima base da cui una cosa è conosciuta» — gli elementi fondanti, non ulteriormente scomponibili, dai quali si costruisce tutto il resto. Non puoi dimostrarli, ma puoi identificarli, e da lì costruire ragionamenti che non ereditano errori da nessuna premessa non verificata.

Nel XX secolo, il fisico Richard Feynman diede al concetto una formulazione operativa che è diventata il gold standard per chiunque lavori con dati e modelli. Il suo metodo era brutale nella semplicità: prendi un concetto, spiegarlo a un bambino di otto anni, identifica il punto esatto in cui la tua spiegazione si fa vaga, e lì hai trovato ciò che non hai ancora capito davvero. Non ciò che non sai ripetere, ma ciò che non sai ricostruire da zero.

Elon Musk ha reso popolare l’espressione «first principles thinking» in ambito ingegneristico. Quando la sua azienda, SpaceX, iniziò a progettare razzi, il prezzo di mercato di un razzo era di circa 65 milioni di dollari. Musk chiese al suo team: qual è il costo delle materie prime di un razzo? Alluminio, titanio, rame, fibre di carbonio. La risposta: circa il 2% del prezzo di mercato. Da quel dato elementare — il costo reale dei materiali — ricostruì l’intera catena produttiva. Il risultato fu il Falcon 9, con un costo per lancio radicalmente inferiore a qualsiasi concorrente. Non fu genio: fu l’ostinazione nel non accettare che «un razzo costa X» fosse un dato di natura. Era solo il prezzo che qualcun altro aveva fissato prima di lui.

Nel lavoro analitico, il first principles thinking ha una traduzione precisa e pratica. Significa che ogni analisi parte da quattro domande, in quest’ordine, senza eccezioni:

  1. Quale decisione stiamo cercando di prendere? Non «cosa vogliamo sapere?», ma «cosa faremo di diverso domani se questa analisi dice X invece che Y?»
  2. Qual è l’ipotesi di meccanismo causale? Quale relazione tra causa ed effetto stiamo assumendo, implicitamente o esplicitamente?
  3. Quale metrica è la rappresentazione più fedele di quel meccanismo? Denominatore esatto, segmento, finestra temporale.
  4. Quale guardrail impedisce che l’analisi venga distorta da rumore, bias o wishful thinking?

Se manca anche uno solo di questi quattro blocchi, l’analisi può essere corretta nei calcoli e completamente inutile nella pratica.

Perché il cervello resiste ai first principles

Daniel Kahneman, premio Nobel per l’economia 2002, ha dedicato la sua carriera a dimostrare che il cervello umano ha una preferenza innata per le scorciatoie. In Thinking, Fast and Slow (2011), Kahneman distingue due sistemi cognitivi.

Il Sistema 1 è veloce, automatico, emotivo. Riconosce pattern, prende decisioni in millisecondi, consuma poca energia. È il sistema che usi quando vedi un’espressione arrabbiata e sai immediatamente che c’è un problema, o quando leggi «il tasso di conversione è calato del 12%» e pensi subito «dobbiamo aumentare il budget».

Il Sistema 2 è lento, analitico, dispendioso. È il sistema che usi per moltiplicare 17 × 24 a mente, o per chiederti se il calo del 12% è reale o è un artefatto del tracking. Il Sistema 2 richiede sforzo cosciente, e il cervello lo evita ogni volta che può.

Il first principles thinking è, per definizione, un’attività del Sistema 2. Il problema è che la maggior parte delle riunioni di lavoro, dei report e delle dashboard è progettata per il Sistema 1: colori, trend, frecce su e giù, numeri che sembrano raccontare una storia. L’analista forte è quello che, in quel contesto, attiva deliberatamente il Sistema 2 invece di lasciarsi trasportare dal Sistema 1. È quello che, davanti a un grafico che mostra un miglioramento, chiede: «Abbiamo cambiato la definizione della metrica? Il campione di questo mese è diverso da quello del mese scorso? Cosa è successo esattamente nel periodo di confronto?»

Le Cinque Perché di Toyota: first principles nell’industria

Negli anni ‘50, Taiichi Ohno, l’ingegnere che avrebbe rivoluzionato la produzione automobilistica con il Toyota Production System, sviluppò una tecnica che è l’incarnazione industriale del first principles thinking: le Cinque Perché.

La regola è semplice: quando si presenta un problema, non accettare la prima causa apparente. Chiedi «perché?» cinque volte, finché non arrivi alla radice.

Un esempio canonico dal reparto produzione Toyota:

  • Problema: il robot di saldatura si è fermato.
  • Perché? — Il fusibile è saltato per sovraccarico.
  • Perché? — Il cuscinetto non era lubrificato a sufficienza.
  • Perché? — La pompa di lubrificazione non pompava abbastanza olio.
  • Perché? — L’albero della pompa era usurato.
  • Perché? — Non c’era un filtro che impedisse ai trucioli metallici di entrare nella pompa.

La causa radice non era il fusibile, né il cuscinetto, né la pompa. Era l’assenza di un filtro che costava pochi dollari. Senza le Cinque Perché, il team avrebbe sostituito il fusibile, il robot si sarebbe fermato di nuovo la settimana dopo, e il problema sarebbe diventato cronico.

Nel lavoro analitico, le domande sono diverse ma la struttura è identica:

  • Problema: la retention della coorte di gennaio è crollata del 30%.
  • Perché? — Perché gli utenti abbandonano dopo il primo giorno.
  • Perché? — Perché l’onboarding chiede troppe informazioni prima di mostrare valore.
  • Perché? — Perché il flusso di registrazione è stato ridisegnato a dicembre senza test A/B.
  • Perché? — Perché il team prodotto aveva una deadline di fine anno e ha saltato la validazione.
  • Perché? — Perché la metrica di successo del team era «numero di feature rilasciate», non «retention a 7 giorni».

La causa radice non era il design dell’onboarding. Era l’incentivo: un KPI che premiava la velocità di rilascio, non la qualità dell’esperienza. Cambiare il flusso senza cambiare il KPI avrebbe solo spostato il problema sulla prossima feature.

Il framework decisionale in cinque blocchi

Dall’integrazione tra Aristotele, Feynman, Kahneman e Ohno emerge un framework operativo che ogni analista dovrebbe interiorizzare. Quando affronti un problema, riempi questi cinque blocchi nell’ordine, prima di aprire qualsiasi dashboard:

Decisione. Scrivi in una frase chiara: «Dobbiamo decidere se fare X entro Y». Se ci sono più stakeholder, la frase deve includere chi decide e con quale autorità. «Dobbiamo decidere se aumentare il budget di Facebook Ads del 20% per il Q2, il CMO decide entro venerdì» è una domanda analitica. «Dobbiamo capire come va il marketing» non lo è.

Ipotesi. Qual è il meccanismo causale che stai assumendo? «Assumiamo che l’aumento del budget su Facebook produca un incremento proporzionale di conversioni, perché la campagna attuale ha un ROAS positivo e non abbiamo saturato il target audience». Scrivi l’ipotesi prima di guardare i dati. Questo è fondamentale: se formuli l’ipotesi dopo, il cervello (Sistema 1) la adatterà ai numeri che hai già visto.

Misura. Quale metrica, con quale denominatore, su quale segmento e in quale finestra temporale confermerebbe o falsificherebbe l’ipotesi? «ROAS (Revenue / Ad Spend) sul segmento utenti iOS 25-34 in Italia, finestra mobile di 7 giorni post-click, confronto pre/post aumento budget con baseline di 4 settimane». La precisione non è pedanteria: è la differenza tra un’analisi che porta a una decisione e un’analisi che genera altre domande.

Guardrail. Cosa non deve peggiorare mentre ottimizzi la metrica primaria? «Il CPA (Cost Per Acquisition) non deve superare €45. Il tasso di conversione organico non deve scendere sotto il 3.2%. La frequenza media per utente non deve superare 8 impression a settimana». I guardrail sono la rete di sicurezza: senza, ottimizzi un numero e distruggi tutto il resto.

Output. Quale raccomandazione consegni, a chi, entro quando, e con quale criterio di revisione? «Memo di due pagine al CMO entro mercoledì: risultati del test con ROAS e CPA, analisi per segmento, raccomandazione con tre scenari (aumento 10%, 20%, nessun aumento), rischi e piano di monitoraggio per le prime due settimane».

Questa struttura non rallenta il lavoro. Lo accelera, perché elimina il loop infinito di «aggiungiamo un altro grafico», «controlliamo anche quest’altro segmento», «forse se guardiamo i dati in un altro modo…». Quando i cinque blocchi sono pieni, sai esattamente quando hai finito.

Il caso Toyota applicato ai dati: un esercizio di pensiero

Prendiamo uno scenario realistico. Un’azienda SaaS B2B con 15.000 clienti nota che il Net Revenue Retention (NRR) è sceso da 115% a 102% in due trimestri. Il CEO chiede un’analisi urgente.

L’approccio da Sistema 1 è immediato: aprire la dashboard, guardare il grafico dell’NRR, notare che la linea scende, e scrivere un report che dice «l’NRR è calato, dobbiamo migliorare la retention». Questa non è un’analisi. È una descrizione.

L’approccio da first principles applica il framework:

  • Decisione: dobbiamo decidere se investire in un team di customer success dedicato alle PMI o se il calo è concentrato su un segmento dove l’intervento è diverso.
  • Ipotesi: il calo dell’NRR è concentrato sui clienti acquisiti nel Q3 dell’anno scorso (la coorte di 12 mesi fa), che stanno rinnovando ora con contratti più piccoli.
  • Misura: NRR scomposto per coorte di acquisizione, per tier (Enterprise vs PMI) e per motivo di churn/contrazione (prezzo, funzionalità mancante, concorrente, inutilizzo).
  • Guardrail: la soddisfazione cliente (CSAT) non deve scendere sotto 4.0 durante l’analisi. Non posso chiedere ai customer success manager di passare ore a compilare cause di churn se questo riduce il tempo che dedicano ai clienti attivi.
  • Output: matrice 2×2 (urgenza × impatto) con le cause di contrazione, priorità di intervento, costo stimato del team dedicato e proiezione di impatto sull’NRR a 6 mesi.

Ora l’analisi ha direzione. Non serviranno due settimane e venti dashboard per arrivare a una raccomandazione. Forse l’analisi rivelerà che il calo non è nelle PMI ma negli enterprise, e che il problema non è il customer success ma una funzionalità mancante che un concorrente ha introdotto sei mesi fa. Il framework non ti dà la risposta. Ti dà la disciplina per trovarla.

Quando il first principles thinking è più difficile (e più necessario)

Ci sono tre situazioni in cui il pensiero per primi principi è insieme più faticoso e più prezioso:

Quando il dato contraddice la narrativa del management. Se il CEO è convinto che «il nostro prodotto è il migliore sul mercato» e la tua analisi mostra che i clienti se ne vanno per una funzionalità che il concorrente offre a metà prezzo, il Sistema 1 del CEO rigetterà l’evidenza. Il tuo compito non è addolcire il messaggio — è rendere l’evidenza così solida e tracciabile da essere inconfutabile.

Quando i dati sono rumorosi. Un segnale di +8% in una metrica con deviazione standard 15% non è un segnale. È rumore. Il Sistema 1 vede il +8% e lo interpreta come un trend. Il Sistema 2 calcola l’intervallo di confidenza e scopre che il risultato non è statisticamente distinguibile da zero.

Quando si è sotto pressione temporale. Il paradosso del first principles thinking è che sembra richiedere più tempo. Riempiere cinque blocchi di framework richiede dieci minuti. Saltarli e cominciare subito a guardare dati richiede zero minuti — ma porta a ore di esplorazione senza direzione, iterazioni con stakeholder che chiedono «e se guardassimo anche…», e un report finale che non risponde a nessuna decisione. Dieci minuti di framework all’inizio risparmiano ore di lavoro a valle.

Vale la pena notare un aspetto che distingue il pensiero per first principles dalla semplice «cautela analitica». La differenza non è nel rigore — entrambi lo richiedono — ma nel punto di partenza. L’approccio cauto chiede «cosa potrebbe andare storto?» e aggiunge controlli incrementalmente. Il first principles thinking chiede invece «cosa è vero indipendentemente dalle assunzioni che mi sono stato tramandato?» e ricostruisce da lì. Nel primo caso, lavori sul margine di un sistema che non hai messo in discussione. Nel secondo caso, metti in discussione il sistema stesso. Per un analista che opera in un’organizzazione, entrambi sono necessari: il first principles per non accettare premesse non verificate, la cautela analitica per non trascurare dettagli operativi che fanno fallire un’analisi perfetta nel ragionamento. Ma se devi scegliere da dove cominciare, comincia sempre dai primi principi. Perché una volta che hai ricostruito il problema da zero, puoi sempre aggiungere dettagli — ma se parti dai dettagli, potresti non accorgerti che la premessa era sbagliata fino a quando non è troppo tardi.

Problema reale

Il problema che questa lezione risolve è molto concreto: evitare che un’analisi nasca già orientata dalla prima spiegazione disponibile. Nel lavoro con i dati succede spesso. Un numero cambia, qualcuno propone una causa, il team cerca conferme e la dashboard diventa uno strumento per difendere una narrativa già scelta.

Il first principles thinking interrompe questo automatismo. Ti costringe a chiedere quale decisione stai supportando, quale ipotesi stai assumendo, quale metrica rappresenta davvero il fenomeno e quale controllo impedisce una lettura ingenua.

Modello concettuale

Il modello operativo è formato da cinque blocchi:

BloccoDomanda da chiarireOutput atteso
DecisioneCosa cambierà dopo l’analisi?Scelta esplicita, con owner e scadenza
IpotesiQuale meccanismo causale stai assumendo?Frase verificabile prima dei dati
MisuraQuale metrica rappresenta il fenomeno?Denominatore, segmento e finestra temporale
GuardrailCosa non deve peggiorare?Vincoli che proteggono dal falso successo
OutputCosa consegni allo stakeholder?Memo, raccomandazione o piano di monitoraggio

Formalizzazione rigorosa

Per applicare il metodo, scrivi i cinque blocchi prima di aprire il tool. Se non riesci a completarne uno, non compensare con più grafici: torna alla domanda. Una formalizzazione solida permette a un altro analista di leggere la tua logica, criticare le assunzioni e riprodurre il percorso decisionale.

La forma minima è questa: “Dobbiamo decidere se X entro Y. Assumiamo che A influenzi B perché C. Misuriamo M sul segmento S nella finestra W. Non accettiamo il risultato se peggiora G. Consegniamo O entro D”.

Esempio o caso studio

Se il Net Revenue Retention cala da 115% a 102%, il Sistema 1 dice: “abbiamo un problema di retention”. Il first principles thinking chiede: quale decisione dobbiamo prendere? Se la decisione è investire in customer success, allora la domanda corretta non è “perché cala l’NRR?”, ma “il calo è concentrato in coorti o segmenti dove customer success può cambiare il comportamento?”.

Questa differenza sembra sottile, ma cambia tutto: dati richiesti, segmentazione, guardrail e raccomandazione finale.

Lab / esercizio

Livello base

Prendi una metrica che controlli spesso e scrivi i cinque blocchi: decisione, ipotesi, misura, guardrail, output.

Livello intermedio

Applica le Cinque Perché a un’anomalia reale o simulata. Fermati solo quando arrivi a una causa che, se modificata, riduce la probabilità che il problema si ripeta.

Livello research-grade

Trasforma l’analisi in un decision memo: ipotesi iniziale, dati necessari, controlli, alternative escluse, raccomandazione e piano di monitoraggio.

Dataset e materiali consigliati

Usa una dashboard reale, un export CSV o un dataset sintetico con almeno una metrica temporale, un segmento e una variabile di outcome.

Errore tipico da evitare

L’errore più comune è confondere una descrizione accurata con una spiegazione. Dire “la retention è scesa del 30%” non spiega nulla. Il lavoro analitico comincia quando colleghi quel calo a un meccanismo verificabile e a una decisione concreta.

Riepilogo operativo

Il first principles thinking, nel lavoro analitico, è una disciplina in cinque passaggi, non quattro. Il quinto è spesso il più difficile:

  • Formula la decisione prima di aprire i dati. Se non sai cosa farai di diverso in base al risultato, non sei pronto per analizzare. Scrivilo in una frase: chi decide, cosa, entro quando.

  • Rendi esplicita l’ipotesi causale. Quale relazione tra causa ed effetto stai assumendo? Scrivila prima di guardare i numeri, così non la adatterai ai dati che vedi. È il principio che Judea Pearl chiama «ladder of causation»: prima la teoria, poi i dati, mai il contrario.

  • Definisci misura e guardrail. Metrica primaria con denominatore, segmento e finestra temporale esatti. Cosa non deve peggiorare mentre ottimizzi. Senza guardrail, ogni ottimizzazione è un potenziale disastro.

  • Applica le Cinque Perché a ogni anomalia. Un calo in una metrica non è mai la causa radice. Continua a chiedere «perché?» finché non arrivi a una condizione che, se modificata, impedisce al problema di ripresentarsi.

  • Verifica l’assunzione più banale per ultima. Il Mars Climate Orbiter è stato distrutto da un fattore di conversione. A volte il problema non è complesso: è ovvio ma nessuno lo ha guardato. Prima di cercare cause sofisticate, controlla che le unità di misura siano corrette, che il denominatore sia giusto, che la definizione non sia cambiata.

Questo è ciò che intendeva Feynman quando diceva che «il primo principio è che non devi ingannare te stesso — e tu sei la persona più facile da ingannare». Nel lavoro con i dati, l’inganno più frequente è scambiare la descrizione di un problema per la sua comprensione. Il first principles thinking è la disciplina che impedisce quell’inganno.

Quiz o checkpoint

[QUIZ]Hai capito il metodo del first principles thinking?3 domande

1.Qual è il primo passo del first principles thinking applicato ai dati?

2.Perché è pericoloso lavorare su dati aggregati troppo presto?

3.Cosa distrusse il Mars Climate Orbiter secondo la lezione?

0/3 risposte

Il punto da ricordare è semplice: un analista forte non parte dal dato disponibile, parte dalla decisione da migliorare.

La prossima volta che apri una dashboard, fermati trenta secondi. Scrivi decisione, ipotesi, metrica, guardrail e output. Se uno di questi blocchi manca, non hai ancora un’analisi: hai solo numeri in cerca di una storia.