Lanciare una feature su Web e App: le domande da farsi

In questo articolo parleremo delle domande che un Product Manager dovrebbe farsi prima di lanciare una nuova feature su Web e App Mobile, in un contesto multi-piattaforma.

Successivamente vedremo insieme quali sono i possibili approcci che ho avuto modo di sperimentare durante la mia carriera da Product Manager. Ti porterò quindi degli esempi derivanti da esperienze dirette e non, con il fine di calare nel pratico i concetti che vedremo nell’articolo. Li chiameremo “Esempio di vita vissuta”. 

Indice

• Introduzione
• Considerazioni Tecnologiche
• Il fattore umano
• Considerazioni Funzionali

Introduzione

Se come me lavori su un prodotto digitale multi-piattaforma, molto probabilmente ti sarai ritrovato nella situazione di dover gestire una Roadmap in cui prendere in considerazione le dipendenze tra sito Web e App.

Naturalmente, questo aspetto varia da azienda ad azienda e può dipendere da diversi fattori: Stadio di crescita dell’azienda, Strategia, Obiettivi, infrastruttura tecnologica, competenze disponibili, e così via.

Ho avuto modo di collaborare con aziende di diversa natura e dimensione, e mi sono reso conto che mi é servito pormi le seguenti tipologie di domande:

• Devo modificare la logica di una funzionalità sul sito. Rompo qualcosa sull’app?
• Devo implementare una nuova funzionalità dell’app. Mi serve anche sul sito? Mi servirá?
• Devo implementare una nuova funzionalità dell’app. Sto rinunciando a fare qualcosa di piú importante sul sito?

Ovviamente, vale il viceversa.

Utilizzandole come punto di partenza, ho derivato 3 categorie di “considerazioni” a cui prestare attenzione quando gestiamo un prodotto digitale:

Considerazioni tecnologiche, il fattore umano e considerazioni funzionali.

Vediamole insieme.

Considerazioni Tecnologiche

Per mia fortuna, i team con cui ho collaborato hanno sempre progettato l’infrastruttura IT in modo da avere comunicazioni semplici tra back-end e front-end. Solitamente tramite un layer di API interne.

Ciononostante, mi sono sempre sentito in dovere (o mi é stato caldamente suggerito sin dall’inizio) di prestare attenzione a ciò che viene “toccato” nello sviluppo della logica di una determinata funzionalità.

Il motivo?

“Non si sa mai che modificando la logica per un componente non si scombini qualcos’altro”.

Ed ha sempre ripagato.

Esempio di vita vissuta:

Ora ti parlerò di un progetto che mi é stato raccontato durante una retrospettiva “post mortem” a cui ho partecipato come ascoltatore.

Il progetto è stato portato avanti per tutto il 2019 dal Product Manager di cui ho preso il posto nell’azienda con cui collaboro attualmente.
Innanzitutto devi sapere che i prodotti B2C sono principalmente 2: un sito e un’ app mobile. 

La piattaforma è un’immensa Online Shopping Community, particolarmente attiva in UK, Germania e Francia.
Qui gli utenti si scambiano segnalazioni su deal, errori di prezzo e consigli per il risparmio senza limitazioni sulla tipologia di deal che possono essere postati.
Per questo motivo, una delle sfide principali consiste nel categorizzare i deal al meglio, al fine di facilitarne la ricerca e la consultazione.

Questo lavoro deve essere fatto nel modo più automatizzato e meno incline ad errori possibile.
In questo caso il need da risolvere era legato ad una modifica nel modo in cui veniva mostrata sul sito l’alberatura delle categorie dei deal che, quindi, non avrebbe avuto nessun impatto sull’app mobile. 

In teoria. 

Nella pratica le cose sono andate un po’ diversamente.
Per semplificare lo sviluppo, la soluzione proposta prevedeva di effettuare una piccola modifica delle API utilizzate anche dall’app che, però, non ne sarebbe stata influenzata.
Quando la soluzione è stata testata e rilasciata in staging, i test case sviluppati non tenevano neanche in considerazione un regression test dell’app.
Neanche a dirlo, la release ha impattato anche la visualizzazione delle categorie nell’app, facendo scomparire dal menu tutte quelle di primo livello.
Questa situazione ha costretto il team a dover effettuare un rollback e, quindi al re-work della funzionalità.

