Case Study: Philosophical Thinking and Business Decision

Questo caso chiude il modulo e fa una cosa precisa: prende i concetti filosofici visti finora e li trasforma in una scelta aziendale concreta. Non serve a citare autori per fare bella figura, ma a usare causalità, falsificabilità, bias e responsabilità per rendere una decisione difendibile davanti a chi dovrà conviverci.

La stanza dove si decide

In azienda capita spesso questo. Un comitato deve scegliere se tagliare il prezzo, rivedere l’onboarding o aumentare il budget marketing. Ogni reparto arriva con dati plausibili, ma nessuno mette sul tavolo cosa conti come evidenza valida, quali ipotesi siano davvero falsificabili e quali conseguenze restino fuori dal modello. Il caso serve proprio a riconoscere quando un dato sostiene una decisione e quando invece nasconde assunzioni comode, bias o una causalità fragile. L’obiettivo è chiudere con una scelta consapevole, non con un’altra riunione.

Dalla domanda alla scelta

Una decisione regge quando attraversa per intero un percorso preciso: si parte dall’osservazione, si rende esplicita l’assunzione, si costruisce un modello, si valuta l’evidenza e solo allora si decide. Saltare un passaggio produce analisi fragili, anche quando sembrano eleganti.

flowchart LR
    A["Observation"]
    B["Assumption"]
    C["Model"]
    D["Evidence"]
    E["Decision"]
    A --> B
    B --> C
    C --> D
    D --> E

Le stesse tappe si possono leggere come domande operative, ciascuna con un esito da fissare prima di andare avanti.

Step	Guiding question	Expected output
Framing	Which decision needs to change?	A concrete choice, not a curiosity
Measure	Which signal represents the phenomenon?	Metric, source, and granularity
Comparison	Compared to which baseline do I interpret the result?	Benchmark or plausible counterfactual
Action	What do I do if the signal exceeds the threshold?	Decision, owner, and next check

Gli elementi del ragionamento

Conviene nominare quattro elementi prima di entrare nel merito, così la discussione non scivola sulle opinioni.

Element	Operational Definition
Unit	Observation, hypothesis, variable, causal mechanism or evidence criterion
Signal	Strength of evidence, causal coherence, robustness of assumptions, cost of decision error
Baseline	Alternative explanation, counterfactual, comparable group or no-intervention scenario
Decision	Accept, reject, or reformulate an explanation before applying it in business

Una misura vale qualcosa solo se riduce l’incertezza su una decisione specifica. Se non cambia nessuna scelta serve come documentazione, e se cambia una scelta senza controlli introduce rischio.

Caso pratico: il programma fedeltà di QuickBite

QuickBite ha 3 milioni di utenti attivi in 12 città europee e sta valutando un programma fedeltà per alzare la retention. Le posizioni in stanza sono diverse: il CEO spinge per investire subito, il CFO è scettico, il Product Head chiede test più rigorosi. Il framework filosofico del modulo serve a mediare tra queste spinte senza appiattirle.

Aristotele entra con le quattro cause e costringe a separare il dato grezzo, la distribuzione dell’effetto, il meccanismo causale e l’obiettivo reale dietro la retention. Hume ricorda il problema dell’induzione: un test limitato non garantisce che lo stesso risultato regga su scala più ampia. Popper aggiunge un vincolo netto, e cioè che l’ipotesi vada formulata in modo falsificabile, con test più estesi e controllati. Pearl porta il DAG e aiuta a smascherare confondenti come il novelty effect e la specificità geografica delle prime città. Kuhn, infine, riconosce che CEO, CFO e Product Head ragionano da paradigmi diversi e propone una mediazione pragmatica invece di una vittoria di principio. La raccomandazione che ne esce è investire 5 milioni in un test più ampio, con criteri chiari fissati in anticipo per scalare o abbandonare.

Provare il metodo su una decisione vera

Per fissare il ragionamento conviene applicarlo a una decisione reale collegata al caso. Descrivi in poche righe obiettivo, metrica primaria, baseline, rischio principale e azione prevista. Poi costruisci una tabella con almeno tre segmenti o scenari, indicando per ciascuno il segnale osservato, una spiegazione alternativa plausibile e il controllo necessario prima di crederci. Chi vuole andare più a fondo può disegnare un piano di validazione completo: ipotesi, dati necessari, criteri di esclusione, soglia decisionale, controllo successivo alla decisione e le condizioni che lo farebbero cambiare idea.

Se mancano dati reali, basta un dataset sintetico con almeno 200 righe e colonne per tempo, segmento, outcome ed esposizione. Sono materiali sufficienti per esercitarsi su case study decisionali, metriche di prodotto, esiti di esperimenti e DAG semplici.

L’errore che rende il caso inutile

Il rischio è trattare questo caso come una definizione da ricordare invece che come un protocollo da usare. Presentare metriche senza baseline, grafici senza ipotesi o raccomandazioni che ignorano il costo dell’errore porta a decisioni fragili, per quanto ben presentate.

Un controllo utile è domandarsi: se questo risultato fosse falso o instabile, quale decisione sbaglierei? Se la risposta non arriva subito, il metodo è rimasto sulla carta. Le stesse domande funzionano come verifica finale prima di portare una raccomandazione: qual è la decisione concreta da migliorare, quale baseline rende leggibile il risultato, quale assunzione ne cambierebbe la conclusione se fosse sbagliata e quale controllo minimo mettere prima di esporsi.

Operational Summary

Questo caso collega concetto, dato e decisione in modo operativo. Si parte da un problema reale, si formalizza il segnale, si cerca una baseline credibile, si costruisce un esempio e si chiude con un controllo pratico. È così che la conoscenza diventa competenza capace di guidare scelte sotto incertezza.