Perché costruiamo prima il segnale, poi il prodotto

La statistica gira da anni: più del 50% delle startup fallisce nei primi tre anni. La metà di queste fallisce per la stessa ragione: "market need". Hanno costruito un prodotto che non serviva. Non perché l'idea fosse stupida — quasi mai lo è — ma perché hanno scelto di costruire prima, e di chiedere al mercato dopo. Quando il mercato risponde, è tardi.

Vibe Lab è il modo in cui evoseed costruisce le startup interne, e il servizio con cui aiutiamo i founder esterni a fare lo stesso. Si basa su un principio noioso ma efficace: prima si misura il segnale, poi si costruisce il prodotto. In quest'ordine, non a caso.

La trappola del codice precoce

Il founder tecnico ha una tentazione naturale: l'idea diventa codice in tre giorni. Il codice fa cose. Le cose si possono mostrare. La sensazione di progresso è immediata. Il problema è che il progresso percepito non è progresso reale: stai accumulando una codebase intorno a un'ipotesi che non hai ancora testato. Più la codebase cresce, più diventa costoso pivotare. Più diventa costoso pivotare, meno hai voglia di sentire che il mercato dice no.

La storia di OptiWize, che è il nostro primo prodotto, è il caso da manuale. Quando abbiamo iniziato — ormai più di quattro anni fa — la prima versione l'abbiamo scritta come Python script monolitico. Configurava cinque tipi di MikroTik. Era brutto, lento, e funzionava. Quel codice è morto dopo sei mesi: l'avevamo costruito per i casi che pensavamo fossero importanti. Quando abbiamo iniziato a far girare il sistema con utenti veri (un solo NOC, gentile), abbiamo scoperto che i casi che contavano erano altri. Tre dei cinque template sono finiti in cantina. Ne abbiamo aggiunti dodici nuovi.

Il framework Vibe Lab in 5 step

Step 1: idea → ipotesi di mercato (1 settimana)

Non scriviamo una riga di codice in questa fase. Definiamo l'ipotesi che vogliamo testare in modo che sia falsificabile: un'affermazione concreta su un mercato concreto. Niente "vogliamo migliorare la customer experience". Sì "i NOC dei piccoli ISP italiani spendono almeno 10 ore alla settimana in troubleshooting MikroTik di livello 1, e pagherebbero 200 euro al mese per ridurre quel tempo del 50%". L'ipotesi è specifica, misurabile, e — soprattutto — può essere smentita.

Step 2: test del segnale (1-2 settimane)

Qui usiamo il pretotyping nel senso classico di Alberto Savoia: prima del prototipo, costruisci uno strumento per misurare se l'interesse è reale. Un landing page con CTA "prenota una call". Una campagna LinkedIn con un offerto chiaro. Una sequenza di outreach personalizzato a 50 contatti dell'ICP. Il segnale è binario: o le persone si scomodano (prenotano, rispondono, cliccano, parlano), o non lo fanno. Se la risposta è no, l'ipotesi è sbagliata e si torna allo Step 1 — senza aver scritto codice.

Step 3: MVP focalizzato (4-8 settimane)

Solo a questo punto si scrive codice. La parola MVP è abusata: per noi vuol dire la versione più piccola possibile che produce davvero valore per i 5+ utenti che hanno detto sì. Niente account, niente settings, niente dashboard prima del valore. Se il valore è "riduci il tempo di troubleshooting", l'MVP è uno strumento che riduce il tempo di troubleshooting, anche se gira su SSH e ha tre comandi in croce. Niente fronzoli.

Step 4: mercato vero (2-4 settimane)

L'MVP gira con i primi utenti veri. Misuriamo tre cose: usano davvero il prodotto, in che frequenza, e cosa succede quando smettono di usarlo. Le interviste qualitative qui sono d'oro. Una domanda che usiamo sempre: "se domani non ci fossimo più, cosa fareste?". La risposta "tornerei a fare tutto a mano" vale dieci volte di più di "trovarei un'alternativa". La prima è product-market fit potenziale; la seconda è commodity.

Step 5: decisione (1 settimana)

