Prodotti falliti

Nota: questo articolo è la versione scritta di un intervento che ho tenuto per sviluppatori alla Craft Conference e per product manager e designer a Mind The Product.

In questo articolo voglio parlare delle cause per cui così tanti prodotti falliscono.

Perché i prodotti e i lanci di prodotto falliscono?

Nella maggior parte delle aziende vedo lo stesso modo fondamentale di lavorare e questo non è nemmeno lontanamente paragonabile al modo di lavorare delle aziende veramente eccellenti.

Lasciatemi fare un avvertimento, perché questa discussione può essere deprimente, soprattutto se siete direttamente coinvolti in questo tema. Se è così, vi chiedo semplicemente un po’ di pazienza.

Il processo di sviluppo prodotto

Guardiamo prima quale processo la maggior parte delle aziende utilizza ancora per sviluppare i propri prodotti. Cercherò di non giudicare per ora, ma semplicemente di descrivere il processo:

Tutto inizia con le idee. Nella maggior parte delle aziende queste idee provengono dalla direzione, dagli Stakeholder principali, dai titolari dell’azienda o dai grandi clienti (o potenziali clienti). In ogni caso c’è una serie di cose che dobbiamo fare per i diversi reparti dell’azienda.

Successivamente, nella maggior parte delle aziende le idee vengono prioritizzate in una Roadmap e questo per due motivi: primo, si vuole lavorare prima sulle cose più di valore, e secondo, si vuole poter stimare quando queste cose saranno pronte.

Per questo c’è quasi sempre una riunione di pianificazione trimestrale o annuale in cui i dirigenti esaminano le idee e negoziano una Product Roadmap. Per poter prioritizzare tutto, hanno però prima bisogno di una sorta di Business Case per ogni elemento.

Alcune aziende elaborano Business Case formali, altre più informali, ma in entrambi i casi si tratta di scoprire due cose:

1) Quanti soldi possiamo guadagnare con questo?

2) Quanto denaro o tempo costerà? Da queste informazioni viene poi creata la Roadmap, solitamente per il prossimo trimestre, ma a volte anche per un intero anno.

A questo punto viene dato l’ordine di marcia per il prodotto e la tecnologia e normalmente i lavori vengono svolti per priorità.

Quando un’idea raggiunge la cima della lista delle priorità, il product manager parla prima con gli Stakeholder per elaborare l’idea e formulare dei “requisiti”.

Questi possono essere User Story o una sorta di specifica funzionale; lo scopo dovrebbe comunque essere la comunicazione con i designer e gli sviluppatori che dovranno costruire il prodotto.

Una volta raccolti tutti i requisiti, al team di User Experience Design (se esiste in azienda) viene chiesto di occuparsi dell’Interaction Design, del Visual Design e, nel caso di hardware, del design del prodotto.

Infine i requisiti e le specifiche di design raggiungono gli sviluppatori. Questo è normalmente il punto in cui Agile entra in gioco.

Il ruolo degli sviluppatori nel processo di sviluppo

Gli sviluppatori suddividono poi il lavoro in iterazioni, che in Scrum vengono chiamate “Sprint”. Servono circa 1-3 Sprint per realizzare l’idea.

Nel migliore dei casi i test QA sono integrati nello Sprint. In caso contrario, il team QA eseguirà alcuni test successivi per verificare se l’idea funziona come desiderato e se non si verificano altri problemi (chiamati anche regressione).

Una volta ottenuto il via libera dal team QA, l’idea viene finalmente deployata e raggiunge l’utente.

Quasi tutte le aziende in cui entro, grandi o piccole, lavorano in questo modo da molti anni. Eppure tutte queste aziende lamentano costantemente la mancanza di innovazione e il lungo tempo necessario prima che un’idea arrivi finalmente nelle mani dei clienti.

Agile vs. Waterfall

Avrai forse notato che, nonostante io abbia menzionato Agile e oggigiorno quasi tutti dichiarino di lavorare in modo agile, il processo appena descritto è fondamentalmente un processo Waterfall. Per correttezza devo dire che gli sviluppatori spesso traggono da Agile tutto ciò che è possibile in questo processo Waterfall.

Ok, questo è forse l’approccio della maggior parte dei team, ma perché questo è necessariamente la causa di così tanti problemi?

Perché così tanti prodotti falliscono a causa di questo?

