Creare con empatia per i clienti

"La necessità è la madre dell'invenzione". Questo detto cattura l'indelibilità dello spirito umano e la nostra guida naturale a inventare. Come spiegato nell'Oxford English Dictionary, "quando il bisogno di qualcosa diventa impellente, si è costretti a trovare un modo per ottenerlo o raggiungerlo". Pochi negherebbero queste verità universali sull'ingegno. Tuttavia, come spiega l'articolo Innovazione nell'economia digitale , l'innovazione del cloud richiede un equilibrio tra invenzione e adozione.

Se continuiamo con l'analogia, l'innovazione deriva da una famiglia più estesa. L'empatia con i clienti è il padre dell'innovazione. Per creare una soluzione di empatia dei clienti, che guida l'innovazione, richiede un'esigenza legittima dei clienti che li mantiene tornare per risolvere le sfide critiche. Queste soluzioni si basano su ciò che i clienti hanno bisogno invece di volere o capricci. Per trovare le vere esigenze dei clienti, iniziare con empatia e una profonda comprensione dell'esperienza del cliente. L'empatia è una competenza sottosviluppata per molti ingegneri, product manager e anche vertici aziendali. Fortunatamente, le diverse interazioni e il ritmo rapido del ruolo di progettista cloud favoriscono questa competenza.

Come si costruisce l'empatia e perché l'empatia dei clienti è così importante? L'empatia dei clienti ti aiuta a comprendere e condividere l'esperienza del cliente. Dalla prima versione di un prodotto minimo funzionante (MVP) alla disponibilità generale di una soluzione di livello di mercato, l'empatia dei clienti consente di creare soluzioni migliori. Più importante, l'empatia meglio posiziona un team per inventare soluzioni che incoraggiano l'adozione. In un'economia digitale, i team di prodotto che possono facilmente emulare con le esigenze dei clienti possono creare un futuro più luminoso con strumenti migliori che ridefiniscono e guidano il mercato.

Definire i presupposti da creare con l'empatia dei clienti

La definizione dei presupposti è una parte fondamentale della pianificazione. Più si pianifica, più chiaramente si possono vedere i vostri presupposti strisciando nella base di una grande idea. I presupposti sono in genere il prodotto dell'auto-empatia. In altre parole, cosa vorrei se fossi in questa posizione? Quando si inizia con la fase di compilazione, riduce al minimo il periodo in cui i presupposti possono invase una soluzione. Questo approccio accelera anche il ciclo di feedback con i clienti reali, anticipando l'opportunità di apprendere e affinare l'empatia.

Le soluzioni più innovative della storia sono iniziate con una convinzione intuitiva. Questa intuizione deriva sia dall'esperienza esistente che dall'osservazione diretta. Iniziare con la fase di compilazione perché consente un rapido test dell'intuizione. Da qui, è possibile coltivare una comprensione più profonda e gradi più chiari di empatia. A ogni iterazione o versione di una soluzione, l'equilibrio deriva dalla creazione di prodotti MVP che dimostrino empatia con i clienti.

Per mantenere costante questa azione di bilanciamento, le due sezioni seguenti descrivono i concetti di come creare con empatia e definire un MVP.

Definire un'ipotesi mirata al cliente

Quando si crea con empatia, significa creare una soluzione in base a ipotesi definite che illustrano le esigenze di un cliente specifico. I passaggi seguenti formulano un'ipotesi che incoraggia a costruire con empatia.

1. Quando si crea con empatia, il cliente è sempre al centro dell'attenzione. Questa intenzione può assumere molte forme. È possibile fare riferimento a un archetipo di cliente, a uno specifico utente tipo o anche all'immagine di un cliente coinvolto da un problema che si vuole risolvere. Tenere presente che i clienti possono essere interni (dipendenti o partner) o esterni (consumatori o clienti aziendali). Questa definizione è la prima ipotesi da testare: possiamo aiutare questo cliente specifico?
2. Comprendere l'esperienza del cliente. Creare con empatia significa relazionarsi con l'esperienza del cliente e comprenderne le sfide. Questo atteggiamento porta alla successiva ipotesi da testare: è possibile aiutare questo cliente specifico con questa sfida gestibile?
3. Definire una soluzione chiara per una singola sfida. Se ci si affida a competenze tra persone, processi ed esperti in materia, può portare a una potenziale soluzione. L'ipotesi completa da testare è quindi: possiamo aiutare questo cliente specifico con questa sfida gestibile tramite la soluzione proposta?
4. Arrivare a una dichiarazione dei valori. Quale valore a lungo termine si spera di offrire a questi clienti? La risposta a questa domanda crea l'ipotesi completa: come verrà migliorata la vita di questi clienti con la soluzione proposta per affrontare questa sfida gestibile?

Questo ultimo passaggio è il punto culminante di un'ipotesi basata sull'empatia con i clienti. Definisce i destinatari, il problema, la soluzione e la metrica in base a cui è necessario apportare miglioramenti, il tutto incentrato sul cliente. Durante la misura e le fasi di apprendimento, è necessario testare ogni ipotesi. Anticipare le modifiche apportate al cliente, la dichiarazione del problema o la soluzione man mano che il team sviluppa una maggiore empatia per la base clienti indirizzabile.

