Una decina d’anni fa vincemmo un premio per fare il prototipo di un servizio di bike sharing peer-to-peer di nostra ideazione, basato sulla condivisione da parte degli utenti delle loro seconde bici abbandonate in cantina. Funzionava così: attraverso un dispositivo (che conteneva l’equivalente tecnologico di uno smartphone e un locker), assicurato al telaio, qualsiasi bicicletta poteva comunicare con il gestionale ed entrare nel servizio. Zero bici progettate ad hoc, zero rastrelliere dedicate, solo un dispositivo. Oggi una banalità, ieri un po’ meno. Usammo tutti i soldi del premio per fare il prototipo tecnologico: mesi di lavoro e ne venne fuori un accrocchio di schede Arduino, prima di scoprire che sul mercato russo si trovavano scatole nere per camion siberiani che facevano al caso nostro. Fatto questo, ci trovammo senza più risorse e non avevamo fatto il prototipo più importante: quello che ci avrebbe permesso di verificare i presupposti più spinosi del servizio. Ma queste persone ci daranno le loro bici? Se ne priveranno, pur se non le usano? Non aver verificato questa ipotesi, anzi averla trattata come tesi, portò il progetto al vicolo cieco. Oppure, se vogliamo, lo condannò a dormire in cantina insieme alle bici.
È affascinante pensare che dentro la parola ipotesi c’è la parola tesi. Fare un prototipo, verificare la fattibilità anzitutto relazionale di un progetto, significa dire cosa stiamo dando per scontato nei confronti dell’utenza. Snidare le ipotesi che si nascondono nelle nostre tesi. Metterle alla prova, falsificarle, avrebbe detto Karl Popper. Ogni progetto si dovrebbe basare su una domanda ipotetica-deduttiva: qual è quella cosa, del mio progetto, che è suscettibile di essere smentita? Si dice spesso che non bisogna innamorarsi delle idee. Dal mio punto di vista, non bisogna innamorarsi delle tesi.