Playbook end-to-end per lo sviluppo di prodotti IoT – Fase 0 – Concetto e fattibilità
Clicca per il capitolo precedente: Introduzione
“Aspetta — ma dovremmo proprio costruirlo, questo aggeggio?”
La maggior parte dei prodotti IoT falliti era persa prima ancora che fosse disegnato il primo schematico: nessuno aveva verificato se l’idea valesse la pena di essere costruita. La Fase 0 esiste per rispondere a quella domanda con evidenze invece che con entusiasmo. Immaginatevi al bordo di una giungla fitta, machete alla mano. Potete sentire che potrebbe esserci un tesoro oltre le liane — voci di clienti riconoscenti, slide deck scintillanti per gli investitori, forse persino il mitico Series B. Ma potete anche percepire le pozze di fango e gli insetti affamati pronti a rosicchiare la vostra runway. Uno sprint disciplinato di Concetto e fattibilità vi dice se la caccia al tesoro giustifica l’aprirsi un sentiero a colpi di machete. I team di fretta spesso saltano questo passo (“Iniziamo a fare sprint e basta!”). Non fatelo. Pochi giorni concentrati qui risparmiano mesi di rilavorazione, dissolvono la nebbia dei wishful thinking e danno al team un grido di battaglia che sopravvive alle lunghe notti di debug del firmware alle 2 di notte.
0.1 Perché questo capitolo conta così tanto?
Perché ogni barra di Gantt, ticket Jira e ordine d’acquisto a valle eredita la sua ragione d’esistere dalla decisione che prendete qui. Se vi lanciate nello schematic capture o nel wireframing dell’app mobile senza un “Perché” chiaro e basato su evidenze, state noleggiando un bulldozer prima di sapere se vi serve un’aiuola o un grattacielo. I team che saltano la fattibilità finiscono anche per proporre sogni fumosi agli stakeholder: “È come un Fitbit, ma per gatti, e mina anche criptovalute!” Divertente — finché la Finanza non chiede il costo del Bluetooth mesh su un collare che Fuffy adora masticare.
0.2 Le quattro conversazioni che dovete fare
1. Intervista sul pain point
Trovate un essere umano reale (o diversi) che vive il problema ogni giorno. Ascoltate più di quanto parlate. Se non usano espressioni colorite o sospirano pesantemente nel descrivere il dolore, probabilmente il problema non è abbastanza acuto da giustificare il burn rate di una startup hardware.
Esempio: Un facility manager confessa di perdere migliaia di euro al mese perché nessuno si accorge quando il congelatore industriale sale oltre i –15 °C alle 3 di notte.
2. Vision statement
Distillate ciò che avete sentito in una frase che stia su una tazza da caffè. “Diamo ai facility manager un preavviso sui guasti delle apparecchiature — prima che il gelato si sciolga.” Se la frase sembra molle o cerca di piacere a tutti, continuate a sfoltirla.
3. User journey ad alto livello
Tracciate uno storyboard semplice: il manager riceve una notifica push, tocca per aprire un grafico di andamento, invia la manutenzione e si gode un tranquillo girello alla cannella perché la catastrofe è stata scongiurata. Ancora niente pixel-pushing sulla UI — pensate a una striscia a fumetti, non a mock-up ad alta fedeltà.
4. Controllo di sanità del mercato
Aprite un foglio di calcolo (sì, quella temuta griglia vuota) e rispondete: Quanto spesso si verifica questo dolore? Quante persone ce l’hanno? Quanto pagherebbe ciascuna per alleviarlo? Report di settore, prezzi degli SKU dei concorrenti su Digi-Key e un rapido conteggio su LinkedIn dei titoli di lavoro “Facilities Manager” nella vostra regione target vi porteranno a un’accuratezza rispettabile. I PM alle prime armi si preoccupano dei decimali; i veterani si preoccupano degli ordini di grandezza.
0.3 Esperimenti di fattibilità rapidi
Lo sviluppo hardware può sembrare glaciale, ma potete comunque generare evidenze convincenti in pochi giorni:
- Smoke test di portata – Prendete un dev-kit BLE commerciale, infilatelo in un congelatore di acciaio inox, fate ping dal corridoio, misurate l’RSSI. Se il segnale muore a due metri, avete appena evitato un errore di connettività prima di ordinare PCB custom.
- Verifica di verità del sensore – Prendete in prestito una sonda di temperatura calibrata, fissatela accanto al vostro sensore digitale candidato e registrate 12 ore di dati. Il sensore economico deriva di 3 °C ogni volta che parte il compressore? Scartatelo subito.
- Demo per gli stakeholder – Convogliate i dati del dev-kit in una dashboard cloud gratuita (ThingSpeak, Adafruit IO) e mostratela al vostro facility manager. Se chiede: “Posso comprarlo domani?”, siete sulla pista giusta. Se alza le spalle, rifinite o pivotate.
0.4 Artefatti da portare a casa (niente di sofisticato)
- Vision one-pager – Elevator pitch, utente target, dolore viscerale, risultato proposto.
- Storyboard a tre riquadri – Identificate trigger, azione ed esito. Abbozzato va bene; foto da telefono di post-it valgono.
- Tabella TAM/SAM/SOM – Stime di mercato Total, Serviceable, Obtainable. Dieci righe bastano. Includete il vostro punteggio di confidenza e i link alle fonti.
- Memo dello sprint di fattibilità – Una pagina: Ipotesi → Esperimento → Dati → Verdetto → Prossimo passo. Leggibile in tre minuti dal vostro VP.
Questi artefatti non sono cerimonia fine a se stessa. Agiscono come fari di allineamento: quando il marketing vuole inseguire un’altra persona, o l’ingegneria propone un’esotica radio mmWave, potete sventolare il one-pager e chiedere: “Questo serve la nostra storia del facility manager salvatore di congelatori?”
0.5 Il costo di saltare
Ancora tentati di dichiarare “costruiscilo e arriveranno”? Un racconto ammonitore fatto sul retro di una busta: un team che ho seguito ha speso 60.000 € in revisioni di PCB prima di accorgersi che gli ospedali — il loro mercato target — non ammettono radio a 2,4 GHz nelle sale di risonanza magnetica. Uno smoke test di fattibilità di due ore con un analizzatore di spettro in prestito avrebbe risparmiato otto mesi e le dimissioni di un ingegnere.
0.6 Costruire il rituale del Go/No-Go
Gli esseri umani — specialmente gli ingegneri alimentati dall’euforia dei LED lampeggianti — odiano dire “No”. Istituzionalizzatelo. Mettete un invito in calendario per una Feasibility Review esattamente due settimane dopo il kickoff del progetto. Invitate una persona ciascuna da business, ingegneria, qualità e customer success. Presentate i vostri quattro artefatti, fate demo di eventuali prototipi rapidi e chiudete la riunione con un voto obbligato: Go o No-Go (il pivot conta come No-Go). Vince la maggioranza. Registrate la decisione nella vostra wiki con timestamp ed elenco dei partecipanti. Il voi-futuro ringrazierà il voi-passato quando auditor o investitori chiederanno: “Perché avete scommesso tutto su LoRa anziché NB-IoT?”
0.7 Trappole comuni per i principianti e come evitarle
| Trappola | Perché fa male | Antidoto |
|---|---|---|
| Prima la soluzione, poi il problema – Innamorarsi di tecnologia figa | Finite per andare a caccia di un mercato | Scrivete il pain statement prima di toccare il firmware del dev-kit |
| Paralisi da analisi – Settimane di fogli di calcolo | Lo slancio muore, il morale cala | Date un time-box di giorni a ogni task di ricerca; condividete apertamente numeri imperfetti |
| Domande suggestive – “Non adoreresti un cloud per congelatori?” | Gli utenti dicono sì per cortesia → Falsa validazione | Chiedete il costo del workaround di oggi; osservate l’emozione reale |
| Ignorare i vincoli nascosti – Divieti normativi, codici edilizi | Le riprogettazioni a sorpresa costano milioni | Telefonate a un veterano del settore; chiedete “Cosa ti ha colto di sorpresa l’ultima volta?” |
0.8 Mini caso di studio: lo Smart-Freezer Sprint di una settimana
Lunedì: Due PM intervistano tre facility manager, confermano che il deterioramento del congelatore costa 10 k€ per incidente.
Martedì: L’hardware lead monta un sensore di temperatura I²C da 12 $ su una dev board Wio-Link, trasmette JSON ad Adafruit IO.
Mercoledì: Lo stagista cloud costruisce un pannello Grafana e un alert SMS via Twilio.
Giovedì: I PM inviano un video demo agli stakeholder; il CFO sbotta: “Se funziona, risparmieremo 1 M€ all’anno su tutti i siti.”
Venerdì: La Feasibility Review vota Go, ma impone di verificare il backhaul cellulare dove il Wi-Fi è instabile.
Spesa totale: 300 € tra componenti e pizza. Chiarezza guadagnata: non ha prezzo.
0.9 La checklist del Capitolo 0 (stampate, annotate, attaccate sopra il monitor)
- Problem statement catturato in una frase brutalmente corta.
- Almeno un’intervista con un sofferente del problema, citazioni registrate alla lettera.
- Vision statement condivisa su Slack, reazioni raccolte (se nessuno reagisce, riscrivete).
- Due o tre schizzi di user journey fotografati e caricati.
- Numeri di sanità del mercato iniziali in un foglio di calcolo, etichettati con link alle fonti.
- Un esperimento di fattibilità eseguito, dati in grafico.
- Blocco in calendario per la review Go/No-Go fatto; arbitro neutrale invitato.
- Decisione registrata, link incollato alla radice del repository del progetto.
- Se Go → rischi ad alto livello e owner del capitolo successivo assegnati.
- Se No-Go → una nota di ringraziamento inviata al team; lezioni apprese documentate.
Attaccate questa checklist al coperchio del laptop. La prossima volta che siete tentati di scattare in avanti perché “il PCB house ha una promozione che scade stanotte”, guardate la casella n. 1. Se non riuscite a recitare il problem statement in cinque secondi, non siete pronti a ordinare rame.
0.10 Per concludere
Concetto e fattibilità è il capitolo più piccolo per tempo di calendario — ma il più grande per impatto. Trattatelo come il prologo di un buon romanzo: saltatelo e il resto della trama sembra confuso e vuoto. Investite qui un impulso concentrato di energia, e ogni capitolo successivo andrà al suo posto con un clic. I vostri ingegneri vi ringrazieranno, i vostri investitori annuiranno a un’articolazione nitida del valore, e i vostri utenti riceveranno alla fine un prodotto che salva davvero la loro pelle (o il loro gelato).
Poi passate al Capitolo 1, dove trasformiamo aspirazioni sfumate in System Requirements ben definiti — così chiari che persino il vostro futuro auditor di conformità accennerà un sorriso.