Applying Microservices Design to the Martech Stack: Lessons Learned

The following is adapted from my presentation at MarTech Europe in November 2016.

—

Peter Thiel has a great question: “What secret do you believe in that few other people do?”

In marketing, a better version today is “what marketing tech do you believe in that few other people do?”

With 3,874 known marketing technologies available, one way to gain an advantage in the market is to identify a technology that your competition doesn’t or cannot use.

Microservices makes this possible.

Why Microservices?

This is the boring background part, but its important.

Microservices is a concept from software development. Here are some of the key principles as they apply to marketing tech:

· Flexible, independently deployable apps

· Apps communicate over network to increase revenue

· Platform-agnostic protocols

· Apps should be lightweight (because YAGNI)

· Independently deployable

· Emergent architecture (because Conway’s Law)

Lightweight apps, independently deployable

If you want to start a Martech Unicorn, you’ll have to eventually become an overweight app that does everything and begs to be the system of record. Fortunately for their sanity, recent founders have ceded this position, seeking instead to be the best tool to solve specific use cases.

This is great news, because 59% of companies do not fully use the marketing technology they have available. And, most likely, the remaining 41% of companies don’t even know they do not fully use the marketing technology they have available.

As the YAGNI rule explains, “You aren’t going to need it.” Implementing the best tools for specific use cases allows you to adopt lightweight apps with inherently better stability.

Emergent Architecture

An important principle here is Conway’s Law:

Any organization that designs a system will inevitably produce a design whose structure is a copy of the organization’s communication structure.”

When you fully architect a system in advance, you end up creating a system that matches your org structure, limiting your future agility. Worse, when you buy a single platform off the shelf, you inherit the communication structure of that vendor.

With Microservices, you can apply an emergent architecture. As your organization changes, your tools can change to reflect this.

Key to this architecture is separating your system of record from your desired features. You shouldn’t be limited to a specific CRM or Marketing Automation platform just because they have your data in a walled garden.

Instead, you adopt the minimum pipes needed to get everything working in concert. Or not: many companies with one platform still operate in silos, so adopting separate tools without connection is not nearly as bad as it sounds, compared to industry norms.

Platform-agnostic protocols

In the last decade we’ve seen a huge increase in APIs:

Marketing technology is no exception: tools I’ve seen launch in the last 24 months generally start with APIs rather than leave them as an afterthought. This makes it possible to integrate them with almost anything.

In contrast, many tools launched in the aughts only added APIs when they were required to win enterprise deals.

When apps use APIs by default, they can communicate across the network to get things done. This shifts some complexity up to the network, sure, but with standardized network protocols this is less of a concern.

If you’ve ever tried to use a REST API dashboard add-on to a platform, you’ll understand: getting data out of one aged API is far more difficult than pulling data from 20 modern APIs.

Why Now?

Many of these trends have been germinating for years, but in the last few months this concept quickly moved from a visionary topic to almost a standard: according to a Walker Sands report just released, an integrated best of breed architecture is the most popular model among those willing to discuss their marketing stacks.

I believe this shift will continue and remain, for three reasons:

· Accelerating speed of technology

· Accelerating learning curve

· A fundamentally new business model

The accelerating speed of technology

The speed of Martech innovations is increasing, and monoliths simply cannot keep up. This great pair of images from Sangram Viajre expresses it well:

With the previous waves of innovation, it was possible for an innovative technology to ride a 5–10 year cycle from early adopters to cash cow. It was predictable and it moved closely with the speed of organizations.

New technologies move far faster than organizations: organizations generally grow logarithmically, while technology grows exponentially.

The standard response is for an organization to buy tools from large, established companies: what you lose in innovative features you make up by avoiding the dissonance between the speed of innovation and the speed of your organization.

This response is reasonable, intelligent, and wrong.

As Andrew Chen put it:

The corollary: in order to win, you need to get to a marketing strategy early, if not first.

As Taylor Pearson explains, the first banner ad had a 458x higher click-through rate than the average ad today. He continues:

If you gave me the choice between having the best professional email marketing copywriter in the world write emails today or having an eleven year old write them, but he gets to go back in a time machine and get 1998 click-through rates, I would absolutely take the eleven year old (it’s not even close).

Microservices architecture won’t take you back to 1998, but it can get you closer to this kind of result today.

The accelerated learning curve

If speed is about implementing what you know, the second factor is discovering what you don’t know.

Marketing moves fast, so its almost necessarily true that this generation of marketers is self-taught: 85% of marketers report they are in fact “self-taught”.

But self-taught actually means “I search Google when I don’t know the answer.”

