La lean startup e il customer development model. In Italia.

La scorsa settimana i ragazzi di Mashape, con un articolo pubblicato su TagliaBlog, hanno dato il via a discussioni piuttosto calde e contrapposte riguardo al tema “Fare una startup in Italia o in Silicon Valley?”. Ne è poi scaturita una risposta diretta ed altre discussioni indirette come questa.

Non nascondo una grande simpatia per i giovani ventunenni milanesi e per la loro visione “romantica” di come portare avanti il proprio sogno in USA (per cui faccio un grande tifo) ma, per una serie di motivi, io attualmente sono e voglio restare in Italia…di conseguenza mi interessa rendermi conto se anche da noi possano funzionare alcuni meccanismi, “pattern” e metodologie proprie delle startup USA. Del resto è oggettivo che oltreoceano ci sia maggiore esperienza al riguardo e che in Italia venture capital ed angel che investono su startup Internet siano di qualche ordine di grandezza inferiori. :)

Tuttavia la teoria del come fare una startup partendo dal basso, ovvero dai bisogni dei clienti che possono essere potenzialmente interessati ad un prodotto, a mio avviso è applicabile anche in Italia. Ovviamente, una volta superata eventualmente la prima fase, il respiro dovrebbe essere Internazionale per avere un mercato in grado di supportare una ragionevole crescita.

Di cosa sto parlando? Del Customer Development Model di Steve Blank, autore di Four Steps to the Epiphany, libro che sto finalmente leggendo con attenzione (cosa che consiglio vivamente di fare). Steve è un imprenditore seriale di successo della Silicon Valley (5 delle sue 8 startup sono state quotate in borsa) e attualmente professore alle università di Berkeley e Stanford. Dalla sua teoria su come realizzare una startup è  nato anche il movimento di Lean Startup, portato avanti insieme ad Eric Ries. Alcuni dettagli li potete trovare in queste due presentazioni: cosa è il Customer Development e cosa significa fare una Lean Startup.

Il concetto di fondo è che in genere tutti coloro che vogliono realizzare un nuovo servizio sono:
- Naturalmente abituati a pensare alle funzioni che dovrebbe avere
- A realizzarlo
e solo successivamente
- A valutare il feedback degli utenti/clienti sul prodotto/servizio.
Nel frattempo vengono tipicamente spesi parecchi soldi in marketing, sviluppo, organizzazione vendite, etc. il tutto sulla base di un business plan previsionale con assunti verificabili solo a posteriori.
Tutto ciò è tipico del Product Development Model, come di seguito.

L’intuizione di Steve Blank è stata quella di analizzare le startup che hanno avuto successo, trovando pattern comuni e riconducibili al fatto di essere state tutte molto attente ai bisogni dei clienti sin da subito. Pochi soldi spesi bene per realizzare quello che gli utenti volevano davvero e per cui erano disposti a pagare. Da qui il Customer Development Model, schematizzato di seguito:

Non entro nel dettaglio dello schema – mi piacerebbe tornarci in seguito – ma volevo intanto colpire la fantasia mettendo a confronto i due diversi modi di approcciare il problema, molto diversi.
Ultima curiosità per chi si intende di metodologie di sviluppo software: non notate un certo parallelismo? Guardate lo schema di seguito, che è la base dell’integrazione portata da Eric Ries al Customer Development Model creando il movimento della lean startup.

Il Product Development Model non ammette quindi di tornare allo stadio precedente (equivarrebbe al fallimento) ed è assolutamente seriale, mentre sia il Customer Development Model che l’Agile Development sono impostati su processi iterativi. Da notare l’importanza dell’analisi dei feedback tornando se necessario allo stadio precedente “imparando” dai propri errori per ripetere meglio l’azione successiva.

Sono tutti concetti non banali a cui ho soltanto accennato. Spero di aver stimolato la fantasia di qualcuno e di poter approfondire alcuni di questi aspetti in seguito.

Intanto io e Giancarlo stiamo portando avanti un gruppo ufficiale qui a Bologna del movimento Lean Startup che è attualmente anche l’unico in Italia. Questa teoria merita invece molta più visibilità e sono contento che ci sia qualcuno che si stia muovendo in questo senso come i ragazzi di TOP-IX di Torino che organizzeranno a breve un evento su questi temi. :)

Enhanced by Zemanta

GTD e Pomodoro: come pianificare e gestire il tempo lavorativo

Io – come il piccoloimprenditore e molti altri :) – credo davvero che la risorsa più importante che abbiamo a disposizione sia il tempo ed ogni giorno che passa ne ricevo conferma.

Il problema è che non è poi così semplice pianificare al meglio le attività da fare e gestire la sequenza di azioni in grado di portarle a termine, insieme a tutti i vari “disturbi” che ci vengono necessariamente posti di fronte ogni giorno…