Cercherò di mostrarti il collegamento tra questo modo di lavorare diffuso e il fallimento dei prodotti.

Potrei parlare per un’eternità dei problemi di questo processo, ma elencherò semplicemente i 10 problemi più gravi di questo modo di lavorare. Anche se ognuno di questi dieci problemi è davvero grave e potrebbe far fallire un team, la maggior parte delle aziende ha molti o addirittura tutti questi problemi contemporaneamente.

1) Partiamo dall’alto – la fonte delle idee. Questo modello porta a offerte speciali orientate al fatturato e a prodotti orientati agli Stakeholder. C’è molto da dire su questo tema, ma per ora voglio semplicemente dire che queste non sono le migliori fonti di idee per i prodotti. Un’altra conseguenza di questo approccio è la mancanza di empowerment del team, perché in questo approccio sono responsabili solo dell’esecuzione – mercenari.

2) Parliamo del punto debole dei Business Case. Perché non mi fraintenda, i Business Case li trovo fondamentalmente buoni, almeno per le idee che rappresentano un investimento significativo. Ma il modo in cui la maggior parte delle aziende li crea in questo momento per ottenere una Roadmap prioritizzata è davvero ridicolo. Ricordi le due cose alla base di ogni Business Case? Quanto si guadagnerà e quanto costerà? A questo punto semplicemente non possiamo saperlo, perché non abbiamo idea di nessuno di questi due fattori.

Semplicemente non possiamo sapere quanto guadagneremo, perché dipende principalmente da quanto saranno buone le nostre soluzioni. Se il team fa un lavoro eccezionale ed ha un enorme successo, può cambiare l’intero corso dell’azienda. D’altra parte, la triste verità è che la maggior parte delle idee di prodotto non porta assolutamente nulla. E non sto esagerando. Intendo davvero nulla. In ogni caso, una delle lezioni più importanti nello sviluppo prodotto è sapere cosa non possiamo sapere. E a questo punto semplicemente non possiamo ancora sapere quanti soldi guadagneremo.

Allo stesso modo non abbiamo idea di quanto ci costerà lo sviluppo del prodotto. Senza una soluzione concreta, anche questo è abbastanza difficile da stimare. Molti sviluppatori esperti si rifiuteranno di dare una stima così presto, anche se alcuni faranno il vecchio compromesso delle “T-shirt”: diteci almeno se è “Small, Medium, Large o Extra Large”!

Le aziende vogliono Roadmap prioritizzate e per questo hanno bisogno di un sistema per valutare le idee. Quindi le persone giocano al gioco del Business Case.

3) Poi arriva un problema ancora più grande. Le aziende adorano le Roadmap. Ho visto molte Roadmap e la maggior parte di esse sono in pratica solo liste di funzionalità prioritizzate. Il marketing ha bisogno di questa funzionalità per una campagna. Le vendite hanno bisogno di questa funzionalità per un nuovo cliente. Qualcuno vuole integrare PayPal. Penso tu abbia capito cosa intendo.

C’è però un problema e forse è il più grande di tutti. Lo chiamo le “due scomode verità sui prodotti”.

La prima verità è che almeno la metà delle nostre idee semplicemente non funzionerà. Ci sono così tanti motivi per cui un’idea non funziona. Il più frequente è probabilmente che i clienti semplicemente non sono così entusiasti dell’idea come noi. Quindi non usano il prodotto. A volte vogliono usarlo, ma è così complicato che causa più problemi che vantaggi. Il risultato è lo stesso: i clienti non lo usano. A volte i clienti adorerebbero il prodotto, ma si scopre che il lavoro necessario è molto più di quanto pensassimo e semplicemente non abbiamo il denaro e il tempo per svilupparlo.

Ti assicuro che almeno la metà delle idee sulla tua Roadmap non porterà i risultati sperati. E tra l’altro, i team veramente bravi partono dal presupposto che almeno tre quarti delle idee non funzioneranno come pensavamo.

Come se non fosse già abbastanza grave, la seconda verità è che anche per le idee che hanno davvero potenziale, normalmente servono diverse iterazioni prima di implementarle al punto da fornire effettivamente il valore di business necessario. Lo chiamiamo “Time To Money”.

La cosa più importante che ho imparato riguardo allo sviluppo prodotto è che non si può sfuggire a queste due verità – per quanto si sia intelligenti. Ho avuto la grande fortuna di lavorare con molti team di prodotto veramente eccezionali. La differenza sta nel modo in cui si affrontano queste verità.

