venerdì 28 maggio 2010

// //

Customer Development Model (CDM) (I)



Dopo aver spiegato il concetto di Minimum Viable Product (MVP), possiamo iniziare l’analisi del processo noto come “Customer Development”.

Come spiegato in un precedente post, solo negli ultimi anni, molti imprenditori ed “addetti ai lavori”, sono giunti alla conclusione che il modello basato sul prodotto, Product development model, non sia il miglior esempio da seguire, soprattutto per startup web.
Per questo motivo, l’imprenditore e professore californiano (Stanford University) Steve Gary Blank, ha teorizzato un nuovo modello che è, appunto, il Customer Development Model. Quest’ultimo è una tecnica che permette alle startup di validare il loro business model tramite un processo iterativo, veloce e che limiti i costi.

In pratica, l’attenzione passa dal prodotto (PDM) al modello di business (CDM).

Lo scopo del CDM è quello di guidare lo sviluppo e la crescita della startup sfruttando al massimo il feedback degli utenti che diventano gli attori principali di tutto il processo. In buona sostanza, visto molto dall’alto, il CDM punta a far sviluppare il prodotto procedendo per piccoli passi (iterazioni), ogni volta chiedendo il parere degli utenti e migliorando in base ai loro suggerimenti. Alla fine, il risultato dovrebbe essere garantito: un prodotto che ha mercato e che non deluderà i suoi utenti.

Prima di tutto, bisogna dire che il CDM è un modello applicabile a tutte le aziende ma, in base alle esigenze, può cambiare la sua struttura. In questo post, valuteremo il CDM applicato ad una startup web.


Lo schema precedente è il percorso che tipicamente porta una startup a diventare una compagnia importante.

Ci sono tutti i passi necessari, in ordine:

1) Si parte con la startup, si individuano business model e mercato, si inizia a pubblicizzare e vendere il prodotto/servizio e si assume il personale.

2) Se tutto procede secondo i piani inzia la fase di transizione. La startup sta crescendo e va a breakeven, addirittura diventa profittevole.

3) Ultimo passo, ormai si è affermata ed ha raggiunto una buona fetta di mercato, è diventata una compagnia. In questo schema, il CDM si posiziona nel primo step, all’interno della fase “Scalable Startup”.



Brevemente, il CDM si basa sul concetto di iterazione per validare il proprio business model ed, in parallelo, sull’Agile Development per uno sviluppo veloce e mirato. Analizzando il modello più in dettaglio, si può affermare che le fasi più importanti sono essenzialmente due: Customer Discovery e Customer Validation.

Customer Discovery per le startup web

La domanda a cui risponde la fase di Customer Discovery è: Cosa dovrei costruire e per chi?

Lo schema sottostante mostra i passi relativi alla fase di customer discovery:


Una startup web, nella fase iniziale, deve individuare il principale problema che vuole risolvere con il suo servizio e stabilire le caratteristiche e le funzionalità del minimum viable product, al fine di testare il business model, tramite 3 differenti iterazioni: Build, Measure (Test) e Learn (Verify).

Possiamo scomporre lo schema nei 5 livelli che lo compongono:

1) Tutto parte dalle assunzioni sul business model:


Questa è una fase in cui il team fondatore della startup inizia ad analizzare tutti gli aspetti importanti come il mercato, la struttura iniziale del MVP, i prezzi del servizio, la possibile domanda ed, ovviamente, i competitors.

2) Il problema del testing


Come detto anche nel post relativo al MVP, una fase molto difficile è capire come strutturare i test per migliorare il proprio servizio/prodotto in base ai suggerimenti degli utenti. Prima di tutto, all’inzio, una startup non ha utenti e, quindi, inizialmente o si investe in campagne di marketing mirato o bisogna arruolare in qualche modo un discreto numero di utenti tester. Successivamente bisogna indicare agli utenti come essere utili ai vostri fini. A tale scopo si può usare la tecnica del “Problem presentation” :

1) Individuate al massimo 3 problemi principali che potete risolvere
2) Chiedete ai clienti di ordinarli per importanza
3) Chiedete come li risolvono in genere
4) Descrivete all’utente come voi potreste risolvere i problemi
5) Chiedete all’utente se la vostra soluzione potrebbe risolvere il problema
6) Chiedete se userebbero la vostra soluzione in maniera gratuita
7) Chiedete se pagherebbero per la vostra soluzione
8) Chiedete di diffondere la voce e portarvi nuovi tester

Basandovi su questo schema, potete decidere quale metodo usare per proporre queste domande agli utenti, alcuni esempi:

- Nella home page mettete questo sondaggio
- Pagate qualcuno per usare il vostro servizio e rispondere alle domande
- Fatelo usare ai vostri amici, amici di amici....
- Usate la fantasia :)

