Prodotto Startup: costruirlo bene significa definire sprint chiari, partire da un MVP e misurare ogni passo. In questo articolo vedremo come strutturare il ciclo di sviluppo, scegliere obiettivi concreti (acquisizione, contenuto, retention) e lavorare con un Product Lead che faciliti un brainstorming inclusivo. Poi trasformeremo idee in specifiche, stime realistiche e test A/B, evitando cicli infiniti, feature inutili e decisioni opache. Infine, imposteremo KPI per ogni rilascio e un processo di test condiviso che riduce bug e accelera le iterazioni. Così il tuo prodotto startup evolve rapidamente, con un team allineato, dati alla mano e una roadmap snella, pronta a convertire risultati misurabili in crescita reale.

Il ciclo di sviluppo del prodotto è uno degli aspetti più importanti per una startup: dalla definizione dei singoli step, alla creazione del MVP e al debug, qui cercheremo di affrontare tutti i passaggi chiave

Prima che Justin.tv diventasse Twitch e Socialcam, abbiamo passato anni con una convinzione sbagliata di come realizzare un prodotto.

Avevamo riunioni di prodotto tortuose in cui non scrivevamo le nostre decisioni. Non abbiamo specificato attentamente i nuovi prodotti, quindi i membri del team avevano spesso idee leggermente diverse su ciò che stavamo costruendo.

Abbiamo sempre voluto costruire prodotti completamente completi invece di MVP. E raramente prendevamo decisioni sulla base di dati per lo sviluppo di nuovi prodotti, quindi spesso non sapevamo come stavano funzionando dopo il lancio.

I cicli di sviluppo spesso duravano mesi. Eravamo stufi delle nuove funzionalità nel momento in cui le lanciavamo, quindi non iteravamo mai. La nostra roadmap di nuove funzionalità era così lunga che i membri del team non erano entusiasti di pensare a nuovi prodotti perché non era chiaro se sarebbero mai stati costruiti.

E ancora peggio, le decisioni sui prodotti erano prese esclusivamente dai fondatori in un processo non trasparente. Le cose erano un disastro.

In questo post coprirò i fondamenti del ciclo di sviluppo del prodotto che ho imparato per aiutare a risolvere tutti i problemi di cui sopra.

Questo ti aiuterà a iterare rapidamente, misurare, testare e migliorare il tuo prodotto mentre coinvolgi completamente il tuo team. Questo non è lo stesso che lanciare un MVP. Sto dando per scontato che tu abbia già lanciato un MVP e che tu stia capendo cosa fare dopo, che è dove la maggior parte delle startup passano la maggior parte del loro tempo.

Definisci la lunghezza del tuo ciclo di sviluppo (sprint)

Il vostro ciclo di sviluppo dovrebbe essere dettato dal vostro prodotto. A Socialcam stavamo costruendo per iOS, quindi ci siamo accordati su un ciclo di due settimane, che ci ha permesso di testare a fondo prima di rilasciare sull’App Store.

Se state realizzando una web app il vostro ciclo può essere più breve (anche di una settimana), se si tratta di hardware potrebbe essere più lungo. La chiave è strutturare il ciclo in modo che i membri del team rimangano entusiasti e sentano ancora di poter fare brainstorming di nuove idee.

Determinare l’obiettivo (o gli obiettivi) e identificare il Product Lead

Abbiamo fatto una e una sola riunione del team. Era la riunione di prodotto e avveniva il primo giorno del ciclo di sviluppo (sprint planning). A volte questa riunione andava avanti anche per cinque ore (scusate).

Ogni riunione di prodotto era incentrata su uno dei tre obiettivi:

1. Aumentare la creazione di contenuti
2. Aumentare i nuovi utenti
3. Aumentare la retention

Qualunque obiettivo avessimo scelto sarebbe stato il focus della riunione e, quindi, delle due settimane successive.

Come Product Lead nel team il mio ruolo era quello di migliorare il ciclo di sviluppo e moderare le riunioni di prodotto per garantire che tutti i membri del team si sentissero a proprio agio nel contribuire.

Spesso il solo fatto di avere l’opportunità di esprimere la propria idea e di averla scritta sulla lavagna – anche se non viene implementata – aumenta enormemente il coinvolgimento nel processo.

Brainstorm organizzato e inclusivo

Mentre facevamo il brainstorming, le idee venivano scritte sulla lavagna in una delle seguenti categorie: nuove funzionalità/ iterazioni di funzionalità, manutenzione e A/B test.

Ci si aspettava che tutti contribuissero. Non era permesso discutere o buttare giù le idee degli altri. Questo era il momento in cui tutti si sentivano liberi di contribuire senza paura del giudizio. Il Product Lead è responsabile della creazione e del mantenimento di questo ambiente.

Da lì ogni elemento del brainstorming sarebbe stato classificato dall’ingegnere nella riunione come facile (occupano da un’ora a qualche ora, in modo che se ne possano completare di diversi ogni giorno), medio (mezza giornata per una persona), e difficile (che occupa la maggior parte del ciclo di sviluppo).

