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.