3) Sviluppate il vostro MVP


Vi rimando al post dedicato all’MVP.

4) Testate il vostro MVP


Avete sviluppato l’MVP iniziale, adesso però va testato per capire se è stato pensato in maniera corretta e coerente con il vostro obiettivo. In questa fase vi conviene anche inserire una presentazione o un video del vostro prodotto per far capire al meglio agli utenti come va utilizzato e cosa offrite. Se il comportamento degli utenti si discosta molto dai risultati delle interviste del passo 3, allora dovete rivedere sia le domande che l’MVP.

5) Iterate ancora o continuate


A quest punto dovete mettere tutto insieme, valutare i risultati e decidere se iterare ancora oppure continuare al passo successivo: la Customer Validation, di cui parleremo nel prossimo post.

All’inizio, tutto questo processo può sembrare ostico da comprendere, lungo e complicato. Come per tutte le cose, occorre fare della pratica ed acquisire esperienza. Dal mio punto di vista i punti critici sono :

- Insieme iniziale degli utenti tester, difficile trovarli sia in quantità che come attinenza al prodotto proposto
- Problem presentation, non è facile convincere un utente a darti del feedback in maniera spontanea
- Design dell’MVP, sbagliare la progettazione dell’MVP potrebbe compromettere l’intero lavoro e portare a risultati non previsti
- Testare l’MVP, interpretare il comportamento degli utenti ed imparare da loro non è per niente semplice

Per adesso ci fermiamo qui, nel prossimo post continueremo ad analizzare il customer development model che, negli utlimi anni, si è affermato in California come modello guida.

Buon weekend!

Stefano Passatordi
Read More

venerdì 21 maggio 2010

// //

Minimum Viable Product (MVP)


Come promesso nell’ultimo post, adesso parleremo delle utlime tendenze della Valley per quanto riguarda la nascita ed i primi sviluppi di una startup: Customer Development e Lean Startup.

Prima però, è obbligatorio, dedicare un post al concetto di Minimum Viable Product (MVP) che, come vedremo, è alla base delle “nuove” teorie californiane.

Partiamo dalla definizione: “L’ MVP è una versione minimale del prodotto che permette ai fondatori di esplorare e capire il mercato e gli utenti, raccogliendo ed elaborando la maggior quantità di dati possibile per validare le ipotesi di base, con il minimo sforzo.”

Il nome, minimum viable product, potrebbe essere forviante e si potrebbe pensare che l’MVP sia solo una versione semplificata e ridotta all’osso del servizio finale. In realtà, non è solo un concetto legato all’aspetto tecnico e di sviluppo del servizio, ma è qualcosa di più generale e complicato che ha come scopo quello di lanciare un prodotto finale andando, quasi, a colpo sicuro.

L’MVP si basa sul concetto di iterazione seguito dall’apprendimento e lo studio dei risultati ottenuti. Prima di produrre l’MVP, i fondatori della startup, devono definire la vision del loro servizio ed individuare la funzionalità core di tutto il sistema.
A questo punto, in base alle esigenze, esistono due principali tecniche:

1) Product: si crea solo la pagina principale del servizio con, in risalto, le sezioni che intendiamo studiare. Ad esempio, se intendiamo valutare quanto possa interessare all’utente il servizio che si vuole offrire, allora nella home si mette in risalto la descrizione del prodotto con link fittizi al video e ad ulteriori chiarimenti. Si effettuano delle campagne di marketing per generare traffico verso il servizio stesso e si monitorizza la quantità di click per il video e la descrizione del prodotto. Se la rispsosta è buona, vuol dire che il servizio che vogliamo offrire piace e suscita attenzione, in caso contrario qualcosa è da rivedere.

2) Feature: come per il caso del Product, si creano dei link fittizi che simulano l’esistenza di una o più features e, quindi, in base alla quantità di click ricevuti, si può intuire quale può essere la funzionalità di maggior successo.

Ad ogni iterazione, si modificano e si aggiungono altri test per capire quale strada suggeriscono gli utenti, ma rimanendo sempre fedeli alla propria vision. Alla fine, dopo un certo numero di iterazioni e quando si raggiungono risultati soddisfacenti per i test eseguiti, si inizia a sviluppare seriamente il prodotto che, a questo punto, dovrebbe andare sul mercato con una ottima possibilità di piacere all’utente e, quindi, di avere successo.

Apparentemente l’MVP può sembrare una tecnica facile da applicare, ma non è così. Si possono verificare dei falsi negativi, ovvero gli utenti non reagiscono bene ai vostri test e voi decidete di abbandonare l’idea o di cambiare radicalmente il servizio. Potrebbe capitare che l’idea piace, ma avete strutturato male i test, per cui ci vuole una certa esperienza per formulare le prove e capire i risultati ottenuti.

