Questo è il secondo di una serie di articoli legati alla mia esperienza di startupper a tempo pieno: all’impegno, alla crescita personale, alle difficoltà del fallimento, alle riflessioni sull’ecosistema italiano e a ciò che ho imparato sulla mia pelle. Trovate la prima puntata qui.
Una startup raggiunge il successo solo dopo aver realizzato un prodotto/servizio che i suoi clienti reputano di grande qualità. Seguono traction e/o revenues. Sappiamo però che questo a volte non basta, nel lungo periodo; le metriche con cui valutare il successo possono inoltre essere diverse, ragion per cui il fine stesso di questo lavoro può variare.
Ho riflettuto ultimamente sulle mie responsabilità in merito al fallimento di NextMags (e alle difficoltà incontrate da Searcheeze prima del rebranding). Non parlerò di questioni legate alla competenza o all’impegno – sono state discusse mille volte altrove. Sono fattori necessari ma non sufficienti a garantire che una startup sopravviva ai momenti difficili, alle sfide più dure.
Tendevo a credere che la cosa più importante fosse il focus, il dedicarsi al 100% al lavoro di squadra per arrivare all’obiettivo. Sono ancora di questa idea, ma da una diversa prospettiva: non si può solo lavorare a testa bassa, alla maniera “canonica” tanto cara ai developer. Ogni startup ha bisogno di un costante apporto di idee, fresche e diverse, oltre che di tonnellate di codice.
Non mi resi subito, davvero conto che, specialmente in principio, la startup è sperimentazione. Un calderone di idee, tentativi e scommesse. Di tutte le proposte che un team formula in fase di brainstorming, poche arrivano ad essere attuate, in genere dopo un processo di raffinamenti successivi. E’ un lavoro di sottrazione continua da cui emergono le caratteristiche che vanno a comporre il quid in costruzione – sia ad alto che basso livello.
Bisogna fare il minimo del lavoro possibile per validare con gli utenti quanti più aspetti possibile del proprio servizio, le sue features, e il suo business model. Necessariamente iterare. Per sperimentare con successo serve un afflusso continuo di idee da scremare, attuare, validare. E questa verità riguarda il team ma anche la porzione di lavoro che è unica competenza dei singoli.
E’ affascinante rendersi conto che il successo (o meno) di una attività di questo tipo passa da migliaia di piccoli bivii, e che ogni volta che il proprio team è riunito a discutere convergono tutte le conoscenze, convinzioni, capacità e… succede la magia. O ciò speriamo.
Il problema è che se le idee che fanno parte dell’insieme sono di per sé deboli, anche una esecuzione perfetta non salverà il risultato finale dal riscuotere poco successo. Un altra complicazione è che, se si arriva a parlarne, evidentemente queste idee sono parse meritevoli di attenzione a chi le ha pensate in prima istanza. Se poi gli interlocutori condividono la stessa estrazione professionale può diventare difficile far emergere per tempo le criticità.
Il miglior consiglio lo dà l’esperienza; peccato che arrivi sempre troppo tardi.
- Abraham Nicolas Amelot de la Houssaye
.
Spesso inventare non è nient’altro che scoprire nuove applicazioni di concetti già noti. Quando una disciplina sconfina in un’altra le contaminazioni possono dare il via alle più originali soluzioni. Il modo più semplice per far accadere qualcosa del genere è diversificare il più possibile nel team le competenze professionali e le attitudini personali. Mentre per queste ultime c’è buona speranza di “pescare” persone diverse fra loro, sul fronte delle skills si faticherà obbligatoriamente con i primi, fondamentali membri dell’equipaggio. Il risultato desiderato è in ogni caso quello di aumentare la varianza delle idee in gioco.
Il nostro era un team di quattro persone, tutti specializzati in informatica e molto orientati alla programmazione oltre che alla progettazione. Con le dovute differenze di ruolo, continua a sembrarmi una scelta sensata. In un mondo ideale, probabilmente, fra i primi impiegati comparirebbe un esperto di business development e uno di design; nella realtà la mole di lavoro è sempre tale da far desiderare di avere al proprio fianco più sviluppatori possibile. A meno di poter contare subito su un team di 10 persone, ci si scoprirà più o meno deboli su user experience, design, business development, copywriting, information architecture, web development…
La scarsità di risorse finanziarie obbliga una startup ad essere davvero molto cauta in fase di scaling. L’acquisizione di talenti rientra in quel filone: espandere il team troppo in fretta significa bruciare fondi e fallire. In questo scenario esiste un modo meno rischioso per aumentare la varianza delle idee ed aumentare le probabilità di innovazione: i membri del team si devono aprire al mondo esterno e devono lasciarsi contaminare, per poi portare la knowledge acquisita all’interno.
Negli ultimi anni iniziative come Talent Garden hanno finalmente importato in Italia il modello degli spazi di co-working. Ho sempre ritenuto questo modo di strutturare gli spazi molto più efficace rispetto ai “classici” spazi di incubazione, favorendo l’interazione fra le persone in ogni momento della giornata. La realtà di molte startup, tuttavia, è quella di essere fisicamente collocati in uffici singoli. La mia esperienza personale è un quadro in cui molti startuppers si riconosceranno: scadenze sempre pressanti, sviluppo costante che “mangia” tutte le risorse e le energie. E presi dal vortice della produttività a tutti i costi, si molla la presa sulla creatività.
Cosa avrei potuto “incastrare” nella mia routine lavorativa al fine di apportare ulteriore valore?
- Partecipare agli eventi. La fase di pubbliche relazioni è utile in sé stessa per l’effetto rete che innesca, ma soprattutto mi interessa lo scambio proficuo di vedute che si può avere con chiunque esterno al proprio progetto. C’è un momento magico durante l’esposizione della propria idea di business: quando l’interlocutore la coglie, e si illumina. Nei minuti seguenti può capitare di essere investiti da considerazioni, alcune fantastiche e diverse, che danno spunti nuovi al cantiere delle idee che vive dentro la startup. Spesso si rinuncia a queste occasioni perché non si vuole “perdere tempo” utile a sviluppare il codice…
- Cercare di validare prototipi e modelli con interlocutori di diversa estrazione. Che si tratti di testare una form per il login piuttosto che intervistare i potenziali clienti riguardo i servizi aggiuntivi, un errore molto più comune di quanto si pensi è interloquire sempre con la stessa audience. Quante volte avete esposto la vostra idea per la prossima startup proprio ad un altro ingegnere/programmatore/startupper? Ci sono pro e contro, variare è importante per cogliere il massimo. Il punto di vista di uno specializzando in biologia può essere sorprendentemente valido riguardo lo user engagement, ad esempio (true story bro)…
- Comunicare sistematicamente ai colleghi le proprie “scoperte”. Si ha sempre l’impressione che in pausa pranzo si farà in tempo a discutere di tutte le meraviglie scoperte con la nostra internet serendipity. La realtà è ovviamente diversa: il nostro bagaglio rimane nostro, spesso senza che ci venga in mente di mandare una mail per portare all’attenzione questo o quel link importante. Forse perché sommersi da mille e mille articoli ogni giorno, sottovalutiamo che ognuno di noi sperimenti una minima porzione dell’informazione sul web, anche se alcune fonti sono ovviamente condivise.
- Dare maggiore spazio alla fase di studio rispetto alla fase di esecuzione. La tendenza è pericolosamente vicina allo 0% studio – 100% esecuzione nelle fasi concitate di sviluppo. La mia scelta preferenziale sarebbe un onesto 15% – 85%, dove il 15% di studio comprende ad esempio: l’approfondimento tecnico e teorico delle discipline legate alla mia professionalità; la scoperta e l’analisi di competitors e del mercato – che è una operazione continuata nel tempo; il contatto con tecnologie e practices nuove; l’utilizzo di servizi e app per aumentare il proprio bagaglio e consapevolezza dei trend in atto.






On the Web