Seguire il ciclo di vita dell'innovazione
Tailwind Traders deve affrontare interrogativi sull'innovazione che interessano anche molte altre organizzazioni:
- Come si fa ad aumentare la frequenza di modifica senza incidere sulle attività di business in corso?
- Come si fa a decidere dove intervenire con l'innovazione e quali modifiche implementare per massimizzare il ritorno di business di queste innovazioni?
La risposta a entrambi i quesiti è: Tailwind Traders deve integrare il cambiamento nella sua cultura organizzativa. Uno dei motivi per cui le organizzazioni poco inclini ai cambiamenti spesso sono soggette a interruzioni legate alle modifiche è che tali modifiche sono troppo estese e di forte impatto sulle attività. Le modifiche sono difficili da testare in ambienti controllati e realistici.
Se vengono definiti i processi necessari per introdurre i cambiamenti di frequente, questi avranno una portata minore e comporteranno minori rischi. Questo processo non comporta, tuttavia, solo l'adozione di determinati strumenti o tecnologie. Richiede anche una cultura che favorisca il cambiamento e accetti gli errori.
Il concetto di accettazione degli errori può sembrare un controsenso, ma è fondamentale per il ciclo di innovazione. Se le persone hanno paura di fallire perché gli errori li espongono al biasimo, è probabile che non tenteranno nuovi approcci alla risoluzione dei problemi per paura di commettere errori. L'intera organizzazione diventerà quindi prigioniera delle proprie prassi consolidate.
È possibile favorire la cultura del "fallire e rispondere immediatamente agli errori" in cui le persone sono incoraggiate a provare nuovi metodi. Sono autorizzati a cambiare rapidamente direzione se non ottengono il risultato previsto, aiutando a creare una cultura di innovazione più ricca.
Innovazione basata su ipotesi
L'innovazione può essere descritta come un ciclo iterativo basato su ipotesi. Una volta identificata l'esistenza di un problema, è possibile formulare una o più ipotesi per spiegare la causa radice e portare alla soluzione. La definizione stessa del problema può essere complessa, perché deve essere misurabile.
Ad esempio, la definizione del problema "i clienti non sono soddisfatti della scelta della piattaforma di pagamento" non è misurabile, quindi è difficile da risolvere. Se invece il problema è definito come "il 23% dei clienti lascia la sessione di acquisto quando passa a scegliere la piattaforma di pagamento", si parte da una posizione migliore per misurare il successo di qualsiasi possibile soluzione.
Dopo aver definito un problema in modo misurabile, è possibile formulare ipotesi potenzialmente in grado di spiegare e risolvere il problema. Ad esempio, un'ipotesi per risolvere la situazione di Tailwind Traders potrebbe essere: "L'aggiunta di ContosoPay alle piattaforme di pagamento supportate ridurrebbe l'abbandono dei clienti nella pagina di pagamento dal 23% al 10%". Una volta formulata un'idea, occorre verificarne la validità.
Le ipotesi devono mirare ad aggiungere valore per i clienti e a migliorare la loro esperienza nelle interazioni con l'organizzazione. Questo concetto è noto anche come empatia con il cliente: porre il cliente al centro dell'innovazione e mirare ad aumentare il valore per il cliente e per l'azienda.
Esistono molti modi per convalidare un'ipotesi senza intervenire sul codice dell'applicazione. I sondaggi dei clienti e le ricerche di mercato sono due esempi di fonti di informazioni preziose utili per decidere se un'ipotesi è valida. Il controllo di queste fonti consente di determinare l'idoneità dell'ipotesi e di sviluppare ipotesi che offrono la massima probabilità di accuratezza e il massimo valore aggiunto di business.
Compilazione
Quando un'ipotesi è sufficientemente valida per essere integrata nell'applicazione, inizia il processo di creazione. Anche in questo caso la velocità è fondamentale.
Gli sprint nello sviluppo devono essere più brevi possibile. La brevità degli sprint consente di verificare o scartare rapidamente l'ipotesi. Consente inoltre di ottimizzare il modo in cui le funzionalità necessarie verranno integrate nell'applicazione. Il risultato è un ciclo di innovazione più rapido.
Misura
È bene che l'accuratezza delle ipotesi venga verificata al più presto. Un prodotto minimo funzionante (MVP, minimum viable product) è una versione preliminare della nuova funzionalità che viene sottoposta a feedback e consente di verificare se si sta andando nella direzione giusta.
L'obiettivo del prodotto minimo funzionante è di verificare non solo l'ipotesi, ma anche gli eventuali presupposti. Ad esempio, se il 23% dei clienti di Tailwind Traders abbandona il processo di acquisto nella pagina di pagamento, l'ipotesi presuppone che il motivo sia il numero insufficiente delle piattaforme di pagamento proposte. Il motivo tuttavia potrebbe essere un altro. L'MVP deve essere studiato in modo da confermare o scartare questi presupposti e l'ipotesi.
Informazioni su
La fase di apprendimento è simile all'inizio del processo. Dopo aver acquisito più informazioni sui presupposti e sull'ipotesi, si potrebbe scoprire che erano giusti, parzialmente giusti o errati. Avere una mentalità di crescita e umiltà sufficiente per ammettere eventuali errori consente di:
- Cambiare rapidamente direzione se è necessario continuare a lavorare sull'MVP.
- Concentrare le attività su altre aree e formulare un'ipotesi alternativa.
È importante comprendere che, anche se l'ipotesi e i presupposti si rivelano errati, il processo ha comunque permesso di imparare qualcosa di nuovo sui clienti e sul business. Non si deve pensare di aver sprecato tempo. La chiave consiste nell'acquisire tale conoscenza quanto prima e applicarla a un'altra ipotesi. Questo concetto è la base della cultura della risposta immediata agli errori.
Risorse utili
La Panoramica dell'innovazione di Cloud Adoption Framework è il punto ideale da cui iniziare l'esplorazione delle modalità di innovazione.