Altre volte, potrebbe capitare di perdere di vista il focus del servizio e seguire quello che gli utenti chiedono, ma che, in realtà, è tutto un altro prodotto.

Inoltre, l’utilizzo di questa tecnica, porta ad un forte overhead di lavoro poichè, ad ogni iterazione bisogna:
1) Pensare il test
2) Raccogliere i dati
3) Elaborare i risultati
4) Sviluppare delle metriche nuove
5) Parlare con gli utenti
6) Ricominciare dal punto 1

L’MVP potrebbe sembrare simile al “release early, release often” del mondo open source, ma si differenzia per il fatto che le funzionalità non vengono scelte dall’utente, ma vengono solo validate dall’’utente ed il prodotto inziale, durante le iterazioni, mantiene costante la sua vision.

Questa tecnica viene utilizzata soprattutto per quesi servizi che richiedono un grosso investimento di tempo e denaro per essere sviluppati oppure quando si vuole immettere nel mercato un nuovo e costoso prodotto. Per servizi più semplici e veloci, bisogna valutare se è il caso di adattarla oppure, magari, solo in parte per valutare qualche aspetto e non tutto il prodotto.

Ad esempio, solo ultimamente, abbiamo usato questa tecnica in Ibrii. Nel pannello di condivisione, abbiamo inserito il bottone per condividere con Posterous, ma, in realtà, non è funzionante e ci serve solo per capire se è una opzione che gli utenti utilizzerebbero.

Adesso abbiamo le basi per poter parlare di Product development e Lean Startup, l’appuntamento è al prossimo post.

Ciao a tutti e buon weekend!

Stefano Passatordi


Minimum Viable Product
View more presentations from Eric Ries.


Read More

domenica 16 maggio 2010

// //

Perchè il Product development model non è sempre corretto


Nell’ultimo post abbiamo analizzato il Product Development Model studiando le quattro fasi che lo compongono.
Più volte ho affermato che questo modello non è adatto per una startup, in particolare per quelle web, e non deve essere utilizzato quando si approccia ad un mercato di cui non si ha conoscenza.
In questo post vi spiegherò quali sono le motivazioni per cui il PDM non è valido per una startup.

Partendo dal nome, ovvero Product development model, è chiaro quale sia il fulcro del modello: il prodotto.
A questo punto, la domanda è : ”Come è possibile sviluppare le attività di marketing, di vendita, di assunzioni o di sviluppo del modello finanziario, su una procedure basata interamente sul prodotto?

Nel PDM , il prodotto è al centro di tutto ed il resto è strettamente legato al ciclo di vita del prodotto stesso. In realtà, per una startup, l’aspetto fondamentale e critico, non è di per sè il prodotto e la tecnologia ad esso associato, ma, piuttosto, l’acquisizione degli utenti e l’attività di promozione. A cosa serve avere un prodotto tecnologicamente avanzatissimo se non si sa come promuoverlo e come acquisire utenti?
Vi siete mai chiesti perchè servizi, tecnologicamente molto banali, hanno molto più successo di altri servizi più complessi ed efficienti? Il segreto è capire le esigenze dell’utente e fargli sapere che voi potete risolvere i suoi problemi.

Tornando al PDM, analizziamo, punto per punto, perchè non è adatto per una startup:

1) Dove sono i customers?

Nel processo di sviluppo basato sul prodotto, i clienti non vengono mai presi in considerazione. Questo è il principale aspetto che ha portato al fallimento numerose startup che hanno basato tutto sul prodotto: non hanno valutato cosa servisse davvero al cliente e non hanno costruito un business model profittevole. Forse, però, in compenso hanno rispettato la data di consegna del prodotto...
Per questo motivo, il PDM è valido solo quando già si conosce il mercato, ovvero si conoscone le esigenze dei customers e si ha, già, un consolidato modello di business.

2) Focus sulla data di rilascio

Nel PDM, tutta l’attenzione è relativa alla data di rilascio del prodotto, per cui, tutte le altre attività correlate si devono adattare a quella data. Se, ad esempio, il prodotto deve essere rilasciato a Giugno 2010, siamo sicuri che l’ufficio marketing abbia avuto il tempo di effettuare le attività di ricerca e verifica necessarie? Siamo sicuri che le ipotesi circa il modello di business siano state adeguatamente verificate e testate? Ecco perchè, lanciare il prodotto, rispettando solo la data di consegna, spesso porta al fallimento: il prodotto è pronto ma tutto il resto (esplorazione clienti, canali di distribuzione, prezzi, ecc) ancora no!

