Se il Marketing è stretto alle corde, nel nome della tutela della privacy (vedi iOS 14 e GDPR), puntare sul miglioramento continuo delle nostre App e investire in features di Prodotto che le rendano più competitive, sembra una scelta vincente e dall’alto valore strategico.
Lavorare con Prodotto presenta però molte insidie; pertanto, sulla base della mia esperienza professionale, vi propongo 4 consigli utili per l’instaurazione di un clima di proficua collaborazione con l’area tecnologica del Business.
1. Non pensare alla soluzione ma al problema
Pensare di conoscere il Cliente, è un errore fuorviante che spesso conduce a conclusioni affrettate; La conoscenza del Cliente è certamente un asset fondamentale nelle mani del Marketing, tuttavia la complessità dello scenario tecnologico e il suo costante dinamismo, impongono di affidare la soluzione a chi ne ha una visione più approfondita.
Formulate bene il problema e scatenerete la creatività degli sviluppatori e di tutto il team di Prodotto. Portategli invece la vostra soluzione e li troverete pronti a smontarla. A voi la scelta!
2. Ragiona in termini di Business Value (anche quando non lo conosci)
Quando ci innamoriamo di un’idea, finiamo inevitabilmente per pensare che tutti ne colgano il valore intrinseco, anche se non siamo in grado di stimarlo o descriverlo chiaramente.
Spesso, inoltre, trovare dati a supporto delle nostre congetture è così impegnativo che vi rinunciamo in partenza, convinti di poter vendere la bontà delle nostre idee con autorevolezza o capacità di argomentazione.
Risultato? Ottenere l’approvazione e il sostegno degli stakeholder diventa complicato.
La mia raccomandazione è quindi di sopperire alla mancanza di dati con chiare assumptions. Dichiarate quelli che sono i dati mancanti nel modello che userete per determinare il valore delle features di prodotto di cui proponete lo sviluppo e utilizzate valori basati sulle vostre migliori conoscenze in merito.
Quando le assumptions sono indicate in modo chiaro, è più facile seguire i vostri ragionamenti.
Inoltre avrete sempre il tempo di sostituire dati ipotizzati (le vostre assumptions) con stime più raffinate o dati effettivi man mano che le vostre idee prendono forma. Insomma, non fatevi fermare dall’assenza di dati ma dichiaratela.
3. Definite le vostre priorità come le definirebbe Prodotto
Le risorse tecniche che ci consentono di tradurre le nostre idee in miglioramenti concreti delle nostre App sono sempre troppo poche, mentre le esigenze dei clienti sono molteplici e sfidanti. Come uscirne?
Quando si hanno delle priorità chiare, si è senz’altro sulla giusta strada. La mia raccomandazione, a tal proposito, è quella di usare le stesse metodologie di Prodotto per definirle.
Un modello di definizione delle priorità abbastanza in voga è quello del RICE scoring.
Stimate Reach (quanti utenti sarebbero raggiunti dalla vostra feature?), lmpact (quale impatto avrebbe la feature per gli utenti interessati), Confidence (quando siete sicuri dei valori stimati?) ed Effort (quanto costa sviluppare la feature) con una scala a vostro piacere, da mantenere costante per tutte le idee o i progetti che vorrete stimare.
I punteggi così ottenuti vi aiuteranno a definire le vostre priorità e a difenderle presso tutti gli stakeholder aziendali, a partire dal team di Prodotto.
Il metodo del RICE scoring può essere usato in qualsiasi contesto per guidare razionalmente le vostre scelte. Usatelo con profitto!
4. Partite in piccolo e puntate sul miglioramento continuo
Mettere le features che desideriamo nelle mani dei nostri Clienti quanto prima, dev’essere sempre il nostro obiettivo. È a questo proposito che è utile ragionare in termini di MVP, Minimum Viable Product. Qual è il minimo livello di funzionalità che siamo disposti ad accettare pur di rilasciare quanto prima una feature e testarla direttamente su un insieme limitato di consumatori?
Avere chiaro il concetto di MVP ci aiuta a minimizzare l’effort necessario per rilasciare una feature, facilitandone la prioritization. Sempre nell’ambito di una MVP, possiamo individuare una MVP1, la versione più basic che si possa immaginare della nostra feature, e una MVP2, che pur non rappresentando il risultato atteso nella sua completezza, costituisce un miglioramento apprezzabile rispetto alla MVP1 e aiuta a delineare una roadmap evolutiva.
MVP1 + MVP2 + MVP3 + MVPn = MMP
In pratica, con la MVP è possibile capire fin da subito come migliorare la nostra feature, velocizzando il processo evolutivo che porterà al MMP.
Questa volta non parliamo di Mobile Measurement Platform, ma di Minimum Marketable Product, ossia il livello di funzionalità minimo per raggiungere il nostro mercato.
Il concetto è chiaro: perfezionare la nostra app lontano dai suoi utilizzatori non ha alcun senso. L’app migliore in fondo è quella in grado di soddisfare le esigenze dei consumatori grazie ad un processo di costante evoluzione. Done is better than perfect!