This, again, is a reasonable approach, for many things. If you want to know how to format an email, or some of the common words to avoid using in subject lines, or the regulations around Spam, Google is great.

This has resulted however in a Google-Industrial complex: companies know what you’ll search for, and they produce content that frames their products as the best solution.

Worse, they may only read their own marketing collateral, leading to echo chambers where the platforms themselves don’t know what others are doing.

So you end up with a company like RelateIQ building a disruptive CRM based on a simple principle of less data entry, and Salesforce has to pay $350M to take it off the market.

In our networked world, the Innovator’s Dilemma increasingly is not “how do I innovate without cannibalizing existing revenue” but “how do I keep up with new trends?”

A new business model

It didn’t start with Slack, but they made other entrepreneurs believe.

Product-led growth is like a bubble: it has been predicted so many times, we don’t actually realize when the prediction will become true.

Developers generally prefer to make things people want, and ignore sales and marketing, but until recently this wasn’t too sustainable.

With Slack, and tools like it, we see a model that can sustain product-led growth.

Consider this chart showing the split between marketing, product, and overhead/profits. Salesforce championed the High Growth Software model, realizing in 2000 the key to sell was… to sell. And this worked: many Unicorns adopted the same model, prioritizing a great business over a great product:

What Slack taught us, however, is that the Inverted Enterprise model works better today: you can actually win by building a superior product. In 2016, great products spread, especially in tech, where the typical high performer changes jobs as often as they change phones.

As marketers, this doesn’t bode well for our job prospects: the best companies spend less money on what we do. But as buyers of Martech, this means we can use better products. And that can mean the difference between a great CTR and a shitty CTR.

But wait, are these new tools so busy building features that they don’t get customers? You can’t risk buying from a company that is going to disappear next year.

It turns out some of these tools have numbers that dwarf the Unicorns:

Anyone who uses Marketo, Adobe, or Hubspot would likely say: tens of thousands of customers is robust enough; no one questions their stability.

But look past the logo, and the actual backbone of most Microservices is Amazon Web Services, home to 1.8M customers, 100x more than any of these platforms.

Gone are the days of SaaS startups launching from a laptop under a desk: the default move is to start with AWS.

The last one on the chart is even more interesting. Mailchimp is my go-to option to send a weekly newsletter, and they’ve been around for quite some years. Many of their customers never pay (a luxury of Microservices), but interestingly they have 10x more customers than even AWS.

Not all Martech Microservices will reach this scale, but when a tool is $0–20 per month and solves one clear problem, getting to millions of customers is far easier. And the number of active customers is likely a far better indicator of robustness than the margin a vendor can negotiate with an enterprise customer.

Results

So I’m watching all of this for a few years, and I wanted to explore this architecture as far back as 2014, but every time I looked at the price comparisons I couldn’t quite make the switch.

Then I looked this year, and I found I could save 80%, and get better features.

Here’s a glimpse of how Microservices features compare to the two platforms I know:

This isn’t a knock on Marketo or Hubspot: they are both good platforms. But so often we see a comparison of one platform to another, and no one mentions there is an alternative that ignores platforms altogether.

For example: reply-rate tracking is a key feature of sales outbound email tools for years and a strategy that leads to better engagement. But marketing platforms have ignored it because their customers didn’t know to even ask for it.

Another obvious feature: sending emails by time zone. Marketo users will recount the hours it took to wrangle the tool to send one email blast around the globe, while Mailchimp users will smile and say “what you can’t just check a box?”

The stack

Here is a glimpse of what my stack looks like:

Your needs will vary, of course, and you may need different tools. The important part is the flexibility: with Segment pushing events to BigQuery, I’m not tied to one CRM or marketing automation tool.

This allows some strange choices. For example, I use Drip for lead nurturing and Mailchimp for newsletters. Most marketers would choose only one of these, but I’ve found they are both far better at one use case, and the pricing still makes it less than one platform.

The full migration was less than 55 hours, which is incredible considering a similar process took my over 2,000 hours in 2008.

Again, your needs will be different: I chose to consolidate blog posts, remove forms from content (it is all un-gated) and keep only the critical lists.

Should you switch?

At the recent conference where I delivered this presentation, everyone I spoke to shared a similar circumstance: they were trying to move faster and faster to keep up with the industry standards.

When I posed the Thiel question “What marketing tech do you believe in that few others do?” not a single person could answer.

Not a single one.

Adopting industry standards won’t get you fired, but they won’t get you promoted either.

Marketing technology itself is no longer a secret: your competition all buy the same platforms you buy and read the same white papers you read.

The only way to move your marketing forward is to find the unfair advantages hidden in your stack.

A microservices architecture won’t get you there alone, but it will make the other steps easier.