3) Focus sulla produzione

Il PDM assume che la conoscenza sui clienti e di quello di cui hanno bisogno siano fattori già noti, così come le funzionalità finali del prodotto ed il business model da applicare. Dando per certi, questi punti cruciali, la startup, in teoria, dovrebbe solo organizzare il team per il marketing e per le vendite ed iniziare ad incassare. Tutto questo è vero per una startup che sta nascendo?..ovviamente no!
Non si conoscono i customers, non si conosce e non si è testato il business model e, spesso, anche le funzionalità da offrire cambiano durante la fase di sviluppo del prodotto.

4) Sviluppo statico

Il PDM è basato su quattro fasi che vanno eseguite in ordine, dalla prima all’ultima, senza possibilità di ripensamenti o di cambi improvvisi. Quale startup può affermare che, durante il suo ciclo di sviluppo, tutto è andato come previsto e non ha avuto la necessità di ritornare su passi precedenti per modificarli?
Le startup hanno bisogno di un modello di sviluppo flessibile, agile, dinamico e non statico e a senso unico.

5) Nessun contatto con i customers

Come più volte anticipato, il PDM, non prende in nessuna considerazione le reali esigenze di mercato e le necessità dei clienti. La startup si isola e sviluppa il prodotto senza alcun feedback esterno, in grado di guidarla verso le giuste scelte. Il risultato, spesso, è un prodotto che non rispecchia le esigenze del mercaro e dei customers, ed è del tutto imprevedibile.

6) Milestones prodotto

Il PDM si basa sul susseguirsi di un certo numero di milestones che devono essere rispettate. In base a questa logica, come è possibile sfruttare le milestones di prodotto per validare e valutare il business model, il piano di marketing e delle vendite? Non c’è alcuna relazione tra la data di rilascio di una milestone e, ad esempio, la bontà del business model oppure la valutazione del mercato di riferimento.

7) Problemi di scalabilità

Non basandosi su alcuna stima realistica del mercato e delle esigenze dei customers, il prodotto che viene lanciato, potrebbe essere un completo insuccesso o, al contrario, per pura fortuna, diventare famoso. In entambi i casi, si corre un enorme rischio legato alla scalabilità. Nel caso di insuccesso, la startup potrebbe, ad esempio, aver investito tantissimo in marketing e sviluppatori, per poi trovarsi con spese enormi da affrontare senza avere alcun ricavo. Questo è il caso che si verifica più spesso e che, inevitabilmente, porta la startup al fallimento. Nel secondo caso, invece, il successo arriva così all’improssivo che non si hanno i mezzi adeguati per far fronte alle numerose richieste.

Questi sono i principali motivi per cui il modello di sviluppo basato sul prodotto non è consigliato alle startup.

Negli ultimi anni, l’imprenditore e professore (Stanford University) californiano Steven Gary Blank, ha teorizzato un nuovo modello per le startup, conosciuto con il nome di Customer Development che si è evoluto nel Lean Startup model.
Attualmente il suo modello è quello standard utilizzato nella Valley e lo esamineremo nel prossimo post.

Ciao a tutti!
Stefano Passatordi
Read More

giovedì 13 maggio 2010

// //

[OT] Il nuovo Ibrii è online!


Ciao a tutti!

La settimana scorsa ho saltato il classico appuntamento del "post del venerdì" perchè ero impegnato con lo sviluppo della nuova versione di Ibrii.

Finalmente, ieri, dopo settimane di duro lavoro, dopo aver risolto assurdi problemi, degni della famosa sfortuna fantozziana, abbiamo pubblicato la nuova versione del nostro caro Ibrii.

La nuova versione ha cambiato direzione, spostandosi dalla tipologia notebook a quella del real real time content sharing con tanto di live stream.

La grafica e l'interazione utente sono state completamente rinnovate e spero che non vi deluderanno!

In realtà, l'attuale versione online, non è ancora quella definitiva. A parte la classica fase di bug fixing (che è d'obbligo e non può mancare!), nelle prossime settimane saranno implementate nuove funzionalità e, grazie al vostro feedback, saranno migliorate quelle già esistenti.

Ibrii è una piattaforma cross-browser ma, per testare al meglio le sue potenzialità, vi consiglio l'estensione per Firefox: una vera bomba per mischiare i contenuti prelevati da pagine diverse!

Sarei felice di ricevere un vostro parere sul nuovo Ibrii, vanno bene anche critiche :)


Tornando al blog, nelle prossime ore scriverò un nuovo post che riprende il precedente sul Product Development Model.

Un saluto a tutti, a presto!

Stefano Passatordi
Read More