Comincia con questo articolo una nuova serie dedicata a una delle fasi più importanti durante la realizzazione di un prodotto software, vale a dire il momento in cui si decide cosa si deve realizzare e perché. Come vedremo nel corso della serie, esistono delle tecniche sperimentate che consentono di partire dall’idea e arrivare al prodotto in maniera efficiente ed efficace.

Introduzione

In questa serie di articoli parleremo di come tradurre un’idea in una serie di funzionalità da implementare per  realizzare il prodotto, ossia, parlando in termini agili, vedremo quali sono i passi per convertire una vision in un product backlog contenente elementi pronti per essere implementati dal team.

Questa fase è estremamente importante e delicata, dato che condiziona non solo quello che il team andrà a realizzare ma anche come lo realizza. Come responsabili del prodotto vogliamo evitare l’errore di costruire un prodotto che non soddisfa i bisogni dei nostri utenti finali.

Prima di capire le dinamiche e le pratiche per concretizzare il product backlog è bene definire cosa si intende per prodotto, servizio e progetto.

Prodotto, servizio e progetto

Un prodotto è un “artefatto” che soddisfa uno o più bisogni del suo utilizzatore o risolve uno o più problemi.

Un servizio è l’equivalente di un prodotto, ma in senso immateriale. Anch’esso soddisfa uno o più bisogni o risolve uno o più problemi del suo utilizzatore.

Un progetto è un’attività limitata nel tempo, che ha un inizio e una fine, il cui scopo è creare prodotti e servizi di valori per gli utilizzatori.

In questo articolo e nei successivi utilizzeremo i termini prodotto e servizio come sinonimi, visto che si tratta di due realtà (“materiali” e “immateriali”) abbastanza sovrapponibili. Invitiamo però il lettore a non confonderli con il progetto. La distinzione è molto importante perchè permette di definire bene anche i ruoli all’interno del team. Il progetto non ha valore per l’utilizzatore: noi non guidiamo i piani di progetto di un’automobile ma, l’automobile vera e proria (il prodotto) che è il risultato di quel progetto.

Questioni agili

In un’ottica agile, questa distinzione è molto importante: l’approccio agile ha l’obiettivo di creare prodotti di valore con il minor sforzo progettuale. I prodotti però non nascono dal nulla ma si sviluppano grazie a un processo graduale che porta dall’identificazione di un bisogno o di un problema da risolvere, poi all’idea per la sua risoluzione, e infine alla realizzazione del prodotto o del servizio che soddisfa il bisogno o risolve il problema.

Il nostro lavoro è riuscire a creare questi prodotti velocemente, a basso costo e generando il maggior valore possibile. È questa la sfida che ci poniamo quando affrontiamo un progetto. Vediamo di seguito i principali passi da svolgere per cercare di ottenere questo obiettivo.

Bisogni e problemi

Quando ideiamo, progettiamo e realizziamo un prodotto, dobbiamo tenere sempre presente che il risultato del nostro lavoro andrà a soddisfare i bisogni degli utenti o risolverà i loro problemi. Si parla spesso di attenzione al cliente e di prodotto “pensato attorno al cliente”: purtroppo spesso questi buoni propositi si perdono per strada durante il progetto, dando maggior importanza ad aspetti ritenuti più importanti come le scadenze e il budget, sottovalutando invece di definire in modo approfondito  cosa effettivamente crei valore per l’utente finale.

È consigliabile quindi partire con il piede giusto identificando da subito chi è l’utente tipo del prodotto e quali sono i suoi bisogni che questo prodotto andrà a soddisfare. Questi saranno i punti fermi durante tutto il progetto. Dovranno essere  convalidati e verificati costantemente. Se ci si dovesse accorgerere che non si sta lavorando per produrre qualcosa che risolve i problemi identificati inizialmente, o se quei problemi non esistono più, significa che si sta costruendo il prodotto sbagliato. In questo caso meglio fermarsi, risparmiare tempo,  soldi e mal di pancia.

