Come ormai ci siamo raccontati più volte, il confronto progetto vs prodotto è un esercizio che non sta in piedi.
Questo soprattutto per il fatto che si stanno confrontando due cose diverse: il prodotto è un output che dovrebbe (e qui il condizionale è d’obbligo) portare un beneficio (outcome) ad un (potenziale) consumatore, mentre il progetto è una delle possibili strutture operative di cui ci si dota per realizzare il prodotto, o dei deliverable in generale.
Per meglio rappresentare ed esplicitare questo concetto, può essere utile ricorrere alla figura seguente (benefits flow):
Benefits Flow
Grazie a questa rappresentazione, è possibile identificare sin da subito come il giusto livello di confronto non sia Prodotto/Progetto, ma Progetto/Value Stream.
Infatti, esattamente come per il Progetto, il Value Stream è oggi l’alternativa organizzativa duale per andare a realizzare un vantaggio per i consumatori, supportando, in questo caso, una continua evoluzione dei prodotti, ed influenzando in modo esplicito come viene “messa a terra” l’operatività annessa.
Questo è il motivo per cui al vertice dello schema rappresentato in figura è sempre presente il Jobs to Be Done, ovvero il beneficio che si vuole generare per i nostri consumatori:
“Upgrade your user, not your product.
Don’t build better cameras — build better photographers.
Kathy Sierra”
Il Prodotto (o i prodotti) realizzato per raggiungere tale scopo è, nella sostanza, il “mezzo tangibile” che permette di soddisfare dei bisogni specifici. La sua realizzazione richiede di tener conto delle specificità intrinseche ed estrinseche che lo caratterizzano:
- Specificità Intrinseche: caratteristiche proprie del prodotto. Sicuramente è possibile convenire che le dinamiche che accompagnano un prodotto digitale (si veda ad esempio un App) sono molto differenti da quelle che accompagnano un prodotto fisico (si veda ad esempio un’automobile)
- Specificità Estrinseche: caratteristiche di mercato. Qui si incontra il mercato, ed in particolare, come i consumatori commissionano, utilizzano e reagiscono al prodotto.
In relazione a queste due specificità essenziali (probabilmente non esclusive), il Product Manager deve essere in grado di sviluppare la vision di prodotto, andando ad utilizzare nel concreto tutta una serie di strumenti (metriche in primis) atte a raccogliere la soddisfazione del cohort di riferimento e far si che gli investimenti vadano nella direzione giusta.
Tale esigenza è ben riassunta dalla definizione che possiamo associare ad un prodotto:
“Un Prodotto è tutto ciò che può essere offerto al mercato per soddisfare uno specifico desiderio o un bisogno.”
È evidente, quindi, tutta la complessità del ruolo del Product Manager, ruolo che non può prescindere da una concreta competenza nel dominio di riferimento, ma anche da un’ampia conoscenza e applicazione delle tecniche strategiche più idonee ad indirizzare le scelte di sviluppo annesse.
Bisogna sottolineare che la visione di prodotto non può prescindere dalla sostenibilità operativa (nonché finanziaria-economica) dell’organizzazione, altrimenti si rischia di “inseguire un sogno”, rincorrendo un risultato non realmente raggiungibile: “Perfect is the enemy of good”!
Ma come possiamo identificare (senza preconcetti e pregiudizi) il modello operativo di sviluppo più opportuno per il prodotto specifico, garantendo, appunto, il miglior equilibrio possibile rispetto alle dinamiche in gioco?
Proprio questa tematica sarà l’argomento di riflessione del nostro prossimo appuntamento, dove vedremo il concetto di Evolutionary Model Archetypes e metteremo a raffronto i due estremi relativi.
Stay tuned J
