Costruire ciò di cui i clienti hanno bisogno: la ricetta definitiva

Secondo Clayton Christensen, professore alla Harvard Business School, ogni anno vengono introdotti quasi 30.000 nuovi prodotti e il 95% fallisce. Sebbene questo numero sia più correlato ai prodotti fisici, ci vuole solo un piccolo sforzo per rendersi conto che questo è vero per i prodotti digitali. E questo è un pensiero terrificante e inquietante perché le startup e gli imprenditori investono tonnellate di denaro per costruire questi prodotti. Questo ci porta a una domanda importante che ogni product manager e i team tecnici associati si pongono ogni volta che immergono i piedi nel fiume della costruzione di prodotti digitali. Perché i prodotti falliscono e cosa possono fare i team per creare i prodotti di cui i clienti hanno bisogno?

Qualche giorno fa, stavo chattando con un product manager di una delle più grandi società di software del nostro tempo. È alla guida di più squadre da oltre due anni. La parte più eccitante della sua esperienza è che ha condotto più di 50 esperimenti in questi due anni. E questi hanno aiutato il suo team a capire cosa costruire e, soprattutto, cosa non costruire per i clienti. Chiacchierando con lui, ho capito che questi esperimenti erano costosi in termini di capitale e tempo. Quindi anche decidere quali esperimenti eseguire è stato complicato poiché il team doveva giustificare il capitale necessario per eseguire gli esperimenti.

Sfortunatamente, solo poche aziende hanno così tanta larghezza di banda e capitale da sperimentare. E quindi è estremamente importante capire di cosa hanno bisogno i clienti e costruire i prodotti di conseguenza. Ma prima di approfondire come costruire i prodotti di cui i clienti hanno bisogno, è essenziale capire perché le aziende non riescono a farlo.

Motivi per cui le aziende non riescono a realizzare i prodotti di cui i clienti hanno bisogno

• Risolvere il problema sbagliato

Dopo un'indagine, si è scoperto che l'automazione era possibile semplicemente modificando i sistemi. E il problema non era usare "ML" per automatizzare determinate attività, ma era automatizzare determinate attività principalmente perché richiedevano tempo. In effetti, dopo ricerche più approfondite, si è scoperto che questa automazione non era affatto necessaria. Ciò è stato possibile perché il product manager ha investito tempo nella comprensione e nella definizione del problema. Ed è per questo che è imperativo comprendere il problema a livelli più profondi in modo che il team/azienda possa trovare il problema giusto da risolvere. Questo è il primo e più importante passaggio e la maggior parte dei prodotti fallisce proprio in questo passaggio.

• Mirando alla soluzione perfetta

Qualcosa di simile è successo con il product manager con cui ho fatto due chiacchiere. È stato coinvolto nella creazione di un prodotto che avrebbe sostituito completamente l'attuale sistema di gestione dei contenuti per circa 600 utenti interni. Il periodo iniziale per costruire questo sistema era di 12 mesi. Ma quando e quando il team di ingegneri ha iniziato a lavorare alla soluzione, si sono imbattuti in diversi casi d'angolo. Ciò ha aumentato la tempistica da 12 mesi a 18 mesi. Quando gli utenti lo hanno saputo, hanno iniziato a mettere in discussione l'intero sistema di gestione dei contenuti. Il loro punto era che se ci fosse voluto così tanto tempo per costruire l'intero sistema, ci sarebbero voluti periodi simili e più lunghi per costruire nuove funzionalità in futuro. Quindi, hanno continuato a spingere per aggiungere più funzionalità all'ambito.

Tutto questo è accaduto perché i team tecnici stavano aspettando di costruire e lanciare la soluzione migliore. Il product manager ha condiviso che invece di questo, avrebbero dovuto dividere il sistema di gestione dei contenuti in funzionalità secondarie più prioritarie e rilasciarle in modo iterativo invece di una versione del sistema big bang. Fortunatamente, il rischio di rilasciare in questo modo era inferiore poiché il sistema era pensato per utenti interni, ma questo avrebbe potuto essere un problema maggiore se gli utenti fossero stati esterni.

