Grandi prodotti: Discovery vs. Delivery

La maggior parte di noi lavora su problemi piuttosto complessi e normalmente servono sistemi abbastanza articolati per risolverli.

Molti team affrontano due grandi sfide:

Innanzitutto devono capire come dovrebbe essere la soluzione per il cliente (Discovery). Questo significa sia scoprire se esistono clienti che hanno bisogno di questa soluzione (domanda), sia trovare una soluzione che funzioni per i clienti e per la propria azienda. Ancora più difficile è trovare un'unica soluzione che funzioni per molti clienti e non solo per alcuni specifici. Per riuscirci, dobbiamo imparare velocemente.

In secondo luogo, bisogna assicurarsi di fornire un'implementazione robusta e scalabile, sul cui valore i nostri clienti possano fare affidamento (Delivery). Il team dovrebbe avere fiducia nel Release. Anche se probabilmente non si può mai avere il 100% di fiducia in qualcosa, non si dovrebbe nemmeno dover pregare che tutto vada bene quando si rilascia qualcosa.

Bisogna quindi sia imparare velocemente sia avere fiducia nei propri release.

Può funzionare?

È comprensibile che molte persone pensino che questi due obiettivi diversi siano contraddittori. Dobbiamo cercare di rilasciare velocemente qualcosa per scoprire cosa funziona e cosa no. Tuttavia, non vogliamo nemmeno rilasciare qualcosa che non è ancora maturo, rischiando di danneggiare i nostri clienti e il nostro brand.

Ho parlato con molti team di prodotto e mi è capitato spesso di essere contestato perché in un momento invito un team a rilasciare più aggressivamente e raccogliere feedback dai clienti, e contemporaneamente pretendo che non facciano compromessi sulla qualità di un software affidabile, performante e sicuro.

Il Minimum Viable Product

Per molti team il concetto di Minimum Viable Product (MVP) non è semplice, perché da un lato si è motivati a offrire rapidamente qualcosa al cliente e ottenere feedback, ma dall'altro si ha subito la sensazione che il cosiddetto "prodotto" potrebbe essere imbarazzante – e come si potrebbe mai presentarlo al pubblico?

Apprendimento rapido e release solidi

Vorrei spiegare qui come i buoni team riescano a conciliare i due obiettivi – apprendimento rapido e release solidi.

Fondamentalmente credo che alla maggior parte dei team il secondo obiettivo – ovvero fornire software ragionevole – risulti più facile che sperimentare rapidamente cose nuove e acquisire nuove conoscenze. La Continuous Delivery, ovvero la consegna continua, è un buon metodo che ho osservato nei team che hanno compreso l'importanza di tanti piccoli cambiamenti incrementali in un sistema complesso.

Che cos'è un prodotto, in realtà?

Una ragione di questa confusione è, tra l'altro, il fatto che spesso non si sa esattamente cosa significhi quando si parla di "prodotto", "qualità del prodotto", "live in production" ecc. Cerco sempre di usare il termine "prodotto" per un prodotto che si trova in uno stato in cui è effettivamente commercializzabile. È scalabile e offre una certa performance. Esiste una solida suite di test di regressione. È progettato in modo da poter raccogliere le analitiche necessarie. A seconda delle esigenze, è stato internazionalizzato o localizzato. È facilmente manutenibile. Corrisponde alla promessa del brand. E soprattutto, il team può rilasciare il prodotto in buona coscienza.

Non è facile e richiede la maggior parte del tempo nello sviluppo. Per questo ci impegniamo a non sprecare tutti questi sforzi.

Svolgere questi lavori quando il product manager stesso non è nemmeno sicuro se i clienti vogliano o abbiano bisogno della soluzione è una ricetta assolutamente sicura per lo spreco.

La Product Discovery

Lo scopo della Product Discovery è quindi raccogliere prove del fatto che tutti gli sforzi degli sviluppatori per un software di alta qualità non saranno vani.

Per questo motivo esistono così tante tecniche diverse per la Product Discovery. Abbiamo tecniche per comprendere meglio i nostri utenti e clienti e per validare qualitativamente e quantitativamente le idee di prodotto. E la maggior parte di queste tecniche non richiede nemmeno il tempo degli sviluppatori (questo è importante, dato che sappiamo quanto tempo e impegno servano per produrre buona qualità).

Una Product Discovery efficace ha molto a che fare con l'ottenere accesso al cliente, e non semplicemente con l'implementare il più velocemente possibile i nostri esperimenti per nuovi prodotti.

Se sei ancora una startup molto giovane e non hai clienti, naturalmente questo non è davvero un problema (e forse è persino troppo presto per software di qualità produttiva).

La maggior parte di noi, però, ha clienti reali e fatturati reali e quindi dobbiamo anche riflettere su questo. Ho già scritto sulle tecniche più importanti per una sperimentazione rapida e responsabile con la Product Discovery nelle aziende consolidate.

Molte di queste tecniche consistono nel convincere alcuni dei nostri clienti o potenziali clienti a testare le nostre nuove idee di prodotto (in qualsiasi modo). Un programma di customer development è particolarmente adatto a questo scopo, poiché queste persone si sono offerte volontariamente come cavie. Possiamo parlare con loro o semplicemente osservarli mentre provano le nostre idee di prodotto, oppure fargli testare i nostri prototipi per un po' e vedere cosa ne esce.

Conclusione: Discovery vs. Delivery

Se vuoi davvero scoprire grandi prodotti, è estremamente importante testare le tue idee presto e spesso con utenti e clienti reali. Se vuoi consegnare grandi prodotti, dovresti utilizzare le migliori metodologie di sviluppo e cercare di non ignorare le preoccupazioni degli ingegneri.

Quando vogliamo procedere velocemente e scoprire nuove idee, utilizziamo metodi di Discovery e coinvolgiamo i clienti. Non appena abbiamo capito quale soluzione dovremmo sviluppare, lasciamo che gli sviluppatori creino un software di qualità produttiva, poiché così potranno consegnarlo con piena convinzione.

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