Purtroppo non è semplice capire che si sta imboccando una strada sbagliata. Vedremo nei prossimi paragrafi (e poi con gli articoli di tutta la serie) come accorgersene e cambiare eventualmente strada.

Idea e innovazione

Abbiamo identificato i problemi e le persone che hanno questi problemi. Abbiamo idee su come risolverli; ma ci basta per partire? Un’idea geniale, nuova, che ha grande appeal non è sufficiente da sola per creare un prodotto di successo.

È necessario partire da bisogni e/o problemi degli utenti finali; sia che questi siano pre-esistenti sia che questi siano indotti.  Troppo spesso si dà valore all’idea senza pensare che l’idea da sola non risolve nessun problema. L’idea può rappresentare il punto di partenza di un progetto che ha bisogno di gambe solide per correre al traguardo.

Da qui nasce l’idea per risolvere il problema in modo innovativo. Essendo innovativa, molto probabilmente solo una parte dell’idea è compresa all’inizio dal team. E questo risulta essere un forte ostacolo.

Lean canvas

Molti prodotti falliscono non perchè si sbaglia a costruire quello che si intendeva realizzare ma perchè si perde tempo (e soldi) a costruire il prodotto sbagliato. Spesso la causa di questi fallimenti è attribuibile alla mancanza di una visione condivisa, il che è dovuto per lo più alla scarsa comunicazione tra le persone coinvolte nel progetto.

Come detto in precedenza, un’idea da sola non basta per fare un prodotto ma è necessario che questa si trasformi in una vision condivisa: come fare? Una possibile risposta è lo strumento Lean Canvas [LC] ideato da Ash Maurya in “Running lean” [RL] e sviluppato a partire dal Business Model Canvas [BMC] di Alexander Osterwalder.

In breve il Lean Canvas è uno strumento utilizzato principalmente per creare velocemente un modello di business. A differenza di un business plan, tipicamente composto da oltre 30 pagine e che necessita di settimane o mesi per essere redatto, il Lean Canvas è composto da una sola pagina realizzabile anche solo in 20 minuti.

Ne risulta uno strumento veloce e conciso che permette da un lato di produrre e validare in poco tempo molteplici modelli di business e dall’altra obbliga a focalizzarsi esclusivamente sui punti salienti e più importanti della vision.

Il Lean Canvas è composto da 9 sezioni che possono essere compilate in ordine sparso, man mano che si hanno le informazioni, anche se tipicamente si segue l’ordine seguente:

1. customer segmentation
2. problem
3. unique value proposition
4. solution
5. channel
6. cost structure
7. revenue stream
8. key metrics
9. unfair advantage

Customer segmentation

È difficile costruire un prodotto/servizio se non conosciamo chi sono i nostri clienti e i nostri utenti e come questi sono “segmentati”: stile di vita, età, amatori o professionisti del settore, livello di coinvolgimento tecnologico e così via. In questa sezione andiamo principalmente a sciogliere questi nodi.

Attenzione alla differenza tra utenti e clienti: mentre i primi sono quelli che utilizzano il nostro prodotto/servizio, i secondi sono quelli che lo pagano. In alcuni casi utenti e clienti coincidono, in altri no.

Si possono eventualmente valutare anche le caratteristiche dell’utente “ideale” che userà il prodotto o il servizio fin da subito, nello spazio early adopters.

Problem

Citando un detto di  Charles Kettering, “un problema ben identificato è un problema mezzo risolto”. In questa sezione si vanno a individuare i principali 3 problemi che i nostri clienti hanno e che andiamo a risolvere. Se esistono, è consigliato anche elencare le possibili soluzioni del problema che ad oggi già esistono, anche se si tratta di soluzioni parziali. A tale scopo è presente lo spazio per le existing alternatives.

Unique value proposition

La UVP è una frase che sostanzialmente spiega il motivo di esistere del nostro prodotto/servizio. In che cosa ci differenziamo dagli altri? Perchè i clienti dovrebbero comprarlo? Questa forse è la sezione più importante del modello in quanto catalizza l’attenzione del lettore e illustra le motivazioni alla base della vision.