• Non ricevere feedback in anticipo

Il 30 giugno 1970, AT&T ha svelato il suo servizio commerciale Picturephone nella città di Pittsburgh, in Pennsylvania. Accecati dalla propria visione, i dirigenti dell'azienda hanno ignorato il feedback negativo ricevuto dall'azienda nella fase di test. Credevano che un milione di unità sarebbero state utilizzate entro dieci anni dal lancio. Con loro grande sorpresa, l'hanno ritirato dal mercato in soli tre anni a causa della mancanza di interesse da parte dei consumatori. Come mai?

Durante la fase di prova, gli utenti hanno condiviso il loro feedback. Hanno trovato l'attrezzatura troppo ingombrante, lo schermo troppo piccolo e costoso. Ma tutto ciò è stato ignorato, portando al fallimento dell'intero prodotto.

Ottenere feedback in anticipo e lavorarci sopra ti aiuterà a creare la soluzione giusta per i problemi dei tuoi clienti.

Prodotti per l'edilizia di cui i clienti hanno bisogno

• Approccio di lavoro all'indietro

• Intestazione : idealmente dovrebbe essere il nome del prodotto e dire essenzialmente di cosa tratta il prodotto
• Sottotitolo : il vantaggio principale del prodotto
• Riepilogo — Riassumi cosa fa il prodotto insieme al suo vantaggio principale
• Problema : problema specifico risolto da questo prodotto
• Soluzione : in che modo il prodotto risolve il problema
• Citazione da parte tua : crea un portavoce immaginario e chiedi una battuta che spieghi perché questo prodotto è un must.
• Come iniziare : spiega come utilizzare il prodotto nel modo più semplice possibile.
• Chiusura e invito all'azione : termina il comunicato stampa informando il lettore su come saperne di più o iniziare a utilizzare il prodotto.

• Sprint di progettazione

Uno degli esempi condivisi dal product manager è stato il modo in cui uno sprint di progettazione ha aiutato il suo team a decidere tra costruire e acquistare. Il suo team aveva il compito di modificare il flusso di produzione dei contenuti che supportava 400 utenti interni. I compiti di questi utenti consistevano nel creare quotidianamente contenuti (immagini, video, gif, ecc.) che apparivano sul sito Web per 50 milioni di utenti attivi giornalieri. Si diceva che il nuovo flusso di produzione di contenuti avrebbe consentito di risparmiare 2 milioni di euro all'anno nel 2020. Il product manager ha riunito uno sprint team composto da un paio di utenti, il loro responsabile, un responsabile tecnico e un responsabile del design. Lo sprint è andato avanti per una settimana. Alla fine dello sprint, il team tecnico non solo ha capito il problema in questione, ma ha anche escogitato una soluzione a basso costo che è stata convertita in un prodotto completo in un periodo di 2 mesi.

• Feedback quantitativo e qualitativo

• Il feedback quantitativo include esperimenti come test A/B, sondaggi con domande a risposta chiusa e analisi del prodotto. Ciò richiede attitudine analitica poiché i dati sono grandi ed espressi in grafici e numeri.
• Il feedback qualitativo include la ricerca utilizzando questionari con domande aperte, interviste 1:1, osservazione diretta, indagine contestuale, focus group e raccolta dati personalizzata. Rispetto al feedback quantitativo, questo è espresso a parole.

Pertanto, esistono diversi modi per comprendere le esigenze dei clienti e creare soluzioni di conseguenza, e l'utilizzo di uno qualsiasi dei metodi dipende esclusivamente dall'azienda e dal team. Ma ciò che è più importante è non costruire prodotti di cui i clienti non hanno bisogno. La storia dice che prima viene raccolto il feedback dai clienti, più facile è costruire le soluzioni giuste e risparmiare risorse.

Quale metodo usi nel tuo team/azienda per creare il prodotto/la soluzione giusta? Quali problemi incontri durante l'utilizzo di questo metodo? Commenta qui sotto; Mi piacerebbe saperlo.