Punti chiave
- Il fallimento piu comune e un disallineamento di ritmi: le corporate si muovono in trimestri, le startup in settimane. Senza un livello di interfaccia chiaro, la collaborazione si blocca prima di produrre qualcosa.
- Il fit tecnologico e necessario ma non sufficiente. Il fit di stadio, la velocita decisionale e la chiarezza dei deliverable contano di piu nella pratica.
- Il team corporate deve avere vera autorita decisionale. Una collaborazione gestita da chi deve escalare ogni scelta non e una collaborazione: e un processo di procurement.
- Definite l'aspetto del successo prima che la collaborazione inizi, e collegatelo a risultati concreti, non ad attivita.
- La crescita della startup e l'obiettivo principale. La corporate cattura valore come conseguenza dell'accelerare la startup, non come punto di partenza.
Ho condotto questo workshop decine di volte: in laboratori di innovazione corporate, in acceleratori universitari e al CERN IdeaSquare durante il programma della summer school. La sala e sempre piena di persone che vogliono sinceramente che la collaborazione funzioni. I problemi riguardano raramente le intenzioni. Riguardano quasi sempre la struttura.
La collaborazione corporate-startup e una di quelle idee che sembrano semplici finche non si prova a realizzarle. Una grande azienda ha risorse, distribuzione e credibilita. Una startup ha velocita, focus e un approccio nuovo a un problema che la corporate conosce bene. La logica di combinarle e chiara. E nell'esecuzione che si rompe tutto.
Questo articolo descrive il framework che uso nella pratica: cosa definire prima che la collaborazione inizi, come strutturare la relazione mentre e in corso, e cosa osservare quando comincia ad andare storto.
Perche la maggior parte delle collaborazioni fallisce
Il fallimento riguarda quasi mai la tecnologia. Quando il team corporate seleziona una startup con cui lavorare, la tecnologia e di solito gia stata valutata con cura. La due diligence sul prodotto e approfondita. Il business case e documentato. E poi la collaborazione si blocca, produce un pilot che non porta da nessuna parte, o si sgonfia silenziosamente dopo sei mesi senza risultati chiari.
La ragione e quasi sempre una di tre cose.
Disallineamento di ritmi. Le corporate operano in cicli di pianificazione trimestrale, con approvazioni di budget, processi di procurement e comitati di steering. Le startup operano in settimane. Quando una startup ha bisogno di una decisione in due settimane e il processo corporate ne richiede otto, la collaborazione non si adatta a quel divario: ci affonda dentro. La startup passa ad altre priorita. Il team corporate perde il filo. Entrambe le parti si lasciano con la vaga sensazione che l'altra fosse difficile con cui lavorare.
Proprieta poco chiara sul lato corporate. Una collaborazione gestita da qualcuno senza vera autorita decisionale non e una collaborazione. E una serie di riunioni. Se la persona che gestisce il programma deve escalare ogni decisione significativa, la startup sta lavorando con un livello intermedio, non con l'organizzazione. I migliori partner corporate sono quei team in cui la persona in sala puo dire di si.
Definizione di successo disallineata. La corporate vuole imparare sulla tecnologia. La startup vuole un cliente pagante, una referenza o un accordo di co-sviluppo. Se queste aspettative non sono allineate all'inizio, entrambe le parti misureranno la collaborazione con criteri diversi e saranno deluse entrambe, anche se vengono prodotti gli stessi output.
La soluzione e strutturale, non culturale. Non si tratta di insegnare alle corporate a pensare come le startup o di chiedere alle startup di essere pazienti con i processi corporate. Si tratta di progettare un livello di interfaccia che permetta a entrambe le organizzazioni di operare al proprio ritmo producendo output condivisi a intervalli concordati.
Prima di iniziare: quattro cose da definire
Ogni collaborazione che ho visto funzionare bene aveva queste quattro cose definite prima della prima sessione congiunta. Ogni collaborazione che ho visto andare male ne mancava almeno una.
Come appare il successo, e entro quando
Non "vogliamo esplorare sinergie" o "vogliamo capire meglio la tecnologia." Un risultato concreto e limitato nel tempo. Un pilot con un perimetro specifico completato entro il mese tre. Un accordo di co-sviluppo firmato entro il mese sei. Una tecnologia licenziata e integrata in una linea di prodotto entro fine anno. L'obiettivo non deve essere ambizioso. Deve essere abbastanza specifico da permettere a entrambe le parti di guardarlo tra sei mesi e concordare se e avvenuto.
L'errore comune: definire il successo in termini di attivita invece che di risultati. "Faremo quattro workshop e produrremo un report" e un piano di attivita, non una definizione di successo. La domanda e: cosa cambia nel mondo come risultato di quei quattro workshop?
Chi ha autorita decisionale su ciascun lato
Indicate la persona sul lato corporate che puo approvare il passo successivo senza escalation. Indicate la persona sul lato startup. Se nessuna di queste persone e presente alla prima riunione, avete gia introdotto un ritardo in ogni decisione successiva. La collaborazione ha bisogno di un punto di contatto su ciascun lato che possa impegnare risorse, approvare modifiche al perimetro e sbloccare problemi senza un comitato.
In pratica: e qui che la maggior parte dei programmi corporate va in crisi. La persona che gestisce il programma e spesso un program manager, non un business owner. Un program manager puo organizzare. Non puo acquistare. Assicuratevi che il business owner sia identificato e impegnato prima che la collaborazione inizi.
Di cosa ha davvero bisogno la startup da questa collaborazione
Non quello che la corporate assume di cui la startup abbia bisogno. Chiedete direttamente. Le startup si impegnano in collaborazioni corporate per ragioni diverse: ottenere un cliente di riferimento, accedere a un canale di distribuzione, co-sviluppare una funzionalita che non possono costruire da sole, validare un caso d'uso in un contesto regolamentato. La corporate non puo essere un partner utile senza sapere quale di questi e l'obiettivo reale. E la startup non puo ottenere quello di cui ha bisogno se non lo dice chiaramente.
La domanda che faccio sempre nel workshop: "Se questa collaborazione producesse esattamente una cosa concreta per la tua azienda entro la fine dell'anno, cosa vorresti che fosse?" La risposta di solito differisce da quello che il team corporate aveva assunto la startup volesse.
La cadenza e il formato dei check-in
Settimanale e quasi sempre troppo frequente per avere qualcosa di significativo da riportare. Mensile e spesso troppo infrequente per intercettare i problemi prima che si compongano. Bisettimanale funziona bene nella pratica: abbastanza frequente da mantenere lo slancio, abbastanza infrequente da permettere che qualcosa sia effettivamente successo tra le sessioni. Anche il formato conta: una chiamata di aggiornamento periodica produce status, non decisioni. Un check-in strutturato attorno a "cosa e bloccato e quale decisione e necessaria" produce movimento.
Un template pratico: iniziate ogni check-in bisettimanale con tre domande. Cosa e progredito dall'ultima volta? Cosa e bloccato e cosa lo sbloccherebbe? Qual e l'unica decisione che deve essere presa prima della prossima sessione?
Come scegliere la startup giusta
Il fit tecnologico e il filtro che la maggior parte dei team corporate applica per prima, ed e il meno predittivo per stabilire se la collaborazione produrra risultati. Quando si valutano le startup, si e gia ristretto il campo alle aziende che lavorano sulla tecnologia rilevante. All'interno di quel pool, i criteri che distinguono davvero le collaborazioni riuscite da quelle fallite sono diversi.
Fit di stadio. Una startup in fase di idea ha bisogno di cose diverse da un partner corporate rispetto a una startup con un prodotto esistente e clienti paganti. Le startup in fase iniziale beneficiano principalmente dell'accesso a conoscenza di dominio, dati e affermazioni di problemi reali. Le startup in fase avanzata beneficiano principalmente di distribuzione, relazioni di procurement e scala. La struttura della collaborazione deve corrispondere allo stadio attuale della startup. Un programma progettato per uno frustrera l'altro.
Capacita del team fondatore di gestire la collaborazione. Un team di due persone che lavora al prodotto principale non puo assorbire una collaborazione che richiede report settimanali, presentazioni a comitati di steering e un workstream di co-sviluppo che gira in parallelo. La collaborazione consumera l'attenzione del team in modi che danneggiano il business principale. Questa non e una ragione per evitare le startup in fase iniziale. E una ragione per progettare la collaborazione in modo che costi alla startup il minore overhead operativo possibile.
La disponibilita della corporate stessa. Questo e il criterio che la maggior parte dei team corporate dimentica di applicare a se stessa. La corporate e in grado di prendere decisioni abbastanza velocemente da essere un partner utile? I dati o l'infrastruttura di cui la startup ha bisogno sono accessibili nella timeline della collaborazione? Esiste un percorso realistico dal pilot alla produzione, o si tratta di un'esplorazione che produce un report e poi si ferma? Una startup che entra in una collaborazione senza porsi queste domande si sta assumendo piu rischi di quanto realizzi.
Come appare una collaborazione che funziona
Una collaborazione che funziona bene ha una texture specifica. Le riunioni iniziano con decisioni da prendere, non con status da condividere. I problemi emergono presto, perche entrambe le parti hanno abbastanza fiducia per dire "questo non sta funzionando" prima che diventi una crisi. La startup sta costruendo qualcosa di reale durante la collaborazione, non preparando materiali su quello che potrebbe costruire. E il team corporate sta imparando cose che cambiano il modo in cui pensa al problema, non raccogliendo osservazioni da aggiungere a un report.
Una collaborazione che sta andando storto ha una texture diversa. Le riunioni diventano piu lunghe e meno conclusive. La startup passa piu tempo a gestire la relazione che a costruire il prodotto. Il team corporate chiede sempre piu documentazione, piu dettagli, piu giustificazioni. Entrambe le parti sono educate ma sempre piu disconnesse dal lavoro reale dell'altra.
Il segnale di allarme precoce che osservo: quando la startup smette di chiedere cose alla corporate. In una collaborazione sana, la startup chiede: dati, introduzioni, accesso agli utenti, una decisione sul perimetro. Quando queste richieste si fermano, di solito significa che la startup ha smesso di aspettarsi che la collaborazione sia utile e si e mentalmente spostata avanti. La relazione e ancora viva sulla carta, ma l'energia l'ha lasciata.
La trappola del pilot
Il pilot e il luogo in cui la maggior parte delle collaborazioni corporate-startup va a morire. Sembra un progresso: la corporate si e impegnata in un test reale, la startup ha una referenza a cui puntare, entrambe le parti sono coinvolte. Ma un pilot che non e progettato con un percorso chiaro verso un passo successivo e un vicolo cieco travestito da milestone.
Prima che un pilot inizi, entrambe le parti dovrebbero essere in grado di rispondere: se questo pilot ha successo sulle metriche che abbiamo concordato, cosa succede dopo? C'e un processo di procurement pronto a muoversi? C'e una linea di budget per la fase successiva? C'e un business owner che si e impegnato nel passo successivo in modo condizionale ai risultati del pilot?
Se la risposta a una qualsiasi di queste domande e "vedremo quando ci arriviamo," il pilot e quasi certamente l'ultima cosa che accadra. Le corporate sono molto brave a fare pilot. Sono molto meno brave a convertire pilot in deployment in produzione, perche le condizioni che rendono facile un pilot, un perimetro ridotto, un budget protetto, un champion motivato, sono di solito assenti quando arriva la vera decisione di procurement.
Il compito della startup e rendere il passo successivo il piu facile possibile da approvare prima che il pilot inizi. Questo significa conoscere il processo di procurement, capire il ciclo di budget e identificare chi e il buyer economico, non solo chi e il champion. Non sono conversazioni comode da avere prima che un pilot inizi. Sono molto piu scomode da avere dopo che uno e concluso inconclusivamente.
Cosa significa se state gestendo un programma
Se state progettando o gestendo un programma di collaborazione corporate-startup, la decisione di design piu importante che prenderete e per chi e il programma. I programmi che producono risultati trattano la startup come il cliente principale. La corporate cattura valore perche la startup cresce, trova il product-market fit piu velocemente, o risolve un problema reale per il business della corporate. L'apprendimento della corporate e una conseguenza di questo, non l'obiettivo.
I programmi che producono report trattano la corporate come il cliente principale. L'obiettivo e dare al team corporate insight sul panorama tecnologico, esposizione a nuovi modelli di business, un senso di connessione con l'ecosistema startup. Non sono obiettivi sbagliati. Ma producono un programma molto diverso, uno in cui le startup percepiscono di essere usate come comparse nel percorso di apprendimento di qualcun altro, e rispondono di conseguenza.
I migliori programmi a cui ho partecipato, incluso il lavoro svolto in contesti universitari e al CERN IdeaSquare, condividono una caratteristica comune: il team corporate si presenta come una risorsa per la startup, non come un valutatore. La relazione assomiglia piu a quella con un cliente che a quella con un investitore. La startup sa esattamente cosa puo chiedere e cosa ci si aspetta che consegni. E il team corporate viene misurato su se le startup con cui lavora fanno progressi, non su se il programma si svolge senza intoppi.
Lavora con noi
Stai progettando un programma corporate-startup?
Aiutiamo le corporate europee a progettare e gestire programmi di collaborazione che producono risultati reali. Dalla selezione delle startup giuste alla strutturazione del livello di interfaccia che rende la collaborazione funzionante, l'abbiamo fatto in molti settori e contesti. Se stai costruendo un programma o ripensando uno che non ha prodotto risultati, parliamone.
Inizia una conversazione