Tony Byrne: Der Experte im Rampenlicht

In dieser neuen Serie tauchen wir tiefer in die Geschichten unserer Experten ein. Dieses Interview wurde aus Gründen der Klarheit und Länge bearbeitet.

Tony Byrne ist Gründer der Real Story Group, einem Technologieanalyseunternehmen. RSG evaluiert Martech- und CX-Technologien, um Besitzer von Enterprise-Tech-Stacks zu unterstützen. Er sprach mit uns darüber, wie er ein Käsefresser war und wie der Fall der Sowjetunion ihn auf den Weg brachte, RSG zu gründen.

F: Woher kommst du?

A: Ich bin in Wisconsin aufgewachsen und im Südosten von Wisconsin in Milwaukee geboren. Und als ich aufs College ging, bekommt man dieses spezielle Ausreisevisum, wenn man Wisconsin verlässt, nämlich eine Uniform der Green Bay Packers, einen Cheesehead und all diese anderen Sachen. Tief im Inneren bin ich immer noch ein „Sconnie“, wie man sagt. Tatsächlich sind wir im Begriff, für zwei Wochen in Nordwisconsin aufzubrechen. Deshalb freue ich mich darüber.

Und dann bin ich an die University of Toronto gegangen und habe schließlich einen Master in Internationalen Beziehungen gemacht, den ich derzeit nicht wirklich nutze. Aber es war interessant, weil es mich dazu brachte, mich in der ehemaligen Sowjetregion mit technischer Hilfe rund um die Internetentwicklung und Open-Source-Internet-Hubs zu befassen. Und das hat mich in diese Welt der Technologie gebracht.

F: Wie passiert das?

A: Das war in dieser seltsamen Zeit, als die Berliner Mauer gefallen war, aber die neue Form dieser Welt hatte noch keine Gestalt angenommen. Ich leitete diese Gruppe, die schließlich das gründete, was wir Internet Peace Corps nannten. Wir nahmen junge, technisch versierte Russischsprachige Studenten und Postgraduierte und schickten sie mit einem Haufen Modems und etwas Geld los, um mit Universitäten und NGOs zusammenzuarbeiten und ihnen dabei zu helfen, online zu gehen. Als das World Wide Web kam, um ihnen beim Aufbau von Communities und der Interaktion in einer unmittelbaren Welt zu helfen, wurde daraus die Unterstützung beim Aufbau von Websites.

Zu Sowjetzeiten wurde sowohl in Osteuropa als auch in der ehemaligen Sowjetunion die gesamte Kommunikation mit internationalen Gruppen sehr sorgfältig über eine internationale Abteilung vermittelt. Und so gab es jetzt ungehinderte Einzelgespräche zwischen Ökologen in Nevada und Ökologen, die an Atomteststandorten in Kasachstan arbeiten, und ähnliches. Und so haben wir dazu beigetragen, einen Teil dieser entstehenden Zivilgesellschaft ins Netz zu bringen. Das war wirklich lohnend und da begann ich, mich für die Technologie selbst zu interessieren, wurde Entwickler und schlug eine ganz andere Richtung ein.

F: Was haben Sie entwickelt?

A: Ursprünglich war es eine Website für unsere gemeinnützige Organisation, und dann begannen wir mit der Entwicklung einiger einfacher Anwendungen in Perl. Also brachte ich mir genug Perl bei, um gefährlich zu sein und einige unsichere Module bereitzustellen, und lernte PHP und ein wenig Javascript, als es auftauchte. Dann, während des Dotcom-Booms, leitete ich schließlich ein Engineering-Team bei einem Systemintegrator. Es war eine dieser hybriden Systemintegrator-Agenturen, die es damals gab.

Wir gehörten Ende der 90er Jahre zu den ersten Anwendern verschiedener Web-Content-Management-Systeme (CMS). Es war sehr frustrierend, weil wir diese begeisterten Analystenberichte über diese Anbieter, oft namhafte Anbieter, gelesen hatten, die über diese großartigen CMS-Tools verfügten. Und wir hatten tatsächlich praktische Erfahrungen mit diesen Tools.
Es gab eine große Lücke zwischen dem, was wir in traditionellen Analystenberichten lasen, und unserer Erfahrung als Implementierer, und ich dachte, dass sie wirklich eine bessere Möglichkeit sein sollten, die wahre Geschichte zu erzählen.

Also machte ich mich selbstständig und gründete CMS Watch, die Vorläuferorganisation der Real Story Group. Eine der Entscheidungen, die wir schon früh getroffen haben und die, wie ich später herausfand, einzigartig in der Analystenwelt war, bestand darin, nur auf der Käuferseite zu arbeiten. Wir würden nur mit Endverbraucherunternehmen zusammenarbeiten und niemals Anbieter beraten oder konsultieren, weil wir dachten, dass dies ein Interessenkonflikt sei.

A: Was führte zu …?

F: Wir haben beschlossen, etwas anderes zu machen. Wir wollten nur arbeiten und unser Einfühlungsvermögen nur auf die Lizenznehmer und Anwender dieser Plattformen richten. Unsere gesamte Forschung wäre auf sie ausgerichtet. Mit der Zeit wurde uns klar, dass es ein ganzes Ökosystem von Technologien gibt, die diese Art der Analyse benötigen. Also haben wir begonnen, uns mit Digital Asset Management, E-Mail-Marketing-Personalisierungstools und in den letzten Jahren schließlich auch mit CDPs und Journey Orchestration Engines und allen möglichen Dingen zu befassen. Wir sind immer noch ein Analystenhaus. Wir bewerten immer noch diese einzelnen Anbieter und haben wahrscheinlich die härtesten Kritiken überhaupt. Aber wir betrachten auch den Stack als Ganzes, wie Sie Ihren Stack organisieren sollten und welche Referenzmodelle es für diese und jene Dinge gibt. Das ist es also in aller Kürze.

F: Was sollte jeder wissen, wenn er einen Stapel zusammenstellt?

A: Suite-Anbieter möchten, dass Sie ihre Produkte kaufen. Und es ist ein sehr verführerischer Pitch, den sie machen, und im Guten wie im Schlechten, ich denke vor allem im Schlechten, es ist ein sehr effektiver Pitch, weil ein Tech-Stack von Natur aus eine komplizierte Sache ist. Es ist ein Organismus, der nicht immer in die gewünschte Richtung gehen möchte.

Ich habe also das Gefühl, dass es mein Leben irgendwie einfacher macht, wenn ich alles so weit wie möglich an einen einzigen Anbieter weitergebe, und dieser Anbieter für meinen Erfolg verantwortlich sein wird, aber das ist nicht wirklich der Fall. Sie sind immer noch für Ihren eigenen Erfolg verantwortlich. Die Realität ist, dass ohnehin nicht einmal Adobe und Salesforce und Microsoft und Oracle und Acoustic Ihren gesamten Stack abdecken können. Sie erhalten also einen zusammengesetzten Stapel. Die Frage ist nur, wie zusammengesetzt.

Unserer Erfahrung nach haben Unternehmen eine höhere Erfolgsquote und eine größere Akzeptanz, wenn sie die Tools, die sie einführen, sehr bewusst einsetzen und sie in einen testbasierten Prozess einbinden, anstatt sie einzuführen, weil sie von einem etablierten Anbieter stammen.