È possibile inoltre specificare un concetto di astrazione ad alto livello (spazio high level concept) che serva a spiegare ulterioremente la unique value proposition: l’esempio tipico è quello che ci spiega come “Youtube = Flickr dei video”.

Solution

Specularmente alla sezione problem, qui si vanno a elencare le principali 3 caratteristiche del prodotto che risolvono i problemi sopra esposti e che dimostrano la unique value proposition.

Channel

In questa sezione si vanno a elencare i canali per mezzo dei quali portiamo la nostra UVP ai clienti. È molto importante capire quanti e quali sono questi canali, in quanto la loro mancata identificazione è una delle principali cause di fallimento.

Cost structure

La sezione relativa alla costs structure serve a identificare quali saranno i costi da sostenere per realizzare il modello di business descritto. La struttura dei costi deve tenere in considerazione svariati aspetti:

• identificare la frequenza dei costi;
• stimare l’ammontare dei costi;
• individuare i costi fissi, ossia quelli che rimangono invariabili indipendentemente dalla quantità prodotta;
• individuare i costi variabili, ossia quelli che sono funzione della quantità prodotta e che variano al crescere di quest’ultima;
• individuare possibili economie: di scala (il costo si riduce in base alla quantità prodotta), di esperienza (il costo diminuisce al crescere dell’esperienza), di scopo (il costo diminuisce grazie a produzioni congiunte e riutilizzo di conoscenze), e così via.

Revenue stream

In contrapposizione alla struttura dei costi, qui si va invece a identificare il flusso dei ricavi generato dalla realizzazione del modello di business. Più in particolare in questa sezione si andrà a descrivere la struttura dei prezzi.

Punto focale resta la definizione del prezzo e, per farlo, potrebbe essere utile considerare i seguenti elementi:

• la strategia di prezzi da utilizzare: freemium (una parte del prodotto/servizio gratuita e un’altra a pagamento), ads (ricavi generati da pubblicità), subscription (ricavi generati da quote di iscrizioni/abbonamenti), licensing (ricavi derivanti da vendita di licenze), e così via;
• le modalità di pagamento: a rate, una tantum, e così via;
• il posizionamento del prodotto/servizio nel mercato.

Key metrics

In questa sezione vanno elencate tutte quelle attività che si andranno a misurare per capire l’andamento del business. Esempi di queste metriche sono: acquisizioni, attivazioni, retention, referenze, revenue, e così via.

Unfair advantage

Jason Cohen descrive un unfair advantage come “qualcosa che non può essere facilmente copiato o comprato”. Molte volte, individuare gli unfair advantage può essere difficoltoso e almeno nella fase iniziale, come suggerisce Maurya, non è sbagliato lasciare questa sezione in bianco.  Per ora i lettori non si preoccupino eccessivamente di questo aspetto, tanto ci torneremo adeguatamente sopra nei prossimi articoli, in cui vedremo l’uso del Lean Canvas in maniera più dettagliata.

Conclusioni

In questo articolo abbiamo fatto una rapida introduzione a un argomento complesso e importante, come quello dell’individuazione della visione e della sua traduzione in prodotto.

Abbiamo presentato brevemente gli elementi fondamentali dello strumento Lean Canvas, che si rivela molto utile per la sua capacità di focalizzare l’attenzione sulla definizione di alcune caratteristiche del prodotto nelle fasi iniziali. Su di esso, e sul suo uso pratico, torneremo nei prossimi articoli. La cosa fondamentale da capire è che un prodotto o un servizio devono nascere come risposta a una serie di bisogni o di problemi che un utente può avere (siano essi preesistenti o indotti…).

Una volta identificate le possibili soluzioni e il modo in cui sostenerle, arriva il momento in cui dobbiamo condividere e comunicare la vision del nostro prodotto. Nel prossimo articolo vedremo quali strumenti abbiamo a disposizione per farlo.