Il checkin non è una recensione. Ecco perchè Foursquare perderà una montagna di soldi

Tweet

Poco più di una settimana fa la crew di Foursquare è riuscita a chiudere il quarto - per altro non facile - round di finanziamento. 41M di $ concessi a Foursquare per testare il business model - basati su una valutazione di 700M di $ della società, come riporta Techcrunch.

Non pochi per testare il business model di un'azienda che è sul mercato dal 2009 e che aveva già raccolto 30M di euro. A quanto pare i precedenti finanziamenti sono serviti per portare sulla piattaforma oltre 25milioni di utenti. Non certo pochi, come non sono pochi i 5milioni di utenti attivi (mensili) che si loggano tramite Facebook (fonte Appdata). Meno incoraggiante è però il rapporto tra utenti giornalieri e utenti mensili che si attesta al 10% - rapporto che è una riconosciuta KPI per misurare la stickyness di un'app ovvero la capacità di fidelizzare per un periodo di tempo- prolungato (mese) gli utenti.

 

Quale sarebbe dunque questo modello di business su cui Foursquare riporrebbe la speranza di generare un ROI positivo? Semplicemente la traslitterazione del modello di Google - keyword advertising - sulla geolocalizzazione. Con la promessa che chi clicca poi visita realmente i luoghi publicizzati. Cerco una venue su Foursquare oppure una tipologia di locali (pizzeria, etc) e questi mi mostra sia risultati organici e risultati sponsorizzati. Dove a determinare la rilevanza di un risultato è principalmente la prossimità geografica (ovvero la speranza di generare pedonalità reale)



Di pari passo con il nuovo round è il restyling massiccio che Crowley & co hanno rilasciato nelle settimane scorso. Un restyling che incentiva la ricerca e valorizza meglio il checkin come perno di un sistema di raccomandazione delle venues.


Il restyling ha dato origine ad una sorta di "Foursquare on steroids" - un miglioramento - indubbiamente - da ogni punto di vista. Ma c'è un però. Foursquare è ora in versione gran gala. Ma non è che Foursquare on steroids è una fabbrica di soldi laddove quello senza makeup era un pozzo senza fondo. Foursquare resta Foursquare anche perchè il restyling non tocca il cuore dell'app.

Un app che ha non pochi problemi, come segnala VentureBeat: "Foursquare has a user intent problem." Che cosa fanno gli utenti su Foursquare - cercano e si divertono con i badge, scovano sconti, scoprono luoghi dove andare? Tutto e niente a quanto pare - teorizzano su VentureBeat.


Il problema di Foursquare resta perfettamente intatto anche con il recente restyling. Io lo riassumo così: IL CHECKIN NON E' UNA RECENSIONE. Questa ambiguità persiste immutata.

La recensione segnala un luogo e ne descrive le caratteristiche. Il checkin segnala la presenza dell'utente che la fa. E' autoreferenziale. Una sorta di messaggio lanciato da una destinazione nota in una bottiglietta dai vetri trasparenti.

Facciamo un esempio. Sapere che un amico ha fatto un checkin in un luogo qualche tempo fa è un'informazione del tutto irrilevante. Al contrario, leggere la recensione di un luogo da parte di un amico (o anche non amico) è rilevante - se questa è avvenuta in un time range significativo e mi da informazioni rilevanti sul luogo dove pianifico di andare. Sostanzialmente questa è la differenza tra Yelp e Foursquare. Recensioni = utili per capire un luogo. Checkin = utili per capire una persona


Ora immaginate di avere a disposizione un'app che vi permette di sapere che in questo esatto momento c'è una persona interessante oppure la vostra anima gemella - esattamente nel posto dove state per andare o dove siamo già - questo si che sarebbe rilevante.Quest'app potrebbe farci decidere se andare in un posto o in un altro. O rimanere comodamente in casa.

Ho sempre pensato che Foursquare fosse l'app di cui sopra - la terra promessa per conoscere nuove persone e/o entrare maggiormente in contatto con quelle che si conoscono. Anche perchè il checkin non dice nulla su un luogo - ma dice qualcosa della persona che lo fa. Ecco la differenza tra Yelp e Foursquare.

Yelp è un motore di ricerca di luoghi - incentrato sul concetto di user review. l'azione fondante di Yelp è la review - un'azione dell'utente che fa seguito alla permanenza in un luogo: l'opinione di chi c'è stato. Foursquare è un motore di ricerca di persone. Il checkin si fa nel momento in cui si arriva un posto Poi si pensa ad altro. Il checkin è un messaggio nella bottiglia. Si fa prima, si fa a prescindere. Si fa per dire: ci sono anche io. L'esserci è in real-time. Non è una recensione.

Eppure Foursquare non riesce a considerare le conseguenze del checkin. Il checkin è geniale. Ed è molto più grande di quello che ne fa Foursquare. Ed è un'azione spiccatamente social. Foursquare spreca la più grande opportunità di creare un social network integrato nel mondo vero. La vera nemesi di Facebook.

Immaginate questo scenario. Sto per andare in un locale, e guardo Foursquare per sapere chi c'è - non solo tra gli amici (non c'è mai nessuno), ma anche tra gli amici degli amici - o persino connessioni di secondo e terzo grado. Basterebbe che Foursquare integrasse la logica di Banjo per mostrare se nella location a cui siamo interessati ci sono gli amici degli amici e altre connessione più indirette. Con i volumi che ha e l'integrazione con Facebook potrebbe riuscirci.