Dopo aver dimostrato i presupposti di base, le iterazioni successive si concentrano sui test di crescita oltre ai test di empatia. Dopo aver compilato, testato e convalidato l'empatia, si inizia a comprendere il mercato indirizzabile su larga scala. È possibile comprendere in modo più approfondito il mercato indirizzabile espandendo la formula di ipotesi standard descritta in precedenza. Quindi, in base ai dati disponibili, stimare le dimensioni del mercato totale (il numero di potenziali clienti).

Da qui, stimare la percentuale del mercato totale che riscontra una sfida simile e potrebbe quindi essere interessata alla soluzione. Hai quindi il tuo mercato indirizzabile. L'ipotesi successiva da testare è: in che modo x% della vita dei clienti verrà migliorata usando la soluzione proposta per affrontare questa sfida gestibile? Un piccolo campionamento dei clienti rivela indicatori iniziali che suggeriscono un effetto percentuale sul pool di clienti coinvolti.

Definire una soluzione per testare l'ipotesi

Durante ogni iterazione di un ciclo di feedback creazione-misurazione-apprendimento, il tentativo di creare con empatia viene definito da un MVP.

Un MVP è l'unità di lavoro minima (invenzione, progettazione, sviluppo di applicazioni o architettura dei dati) necessaria per creare una soluzione sufficiente per apprendere con il cliente. L'obiettivo di ogni MVP è testare alcune o tutte le ipotesi precedenti e ricevere feedback direttamente dal cliente. L'output non è una bella applicazione con tutte le funzionalità necessarie per modificare il settore. L'output desiderato di ogni iterazione è un'opportunità di apprendimento, una possibilità di testare in modo più approfondito un'ipotesi.

Il timebox è un metodo standard per assicurarsi che un prodotto rimanga snello. Ad esempio, verificare che il team di sviluppo pensi che la soluzione possa essere creata in un'unica iterazione per consentire test rapidi. Per comprendere meglio come usare velocità, iterazioni e versioni per definire i mezzi minimi, vedere Pianificazione della velocità, iterazioni, rilascio e percorsi di iterazione.

Ridurre la complessità e ritardare i picchi tecnici

Le discipline dell'invenzionedescritte in Metodologia di innovazione esplorano le funzionalità che spesso sono necessarie per offrire una soluzione MVP avanzata o pronta per la scalabilità. Usare queste discipline come guida a lungo termine per l'inclusione di funzionalità. Analogamente, usarle come guida cautelativa durante i test iniziali del valore e dell'empatia per i clienti nella soluzione.

La varietà di funzionalità e le diverse discipline dell'ingegno non possono essere create tutte in una singola iterazione. Una soluzione MVP potrebbe richiedere diverse versioni per includere la complessità di più discipline. A seconda dell'investimento effettuato in sviluppo, potrebbero esserci più team paralleli che lavorano all'interno di diverse discipline per testare più ipotesi. Anche se è intelligente mantenere l'allineamento dell'architettura tra i team, non è opportuno provare a creare soluzioni complesse e integrate fino a quando non è possibile convalidare le ipotesi di valore.

È possibile rilevare la complessità migliore nella frequenza o nel volume di picchi tecnici. I picchi tecnici sono tentativi di creare soluzioni tecniche che non possono essere facilmente testate con i clienti. Quando il valore del cliente e l'empatia dei clienti non vengono verificati, i picchi tecnici rappresentano un rischio per l'innovazione e devono essere ridotti al minimo. Per i tipi di soluzioni testate mature che rientrano in un'iniziativa di migrazione, i picchi tecnici possono essere comuni durante l'adozione. Ma ritardano i test delle ipotesi negli sforzi di innovazione e dovresti rimandarli quando possibile.

Un approccio di semplificazione implacabile aiuta qualsiasi definizione MVP. Questo approccio significa rimuovere qualsiasi elemento che non aiuti la capacità di convalidare l'ipotesi. Per evitare complessità, ridurre il numero di integrazioni e funzionalità non necessarie per testare l'ipotesi.

Creare un MVP

A ogni iterazione, una soluzione MVP può assumere molte forme diverse. Il requisito comune è solo che l'output consenta la misurazione e il test dell'ipotesi. Questo semplice requisito avvia il processo scientifico e consente al team di costruire con empatia. Per mantenere il cliente al centro dell'attenzione, un MVP iniziale potrebbe essere basato solo su una delle discipline dell'ingegno.

In alcuni casi, il percorso più veloce per l'innovazione significa evitare temporaneamente queste discipline completamente, fino a quando il team di adozione del cloud non è sicuro che l'ipotesi sia convalidata in modo accurato. Da un'azienda tecnologica come Microsoft, questa guida potrebbe sembrare controintuiva. Ma sottolinea che le esigenze dei clienti, non una decisione tecnologica specifica, sono la priorità più alta in una soluzione MVP.

