Tony Byrne: Spotlight on the expert

In this new series, we dig deeper into the stories of our expert contributors. This interview has been edited for clarity and length.

Tony Byrne is founder of Real Story Group, a technology analyst firm. RSG evaluates martech and CX technologies to assist enterprise tech stack owners. He talked to us about being a cheesehead and how the fall of the Soviet Union started him down the path to founding RSG.

Q: Where are you from?

A: I grew up in Wisconsin, born in southeastern Wisconsin in Milwaukee. and, left for college but, you get this special exit visa when you leave Wisconsin, which is a Green Bay Packers uniform and a cheesehead and all this other stuff. So deep down, I’m still, very much a “Sconnie,” as they say. In fact, we’re about to head off for two weeks in northern Wisconsin. So I’m excited about that.

And then I went to the University of Toronto and ultimately got a master’s in international relations, which I’m not really using right now. But it was interesting because it did get me involved in technical assistance in the former Soviet region around internet development and open-source internet hubs. And that’s what got me into this world of technology. 

Q: How does that happen?

A: This was in that strange period when the Berlin Wall had fallen, but the new shape of that world had not yet taken shape. I led this group that ultimately created what we called an Internet Peace Corps. We took young, technically savvy Russian-speaking, undergrads and post-grads and sent them off with a bunch of modems and a bit of money to go work with universities and NGOs to help them get online. It morphed into helping them build websites when the World Wide Web came to help them build communities and interact in an unmediated world. 

In the Soviet days, both in Eastern Europe and the former Soviet Union, all communications with international groups were very carefully mediated through an international department. And so now there were unfettered, one-to-one discussions between ecologists in Nevada and ecologists working on nuclear test sites in Kazakhstan and just stuff like that. And so we helped bring some of this emerging civil society onto the net. That was really rewarding and that’s when I got interested in the technology itself and became a developer and went in kind of a different direction.

Q: What did you develop?

A:  It was originally a website for our nonprofit and then we started building some light applications in Perl. So I taught myself enough Perl to be dangerous and deliver some insecure modules and learned PHP and a little bit of javascript when it emerged. Then, during the dot-com boom, I ended up leading an engineering team at a systems integrator. It was one of these hybrid system integrator agencies that you had back in those days. 

We were early adopters of various web content management systems (CMSs) in the late ‘90s. It was very frustrating because we’d read these glowing analyst reports about these vendors, often big-name vendors, who had these awesome CMS tools. And we actually had hands-on experience with these tools.
There was a huge gap between what we were reading in traditional analyst reports and our experience as implementors and I thought that they really should be a better way to tell the real story. 

So I went out on my own and founded CMS Watch which was the precursor organization to Real Story Group. One of the decisions that we made early on, which I discovered later was unique in the analyst world, is we decided to only work on the buy side. We would only work with end-user enterprises and never advise or consult with vendors because we thought that that was a conflict of interest.

A: Which led to…?

Q: We decided we would do something a little bit different. We were only gonna work and only have our empathy oriented towards the licensees and adopters of these platforms. All of our research would be bent toward them. Over time we came to realize that there’s a whole ecosystem of technologies that needed this type of analysis. So, we started covering digital asset management, email marketing personalization tools, and ultimately, in recent years, CDPs and journey orchestration engines and all sorts of things. We’re still an analyst firm. We still evaluate these individual vendors and probably have the toughest critiques out there. But we also look at the stack as a whole, how you should organize your stack, and what are some reference models for that and that sort of thing. So that’s it in a nutshell. 

Q: What should everyone know when they’re putting together a stack?

A: Suite vendors want you to buy their products. And it’s a very seductive pitch that they’re making and for better or worse, I think mostly for worse, it’s a very effective pitch because a tech stack is an inherently complicated thing. It’s an organism that doesn’t always want to go in the direction you want. 

So there’s a sense that if I just render it all into a single vendor as much as I can, somehow that will simplify my life and this vendor will be accountable for my success, but that’s not actually what happens. You’re still accountable for your own success. The reality is that not even Adobe and Salesforce and Microsoft and Oracle and Acoustic can stretch across your whole stack anyway. So you’re going to have a composite stack. The only question is how composite.

In our experience, organizations have a higher success rate and greater adoption if they’re very deliberate about the tools that they bring in and they bring them in on a test-based process rather than adopting them because they came from an incumbent vendor.