E poi potrebbe raccontarci qualcosa di queste connessioni, per esempio che cosa abbiamo in comune con loro (integrando l'incredibile grafo sociale di Facebook). Improvvisamente i luoghi si animerebbero e diventerebbero trasparenti. Il mondo diventerebbe più connesso, avremmo più strumenti per decidere se entrare o non entrare in un luogo, in un locale, ad un evento.

Foursquare in questo modo potrebbe innescare meccanismi di incontro e dating. Se c'è un motivo per cui Facebook è esploso come un vulcano e non hai mai smesso di farlo è perchè fondamentalmente è sempre stato uno strumento per connettersi (e conoscere) persone. Una forma di casual dating super-soft - qualunque cosa se ne voglia pensare.

Foursquare è un macchina per connettere persone, ma non lo sa. Insegue la chimera del checkin come strumento di recensione dei luoghi. Foursquare non ha alcun valore come strumento per trovare la pizzeria giusta. Se vado a managiare la pizza, voglio sapere se è buona. Non se il mio amico Pippo ha fatto checkin 3 giorni fa.

Mancando totalmente questa sensibilità social, prevedo lo sperpero dei 41M$ - anche perchè Foursquare non è più cool, non ha più traction, non interessa i giovani (che tirano) e come user review tool è incredibilmente debole.

Flipboard. Content curation sul mobile

Tweet

La content curation è un'esperienza tipicamente PC e/o desktop. Basti pensare agli esempi più eclatanti: Tumblr e Pinterest. In entrambi casi,  l'app - Android e iOS - è un prolungamento zoppicante dell'esperienza web (nel caso di Pinterest presenta anche una serie di contraddizioni)

In un certo senso, la content curation non può essere adeguatamente espletata adeguatamente a livello mobile. Se consideriamo i due meccanismi/plugins che consentono la cura dei contenuti - ovvero il bookmarklet (per la cura di contenuti esterni alla piattaforma) e secondariamente la ricondivisione (retweet, reblog, repin) per curare contenuti interni alla piattaforma. E' evidente che il mobile è un ecosistema impervio per la prima forma di curation (dall'esterno all'interno)

Il bookmarklet (plugin essenziale per tutte le piattaforme di curation - da Storify a Pinterest, da Scoop.it a Paper.li)- è un'esperienza non immediata su un browser mobile, anche per un utente avanzato un power user. Che è molto improbabile diventi un'esperienza mainstream. Qui un tutorial realizzato da Flipboard

La conseguenza di questo scenario eterogeneo tra browser web e browser mobile o apps - è l'apparentemente sbandamento di molte piattaforme di content curation che fanno fatica a gestire l'esperienza mobile in maniera adeguata. Si pensi a Pinterest che incentra la UX dell'app sul caricamento di foto - un non sense che ne snatura anche il probabile business model incentrato sull'affiliazione (traffico verso siti) - oppure di Scoop.it che su mobile e iPad si presenta come Read.it - ovvero un'app di fruizione di contenuti e non di curation

In definitiva, la curation a livello mobile zoppica per definizione, in quanto la parte di import dall'esterno tramite bookmarklet non è percorribile come forma di esperienza mainstream e di conseguenza le piattaforme possono trarre nutrimento solo da contenuti "già presenti" all'interno della piattaforma (trovo un contenuto interessante su pinterest e lo "ri-pinno" - repin - tra le mie boards, trovo un post interessante su tumblr e lo "ri-bloggo" - reblog)

Ma anche l'esperienza di ricondivisione da interno a interno non è stata - finora - sviluppata con schemi di UX tipicamente mobile. Si pensi al layout a doppia colonna di Pinterest che non favorisce
certo un'esperienza di discovery autentica (immagini troppo piccole), nonchè la gestione arzigogolata della selezione del board e la descrizione del pin strutturata in più schermate per pinnare - un lento e farraginoso progetto.

Curiosamente Flipboard - la più famosa piattaforma di social reading e aggregatore di news per iPad e smartphone - si è trovato ad "osservare" il problema da un punto di vista differente. Gli utenti su Flipboard aggregano rss feeds, importano streams (da Twitter, da Facebook) dai gruppi e da qualunque social a cui partecipano. Sostanzialmente in quanto evoluzione mobile di un Rss Reader, Flipboard si è trovato
ad essere il centro dell'esperienza di raccolta informativa sul web - non un walled garden come Pinterest o Tumblr - ma piuttosto come un rivisualizzatore di ciò che "già" seguiamo sul web.

Su Flipboard si può navigare - quasi come se fosse un browser più che un semplice reader - su una quantità eterogenea di contenuti - alcuni offerti dalla redazione e altri importati "una volta per tutte" dai nostri feeds e stream che seguiamo abitualmente. Grazie alla vastità delle API su cui interagisce, Flipboard è molto più di un RSS reader, che permette di seguire i publishers, ma è anche uno strumento di social e content discovery (tramite il collegamento agli stream social)

Curiosamente, solo pochi giorni fa, Flipboard ha annunciato il lancio di un servizio di content curation - ovvero di creazione di magazine personalizzati all'interno della piattaforma - che possono essere condivisi con gli amici, resi pubblici su Flipboard e/o mantenuti privati. Sostanzialmente l'utente può inserire nei custom magazine, i contenuti che scopre tramite la piattaforma

Rispetto a Pinterest e Tumblr - l'esperienza di Flipboard è un'esperienza di scoperta aperta - in quanto si nutre di streams continuamente aggiornati provenienti da ogni fonte. Fonti - ovviamente selezionate/scelte dall'utente (rss feeds), oppure direttamente collegate a lui (gruppi che segue, twitter streams, etc). Detto in altro modo, per l'utente che cura contenuti su Flipboard non si pone il problema di rilevare contenuti all'interno di Flipboard - quindi non necessità di nessun plugins per la propria attività.

Per contro, tanto Pinterest che Tumblr forniscono un'esperienza di scoperta "chiusa" - tutti i contenuti che trovo su queste piattaforme social vi sono stati inseriti - uno ad uno. I contenuti che afferiscono a Flipboard sono potenzialmente infiniti e non dipendono dalla pro-attività della sua community.

La risultante è che Flipboard rende più fluida - e labile - la differenza tra esterno (contenuti da importare tramite bookmarklet) e interno (contenuti da ricondividere) e questo gli consente di entrare a gamba tesa nella nicchia - ancora scoperta - della content curation mobile, con un vantaggio di prodotto rispetto a Tumblr e Pinterest. E altri player. 

E non sono in pochi che sottolineano come Flipboard sia entrato minacciosamente nel territorio di Pinterest e Tumblr. Durante la prime 24 ore del lancio sono stati creati più di 100000 magazines, segno che la community era pronta e sensibile a questo lancio. D'altra parte - se ci si pensa - la catalogazione e la cura dei contenuti e' da sempre stata un'esperienza fondante degli rss reader (creazione cartelle e sottocartelle) La differenza fondamentale sta nel fatto che Flipboard trasforma quella pratica di catalogazione 1.0 in una forma di content curation 2.0 - pubblica, social e formattata in una forma visiva elegante - quella del magazine. Un po' come fa Paper.li

In realtà, il risultato finale - il magazine - ricorda più Scoop.it. I contenuti non vengono generati attraverso un sistema di filtri e algoritmi come accade in Paper.li o attraverso un sistema di ricerca social come in Storify. Piuttosto vengono selezionati dall'utente - attraverso la logica del pickup come in Scoop.it

All'unità formale del blog - come in Tumblr - o dello stream di pins - come Pinterest, Flipboard preferisce quella del magazine. Gli utenti non creano blogs, ma sorte di riviste online che aggregano contenuti presi dalla rete aperta di Flipboard (e/o tramite il bookmarklet a livello desktop). Indubbiamente, il magazine sembra più coerente con l'impostazione visiva e l'esperienza di Flipboard, e forse è anche più vicino alla sensibilità  dei grossi publishers - già presenti sulla piattaforma - che potrebbero creare magazine ad hoc per Flipboard - puntando ad una diversficazione dei followers o alla creazione di progetti completamente ad hoc (se non advertising based).

Altrettanto vero è però che il magazine frammenta e depersonalizza l'esperienza di curation - rendendone più complessa la gestione. Non è un caso che Paper.li che incentra la propria user experience sulla creazione di magazine, lo fa con un sistema automatizzato ("Build and forget it"). E non è un caso che Pinterest che chiede all'utente di strutturare i propri contenuti attraverso le boards (simili per certi versi al concetto di magazine di Flipboard) mostra nello stream i singoli pins - a prescindere dall'unità di cui sono parte. Questo rende meno disincentivante la pubblicazione di pins. Perchè sono proprio questi l'unità di comunicazione, la grammatica visiva di Pinterest.

All'apposto le singole news che entrano nei magazine non appaiono su uno streaming separato di contenuti. Questo rende complesso da gestire, il problema della notifica ai subscribers di aggiornamenti nei magazines, nonchè la visualizzazione degli aggiornamenti (dove vedo i contenuti nuovi di un magazine che seguo?). Problema che Paper.li e altre piattaforme di content curation hanno affrontato con la logica delle "editions" (Paper.li) oppure con quella delle storie (semi-chiuse) come Storify. E in effetti, nel caso di Storify il subscribe si riferisce - per conseguenza di questo - all'utente e non alla storia. Mentre Flipboard richiede all'utente di iscriversi ai magazine - che però se non viene pensata adeguatamente la parte di notifications e visualizzazione degli aggiornamenti ai subscribers - rischiano di nascere morti. Ovvero di non generare traction, mancando un motivo forte per venire seguiti e di conseguenza per venire proseguiti dai curators.

Il problema del matching nei location based social network – chicken egg revisited

Tweet

Sempre di più vedo applicazioni mobile (e startup) che provano a lavorare sull’idea di location based social network – sia in un contesto business che di dating. In molti casi (Highlight, Grindr) il problema o meglio la value proposition sulla quale lavorano questi servizi – è quello di consentire all’utente di incontrare/conoscere persone nuove e rilevanti – per loro - nei pressi di dove si trovano.

Il fatto è che dietro a questa utopistica e auspicabile opportunità si nasconde un problema – che per certi versi ricorda il chicken egg problem di cui abbiamo già parlato –  e in una forma difficilmente risolvibile – ovvero il matching spazio-temporale tra le persone che dovrebbero incontrarsi tramite l’applicazione

Nei location - che siano social o dating nello specifico - services – serve un matching spazio-temporale tra più utenti. Altrimenti l’app non ha senso – o meglio la parte di geolocalizzazione della value proposition non ha ragione d’essere presente. Facciamo un esempio che potrebbe riguardare un contesto di dating. Immaginiamo uno scenario altamente favorevole al buon funzionamento dell’app.  Ci troviamo in una città molto popolata (Milano), in una zona vicino al centro. Apriamo l’app e – mettiamo che abbia raggiunto una buona traction nella nostra città – e ci aspettiamo di avere buone possibilità di trovare persone interessanti in un raggio tale da consentire un incontro. Senza questa ragionevole possibilità – il location based service è inutile. Uno specchietto per le allodole, senza utilità.

Il problema è che se si considerano tutte le variabili in gioco – la ragionevole possibilità diventa un improbabile eventualità. Innanzitutto deve esserci un match spaziale. Due persone devono trovarsi in un raggio di prossimità. Un raggio d’azione che renda possibile un eventuale incontro – o almeno la possibilità di questo. In secondo luogo deve esserci un match temporale. Ovvero un tempo comune per dirottare le rotte ed eventualmente decidere di incontrarsi. In questo caso matching spaziale e temporale, convergono sull’asse del tempo reale. L'interesse reciproco deve manifestarsi hic et nunc.

A questi due elementi si aggiungono le modalità di matching specifiche dell’app. Ovvero che le due persone abbiamo un interesse reciproco ad incontrarsi (attrazione, opportunità professionale, disponibilità) e che lo scoprano “molto velocemente”(quindi sistemi di notification, alerts vari) Sia di tipo push (avvertire che c'è una persona nei paraggi che corrisponde ad un set di criteri) che pull (ovvero generati da azioni più specifiche dell'utente, interessi a qualcuno, qualcuno vuole conoscerti, etc). Location based fa rima con tempo reale. E gli elementi in gioco sono tanti (tempo, spazio, obiettivi comuni, tempo reale dell'app stessa)

La conseguenza di questo accumulo di variabili è che l’insieme intersezione che dovrebbe definire i soggetti disponibili per un matching positivo è sempre vuoto. Tanto per fare un esempio è raro trovare una persona a meno di 500metri su siti ampiamente utilizzati come Badoo o Highlight. E – tanto per ricordarlo – 500 metri è una distanza che non consente nessun incontro (a parte rarissimi casi, vedremo in seguito). Allo stato attuale delle cose solo una base utenti come quella di Facebook potrebbe consentire un proximity people discovery network (che sia dating, o amicizia, o networking). Il problema è che Facebook è completamente incentrato sulle relazioni esistenti più che su nuove conoscenze. Ma non è escluso che possa lanciare apps di questo tipo in modalità standalone - visto il recentissimo interesse anche per il discovery di cose & persone - nuove. (vedi lancio del Facebook Messanger, vedi acquisizione della tecnologia di Glancee, vedi il lancio del Graph Search)

 

La metafora sarebbe quella dell’incontro casuale e fortunato – pilotato. Sali sul tram, lanci un occhiata, vieni ricambiato e pensi che quello sia un incontro importante per la tua vita. I location based social services recuperano quella metafora e la trasformano tecnologicamente. Apro l’app - invece di guardarmi attorno - e do una "sbandata" digitale invece di approcciare timidamente qualcuno. Il vantaggio dell'approccio tecnologico dovrebbe consistere nella riduzione del margine di errore: verifichi la presenza di interessi in comune, lo stato sentimentale, la disponibilità ad un incontro. Raggi X relazionali.

Ma è un’utopia. Nella maggior parte delle cose sembra più un sogno adolescenziale che un'opportunità reale.

In che modo le startup che operano su questo territorio labilissimo affrontano la questione del matching? Guardando al mercato si possono individuare almeno 3 soluzioni

Generalizzazione del goal 

E’ il caso per esempio di Highlight – l’applicazione che mostra gliutenti che sono vicini a noi lanciata lo scorso anno al SXSW– che lavora in background e sfrutta il grafo sociale di facebook, indicandoci se le persone nei paraggi – su un raggio d’azione che va da qualche centinaio di metri a qualche chilometro - hanno contatti in comune con noi e/o interessi comuni. In pratica non si propone come un’app di networking, ne’ di dating, ma come un social discovery di prossimità. Il problema è che espandendo le maglie, perde incisività e specificità, e lato end users lascia molto incerto il tipo di opportunità che può nascere dal tipo di persone che ci passano vicino (sono single? lavorano in aziende che mi interessano? etcetc)

Il rischio in questo caso è chiaramente la vacuità del servizio (pointless) e la domanda sorge spontanea: a che cosa serve Highlight, perché dovrei usarlo? Tra l’altro questa indecisione – nel caso di Highlight – si manifesta anche nell’azione fondante l’app – ovvero l’evidenziare un utente (highlight) – che altro non è che una forma blanda – ma non per questo meno stupida - di stalking. Evidenziare un utente avrebbe come conseguenza quello di restare aggiornati sui suoi spostamenti (e considerando che non si tratta di checkin ma di aggiornamento in background - non siamo molto lontani dalla logica del pedinamento). E d'altra parte l'azione core della UX di Highlight non potrebbe essere il contatto/o il volere incontrare qualcuno. Perchè non sussistono le condizioni di un matching user to user. Ne è chiaro perchè dovrei incontrare tali persone

Verticalizzazione del target 

A volte è il tema che si tratta e il target che si cerca di raggiungere a far la differenza. E’ il caso di Grindr l’app di dating geolocal per gay che ha avuto un successo enorme negli Stati Uniti e in alcune nazioni europee (strepitosa la performance di Grindr a Londra http://en.wikipedia.org/wiki/Grindr con quasi 400K downloads)

Il successo è stato talmente stellare da avere addirittura provocato un aumento di sifilide in alcune città della Nuova Zelanda, secondo un report pubblicato su The Examiner. In questo caso – non me ne vogliano i lettori gay di questo blog – la vivacità sociale di alcune parti della comunità gay ha preso alla lettera il senso di Grindr – in quanto hookup tool di prossimità per avere incontri occasionali e appassionati. Il matching in tempo reale in questo caso ha incontrato perfettamente il desiderio di incontrare altre persone e dirottare le proprie rotte per incontrare quelle altrui.

Il problema è che i verticali con le caratteristiche di cui sopra  sono molto pochi. Il dating per gay è più un eccezione che una regola. Un verticale con caratteristiche analoghe potrebbe essere legato a situazioni acute o di emergenza dove incontrare persone potrebbe essere molto importante (flashmobs, forme di mobilitazione, emergenza territoriale, etc). Oppure in contesti dove la vicinanza è coatta, duratura nel tempo (eventi, scuole, grandi aziende). In tutti questi casi app che geolocalizzano le persone accumunate da qualche cosa potrebbero favorire la socializzazione, l'incontro, le relazioni.

Immaginiamoci di trovarci in un locale molto frequentato e pieno di persone - e di vedere molte persone interessanti - ma di non capire quali persone potrebbero essere interessate a noi. E' l'esempio di partenza in un certo senso, ma c'è una variabile specifica completamente differente. E' un locale/evento - e' pieno di persone, e l'app svolge una funzione di facilitatore di relazioni sociale rese possibile dalla presenza reale degli interessati in un luogo fisico condiviso.

Su questo punto va però fatta un'osservazione a livello di UX. Oggi la maggior parte delle apps location based di dating o di discovery lavorano in background - tracciando i movimenti delle persone in maniera costante e implicita. Il che però - non me ne vogliano gli sviluppatori  - è un non sense per due ragioni.

In primo luogo incappa nella principale criticità del mobile, ovvero la durata della batteria. Con 2-3 apps che lavorano in background tramite GPS una carica di batteria si consuma in 3-4 ore.

In secondo luogo - questo è l'aspetto che mi interessa maggiormente - la distanza misurata in background è aleatoria, la persona che ci interessa potrebbe essere in macchina, in autobus oppure vicino 100metri in linea d'aria, ma a un'ora di distanza (si trova dall'altra parte dei binari di una ferrovia). L'unica modalità sensata di definizione della prossimità di un location based social è il checkin.

Il checkin definisce una presenza costante, reale. Noi siamo abituati al checkin di Foursquare - un'azione percepita come inutile - anche dai più solidali utilizzatori dell'app. Ma che potrebbe acquisire nuovo valore nel momento in cui il checkin servisse a incontrare persone (invece che sbloccare badge). In un dating, il checkin in un locale potrebbe indicare - non solo la presenza fisica - ma anche la disponibilità a conoscere persone nuove. Una sorta di "feromone wifi".

Ho espresso seri dubbi sulla sensatezza del checkin come elemento core della UX di Foursquare - in quanto il reward dell'azione è estrinseco ed estemporaneo: faccio checkin perchè forse c'è un badge (chissenefrega) o uno specials (ma non c'è quasi mai, e chissenefrega comunque). Nel caso però dei proximity dating e social network, il checkin indicherebbe una presenza reale - non aleatoria. Nonchè un segnale di disponibilità all'incontro. L'antidoto all'approccio imbarazzato e rivolto alla persona sbagliata - che si diceva all'inizio.

Arricchito di questa possibilità (non certezza) il checkin diventerebbe assolutamente sexy e sarebbe la condizione che rende possibile qualcosa percepito come di valore dall'utente. 

Da questo punto di vista, mi permetterei di suggerire ai founders di Foursquare - impegnati ormai dal 2011 in un neverending brainstorming su quale linea dare al prodotto - una virata forte verso il dating o quanto meno il "meet new people in amazing venues"

Diversificazione della value proposition

L’altra opzione è quella di rendere il match via proximity una possibilità non univoca dell’app. E’ il caso per esempio di Banjo che sta progressivamente virando (pivoting) da app finalizzata a conoscere persone –  proximity people discovery - attraverso il grafo sociale dei social  - ad app che permette di scoprire i luoghi attraverso gli amici in un senso più generale (luoghi frequentati, attività sociali in luoghi ravvicinati), in un modo non molto diverso da quello che stanno facendo app come Vamos e altre. Banjo permette agli utenti di sindicare i contenuti postati su Facebook, Twitter, Instagram e in questo modo popola - senza sforzo - di contenuti la piattaforma. Inoltre mette a disposizione degli utenti una chat che consente di comunicare in tempo reale con le persone. Tuttavia l'attenzione sui contenuti sposta il focus dall'incontrare/scoprire persone interessanti - legate a noi direttamente (amici) o indirettamente (amici di amici) - allo scoprire/conoscere luoghi frequentati/fotografati da queste persone (Foursquare meet Instagram)

Anche in questo caso il rischio è che l’app diventi completamente pointless. Caso diverso è dato dalla situazione in cui un’app mantiene il suo valore anche nel caso in cui non avvenga l’incontro vero e proprio e la proximity fisica è semplicemente un modo per capire se possono esserci - in un secondo momento - le condizioni necessarie per un incontro reale- Si pensi per esempio alle tante apps di dating (da Badoo a Tinder) – dove la geolocalizzazione è una sorta di radar che gli utenti utilizzano per capire se una persona interessante vive a una distanza compatibile con una frequentazione. Ma in questo caso la vicinanza è più un driver motivazionale che una value proposition.

Come i marketplace digitali devono affrontare il chicken egg problem

Tweet

Del chicken egg problem ne ho già parlato in precedenza, quando ho analizzato uno dei paradossi di Pinterest. Esso rappresenta una delle difficoltà concettuali e di strategia più importanti per una startup ai suoi inizi. Il chicken egg problem consiste nel fatto che il valore di una piattaforma per un categoria di utilizzatori dipende dalla presenza di altra categoria di utilizzatori distinta - però - dalla prima. Non riguarda tutte le startup - ma unicamente quella tipologia che vengono definite multi-side business o two-side business - dove il funzionamento corretto della piattaforma dipende dalla co-presenza di differenti categorie di utilizzatori. Un esempio tipico sono i marketplace come eBay - il cui valore per gli utenti finali è dato dall'ampia disponibilità di merchants. E viceversa. Oppure i siti di dating, dove il valore per gli uomini sta nel trovare un numero sufficiente di donne da conoscere. E viceversa.

Il viceversa va preso però con le pinze. Le esigenze delle due categorie che appartengono ad un network multiside sono sostanzialmente diverse. Basti pensare al caso dating. Per gli uomini l'esigenza fondamentale è quella di avere la possibilità di conoscere un numero consistente ragazze. Per le ragazze principalmente si tratta di mettersi in mostra in un contesto che privilegi la privacy, la sicurezza, nonchè la qualità dei potenziali partners. Caso diverso è quello dei social network che devono affrontare una variante specifica del chicken egg problem che è il network effect, che definisce un algoritmo secondo cui il valore della piattaforma aumenta con l'aumentare del numero di utilizzatori.

In questo post vorrei parlare di un contesto particolare - quello dei marketplaces di contenuti digitali- come gli appstores, i marketplaces di plugins, le piattaforme videoludiche - che rappresentano una tipologia molto importante di piattaforme two-side e che devono affrontare in maniera prioritaria la problematica del chicken egg. I marketplace di contenuti digitali sono paradigmatici, in quanto mostrano in maniera evidente tutte le difficoltà di un chicken egg problem - ma anche forniscono molte idee e spunti per affrontarlo con successo. Un esempio di successo davanti agli occhi di tutti è quello dell'AppStore della Apple, un esempio meno di successo "fu" l'Ovi Store di Nokia.


Qui di seguito 5 aspetti fondamentali per affrontare il chicken egg per i marketplace di contenuti digitali

1. Capire dove sta il valore
E' fondamentale capire da quale delle due parti viene generato valore. Perchè questa tenderà ad attrarre l'altra parte. Nel caso del dating - solo apparentemente molto lontano - il valore è nella parte femminile del database. Quindi lo sforzo del marketing dovrà essere rivolto nell'attrarre questo lato del chicken egg. Nel caso di un app store il valore è nella qualità e nella varietà delle apps. Dunque attrarre i producers è la priorità assoluta. Molto più che attrarre gli utenti finali. Non solo. Organizzare l'offerta in termini di assortimento e varietà delle apps disponibili, diventa poi uno strumento efficace per attrarre i consumatori. In quanto si è generato il polo che da valore alla piattaforma.

2. Creare casi di successo
E' fondamentale per attrarre producers fornire loro la sensazione di poter ottenere un successo dall'uso della piattaforma. Questa sensazione non può che derivare che da una serie di casi di successo. Udemy racconta in modo molto affascinante la loro crescita come marketplace di corsi digitali su Quora e si sofferma proprio sul fatto che la creazione di alcuni casi di successo è stato uno dei principali driver per la crescita della piattaforma e l'afflusso di nuovi teachers. D'altra parte non bisogna dimenticarsi, che i produttori di contenuti di un marketplace sono generalmente professionisti alla ricerca di visibilità - se non addirittura ricavi. Di conseguenza creare una prima serie di casi di successi significa creare un esempio positivo ed edificante da seguire.


3. Cominciare da se' stessi - per creare i primi case studies
Quando la piattaforma è vuota - e mancano i producers e gli utenti finali - l'appeal è approssimativamente zero. E' questo il momento "zero" del chicken egg problem. In questa fase, attirare i producers è impossibile. Non ci sono utenti, non ci sono case histories, non ci sono case successes, non c'è nulla. Il driver per iscriversi ed essere ingaggiati come producers è assimilabile allo zero assoluto.
Apple quando lanciò l'iPhone non aveva un'appstore. Ma aveva già "preloaded" sull'Iphone alcune apps. Queste apps dovevano servire da esempi e best practices per lo sviluppo di nuove apps, nonchè da base per costruire case histories di successo (numero downloads di apps, etc). Le apps erano create da Apple. Cominciare da se' stessi. E' un tema ricorrente nelle prime fasi di crescita di piattaforme di contenuti digitali. Su Quora trovate il bellissimo racconto del courses acquisition manager di Udemy che racconta come i primi corsi sul sito erano stati sviluppati e tenuti proprio dal team interno di Udemy. E quelli direttamente successivi furono stati tenuti dalla cerchia interna di conoscenze del team. Una piattaforma non nasce dal nulla, si sviluppa gradualmente da un modello molto più semplice. Nasce come un ecommerce (dove l'azienda eroga un servizio e producers=team dell'azienda) e diventa pian pianino una piattaforma. Quindi non è un caso se in molti stanno facendo così. E' nella logica delle cose. I producers non utilizzano una piattaforma vuota, hanno bisogno di case histories, di casi di successo, di best practices. Le prime apps autoctone generano anche quel minimo di traction sul pubblico che permette di fidelizzare una base utenti minimale.

4. Fare in modo che siano i producers a portare gli utenti finali
Un modo per uscire da un contesto di chicken egg problem è quello di fare in modo che aggredendo una delle due categorie sia poi questa a promuovere la piattaforma sull'altra. Questo accade in tutti quei casi in cui il marketplace/piattaforma offre ai producers degli strumenti abilitanti - non soltanto facilitanti. Si pensi ad un sistema videoludico come la Playstation oppure il Wii. In questo caso far parte della piattaforma consente agli sviluppatori di giochi la distribuzione. Non è un fattore favorente la distribuzione, ma abilitante a tutti gli effetti. Non dissimile il caso di Youtube, oggi più che mai Youtube non è solo distribuzione ma anche creazione, traduzione, ottimizzazione di contenuti video. E' abilitante. Questo favorisce da parte dei produttori un'attività di comarketing con la piattaforma stessa. Su queste dinamiche suggerisco questo approfondimento

Se la piattaforma abilita il mercato dei producers questi avranno tutto l'interesse a promuovere le loro attività all'interno della piattaforma. Da questo punto di vista si pensi a eBay, e a tutte le funzionalità che ha implementato per rendere la piattaforma altamente funzionale, efficiente, performante per i merchants. Su Ebay questi non solo trovano un mercato ma anche una struttura che facilita loro le attività di fatturazione, negoziazione, conflittualità con i clienti.

Bolla Pinterest?

Tweet

Ho scritto un post per il blog Pinterestitaly  sull'ultimo round di Pinterest di 200M$ a una valutazione di 2,5B$. La questione è: esiste una bolla speculativa intorno a Pinterest, o no? Io credo che esista, ma Dite anche voi la vostra

Colgo l'occasione per ringraziare i ragazzi di Pinterestitaly ovvero nell'ordine  (ma non nell'ordine) Domenico Armatore, Paola Sangiovanni, Azzurra Tacente - per l'ospitalità

Quel pulsante sbagliato nell'app iOS di Pinterest

Tweet

A volte si vedono in giro degli errori così grossolani, che si stenta a crederci. Ho avuto questa sensazione quando ho usato per la prima volta l'app iOS di Pinterest. Non è l'app nell'insieme a non funzionare. Ma alcune parti mi lasciano veramente perplesso. Per accorgersi del problema basta dare un occhiata allo screenshot qui sotto. Che cosa c'è che non va? Anzi direi: che cosa c'è che "assolutamente" non ha alcun senso?

L'icona della camera - senza dubbio. Il bottone centrale nel footer ha una funzione assolutamente lontana dalla user experience di Pinterest. Apre la camera e permette di fare foto e caricarle nelle board. Una funzione apparentemente ovvia, ma che ribalta in toto il product-market fit di Pinterest.

Su questo blog ne ho parlato fino allo sfinimento, Pinterest si inserisce nel filone della content curation - e vede il core della  user experience nel bookmarklet e nel repin. Sono queste le due azioni attraverso cui gli utenti possono curare contenuti - importandoli dall'esterno con il bookmarklet; e selezionandoli dall'interno con il repin. Gran parte di quello che Pinterest è (infinite scrolling, repin, bookmarklet, layout a mosaico) ruota intorno all'obiettivo di aiutare gli utenti a trovare contenuti interessanti e inserirli nelle proprie board di interesse. In una parola: content curation.

In questo quadro non c'è spazio - logico - per una funzionalità che consente di uploadare le foto appena scattate. Non ha alcun senso. E' lontanissimo da ciò che rappresenta Pinterest. Sia per i power users, che lo usano - come vetrina - per curare contenuti rilevanti per il proprio settore, che per i casual users che lo usano - come destination - per trovare contenuti interessanti. Pinterest come foto app non ha veramente alcun senso. 

C'è un attenuante? Solo apparente. Come si dice su SocialTimes l'uso del bookmarklet a livello di browser mobile o a livello dell'app è sostanzialmente un'eventualità impossibile. Per pinnare contenuti su Pinterest da mobile ci sono due possibilità, la prima consiste nel salvare le immagini che si trovano navigando nella cartella immagini del dispositivo e poi pinnarle. La seconda nell'istallare un codice, salvarlo, inserire uno script, modificarlo etc per usare il consueto bookmarklet (tutorial qui). Mission Impossible per il 99% degli utenti. Ma ancora più Mission Impossible è la risposta di Pinterest a questo problema: non serve il bookmarklet, consentiamo agli utenti di caricare le foto che scattano. Così plachiamo il bisogno di pubblicare contenuti...

Un attimo, cliccate su rewind: content curation ≠ user generated content, giusto?

A Pinterest succede l'esatto inverso di quello che accade a Instagram. Mentre Instagram è un'esperienza nativamente mobile (phone camera - filtri - upload), Pinterest è un app nativamente desktop (scoperta contenuti - pin attraverso il bookmarklet). Il problema - a livello di digital strategy - è che core della user experience di Pinterest non può essere adattato - senza grane - all'esperienza mobile. E il problema ancora più grave è che Pinterest trasforma la propria identità per consentire un uso della piattaforma analogo tra desktop e mobile. Ma il pin non è un upload. E' la content curation non ha niente a che vedere con gli "user generated contents" che hanno reso grande Instagram.

Scelta rischiosa, soprattutto se si pensa al trend dei social di oggi che stanno molto attenti a definire una propria esperienza core. D'altro canto - se non è addirittura l'altro lato della medaglia - La crescita di Pinterest si è assestata e il lancio delle apps - sia Android che iOS (nativa anche per iPad) non hanno ridato slancio alla traiettoria. A prova - probabilmente - che il mobile non può essere il core dell'esperienza di Pinterest. La snaturamento dunque non ha modificato la crescita ma ha certamente impattato sul concetto stesso di product - market - fit di Pinterest. Ovvero sul problema a cui Pinterest risponde e la risposta che ne viene data. Se Pinterest è il luogo dove trovi contenuti interessanti e lo strumento che ti permette di acquisirli. Perchè spingere sull'upload di foto da cellulare? Tra l'altro senza filtri i contenuti uploadati da cellulari - sono tutt'altro che interessanti.

A complicare lo scenario è il fatto che sul terreno della content curation si sta muovendo in maniera decisa Tumblr - la cui crescita non cenna a diminuire e che a livello mobile, ulteriormente accentua la sua dimensione di piattaforma di ricondivisione e curation. La competizione tra Tumblr e Pinterest si farà ancora più netta nel 2013, quando sarà chiaro che entrambi competono sulla stessa nicchia di market-fit - ovvero la curation di contenuti interessanti ed entrambi ambiscono ad essere spazi di scoperta

Ma c'è di più. Il problema del bottone di upload nell'app iOS di Pinterest non è soltanto una feature che induce una percezione di Pinterest app differente da quello che è Pinterest desktop - ma  fatto ancora più grave, distoglie l'attenzione dall'uso di Pinterest come luogo di scoperta, ovvero come destination, wunderkammer di contenuti fantastici. E questo dimostra - mi permetto di dirlo - una certa impreparazione del team di Pinterest - in quanto l'esperienze della scoperta di contenuti è fortemente penalizzata sul mobile e quindi un servizio come Pinterest che ormai include miliardi di contenuti indicizzati e categorizzati sarebbe assolutamente avvincente, o quanto meno andrebbe a rispondere ad un'esigenza vivissima. Peccato che non l'abbiamo considerato tale i suoi founders.

I tablet come vettori di contenuti: la lotta fra Amazon e Google

Tweet

Sono passati 3 anni circa da quando Apple presentò il primo iPad, un prodotto discusso che inizialmente sembrava non avere un vero e proprio scopo. Con il tempo e il grande gradimento del pubblico è apparso chiaro che le tavolette avrebbero modificato fortemente il computing personale soprattutto nella fruizione dei contenuti multimediali.

 Ad oggi il prodotto della casa di Cupertino è ancora il dominatore del mercato e ha da poco guadagnato un “fratellino minore” destinato a mettere in difficoltà la concorrenza. Non per questo la battaglia fra gli inseguitori è meno interessante, con Amazon e Google che competono duramente per conquistare una quota di mercato significativa e rinunciano a guadagnare sull’hardware per massimizzare la diffusione. Lo fanno per motivi molto diversi e un confronto è utile per comprendere i modelli e le strategie delle due aziende.

UN VETTORE DI CONTENUTI
Amazon vende molte cose ma se possiamo definire il suo core business – questione non facile anche per via dell’avarizia con la quale la società rivela i dati sulla propria attività – è quello della vendita di media di tutti i tipi, dai libri in formato digitale e non, ai film e alla musica. E’ noto che avere il controllo della distribuzione aiuta il business e nel mondo sempre più digitalizzato la distribuzione vuol dire il tablet. Così il Kindle Fire è apparso nell’autunno del 2011 – poi rinnovato nel 2012 – con lo scopo di consentire ai clienti della compagnia di fruire i contenuti digitali ad un prezzo accessibile. Solo 200 dollari per tavoletta. Amazon aveva già provato una simile esperienza con i primi Kindle, gli e-book reader. Nulla di nuovo salvo il vettore in se stesso. Google scende in campo A metà 2012 Google scende in campo con un proprio tablet. Prodotto fisicamente da ASUS e venduto allo stesso prezzo del Kindle Fire, il Nexus 7 è un bel pezzo di hardware che vanta una risoluzione davvero elevata (1280x800) considerata l’esigua diagonale.

Cosa ha spinto la casa di Mountain View ad entrare in campo? Il loro business non si basa sulla creazione di contenuti ma ci sono altre ragioni rilevanti. Innanzitutto Android aveva un dannato bisogno di un tablet “di massa”. I pochi modelli presenti non attiravano il pubblico e gli sviluppatori snobbavano le app specifiche per il “grande piccolo schermo”. Questo è un problema quando si cerca di strappare quote di mercato da un’azienda come Apple. E i prodotti di Motorola, ASUS e Samsung non erano neanche economici. Inoltre l’utilizzo da parte di Amazon di un sistema operativo derivato da Android – ma customizzato pesantemente – rappresentava una “ingerenza” nell’attività del colosso delle ricerche. Non solo i tablet con il robottino non guadagnavano trazione ma chi vendeva era un free rider che sfruttava i 200 milioni annuali che Google investe sul sistema (stima di Horace Dediu per l’anno 2012 -) senza restituire un centesimo. Un vero e proprio affronto.


IL PASSATO PROSSIMO
Il resto è storia davvero recente. Amazon ha aggiornato la sua famiglia aggiungendo un tablet da 8.9” mentre Google ha partorito il Nexus 10 e dato una rivisitata “competitiva” ai prezzi. Chi ha vinto? Parlando di numeri puri Amazon () e il merito lo deve all’interesse che destano i suoi contenuti oltre all’immensa forza commerciale, aspetto sul quale Google non riesce a rivaleggiare. Non bisogna dimenticare che nonostante entrambi i colossi giochino la guerra dei prezzi soltanto uno può permettersi di produrre i volumi che desidera. BigG si rivolge a Samsung, ASUS e LG per i suoi prodotti, di fatto si pone in concorrenza con loro. Voi sareste disposti a vendere per un fornitore una soluzione concorrente alle vostre per giunta ad un prezzo più basso e con hardware migliore? Probabilmente solo se lautamente ricompensati. Ed è per questo che i Nexus non sono così diffusi eccezion fatta del Nexus 7 che è l’unico sviluppato per vendere volumi significativi.

HARDWARE COME COMMODITY
A prescindere dai risultati di queste due aziende appare evidente come i distributori di contenuti possano beneficiare dal mettere in commercio tavolette economiche per incrementare le proprie vendite o sostenere il passaggio al digitale. L’hardware non è più il fine ultimo dell’acquisto ma solo una piccola parte di esso, una porta d’accesso ad un “universo” di servizi e prodotti che consentono al venditore di guadagnare. Quando questo si chiama Amazon la merce venduta sono libri, canzoni, film e via dicendo. Quando si parla di Google si vende pubblicità e i clienti sono gli inserzionisti. Per entrambi maggiore è la diffusione e più incisive sono le strategie. Il rischio maggiore è per i vecchi – tradizionali – produttori OEM che subiscono una forma di competizione impari. Quando a praticarla è BigG possono far valere la loro forza contrattuale in quanto partner ma con Amazon questo non è possibile, con la beffa di un sistema aperto – meno di quanto non si creda - che viene “chiuso” ad uso e beneficio di chi capita. In questo caso Bezos, in futuro chissà.

AUTORE: Davide Costantini
Di giorno mi occupo di marketing per una società di sviluppo software mentre la notte indosso il costume del blogger. Scrivo di strategie competitive dei colossi della Silicon Valley e business hi-tech. Ho fondato Hymn to Future sul quale pubblico i miei lavori.