Digital Marketing Technology: A Tale of Two Approaches

For the last nine years, our team at Leapfrog has worked on an integrated technology platform that’s designed to solve a fairly unique problem in digital marketing: the acquisition of customers in high-consideration, complex sales in direct-response categories like Financial Services, Home Services, For-Profit Education and Telecommunications. Unlike physical goods, where a single leading online retailer has set the pattern across industries, digital marketing for services has some unique challenges, especially the fact that differentiating between products is more challenging for consumers, the ordering process can be more involved, and the number of legacy systems tends to be a bit higher.

That alone has made for an interesting nine years, with a modicum of technical challenge and fun problems to solve. And the way we’ve solved those problems has been pretty intriguing on its own right, with a set of agile approaches, and a team-development focus—development of the *team* not just development of the software. But what’s made it much more interesting is the who of the software.

Unlike the majority of software being built today, which is built for either end-users in a software-as-a-service mode, we built a form of what used to be called “expert systems.” And what’s even less common is that we built it for people—co-developed it, really—for a set of knowledgeable users with a very specific understanding of how the domain works, and a well-defined methodology that the software empowers and enables.

Now certainly there are some industries, like healthcare for example, where people are building software that their colleagues operate. But in the world of digital marketing technology, AdTech and MarTech, it’s a far less common thing. And part of the reason is because the standard approach of having the software eat the world has taken firm root. There are so many software-as-a-service providers in the AdTech/MarTech space that the visuals have become impossible to parse.

And there’s a ton of value in a lot of the SaaS that’s been built for marketers. I know; we’ve integrated with a lot of it. But, like most SaaS today, its genealogy is highly defined by the market for software companies. Not market for software, but market for software companies. Software companies grow, generally speaking, through one of two strategies: by either (A) expanding vertically by solving for the entirety of a set of tasks up and down the supply chain of a given business challenge; or (B) by expanding horizontally, by moving into adjacent business domains to deliver an all-encompassing solution for a much broader business domain.

In the world of AdTech and MarTech, think of Optimizely as a very successful example of Strategy A, and the Adobe Marketing Cloud as a very successful example of Strategy B. Both of these approaches have one thing in common: when successful they result in enabling the progressive rounds of funding which (as eloquently described here by William Janeway) are critical to the way enterprise software works today. The former, through venture capital funding; the latter, through mergers and acquisitions of software companies. In both cases, it is a set of considerations largely driven by the market for companies and the investors in those markets, which determine outcomes.

We took a different approach. Leapfrog, which is today a marketing solutions provider, started as a very straightforward pay-for-performance marketing company. This was back in 1999, when most large brands did not have the internal awareness, let alone people, software, or data, to acquire customers online. Google was not yet the AdWords-powered behemoth it is today. There were no display advertising networks. Most companies’ Web sites did not actually try to acquire customers through the full transaction process.

The problem we faced was easy to conceptualized but difficult to solve. In order to get paid, we had to prove to a client—in a repeatable, provable fashion—that it was our specific ad, which was shown to this specific consumer, which resulted in this specific page view, this specific form submit, and the back-office system events it triggered, which all resulted in that same consumer becoming a customer and paying their first month’s bill on this specific date.

The challenge for us was to create a single view of a set of events that took place across disparate and disconnected systems, most of which we did not operate, using a variety of different formats, without shared identifiers, in which the lifecycle of data was inconsistent between sources. The approach we took was one of *instrumentation*  in which we pragmatically link together those things we can control at run-time, while focusing heavily on data management practices that tie together all of the data progressively as it arrived. Not dissimilar in concept from what folks call a lambda architecture today, but with the added fun of having the system consume its own outputs, and incorporate them in its next iteration.

Hindsight makes this look like a pretty decent decision, because most of what challenges marketers today is connecting all of the disparate data together to get insights and intelligence that they can act upon. And while you’d think all of the SaaS that they have purchased would have made it easier, the reverse is true. There’s a strong incentive for SaaS providers to focus on the one thing their SaaS does really well. And unlike enterprise software vendors of days past in which whole economies were built around systems integration, SaaS companies do not benefit economically from being really thoughtful about how their application’s data fits into *all* of the other software that its customers utilize. How could they?

We took a different approach at  Leapfrog. We started with a strategic problem to solve, not a functional problem, and that’s made a ton of difference. Even though the latter approach is easier for  building a classic SaaS-style set of features around, we played a longer-term game oriented around the underpinnings of instrumentation. The ‘special sauce’ of the technology platform our team built at Leapfrog is really the years and years of data and application integration successes and failures. It’s given us a brutally clear understanding of what it takes to do integrations properly, efficiently and scalable, whether we’re dealing with robust, well-documented marketing cloud software, legacy billing systems written in COBOL, or some erratically-delivered spreadsheets from an offshore call center where an IT guy comes by once every few weeks to kick off a manual export. Building a well-defined set of  features on top of that is the (relatively) easy part.