4) Il ruolo del prodotto in questo modello: in realtà non parlerei nemmeno del prodotto come ruolo. Fondamentalmente è più una forma di project management. In questo modello si tratta più di raccogliere requisiti e documentarli per gli sviluppatori. Credimi, questo non ha nulla a che fare con il product management moderno.

5) Similmente per il ruolo del design. A questo punto è già troppo tardi per creare valore reale attraverso il design. Allora ci si aiuta con il cosiddetto modello “Lipstick on the pig”. Il danno è già fatto e si cerca semplicemente di mascherarlo. I designer UX sanno che non va bene, ma cercano di far apparire tutto il più bello e coerente possibile.

6) Il motivo principale per cui si perdono opportunità con questo modello è che lo sviluppo viene coinvolto troppo tardi nel processo. Si dice che se si utilizzano i propri sviluppatori solo per scrivere codice, si perde metà del valore che potrebbero offrire. Gli sviluppatori sono normalmente la migliore fonte di innovazione eppure non vengono coinvolti nel processo.

7) Non solo gli sviluppatori, ma anche i principi e i vantaggi principali di Agile entrano in gioco troppo tardi. I team che utilizzano Agile in questo modo ottengono solo circa il 20% del valore e del potenziale dei metodi agili. Qui Agile si riferisce solo alla delivery, ma il resto dell’organizzazione e del contesto è ancora tutt’altro che agile.

8) L’intero processo è molto orientato al progetto. Un’azienda finanzia progetti, assume personale per i progetti, spinge i progetti avanti e li implementa. Purtroppo i progetti sono solo Output, mentre nello sviluppo prodotto si tratta di Outcome. Questo processo porta inevitabilmente a progetti orfani. Ok, alla fine qualcosa è stato rilasciato, ma non soddisfa lo scopo reale. E allora a cosa serve? Questo è un grande problema e si avvicina molto al modo in cui costruiamo i nostri prodotti.

9) La più grande debolezza del vecchio processo Waterfall è e è sempre stata il fatto che tutto il rischio emerge alla fine. La validazione da parte del cliente avviene semplicemente troppo tardi.

Spero tu abbia già sentito parlare dei metodi Lean Startup, che rappresentano più o meno l’esatto contrario. Il principio fondamentale è minimizzare lo spreco e il più grande spreco è progettare, costruire, testare e deployare un feature o un prodotto, solo per scoprire poi che non serve. Ironicamente, molti team credono di applicare i principi Lean, ma in realtà seguono solo il processo descritto sopra. E allora spiego loro che stanno testando le loro idee nel modo più costoso e lento che conosciamo.

10) E infine, mentre siamo occupati con il processo e sprechiamo tempo e denaro, i costi opportunità per le cose che un’organizzazione avrebbe potuto e dovuto fare al posto nostro rappresentano la perdita maggiore. Quel tempo e tutto quel denaro non li riavremo mai più.

Non sono molto sorpreso che tante aziende investano così tanto denaro e tempo e ne ricavino così poco. Ti avevo avvertito che poteva essere deprimente.

La buona notizia è che posso assicurarti che i migliori team non lavorano nemmeno lontanamente come ho descritto.

Riepilogo

Ho già scritto molti articoli sui diversi aspetti dei migliori team. La Product Discovery riguarda il modo in cui troviamo soluzioni di successo ai nostri problemi. È un modo attivo e continuo di collaborare tra le aree prodotto, User Experience Design e sviluppo. Continuous Discovery e Continuous Delivery procedono in parallelo. Le funzionalità nelle Roadmap (Output) vengono sostituite da problemi di business da risolvere (Outcome). L’obiettivo è che il prodotto si adatti il più possibile alla domanda del mercato (Product/Market Fit).

Se la tua azienda si aggrappa ancora a questo vecchio processo superato, spero che ora tu possa fare chiarezza e partire verso il futuro. E spero che ci riuscirai prima di essere superato da una startup o un concorrente che è molto più veloce ed efficace della tua azienda.

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

Modello di tabella per il Product Backlog

=> Ecco come puoi rappresentare le User Story nel Product Backlog sotto forma di tabella.

Il Product Goal Canvas

=> Definisci il tuo obiettivo di prodotto con il Product Goal Canvas.