Tony Byrne: Riflettori puntati sull'esperto

In questa nuova serie, scaviamo più a fondo nelle storie dei nostri collaboratori esperti. Questa intervista è stata modificata per chiarezza e lunghezza.

Tony Byrne è il fondatore di Real Story Group, una società di analisti tecnologici. RSG valuta le tecnologie martech e CX per assistere i proprietari di stack tecnologici aziendali. Ci ha parlato dell'essere una testa di formaggio e di come la caduta dell'Unione Sovietica lo abbia avviato sulla strada per fondare RSG.

D: Da dove vieni?

A: Sono cresciuto in Wisconsin, nato nel sud-est del Wisconsin a Milwaukee. e, partito per il college ma, ottieni questo visto di uscita speciale quando lasci il Wisconsin, che è un'uniforme dei Green Bay Packers e una testa di formaggio e tutte queste altre cose. Quindi, in fondo, sono ancora una "Sconnie", come si suol dire. Infatti, stiamo per partire per due settimane nel nord del Wisconsin. Quindi sono entusiasta di questo.

E poi sono andato all'Università di Toronto e alla fine ho ottenuto un master in relazioni internazionali, che non sto davvero usando in questo momento. Ma è stato interessante perché mi ha coinvolto nell'assistenza tecnica nell'ex regione sovietica per lo sviluppo di Internet e gli hub Internet open source. Ed è quello che mi ha portato in questo mondo della tecnologia.

D: Come succede?

R: Era in quello strano periodo in cui era caduto il muro di Berlino, ma la nuova forma di quel mondo non aveva ancora preso forma. Ho guidato questo gruppo che alla fine ha creato quello che abbiamo chiamato Internet Peace Corps. Abbiamo preso giovani studenti di lingua russa tecnicamente esperti e laureati e li abbiamo mandati via con un mucchio di modem e un po' di soldi per andare a lavorare con università e ONG per aiutarli ad andare online. Si è trasformato nell'aiutarli a costruire siti Web quando il World Wide Web è arrivato per aiutarli a costruire comunità e interagire in un mondo non mediato.

Ai tempi dell'Unione Sovietica, sia nell'Europa dell'Est che nell'ex Unione Sovietica, tutte le comunicazioni con i gruppi internazionali erano mediate molto attentamente attraverso un dipartimento internazionale. E così ora c'erano discussioni libere e individuali tra ecologisti in Nevada ed ecologi che lavoravano su siti di test nucleari in Kazakistan e cose del genere. E così abbiamo contribuito a portare in rete un po' di questa società civile emergente. È stato davvero gratificante ed è stato allora che mi sono interessato alla tecnologia stessa e sono diventato uno sviluppatore e sono andato in una direzione diversa.

D: Cosa hai sviluppato?

R: Originariamente era un sito web per la nostra organizzazione non profit e poi abbiamo iniziato a creare alcune applicazioni leggere in Perl. Quindi ho imparato abbastanza Perl da essere pericoloso e fornire alcuni moduli non sicuri e ho imparato PHP e un po 'di javascript quando è emerso. Poi, durante il boom delle dot-com, ho finito per guidare un team di ingegneri presso un integratore di sistemi. Era una di queste agenzie di integratori di sistemi ibridi che avevi a quei tempi.

Siamo stati i primi ad adottare vari sistemi di gestione dei contenuti Web (CMS) alla fine degli anni '90. È stato molto frustrante perché abbiamo letto questi brillanti rapporti di analisti su questi fornitori, spesso fornitori di grandi nomi, che disponevano di questi fantastici strumenti CMS. E in realtà abbiamo avuto esperienza pratica con questi strumenti.
C'era un enorme divario tra ciò che stavamo leggendo nei rapporti degli analisti tradizionali e la nostra esperienza come implementatori e ho pensato che dovessero davvero essere un modo migliore per raccontare la vera storia.

Così mi sono messo in proprio e ho fondato CMS Watch, l'organizzazione precursore di Real Story Group. Una delle decisioni che abbiamo preso all'inizio, che ho scoperto in seguito essere unica nel mondo degli analisti, è che abbiamo deciso di lavorare solo sul lato degli acquisti. Lavoreremmo solo con le imprese degli utenti finali e non consiglieremmo o consulteremmo mai i fornitori perché pensavamo che si trattasse di un conflitto di interessi.

A: Che ha portato a...?

D: Abbiamo deciso di fare qualcosa di leggermente diverso. Stavamo solo lavorando e la nostra empatia era orientata solo verso i licenziatari e gli utilizzatori di queste piattaforme. Tutta la nostra ricerca sarebbe orientata verso di loro. Nel corso del tempo ci siamo resi conto che esiste un intero ecosistema di tecnologie che necessitava di questo tipo di analisi. Quindi, abbiamo iniziato a occuparci della gestione delle risorse digitali, degli strumenti di personalizzazione dell'email marketing e, infine, negli ultimi anni, dei CDP e dei motori di orchestrazione del viaggio e di ogni sorta di cose. Siamo ancora una società di analisi. Valutiamo ancora questi singoli fornitori e probabilmente abbiamo le critiche più dure là fuori. Ma esaminiamo anche lo stack nel suo insieme, come dovresti organizzare il tuo stack e quali sono alcuni modelli di riferimento per questo e quel genere di cose. Quindi è tutto in poche parole.

Q: Cosa dovrebbero sapere tutti quando mettono insieme uno stack?

R: I venditori di suite vogliono che tu acquisti i loro prodotti. Ed è un discorso molto seducente quello che stanno facendo e nel bene e nel male, penso soprattutto nel peggio, è un discorso molto efficace perché uno stack tecnologico è una cosa intrinsecamente complicata. È un organismo che non vuole sempre andare nella direzione che vuoi tu.

Quindi c'è la sensazione che se trasformo tutto in un singolo fornitore il più possibile, in qualche modo ciò semplificherà la mia vita e questo fornitore sarà responsabile del mio successo, ma in realtà non è quello che succede. Sei ancora responsabile del tuo successo. La realtà è che nemmeno Adobe, Salesforce, Microsoft, Oracle e Acoustic possono comunque estendersi all'intero stack. Quindi avrai uno stack composito. L'unica domanda è come composito.

Nella nostra esperienza, le organizzazioni hanno un tasso di successo più elevato e una maggiore adozione se sono molto deliberate riguardo agli strumenti che introducono e li introducono in un processo basato su test piuttosto che adottarli perché provengono da un fornitore storico.