Nessun elemento poteva essere così difficile da durare più di un intero ciclo di sviluppo e se lo fosse stato, lo avremmo diviso in pezzi più piccoli. Di solito questa classificazione veniva fatta voce per voce dall’ingegnere con più esperienza in quell’area specifica.

Le caratteristiche di iOS erano classificate dal ragazzo di iOS e così via. Questo ha davvero aiutato le persone non tecniche a capire quali delle loro idee erano facili da costruire e quali erano difficili.

Con questa consapevolezza spesso sono diventati più bravi a pensare a MVP sempre più facili delle loro idee. Queste idee facili sarebbero poi costruite e, se funzionavano, sarebbero state iterate.

Costruire con il consenso

Una volta che abbiamo scritto le nostre idee, abbiamo iniziato a scegliere su cosa lavorare attraverso il consenso. Avremmo iniziato con le idee difficili – era facile formare il consenso perché sapevamo di poterne fare solo una e perché sapevamo che avremmo iniziato un nuovo ciclo di sviluppo in due settimane.

Poi medio e poi facile. Sviluppare quel consenso non era molto difficile perché ognuno aveva l’opportunità di suggerire le proprie idee e perché c’era un chiaro obiettivo e una misurazione oggettiva di quanto tempo ci sarebbe voluto per costruire ogni idea. Questo processo ci ha permesso di valutare la qualità dell’ idea e non ha permesso alle singole personalità di far passare le loro idee preferite.

Specifiche chiare e misurazioni chiare del successo

In seguito avremmo specificato ogni elemento della nostra lista in dettaglio e assegnato ogni elemento a un membro del team (o a più membri del team). Specificavamo anche le statistiche che avevamo bisogno di tracciare per misurare l’efficacia della funzionalità.

Non avremmo mai rilasciato una funzione senza rilasciare il kpi per quella funzione e capire quale specifico risultato misurabile volevamo creare. Infine, abbiamo separato le funzionalità in base alle priorità, definendo come maggiormente prioritarie le funzionalità più richieste dagli utenti.

Se non c’era tempo, i “nice to haves” non sarebbero stati costruiti. Una volta fatto questo, facevamo una foto della lavagna e la cancellavamo.

Non avevamo una roadmap del prodotto al di fuori di queste due settimane e ogni riunione del prodotto partiva da zero con il nuovo obiettivo, i nuovi dati analitici delle ultime due settimane, e spesso anche nuove intuizioni dai test utente di persona, che cercavamo di fare almeno una volta al mese.

Lavorare durante il ciclo di sviluppo

Per me, il lavoro dopo il primo lunedì del ciclo di sviluppo era un’attività silenziosa. Il mio compito era quello di portare a termine tutti i compiti commerciali e operativi. Poi scavavo attraverso Mixpanel alla ricerca di approfondimenti interessanti sul prodotto o di potenziali bug.

Infine, gestivo anche sessioni mensili di test degli utenti nel nostro ufficio.

I miei compagni di squadra – ingegneri e un designer – lavoravano tranquillamente e velocemente sapendo che avevano progetti con obiettivi raggiungibili che erano ben definiti. Infine, durante gli ultimi tre giorni di ogni ciclo di sviluppo, smettevamo tutti di costruire e testavamo.

Avevamo una lista di test in Excel che includeva test manuali per tutte le nostre funzionalità di base. Ogni ciclo aggiungevamo test per le nuove funzionalità costruite in quel ciclo e testavamo tutti gli elementi della nostra lista di test due volte.

Tutti nel team testavano e spesso facevamo a gara a chi riusciva a testare più velocemente e a chi trovava più bug. L’attività di test non è molto divertente quindi è importante che l’onere sia condiviso.

I risultati

Guardandoci indietro, Socialcam non ha realizzato il nostro sogno di essere “Instagram per i video”. Infatti quello che avremmo dovuto costruire probabilmente sarebbe dovuto essere un prodotto più simile a quello che è Snapchat.

Ma questo processo ci ha permesso di iterare in modo estremamente rapido.

Come risultato siamo stati in grado di produrre molto rapidamente una lista di features interessanti: filtri video, bordi video, titoli video, colonne sonore video, ottimizzazioni del feed video, redesign visivi multipli, profili utente, canali raccomandati, commutazione della fotocamera anteriore e posteriore durante un video, e molto altro ancora.

Abbiamo anche sviluppato features che hanno prodotto una crescita di di 16 milioni di download in circa 3 mesi e oltre 100 milioni di persone che guardano video sul nostro sito web durante lo stesso periodo di tempo. La cosa più importante, però, è che abbiamo fatto tutto questo lavoro in modo rapido, efficiente, senza grandi discussioni, problemi con l’impegno dei founders, o davvero nessun problema di squadra.

A volte mi chiedo cosa sarebbe successo se invece di vendere l’azienda avessimo continuato a costruire per un altro anno… ma questa è un’altra storia.

Source: articolo tratto e rielaborato dal blog di Y Combinator: Product Development Cycle Fundamentals di Michael Seibel