The other thing we did was to work with a set of knowledgeable users. These were marketers inside our company, people who dug into the details, who wanted as much data as they could possibly get to drive better decision-making for our clients. And while there have been discussions over the years that we should move towards making our platform more SaaS-like, there’s a fundamental difference that tends to bring those discussions to a close: we built this software platform to make a complex set of tasks easier.

It’s a great thing in some ways—though not *all* ways—that software is eating the world. But for every business domain in which a really well-designed SaaS solution is super-helpful, there are at least two in which the underlying set of activities do *not* easily lend themselves to the sort of automation that SaaS provides. I’d argue that digital marketing, especially customer acquisition marketing, is one of them.

The actual material, the actual objects of inquiry, the information that marketers need to understand and manipulate in order to make decisions is hard enough. It’s the complex behavior of humans who themselves display a high degree of internal complexity. SaaS in digital marketing has added an additional layer of work for those marketers perform, as they take on the management of their marketing clouds and best-of-breed solutions. The software requires technical people to implement and operate, but technical are trying to make the software run successfully. They cannot also try to make the marketing operate successfully.

So the more humane thing that our platform does for clients is to put the tools to connect data from all of those systems together and manage the operational tasks associated with it for them. We have marketing operations folks perform the complex set of tasks to make sure things are configured and functioning properly for our clients across the parts of their stack we manage and they manage. That way they can focus on using that information to make decisions, which we can then feed back into the integrated stacks to implement. Their SaaS continues to do all of the specialized things that it was explicitly designed to accomplish, and we can make sure all of the pieces fit together.

As I said to a new business prospect a few weeks back, this model and approach is different. But as we’ve found, it just works better. And having built software that works better for its users, not just its investors, as important as they are, makes us an engineering and product development team deeply satisfied.

Vulgo enim dicitur, iucundi acti labores.

The Startup Thing
(History Lesson, Part III)

This week Leapfrog Online held its first Hackathon. It was the culmination of several efforts in the organization around making innovation more tangible, and demonstrating the capabilities of unfettered time to build. We had 14 teams, with well over three-quarters of the company participating, and every single one of the teams’ projects was green-lighted. It was, in the words of our CEO, an “unqualified success.”

We tried something different, and it worked. And the things it produced will add meaningful amounts of business value for our teams, our company and our clients. You can read our blog post on the corporate site for that part. It’s meaningful, but there’s a deeper story.

MinutemenI’m a veteran of the dot-com era, which for me started in the mid-90s. I had a friend at CERN, and a friend at the National Center for Supercomputing Applications. I was in a PhD program at the University of Minnesota1 studying the political economy of technology. The friend at CERN would send both of us stuff about what Tim Berners-Lee was hacking on from time-to-time. Evenually, the friend at NCSA called me up in Minneapolis to try to get me to come back to Chicago to work for this company he was starting up. That friend was Alex Zoghlin and that company was Neoglyphics, the first real Web consulting firm in Chicago.2 I declined, but ended up coming back to Chicago anyway, when my proto-dissertation about how the Internet was going to radically change our socio-economic order was viewed with amused skepticism.

That was the summer of 1995. I started doing freelance Web consulting.3 and was shortly recruited by Playboy Enterprises to begin what would become Playboy Online. Alongside some early experiments from the New York Times, the Chicago Tribune and others, we built one of the earliest online magazines, and definitely one of the first major subscription revenue-model Web sites.

When I was at Playboy, we shared something…special. And it wasn’t about the content, or the brand, or the vibe provided by Hef.4 It was about the people. Most of us came from a variety of semi-related pre-Internet disciplines. Writers. Designers. Nerds. Musicians. Journalists. Theater people. There was only one real software engineer who had formal training. We were all the developer, all the sysadmin, all the UX person, and whatever else was required. We did our best, and it mostly worked.

And it was intriguing that it actually worked, because not only were there no clear guidelines about *how* to do something, but there were also no clear guidelines on even *what* you should do. Various generations of imported management made assertions. Various generations of salespeople from big and small software and consulting firms made more vague, PowerPoint-based assertions. But when it came down to cases, we just had to make it up. More precisely, we thought about it, tried something, and then iterated. There was less a sense of hierarchy, less a sense of rigidity, and more a spirit of adventure in the face of adversity and uncertainty. We made it up as we went along, and it was Good.5