Cosa si poteva fare meglio?

Ciò che è emerso anche dalla retrospettiva, é stata una pecca nella comunicazione tra i vari team e la poca challenge sulla soluzione proposta.
Naturalmente, é solo una supposizione, ma forse una di queste due azioni avrebbe potuto prevenire o ridurre l’impatto del problema:

• Richiedere un double check dell’informazione coinvolgendo anche il Mobile Product Manager
• Chiedere a chi ha proposto la soluzione: “Come mai non influisce sulla parte mobile se lavoriamo su API condivise tra le due piattaforme?”, anziché accettare passivamente la soluzione

La conclusione é che, anche se “non siamo tecnici”, la challenge e il testing della soliditá di una soluzione, prima ancora dello sviluppo, non é mai abbastanza.

In ogni caso, state tranquilli… Nessun PM è stato maltrattato o cacciato dall’azienda per questo. Ha deciso spontaneamente di ricollocarsi internamente come Project Manager 🙂

Il Fattore Umano

In questa categoria rientrano, a mio avviso tutte le dipendenze che hanno a che fare con le persone, con le loro competenze e la loro motivazione. 

Dal momento che generalmente gli sviluppatori backend di API lavorano su risorse “condivise” tra applicazione Web e Mobile, vale la pena prendere in considerazione, durante la prioritizzazione di una serie di funzionalità o della costruzione di una roadmap, quali siano i costi opportunità di far lavorare il team su una determinata funzionalità condivisa.

Inoltre non avere timore di coinvolgere i vari team di prodotto nella valutazione delle complessità e nella proposta di soluzioni alternative.
Tuttavia tieni sempre a mente quanto sia importanto stimolare il dialogo e fare challenge sulle soluzioni senza il timore di dire la cosa sbagliata, anche in termini di utilizzo delle risorse disponibili.

Considerazioni Funzionali

L’ultima categoria di considerazioni é forse la più importante.
Si riferisce alle funzionalità che l’una o l’altra piattaforma dovrebbero, quasi citando Amleto, AVERE o NON AVERE.

AVERE

In riferimento al primo caso, potrebbe capitare di dover sviluppare una certa funzionalitá su tutte le piattaforme per servire un bisogno specifico in modo coerente.
Ad esempio, se dai la possibilitá di effettuare il login con Facebook su Web devi garantirlo anche su Mobile. Come fanno i tuoi utenti a loggarsi da App, altrimenti?

In questa categoria, rientrano quindi tutte le feature Core del vostro prodotto che hanno senso di esistere su ogni canale.
Non avrebbe senso, ad esempio, che Netflix permettesse di riprendere la riproduzione del contenuto dal punto in cui l’hai interrotto solo su Web e non su App. Make sense?

Esempio di Vita vissuta

8 Mesi fa, nonostante la pessima documentazione disponibile (ndr), Apple ha reso l’Apple Sign-in obbligatorio su tutte le piattaforme che fornissero almeno un servizio di autenticazione sulla propria app iOS (ie: Facebook o Google Login). In questo caso, nonostante nessuno avesse “voglia” di farlo, abbiamo necessariamente dovuto prevederne l’implementazione anche su Web per consentire agli utenti che avessero utilizzato questa opzione di accedere.

NON AVERE

Nel secondo caso, mi riferisco a tutte quelle funzionalità che hanno senso di esistere solo su una delle due piattaforme ma non necessariamente portano un vantaggio competitivo sull’altra.

“Voglio davvero che i miei utenti possano cancellare la propria Subscription con un click e direttamente da app? Posso farlo con una Web View o magari reindirizzarli al sito?”

Probabilmente é questo che si sono chiesti i product manager di Spotify e Netflix al momento di scegliere e prioritizzare le funzionalitá da implementare nella mobile app.