Tre opzioni esplicite. Scaliamo: aumentiamo investimento, aggiungiamo team, prepariamo il GTM serio. Fermiamo: la metrica del PMF non è lì, e nessun aggiustamento ragionevole la sposterà. Spin-off: c'è valore ma non per noi — il prodotto va in mano a un altro team, o open-sourced, o venduto. L'importante è che la decisione sia esplicita, datata, e basata su numeri che abbiamo concordato all'inizio.

Caso concreto: come OptiWize è diventato ARIA

ARIA, il nostro AI NOC Engineer, è nato come spin-off interno di OptiWize. La domanda era: vale la pena costruire un'interfaccia conversazionale sopra il template engine di OptiWize, oppure rimaniamo solo con dashboard e API? L'ipotesi era specifica: i NOC dei nostri clienti spendono almeno il 40% del tempo in operazioni che sono riconducibili a 20 macro-pattern di troubleshooting, e un'interfaccia conversazionale può ridurre quel tempo del 70%.

Test del segnale: abbiamo mostrato un mockup live ai NOC di tre clienti, in interviste guidate da uno script. Tutti e tre hanno chiesto "quando posso averla?". Due dei tre hanno offerto di partecipare a un programma pilota a pagamento immediato. Quel signal è quello che ha sbloccato l'investimento di 4 mesi di sviluppo. Se non fosse arrivato, non avremmo costruito ARIA — o l'avremmo costruita molto diversa.

MVP costruito in 6 settimane. Architettura agentica template-driven con catalogo di playbook. Niente UI fancy, solo una chat. Provato per 8 settimane con i NOC pilota. Risultato: tempo medio di prima diagnosi sceso da 47 a meno di 5 minuti per i casi coperti. La decisione del passo finale è stata facile: scaliamo. Oggi ARIA è un prodotto separato (runaria.ai), con il suo team, il suo pricing, e una pipeline commerciale a parte.

Cinque domande che usiamo all'inizio di ogni Vibe Lab

1. Chi è esattamente l'utente? Non "le aziende", non "i CIO". Una persona reale, in un contesto reale, con un nome ipotetico e un calendario tipico. Se non riuscite a descriverli in due righe, l'ipotesi è troppo astratta.
2. Cosa fanno oggi al posto vostro? Tutte le idee nuove competono con uno status quo. Capire lo status quo è capire perché qualcuno dovrebbe cambiare. Se la risposta è "niente, non hanno questo problema", potreste essere nel posto sbagliato.
3. Qual è il segnale binario che testerà l'ipotesi? Non "valuteremo l'interesse". Sì "se almeno 5 persone su 50 prenotano una call entro 10 giorni, è un sì". Concordate il numero all'inizio, prima di partire. È difficile baronare i propri numeri quando sono scritti su un Notion datato.
4. Quanto siete disposti a perdere? Vibe Lab è un investimento. Se è 8 settimane di un fondatore part-time, ok. Se è un round seed da 500k, ok. Quello che non funziona è non sapere quanto. La risposta deve essere un numero, espresso prima.
5. Cosa fa scattare lo stop? Definite criteri di kill prima di iniziare. "Se a 4 settimane non abbiamo 5 interviste vere, fermiamo." Senza criteri di kill, l'ipotesi muore lentamente per inerzia — la peggiore delle morti.

Per chi è (e per chi non è)

Vibe Lab funziona meglio per chi ha un'idea con un'ipotesi specifica e un budget di tempo limitato. Non funziona per chi cerca "validare in generale che la mia idea ha senso": è un atteggiamento che ci farebbe sprecare quattro settimane a parlare di tutto e niente. Non funziona neanche per chi ha già scritto 30.000 righe di codice: a quel punto il sunk cost è troppo alto per applicare il framework onestamente.

Funziona benissimo per: founder tecnici che hanno un'intuizione su un settore verticale e vogliono testarla, team interni di aziende mid-market che vogliono validare un nuovo prodotto/feature prima di committare 6 mesi di sviluppo, manager con budget limitato e una vision specifica. Per loro, abbiamo costruito Vibe Lab.

Se vi riconoscete, la prima call è di assessment, dura 45 minuti, è gratuita, e ne usciamo con un'indicazione concreta — anche se non lavoreremo insieme.