This feeling will be familiar to anyone who has participated in a startup. In fact, every day is like this in a startup. It’s an adventure. There’s a lot of fear and anxiety. There’s a lot of exultation. There’s a lot of crushing loss. It’s not really for the faint-hearted, and if it’s not like that, then maybe you’re not doing it right, or it’s not doing it right for you.

In between the time I left Playboy and started at Leapfrog Online, I did two startups. One of these, Edventions, was started by someone who knew about executing on big ideas. Irv Shapiro’s idea was ahead of its time, an intranet/extranet system in a box, with hardware, software and networking for K-8 school. It was a fantastic idea, but the educational system was not ready for it yet. What made it great was that the Thing I experienced at Playboy was there. And it wasn’t just Irv himself, who was the first CEO I worked with that embodied the Thing, but a meaningful portion of the whole company. They believed in what we were doing, which hadn’t been done before, and it was Good.

I went elsewhere after Edventions was sold, and the Thing was totally gone. Not even part of the scene. I learned to sell, inside and outside. And then I did another start-up. This one was mine. And the horrible part was this: I didn’t create the Thing. I was so worried about the product, the next client, and not going broke that I didn’t even consider it. Terrible.

But when I sold the intellectual property from that startup to Leapfrog Online, the fact that I had been missing the Thing—not even *considering* it as important—came back in an instant. Smart people trying to do something that hadn’t been done before. And real value was being created.

Where was the Thing?

When I arrived at Leapfrog, I began pining for it. The Thing would show up in fits and starts, sometimes in big ways, sometimes in small ways, but it’s much harder to maintain that feeling—which certainly existed during LFO’s startup phase—when you get to medium size. Mid-size companies have unique leadership, strategy and talent challenges, and they’re all about scale and growth.6 Rapid change, but the kind of change that cannot be as nimble as that of a start-up, because the company has different things to prove to its founders and investors and clients. The pressures are different and the solutions to them are about maintaining focus while building out more specialized functions. Not the most conducive to that elusive startup Thing, or so I thought.

Until this week.

I have been trying to recapture that feeling, what it was like at Playboy back in the day, for a long, long time. And during the Hackathon, I felt it. It was glorious. But that was not the best part. The best part was at the *end* of the Hackathon, when I had a chance to sit down and talk with the people I had stayed up all night with, and who really, really got a lot out of it. I realized that THEY felt a Thing—not my Playboy thing—but their *own* version of that class of thing that they could look back on and say “I felt that and I *did* that.” I realized I wasn’t really trying re-create that feeling for myself. What I *was* trying to do was to create it for THEM. And that is really what I’ve been striving for all this time.

So. Pretty please, with sugar on top. Do a Hackathon at your company. Even if you’re not a startup.

  1. Home of Gopher. []
  2. Started with his dad, Gil Zoghlin, whose then-ultra bleeding edge color laser printer we utilized for various nefarious purposes back in high school. []
  3. You had to know sysadmin stuff. You had to know Perl, which was really the only viable language other than C to do stuff in, and you had to have some knowledge of visual design. But most importantly, you had to explain the crazy notion that the “World Wide Web” was critical to the future viability of a mid-size insurance company. Not easy. []
  4. Though producing several live pay-per-view Webcasts from the Playboy mansion certainly delivered its share of amusing anecdotes. []
  5. That it actually worked, to the benefit of the parent company, seemed almost but not quite secondary. []
  6. A point worthy of explanation here, since the challenges of mid-size companies, relative to startups and big corporations, do not get discussed as much in the Internet world. []

Leapfrog Online Profiled in Chicago Tribune

From the February 1, 2010 Chicago Tribune:

Culligan turned to Leapfrog Online for help about a year ago because it liked its quantitative approach. “Finding our target consumer can be difficult,” Rosenthal said.

Leapfrog creates Web pages with specific promotional offers, tracks results and handles search engine keyword buys.

“They report back weekly on, ‘Here’s where we are having success and here’s where we’re not,’ ” Rosenthal said.

The relationship works best through collaboration. Clients must trust Leapfrog Online with their brands because the agency works as a mini-marketing department for them.

Full Article:–20100129,0,3879233.column

Leapfrog Online Makes the Crain’s Fast 50

From Crain’s Chicago Business:

Business is booming at Leapfrog as the popularity of the Internet continues to rise for everything from shopping for shoes to reading the news. In March, 188 million Americans visited Web sites, up 6% from the same month last year. And the marketers are following: Online ad revenues reached $21.1 billion last year, a 25% jump over 2006.

“The online space is growing, and that’s the space we occupy,” says Scott Epskamp, Leapfrog’s president.

Making it happen.