La mia soluzione a questo problema è l’utilizzo combinato di due note tecniche di pianificazione e gestione del proprio tempo, ovvero: GTD (Getting Things Done) e The Pomodoro Technique, sulle quali vorrei spendere due parole introduttive.

Introduzione

GTD (Getting Things Done)

Tecnica ideata da David Allen ed esposta attraverso un libro (di cui ne esiste anche una versione italiana). Potete trovare maggiori informazioni sul sito dell’autore ed in moltissimi altri siti dedicati a al GTD, tuttavia vorrei comunque allegare di seguito un’immagine per avere un’idea del processo: si tratta di un workflow da seguire (più o meno rigorosamente) che permette di gestire in maniera strutturata e organizzata ogni tipo di attività (lavorativa e non) ci si presenti.

gtd-workflowConcettualmente ogni attività passa per una inbox (reale o virtuale che sia) e viene valutata:

  • Se non può essere eseguita, sulla base di una nostra valutazione, può venire:
    • archiviata per consultazioni successive
    • inserita in una lista delle cose possibili/da fare più avanti
    • eliminata
  • Se può essere eseguita, sulla base di una nostra valutazione, può:
    • essere eseguita immediatamente nel caso impegni al massimo due minuti
    • essere delegata ed inserita in una lista (da tenere sotto controllo) delle attività delegate ad altri
    • essere inserita nella lista delle attività da fare quanto prima
    • essere inserita a calendario nel caso che debba essere fatta in un preciso momento
    • essere inserita nel planning dei progetti, da revisionare ciclicamente e deciderne la prossima attività da eseguire

The Pomodoro Technique

Questa tecnica è stata inventata da un italiano, Francesco Cirillo, ideata all’inizio degli anni 90 e divenuta nota in tutto il mondo poco prima del 2000. E’ una metodologia utilizzata particolarmente per lo sviluppo Agile, ma può essere applicata tranquillamente a qualunque tipo di attività. Esiste un apposito sito web in cui trovare tutte le informazioni necessarie, comprese: le istruzioni veloci per chi ha poco tempo o il libro sia in inglese che in italiano.

Il concetto di base, che vi consiglio di approfondire attraverso i riferimenti di cui sopra, è davvero molto semplice: si basa sull’uso di un timer da cucina (da qui nasce il termine “Pomodoro” inteso come timer in una sua forma classica) per controllare un tempo di 25 minuti in cui dobbiamo essere concentrati nello svolgere un’attività pianificata precedentemente; alla scadenza abbiamo 5 minuti di pausa e poi via con il pomodoro successivo. Ogni 4 pomodori la pausa si fa più lunga (15-30 minuti).

Il mio metodo

Io usavo già da qualche anno GTD prima di conoscere la tecnica del Pomodoro (in realtà l’avevo già utilizzata parzialmente a Yoox durante lo standup meeting, adottandola quindi solo marginalmente) ma approfondendola ho pensato che fosse proprio perfetta per colmare il gap lasciato a mio avviso dal GTD, ovvero: un aiuto nel controllo, nell’esecuzione e nella misurazione delle varie attività, al fine di ottimizzare al massimo il proprio tempo.

Quindi nella pratica:

  • Utilizzo il GTD seguendo completamente il workflow “standard” fino a dove può arrivare, ovvero alle “Next Actions”
  • Da quel momento in poi entra in gioco il Pomodoro: le attività vengono inserite in un’apposita lista di quelle da fare oggi, stimate sulla base del tempo a disposizione per quel giorno e i “pomodori” che riesco mediamente a completare in quel tempo.

Gli strumenti che utilizzo per fare tutto ciò sono: Evernote (di cui ho già parlato), Google Spreadsheet e  – da vero geek :)un timer software per Mac dedicato alla tecnica del Pomodoro.

In Evernote gestisco completamente il workflow GTD, considerando le “Next Actions” coincidenti con la “Lista Attività” della tecnica del Pomodoro e gestendo un’apposita lista delle cose da fare oggi (Pomodoro: To do TODAY). Di seguito uno screenshot esplicativo:

Immagine 3

Google Spreadsheet invece lo utilizzo per le registrazioni delle attività completate (come da tecnica del Pomodoro) esplicitando: data e ora, tutti i parametri di mio interesse per reportistiche future (quali: progetto, area di appartenenza, tipologia di attività, etc.), i pomodori stimati, i pomodori reali per completarla e gli eventuali disturbi (interni ed esterni).

Come metodologia Agile in team ho sempre utilizzato Scrum ma, non appena ne avrò occasione, mi piacerebbe valutare anche un’uso combinato di queste tecniche per il gioco di squadra.

Buon lavoro! ;)

Reblog this post [with Zemanta]