Product Discovery

Conosci questa situazione? Nella tua azienda sono tutti entusiasti di una determinata idea di prodotto e tu, come product manager, devi definire questo prodotto. Ti viene detto che gli sviluppatori finiranno il loro progetto attuale tra quattro settimane. Ciò significa che puoi prenderti tutto il tempo che vuoi, purché tu abbia finito in quattro settimane...

Dici che non è un problema (dopotutto a volte hai solo pochi giorni, quindi quattro settimane sembrano un sogno). Utilizzerai persino tutti quei metodi fantastici di cui parlo sempre. Inizierai con la valutazione delle opportunità per capire il problema da risolvere. Poi condurrai interviste con utenti reali e creerai un elenco preliminare di requisiti. All'inizio della seconda settimana dovresti già poter lavorare con un Interaction Designer su un prototipo. Nella terza settimana potrai testare questo prototipo e nella quarta settimana elaborerai i dettagli dei casi d'uso e rivedrai il prototipo e le specifiche con gli sviluppatori.

La realtà nella Product Discovery

Sembra davvero fantastico – ma quello che succede in realtà di solito non è così fantastico: durante le prime conversazioni con i clienti, si scopre che i clienti non sono così entusiasti del prodotto come lo era il management, e/o hai difficoltà a progettare un prototipo con cui i clienti riescono a orientarsi, e/o i clienti non trovano particolarmente entusiasmanti le idee implementate nel prototipo. Ora però il tempo è scaduto e gli sviluppatori sono pronti. Nei successivi tre-sei mesi viene quindi sviluppato lo stesso prodotto inutile e noioso che si era già visto come prototipo. Quando il prodotto viene consegnato, il management è giustamente deluso dal risultato.

Qual è il problema?

Il problema non è l'affidabilità del software. Gli sviluppatori non ne hanno colpa – dopotutto hanno costruito solo ciò che hai chiesto loro. Tutti sanno quindi che è colpa tua come product manager.

Non serve a niente parlare con gli utenti, sviluppare prototipi e testarli insieme agli utenti, se non si mette in pratica ciò che si impara.

L'idea di considerare requisiti e design come una fase sequenziale, prevedibile e pianificata nel processo di sviluppo del prodotto è così radicata nel nostro settore che spesso è molto difficile per le organizzazioni di prodotto abbandonare questa abitudine.

Ma devono farlo. Nelle organizzazioni di prodotto bisogna capire che l'invenzione di nuovi prodotti è fondamentalmente un processo creativo. È più un'arte che una scienza. Per questo preferisco chiamare questa fase "Product Discovery" piuttosto che "requisiti e design".

Il termine "Product Discovery" sottolinea due punti particolarmente importanti:

• In primo luogo, bisogna scoprire se là fuori ci sono davvero clienti che vogliono questo prodotto. Ciò significa che bisogna definire il mercato e farsi confermare l'opportunità di prodotto dai propri clienti.

• In secondo luogo, bisogna trovare una soluzione a questo problema che sia utilizzabile, utile e realizzabile. E ciò significa che bisogna progettare il prodotto e poi validarlo insieme ai clienti e al team di sviluppo.

Product Discovery nell'industria farmaceutica

L'industria farmaceutica è un esempio estremo. Trovare un mercato non è difficile – ci sono sempre abbastanza problemi che vale la pena risolvere (ad es. salvare vite, prolungare la vita o migliorare la qualità della vita). Trovare la soluzione è la parte difficile. Quando le aziende farmaceutiche iniziano la "fase di Discovery", sono perfettamente consapevoli che non c'è alcuna garanzia di trovare una soluzione o di quanto durerà il processo. In questo settore bisogna quindi convivere con questa incertezza (e il rischio si riflette nei prezzi dei prodotti).

Motivi delle difficoltà con la Product Discovery

E sebbene sappiamo tutti che è difficile e che la maggior parte delle release software sono fallimenti perché non raggiungono gli obiettivi desiderati, nello sviluppo software insistiamo ancora nel pianificare la fase di Discovery come la costruzione di un edificio.

Soprattutto il management ha difficoltà con il concetto di Product Discovery. E credo che ci siano due ragioni per questo:

• In primo luogo, il processo di Discovery non è prevedibile. Il management teme che si lavori per mesi su qualcosa senza ottenere risultati. Se si inizia semplicemente a sviluppare qualcosa, si può almeno affermare di aver consegnato qualcosa. Questa è probabilmente la stessa ragione per cui molti manager non vanno d'accordo con Scrum, perché vogliono sapere esattamente quanti Sprint di 30 giorni saranno necessari per finire.

• In secondo luogo, in un'organizzazione di prodotto software, gli sviluppatori vengono sempre visti come una risorsa scarsa. L'idea che un team di sviluppatori stia seduto senza far niente, se non giocare a calcio balilla, fa impazzire il management.

Ironicamente, è esattamente questo ragionamento che porta a sprecare gli sviluppatori come risorsa.

Quasi ogni azienda utilizza il processo di Discovery appena descritto. Invece di dedicare diverse settimane a un prototipo, fanno fare all'intero team di sviluppo interi cicli di release per sviluppare il software, che poi passa attraverso il controllo qualità e viene messo in produzione. Questo è il motivo per cui molte aziende hanno bisogno di tre o anche più release e di uno o due anni prima di ottenere qualcosa di utile e utilizzabile. Utilizzano l'organizzazione di sviluppo per costruire un prototipo molto molto costoso e rendono i loro clienti cavie involontarie.

Questo è anche il motivo per cui molte startup non hanno successo. Semplicemente non hanno il capitale necessario per aspettare due anni prima di poter decollare. Quindi prendono i loro sviluppatori, li lasciano fare del loro meglio e aspettano di vedere cosa succede.

Conclusione

Sia alle startup che alle grandi aziende consiglio quindi di concentrare le proprie energie su questo processo di Discovery molto più veloce. Una volta trovata una soluzione che funziona (che sia utilizzabile, utile e realizzabile), tutto ruota attorno al lavoro di sviluppo. Fino a quel punto non hanno bisogno di così tanti sviluppatori. Gli sviluppatori che hanno possono e dovrebbero partecipare attivamente al processo di Discovery. Fino a un certo punto, gli sviluppatori possono anche preparare l'infrastruttura durante il processo di Discovery.

Puoi aiutare il tuo management a comprendere il processo di Product Discovery. Se insisti costantemente sul fatto che è tuo dovere assicurarti che gli sviluppatori creino qualcosa di utile e utilizzabile, e ti impegni nella ricerca di una soluzione promettente, riuscirai a dirigere l'attenzione del management su questa fase estremamente importante nel processo di sviluppo del prodotto.

Questo testo proviene dal blog di Marty Cagan ed è stato tradotto in italiano.

Creare grandi prodotti

=> Discovery vs Delivery nei prodotti.

Progettare una strategia di prodotto

Scopri come si differenziano la tua strategia aziendale vs. strategia di prodotto.