Modello · Software e digitale

Primo rilascio di un prodotto SaaS

Da un'idea al primo rilascio di un SaaS: interviste, perimetro MoSCoW, architettura multi-tenant, quattro sprint, beta con clienti veri, lancio.

16
settimane di piano
5
fasi: le liste dello Space
46
task con stime e dipendenze, 8 milestone

A chi serve

Il lavoro, com'è davvero.

Startup e software house che portano un prodotto in abbonamento dall'idea al primo rilascio a pagamento, con la commessa a tempo: scoperta con i clienti, perimetro stretto, sprint di due settimane, beta, fatture elettroniche e lancio.

Con «Usa questo modello» nasce lo Space «Primo rilascio SaaS» nel tuo workspace, con le date dal giorno che scegli: liste e stati, task con stime e dipendenze, milestone, rischi, pagine dei documenti e, se indichi il cliente, la commessa.

Lo Space «Primo rilascio SaaS» in KeenHour: il Gantt del modelloLo Space «Primo rilascio SaaS» in KeenHour: il Gantt del modello

Le fasi

  1. Scoperta

    settimane 1–3
    • Incarico firmato
    • Workshop di avvio: problema, clienti, modello di ricavoDopo «Incarico firmato».
    • Interviste a dieci potenziali clientiDopo «Workshop di avvio: problema, clienti, modello di ricavo».
    • Concorrenti, alternative e prezzi di mercatoDopo «Workshop di avvio: problema, clienti, modello di ricavo».
    • Vincoli tecnici, normativi e di budgetDopo «Workshop di avvio: problema, clienti, modello di ricavo».
    • Perimetro del primo rilascio: che cosa entra e che cosa noDopo «Interviste a dieci potenziali clienti», «Concorrenti, alternative e prezzi di mercato», «Vincoli tecnici, normativi e di budget».
    • Metriche di successo della beta e del lancioDopo «Interviste a dieci potenziali clienti».
    • Perimetro del primo rilascio approvatoDopo «Perimetro del primo rilascio: che cosa entra e che cosa no», «Metriche di successo della beta e del lancio».
  2. Progettazione

    settimane 3–6
    • Percorsi utente e mappa delle schermateDopo «Perimetro del primo rilascio approvato».
    • Architettura: stack, multi-tenant, hostingDopo «Perimetro del primo rilascio approvato».
    • Wireframe delle schermate del primo rilascioDopo «Percorsi utente e mappa delle schermate».
    • Modello dei datiDopo «Architettura: stack, multi-tenant, hosting».
    • Protezione dei dati fin dalla progettazioneDopo «Architettura: stack, multi-tenant, hosting».
    • Interfaccia e libreria di componentiDopo «Wireframe delle schermate del primo rilascio».
    • Backlog del primo rilascio, scritto e stimatoDopo «Wireframe delle schermate del primo rilascio», «Modello dei dati».
    • Backlog e architettura approvatiDopo «Backlog del primo rilascio, scritto e stimato», «Protezione dei dati fin dalla progettazione».
  3. Sviluppo

    settimane 4–15
    • Infrastruttura come codice, ambienti e rilascio continuoDopo «Architettura: stack, multi-tenant, hosting».
    • Registrazione, accesso, organizzazioni e invitiDopo «Backlog e architettura approvati», «Infrastruttura come codice, ambienti e rilascio continuo».
    • Il flusso principale, dall'inizio al risultatoDopo «Backlog e architettura approvati», «Infrastruttura come codice, ambienti e rilascio continuo».
    • Email transazionali: benvenuto, inviti, recupero della passwordDopo «Registrazione, accesso, organizzazioni e inviti».
    • Primo accesso guidato e dati di esempioDopo «Registrazione, accesso, organizzazioni e inviti».
    • Pannello interno per l'assistenza e l'amministrazioneDopo «Registrazione, accesso, organizzazioni e inviti».
    • Tracciamento degli eventi per le metriche di prodottoDopo «Registrazione, accesso, organizzazioni e inviti».
    • Sicurezza: limiti alle richieste, registri degli accessi, separazione dei dati provataDopo «Registrazione, accesso, organizzazioni e inviti».
    • Revisioni di fine sprint con il clienteDopo «Backlog e architettura approvati».
    • Prodotto pronto per la betaDopo «Il flusso principale, dall'inizio al risultato», «Email transazionali: benvenuto, inviti, recupero della password», «Primo accesso guidato e dati di esempio», «Pannello interno per l'assistenza e l'amministrazione», «Tracciamento degli eventi per le metriche di prodotto», «Sicurezza: limiti alle richieste, registri degli accessi, separazione dei dati provata».
    • Piani, prova gratuita e pagamenti con cartaDopo «Prodotto pronto per la beta».
    • Fatture elettroniche degli abbonamentiDopo «Prodotto pronto per la beta».
    • Correzioni e miglioramenti dai riscontri della betaDopo «Beta aperta ai primi clienti».
  4. Beta

    settimane 9–15
    • Selezione dei clienti betaDopo «Perimetro del primo rilascio approvato».
    • Accordo per la beta e accordo sul trattamento dei datiDopo «Selezione dei clienti beta», «Protezione dei dati fin dalla progettazione».
    • Beta aperta ai primi clientiDopo «Prodotto pronto per la beta», «Accordo per la beta e accordo sul trattamento dei dati».
    • Accompagnamento dei clienti betaDopo «Beta aperta ai primi clienti».
    • I clienti beta usano il prodotto nel lavoro veroDopo «Beta aperta ai primi clienti».
    • Raccolta e smistamento dei riscontri nel backlogDopo «Beta aperta ai primi clienti».
    • Analisi della beta: metriche, riscontri, disponibilità a pagareDopo «I clienti beta usano il prodotto nel lavoro vero», «Raccolta e smistamento dei riscontri nel backlog», «Accompagnamento dei clienti beta».
    • Lancio confermatoDopo «Analisi della beta: metriche, riscontri, disponibilità a pagare».
  5. Lancio

    settimane 13–16
    • Piani e prezzi definitiviDopo «Beta aperta ai primi clienti».
    • Condizioni d'uso, informativa privacy, cookie, accordo sul trattamentoDopo «Beta aperta ai primi clienti».
    • Pagina del prodotto con piani, prezzi e registrazioneDopo «Beta aperta ai primi clienti».
    • Versione del lancio congelata e provataDopo «Lancio confermato», «Piani, prova gratuita e pagamenti con carta», «Fatture elettroniche degli abbonamenti», «Correzioni e miglioramenti dai riscontri della beta».
    • Prontezza operativa per il primo giornoDopo «Lancio confermato».
    • Lancio pubblicoDopo «Versione del lancio congelata e provata», «Prontezza operativa per il primo giorno», «Condizioni d'uso, informativa privacy, cookie, accordo sul trattamento», «Pagina del prodotto con piani, prezzi e registrazione», «Piani e prezzi definitivi».
    • Presidio dei primi giorni: errori, registrazioni, domandeDopo «Lancio pubblico».
    • Bilancio del lancio e backlog della versione successivaDopo «Presidio dei primi giorni: errori, registrazioni, domande».
    • Primo rilascio chiusoDopo «Bilancio del lancio e backlog della versione successiva».

