Dall'Idea al Primo Partner: OnStage
Novembre 2024. Avevo l'idea, ma un'idea senza validazione è solo un'opinione. Sapevo che per costruire qualcosa di utile dovevo parlare con chi organizza eventi davvero.
La fortuna ha voluto che conoscessi già qualcuno: l'associazione culturale OnStage, un gruppo di appassionati di teatro e musica che organizza eventi nel Salento da anni. Serate, spettacoli, rassegne. Decine di eventi all'anno.
Cosa Troverai in Questo Articolo
- Come ho trovato il primo partner per validare l'idea
- La metodologia agile applicata a un side project
- I requisiti reali emersi dalla collaborazione
- Il primo sprint e le prime funzionalità
Perché OnStage Era il Partner Perfetto
OnStage non era un'associazione qualsiasi. Erano il caso d'uso ideale per Play the Event.
Il Loro Profilo
- 15-20 eventi all'anno
- Dai 30 ai 200 partecipanti
- Team di 8 organizzatori
- Budget limitato ma esigenze reali
- Nessuno strumento dedicato
I Loro Pain Points
- Gestione RSVP via WhatsApp
- Liste partecipanti su fogli Excel
- Comunicazioni frammentate
- Nessun storico degli eventi
- Difficoltà nel tracciare i pagamenti
Ho proposto loro un accordo semplice: mi fate da beta tester, io vi costruisco lo strumento gratis. Loro avrebbero avuto una piattaforma su misura. Io avrei avuto feedback reale da utenti veri.
"Finalmente qualcuno che capisce che non siamo un'azienda ma
nemmeno una festa di compleanno. Siamo nel mezzo, e nessuno
pensa a noi."
— Marco, presidente OnStage
Metodologia Agile per un Side Project
Non potevo dedicare 40 ore a settimana a Play the Event. Era un side project, sviluppato la sera e nei weekend. Ma questo non significava rinunciare a un approccio strutturato.
Ho adattato Scrum alle mie esigenze: sprint di 2 settimane, backlog condiviso con OnStage, demo ogni fine sprint.
STRUTTURA SPRINT (2 settimane)
LUNEDÌ SERA (1h)
├── Sprint Planning
├── Review backlog con OnStage (via call)
└── Selezione user stories per lo sprint
MARTEDÌ-DOMENICA
├── Sviluppo (2-3h/giorno quando possibile)
├── Commit frequenti
└── Deploy su ambiente di staging
LUNEDÌ SUCCESSIVO (1h)
├── Sprint Review con OnStage
├── Demo delle nuove funzionalità
├── Raccolta feedback
└── Sprint Retrospective (cosa migliorare)
ARTEFATTI
├── Product Backlog (Notion)
├── Sprint Board (Notion Kanban)
├── User Stories con acceptance criteria
└── Definition of Done chiara
Il Primo Incontro: Raccolta Requisiti
Il primo incontro con OnStage è stato illuminante. Mi sono presentato con un'idea vaga di "piattaforma per eventi". Sono uscito con una lista di problemi concreti da risolvere.
Come Ho Condotto l'Incontro
Non ho parlato di tecnologia. Non ho mostrato mockup. Ho fatto una cosa sola: ho ascoltato.
Le Domande che Ho Posto
- "Raccontatemi l'ultimo evento che avete organizzato." Passo per passo, dalla prima idea alla fine.
- "Qual è stata la parte più frustrante?" Cosa vi ha fatto perdere più tempo?
- "Se poteste cambiare una sola cosa del processo, quale sarebbe?"
- "Quali strumenti usate oggi?" Perché proprio quelli?
I Problemi Emersi
Problema #1: Il Caos delle Conferme
Per ogni evento, ricevevano conferme via WhatsApp, email, messaggi Instagram, e a voce. Nessun punto centralizzato. Ogni volta dovevano ricostruire manualmente la lista partecipanti.
Problema #2: I Pagamenti Fantasma
Gli eventi a pagamento erano un incubo. "Chi ha pagato? Chi deve ancora pagare? Quanto manca per coprire i costi?" Tutto su un foglio Excel che nessuno aggiornava in tempo reale.
Problema #3: La Comunicazione Frammentata
Dovevano inviare aggiornamenti a tutti i partecipanti? Significava mandare lo stesso messaggio su 3 gruppi WhatsApp diversi, più email a chi non era nei gruppi.
Problema #4: Zero Storico
"Quante persone sono venute all'evento dell'anno scorso?" Nessuno lo sapeva. Ogni evento ripartiva da zero, senza dati storici su cui basarsi.
Dal Problema alle User Stories
Dopo l'incontro, ho tradotto i problemi in user stories seguendo il formato standard.
US-001: CREAZIONE EVENTO
Come organizzatore
Voglio creare un evento con data, luogo e descrizione
Per avere un punto centrale di riferimento
Acceptance Criteria:
- Form con campi: nome, data, ora, luogo, descrizione
- Generazione automatica di un link condivisibile
- Salvataggio in database
US-002: RSVP SEMPLIFICATO
Come partecipante
Voglio confermare la mia presenza con un click
Per non dover scrivere messaggi o email
Acceptance Criteria:
- Pagina pubblica accessibile senza login
- Bottoni: Parteciperò / Non parteciperò / Forse
- Campo note opzionale (es. allergie, +1)
US-003: LISTA PARTECIPANTI REAL-TIME
Come organizzatore
Voglio vedere chi ha confermato in tempo reale
Per sapere sempre quante persone aspettarmi
Acceptance Criteria:
- Lista aggiornata automaticamente
- Filtri: confermati, rifiutati, in attesa
- Export in CSV/Excel
US-004: NOTIFICHE CENTRALIZZATE
Come organizzatore
Voglio inviare un messaggio a tutti i partecipanti
Per non dover usare 5 canali diversi
Acceptance Criteria:
- Invio email a tutti i confermati
- Template personalizzabile
- Storico messaggi inviati
US-005: GESTIONE PAGAMENTI (v2)
Come organizzatore
Voglio tracciare chi ha pagato e chi no
Per avere sempre il quadro finanziario chiaro
Acceptance Criteria:
- Campo "pagato sì/no" per ogni partecipante
- Totale incassato vs totale atteso
- Promemoria automatico a chi non ha pagato
Sprint 1: L'MVP
Con il backlog pronto, ho pianificato il primo sprint. L'obiettivo era chiaro: costruire un MVP funzionante che OnStage potesse usare per il loro prossimo evento.
SPRINT 1 (2 settimane)
Goal: "Un organizzatore può creare un evento e ricevere conferme"
USER STORIES SELEZIONATE:
├── US-001: Creazione evento (5 punti)
├── US-002: RSVP semplificato (8 punti)
└── US-003: Lista partecipanti (5 punti)
CAPACITY: 18 punti (realistici per un side project)
COMMITMENT: 18 punti
TECHNICAL TASKS:
├── Setup progetto (Next.js + Supabase)
├── Modello dati eventi e partecipanti
├── API REST per CRUD eventi
├── Pagina creazione evento
├── Pagina pubblica RSVP
├── Dashboard lista partecipanti
└── Deploy su Vercel
La Prima Demo
Due settimane dopo, avevo qualcosa da mostrare. Non era perfetto. L'UI era minimal. Ma funzionava.
Ho fatto la demo a OnStage via videocall. Le loro reazioni mi hanno detto tutto quello che dovevo sapere.
"Aspetta, posso semplicemente mandare questo link e la gente
clicca per confermare? Senza che debbano scaricare nulla?"
— Elena, organizzatrice OnStage
"E la lista si aggiorna da sola? Non devo più chiedere
'chi aveva detto che veniva?' ogni volta?"
— Marco, presidente OnStage
Feedback dallo Sprint Review
Cosa Funzionava
- Link condivisibile senza login
- RSVP con un solo click
- Lista partecipanti in tempo reale
- Interfaccia semplice
Cosa Mancava
- Campo per +1 (accompagnatori)
- Note visibili all'organizzatore
- Reminder per chi non ha risposto
- Versione mobile migliorata
L'Approccio Iterativo in Azione
Questo è il bello dell'approccio agile: non ho dovuto indovinare cosa serviva. Ho costruito, mostrato, raccolto feedback, migliorato. Ogni sprint portava valore reale.
SPRINT 1: Creazione evento + RSVP base + Lista partecipanti
→ OnStage lo usa per "Serata Jazz" (45 partecipanti)
SPRINT 2: Campo +1 + Note partecipanti + Reminder email
→ OnStage lo usa per "Teatro sotto le Stelle" (120 partecipanti)
SPRINT 3: Gestione pagamenti base + Export CSV + Mobile responsive
→ OnStage lo usa per "Concerto di Natale" (200 partecipanti)
METRICHE DOPO 6 SETTIMANE:
├── 3 eventi gestiti
├── 365 partecipanti totali
├── 0 email "chi viene?" inviate
├── 100% delle conferme tracciate
└── Tempo risparmiato: ~10 ore per evento
Cosa Ho Imparato
Lezioni dalla Collaborazione con OnStage
- Un partner reale vale più di 100 interviste: Vedere qualcuno usare il tuo prodotto per un evento vero ti insegna cose che nessun sondaggio può dirti.
- Agile funziona anche per i side project: Sprint brevi, feedback frequente, iterazioni rapide. Non serve un team di 10 persone.
- Inizia con il problema più doloroso: Per OnStage era la gestione RSVP. Ho risolto quello prima di tutto il resto.
- La semplicità è una feature: Ogni volta che aggiungevo complessità, il feedback era "ma non si può fare più semplice?"
- Il valore si misura in tempo risparmiato: 10 ore risparmiate per evento = valore tangibile e misurabile.
Nel Prossimo Articolo
Con un MVP validato e un partner soddisfatto, era il momento di pensare in grande. Come scalare da un'associazione a centinaia di organizzatori?
Nel prossimo articolo parlerò delle scelte architetturali: perché ho scelto quella tecnologia, come ho strutturato il database per supportare la crescita, e le decisioni che definiranno il futuro di Play the Event.
Punti Chiave di Questo Articolo
- Trova un partner reale disposto a usare il tuo prodotto
- Usa metodologia agile anche per i side project
- Raccogli requisiti ascoltando, non proponendo soluzioni
- Costruisci, mostra, raccogli feedback, itera
- Misura il valore in tempo risparmiato agli utenti