In genere, una soluzione MVP è costituita da un'applicazione o una soluzione dati con caratteristiche minime e lucido limitato. Per le organizzazioni con competenze di sviluppo professionale, questo percorso è spesso il più veloce per l'apprendimento e l'iterazione. L'elenco seguente include diversi altri approcci che un team potrebbe adottare per creare un MVP:

• Un algoritmo predittivo che è sbagliato il 99% delle volte, ma che dimostra risultati specifici desiderati.
• Un dispositivo IoT che non comunica in modo sicuro su scala di produzione, ma dimostra il valore di dati quasi in tempo reale all'interno di un processo.
• Un'applicazione creata da un citizen developer per testare un'ipotesi o soddisfare esigenze su scala ridotta.
• Un processo manuale che ricrea i vantaggi dell'applicazione da seguire.
• Un wireframe o un video abbastanza dettagliato per consentire al cliente di interagire.

Lo sviluppo di un MVP non dovrebbe richiedere enormi investimenti. Preferibilmente, si limitano gli investimenti il più possibile per ridurre al minimo il numero di ipotesi testate alla volta. Quindi, in ogni iterazione e con ogni versione, si migliora intenzionalmente la soluzione verso la soluzione pronta per la scalabilità che rappresenta più discipline di invenzione.

Accelerare lo sviluppo di MVP

Il time-to-market è fondamentale per il successo di qualsiasi innovazione. I rilasci più veloci portano a un apprendimento più rapido. L'apprendimento più rapido porta a prodotti più facilmente scalabili. A volte, i cicli di sviluppo di applicazioni tradizionali possono rallentare questo processo. Più spesso, l'innovazione è vincolata dai limiti delle competenze disponibili. I budget, il conteggio e la disponibilità del personale possono creare tutti i limiti per il numero di nuove innovazioni che un team può gestire.

I vincoli di personale e il desiderio di costruire con empatia hanno generato una rapida tendenza in crescita verso gli sviluppatori cittadini. Questi sviluppatori riducono i rischi e offrono scalabilità all'interno della community di sviluppo professionale di un'organizzazione. Gli sviluppatori di cittadini sono esperti di materia nell'esperienza dei clienti, ma non sono sottoposti a training come ingegneri. Questi individui usano strumenti di prototipazione o strumenti di sviluppo più leggeri che potrebbero essere disapprovati dagli sviluppatori professionisti. Questi sviluppatori allineati all'azienda creano soluzioni MVP e testano teorie. Se allineato bene, questo processo crea soluzioni di produzione che forniscono valore, ma non passano un'ipotesi di scala sufficientemente efficace. Teams può anche usare le soluzioni per convalidare un prototipo prima di iniziare le attività di scalabilità.

All'interno di qualsiasi piano di innovazione, i team di adozione del cloud devono diversificare i loro portfolio per includere le iniziative dei citizen developer. Ridimensionando gli sforzi di sviluppo, è possibile formare e testare più ipotesi a un investimento ridotto. Quando si convalida un'ipotesi e si identifica un mercato indirizzabile, gli sviluppatori professionisti possono quindi rafforzare e ridimensionare la soluzione usando strumenti di sviluppo moderni.

Ultimo passaggio per la creazione: i problemi dei clienti

Quando l'empatia con i clienti è forte, un problema chiaramente esistente dovrebbe essere facile da identificare. Il problema del cliente dovrebbe essere ovvio. Durante la compilazione, il team di adozione del cloud lavora su una soluzione per testare un'ipotesi basata su un punto di dolore del cliente. Se l'ipotesi è ben definita, ma il punto di dolore non è, la soluzione non è veramente basata sull'empatia del cliente. In questo scenario la compilazione non è il punto di partenza corretto. Investire invece prima di tutto nella creazione di empatia e nell'apprendimento da clienti reali. L'approccio migliore per costruire empatia e convalidare il dolore è semplice: ascoltare i tuoi clienti. Investire tempo per incontrarli e osservarli fino a quando non è possibile identificare un problema che si verifica di frequente. Dopo aver capito bene il punto di dolore del cliente, si è pronti a testare una soluzione ipotesi per affrontare quel dolore.

Quando non applicare questo approccio

Esistono molti requisiti legali, di conformità e di settore che potrebbero richiedere un approccio alternativo. Questo approccio potrebbe non essere adatto se le versioni pubbliche di una soluzione di sviluppo:

• Creare rischi per la durata dei brevetti, la protezione della proprietà intellettuale o le perdite di dati dei clienti
• Viola i requisiti di conformità stabiliti

Quando questi rischi percepiti esistono, consultare consulenza legale prima di adottare qualsiasi approccio guidato alla gestione del rilascio.

Riferimenti

Alcuni dei concetti di questo articolo si basano sulle idee illustrate da The Lean Startup Eric Ries.

Passaggi successivi

Dopo aver creato una soluzione MVP, è possibile misurare il valore di empatia e il valore di scala. Vedere come misurare l'impatto sui clienti.