I rischi tipici

  • Il perimetro cresce sprint dopo sprint

    Critico · 20

    Ogni idea sembra indispensabile: il primo rilascio si allontana e le ore si consumano prima del lancio.

    Mitigare: Perimetro MoSCoW approvato; una funzione nuova entra solo se ne esce una di peso simile; le altre restano nell'elenco «Non ora».

  • Nessuno è disposto a pagare

    Critico · 15

    Il problema esiste ma non pesa abbastanza: i clienti beta usano il prodotto gratis e non si abbonano.

    Mitigare: Interviste sui comportamenti, non sulle opinioni; prezzo detto ai clienti beta fin dall'inizio; un impegno concreto prima del lancio, come una lettera d'intenti o un prezzo riservato ai primi clienti.

  • Le ore finiscono prima del lancio

    Alto · 12

    A tempo il cliente paga le ore: se la stima era ottimista, il budget si esaurisce a metà sviluppo.

    Mitigare: Ore consumate e rimaste a ogni revisione di sprint, con la previsione a finire; si taglia il perimetro prima di sforare, non dopo.

  • Clienti beta che non usano il prodotto

    Alto · 12

    Si iscrivono, entrano una volta e spariscono: la beta non dice nulla su ciò che va cambiato.

    Mitigare: Pochi clienti scelti per l'intensità del problema; impegno scritto nell'accordo per la beta; chiamata settimanale fissata; primo accesso fatto insieme.

  • Scorciatoie tecniche che restano nel codice

    Alto · 12

    Per arrivare alla beta si prendono scorciatoie: se nessuno le ripaga, ogni funzione successiva costa di più.

    Accettare: Si accettano consapevolmente fino alla beta, scritte in un elenco con il costo stimato; le più rischiose si chiudono prima del lancio.

  • Dati di un cliente visibili a un altro

    Alto · 10

    Un filtro dimenticato in una query mostra i dati di un'azienda a un'altra: in un prodotto multi-tenant è l'errore che fa perdere i clienti.

    Evitare: Separazione dei dati decisa nell'architettura e applicata in un punto solo del codice; test automatici che provano ad attraversarla a ogni rilascio.

  • Fatture elettroniche non pronte al lancio

    Medio · 9

    Arrivano i primi abbonamenti ma le fatture non partono verso il Sistema di Interscambio: l'amministrazione le rifà a mano, una per una.

    Mitigare: Intermediario scelto durante la beta; una fattura di prova inviata e ricevuta prima del lancio.

La commessa

A tempo · 5 voci. Importi e tariffe li metti tu.

  • Scoperta
  • Progettazione
  • Sviluppo
  • Beta con i clienti
  • Lancio

Le pagine dei documenti

  • Lean Canvas del prodotto
  • Perimetro del primo rilascio
  • Lista di controllo del lancio
I modelli li scriviamo con cura, ma possiamo sbagliare: una norma cambiata, una durata ottimistica, un passaggio che manca. Sono un punto di partenza, non una consulenza: prima di impegnarti con un cliente, adattali al tuo caso. Hai trovato un errore? Scrivici: lo correggiamo per tutti e ti diciamo quando è fatto.

I file

In KeenHour, in Excel o in CSV.

Il modello vive in KeenHour, dove le date, il percorso critico e il carico si aggiornano da soli. Se preferisci partire da un file: l'Excel con il Gantt e il registro dei rischi, o il CSV da importare in una lista, con le date dal lunedì prossimo.

Tutti i modelli →

Every hour, under control.

Il prossimo lunedì, apri la settimana con il quadro completo.

Crea il workspace, invita il team e importa i progetti in corso. Hai 14 giorni per provarlo, senza carta.