Ed è quello che mi sono chiesto anche io quando abbiamo deciso di implementare un servizio di subscription.

A questa categoria appartengono anche quelle funzionalitá nice-to-have ma comunque importanti che sviluppo su un solo canale perché voglio aumentare l’adoption del mio prodotto sul canale stesso.

Un esempio molto basic é:
Ho un e-commerce e al checkout su App mobile integro un efficientissimo servizio di card reader. Invece, nella web app ti “costringo” ad inserire i dati della carta manualmente.

L’esempio é a scopo puramente dimostrativo. Nella realtá, il checkout é probabilmente il touchpoint più delicato della User Journey. Ottimizzalo ovunque!

Esempio di Vita vissuta

Questa volta vi racconto la mia esperienza diretta nell’implementazione di una nuova funzionalità sia su web che su app.
Una piccola premessa è, ancora una volta, necessaria. 

In generale, il servizio è un’applicazione sia Web che Mobile che ti permette di effettuare la spesa online, scegliendo i prodotti da uno dei supermercati disponibili nella tua zona, per poi riceverla a casa all’orario desiderato.

Nonostante durante il mio primo anno di permanenza non avessimo ancora implementato gli OKR (arrivati l’anno successivo), risultava chiaro che una delle priorità su cui avremmo dovuto concentrarci era la retention degli utenti e quindi la loro order frequency, ovvero la frequenza con cui un utente effettua un’ordine, al fine di sviluppare un’abitudine di acquisto e legare il cliente al prodotto.
Lo step successivo sarebbe stato quello di incrementare il carrello medio e quindi la profittabilitá di ogni ordine.

Dopo una prima fase di identificazione degli obiettivi, raccolta di idee, valutazione del business case e degli scenari, abbiamo deciso di procedere con lo sviluppo di un servizio di Subscription che permettesse all’utente di effettuare spese (ndr. quasi) “illimitate” senza costi di consegna aggiuntivi, in cambio di una fee mensile o annuale fissa.

Sapevo su cosa avremmo dovuto lavorare ma adesso dovevo trovare l’approccio migliore per sincronizzare i team di sviluppo Web, App, e la relativa parte di design del prodotto, minimizzando i colli di bottiglia.
L’obiettivo era quello di andare live con il MVP su ogni piattaforma per iniziare a valutare la risposta degli utenti al servizio. 

Lanciare un MVP su Web e App in quattro step

Abbiamo quindi adottato un processo in cui é possibile identificare quattro fasi:

Fase Esplorativa (Competitor Benchmarking)

Studiare servizi che avevano implementato un servizio simile e identificare, insieme a Product Designer, Stakeholder di Business e CTO, quale fosse l’obiettivo finale che avremmo voluto raggiungere in termini di funzionalità e UX, in un mondo ideale.
In questo scenario le risorse sono potenzialmente infinite e non abbiamo ancora posto limiti o prioritizzato alcunché. Il risultato é il prodotto ottimo.

Fase Realistica

Con un background tecnico e qualche mese alle spalle di conoscenza del prodotto specifico, ho potuto identificare le parti potenzialmente più complesse del prodotto ottimo definito nella fase precedente, senza andare nei dettagli.
Ho coinvolo gli stessi referenti della fase precedente ed insieme abbiamo definito una possibile UX ad alto livello, separando l’esperienza Web da quella Mobile e definendo quindi due Journey distinte e parzialmente indipendenti, ottenendo quindi un prodotto sub-ottimale.
Ho utilizzato il termine “parzialmente” in quanto il nostro amato team di Product Design ha dovuto effettuare alcune considerazioni specifiche per piattaforma, giá in questa fase.
Vi faccio un esempio: se offro ai miei utenti la possibilità di salvare un prodotto in una lista dei desideri su Web, devo necessariamente prevedere che l’utente possa vedere quello stesso prodotto anche da App Mobile.

Fase VR (Veramente Realistica)

In questa ho coinvolto anche dei referenti Tech, sia lato Web che lato Mobile, per definire il prodotto potenziale.
Sulla base del prodotto sub-ottimale della fase realistica, abbiamo effettuato delle stime più accurate di complessità assumendo che la logica fosse in comune indipendentemente dalla piattaforma.
Abbiamo quindi valutato quali fossero le dipendenze ed elaborato il modello di dati piú adeguato da adottare.
Per quanto riguarda il Front-end, invece, abbiamo considerato la piattaforma Web e quella Mobile in modo indipendente, senza sostanziali differenze tra iOS e Android.
Ricorda che in questa fase l’ipotesi é ancora che tutte le piattaforme offrano lo stesso set di funzionalità

Fase di Cut-Out

Una volta ottenuti gli elementi importanti per il business, le complessitá lato Tech e un’idea della UX abbiamo definito l’MVP.

Quest’ultimo definito come il prodotto che avremmo lanciato e su cui avremmo poi lavorato per i successivi 4-6 sprint. Qui abbiamo fatto valutazioni profonde su cosa fosse veramente necessario avere su tutte le piattaforme affinché:

• La logica fosse consistente e gestita adeguatamente
• L’utente non incontrasse frizioni forti o blocchi che gli impedissero di utilizzare tranquillamente la funzionalitá
• L’impatto delle nostre scelte di prodotto, sulle metriche di business fosse neutro o positivo

Con l’aiuto di alcuni esempi, ti spiego cosa intendo:

La logica che annulla le spese di consegna e una notifica esplicita di consegna gratuita sono funzionalitá necessarie su tutte le piattaforme. 

Permettere all’utente di iscriversi da app mobile non è strettamente necessario ma avrebbe ridotto il numero di utenti iscritti al servizio.
Per contro, permettere all’utente di annullare l’iscrizione dal servizio non é strettamente necessario su tutte le piattaforme e non rema contro l’obiettivo di business.
Abbiamo quindi deciso di semplificare l’implementazione del processo di unsubscription su App e inserire invece un rimando alla funzionalitá su Web.

Un altro aspetto importante trattato in questa fase è quello relativo alla prioritizzazione dello sviluppo dei vari pezzi della feature.
Infatti, non é necessario che il lancio avvenga in perfetta sincronia su tutte le piattaforme, purché la feature sia consistente e ben gestita ovunque.

Al primissimo lancio, ad esempio, abbiamo implementato la possibilità di iscrizione e gestione del servizio solo su Web.
Su Mobile abbiamo reso disponibile soltanto la logica di azzeramento dei costi di consegna per i subscriber.

Il resto delle funzionalità che avevamo deciso di implementare sono state poi prioritizzate e rilasciate successivamente, in modo indipendente.

Come è andata a finire?

Purtroppo siamo andati oltre il Quarter che ci eravamo dati per lanciare l’MVP ma tutto sommato il processo ha funzionato abbastanza bene.
Come avevamo giá ipotizzato, siamo riusciti a lanciare la parte Web prima di quella Mobile.
Abbiamo anche ottenuto degli early finding sul comportamento degli utenti ma erano troppo poco significativi per essere utilizzati prima del lancio sulle piattaforme mobile.

Conclusioni e Riepilogo

Di come gestire un prodotto multipiattaforma si potrebbe parlare per ore ma qui il mio obiettivo era quello di darvi il mio punto di vista su quali potrebbero essere alcuni degli aspetti da considerare, e portarvi qualche esempio che mi auguro sia stato utile per dare pragmaticità ai concetti.

In uno dei miei prossimi articoli, riprenderò il concetto della gestione di un prodotto multipiattaforma e vi parlerò di 3 possibili approcci per disporre i team e prioritizzare le funzionalitá.

Nel frattempo mi piacerebbe sapere cosa ne pensi dell’articolo. Ti é piaciuto?
Quali sono gli strumenti e i processi che usi per lanciare una nuova feature su Web e App?
Hai anche tu qualche esempio di vita vissuta da raccontare?
Fammelo sapere con un commento!