The theme of my keynote talk at the MarTech conference earlier this month was “platforming marketing.” (Watch a reenacted video of the keynote here.)
I’ve spent much of my career thinking about two broad topics: marketing and platforms. Yet it took me a while to recognize that the patterns I see in software platforms are the same thing I now see happening with the democratization of martech within marketing organizations today.
They’re both striving to harness the energy of a wider ecosystem of contributors.
I had that epiphany a couple of months ago, when I wrote a post about a martech maturity model, describing how companies seem to evolve through three stages of how they leverage martech within marketing:
- Assisted — limited use of martech as scattered point solutions
- Embedded — a centralized martech/marketing operations role/team
- Absorbed — a strong martech center, but also widely distributed use & adoption
In my original maturity model post, I also acknowledged a theoretical fourth stage — “martech dominated” — where AI would take over marketing and do everything for us. Now, that’s not happening anytime soon, so I’m skipping it here. (I’m happy if martech is finally entering the trough of disillusionment on Gartner’s hype cycle, so we can move past the fantasy of martech and focus on reality and the real work to be done.)
Most companies that have a dedicated marketing operations or marketing technology role or team — larger companies often label it as a “center of excellence” — are at the embedded stage of martech maturity.
Moving there from a limited or scattered assisted stage of martech maturity has been relatively straightforward: hire good marketing technology talent, give them clear martech management job responsibilities, allocate a sufficient martech budget, and you’re well on your way to a solid embedded martech function.
But how do you move from embedded to absorbed? That’s not as obvious.
The first question, however, is probably why move from embedded to absorbed martech? What benefits would that offer?
The Next Stage of Martech Maturity: Agility at Scale
The key difference between embedded and absorbed is how much marketers outside of the core marketing operations team are able to self-service their own martech-related needs.
It’s a variation of the proverb of feeding someone a fish versus teaching them how to fish for themselves. Instead of “do it for me,” it’s “help me do it for myself.”
See, the challenge that an embedded martech function inevitably runs into is the same that any centralized service is bound to face: there are always more requests of things to be done than hours in the day or resources to do them all.
Therefore, as requests stream in from across organization, the centralized service must either filter out requests (“sorry, we’re not going to do that”) or put the requests in a queue (“here’s your ticket number, we’ll get to it as soon as we can”).
This limits the speed by which the organization as a whole can act on ideas. As shown above, with a centralized service, a new idea often waits in such a queue. Eventually, the centralized team will get to it. They’ll typically execute it efficiently — after all, this is what they specialize in. But they usually won’t be able to iterate on the idea very much before they have to move on to the next request in the queue.
Further iterations of the idea need to get back in line and wait their turn again.
But when you empower people throughout the organization to self-service more of their ideas, there’s no waiting. They can go directly from idea to implementation. And, hey, if they want to iterate on that implementation, they can do so immediately — and continue to iterate as many times as they want, for as long as they find it valuable to do so.
Several additional benefits are derived from such self-service capabilities:
- Bandwidth — Because all martech-related activities don’t have to be funneled sequentially through the centralized team, your capacity for “parallel processing” of martech tasks grows significantly. You have fewer scenarios where martech becomes a bottleneck.
- Creativity — The creative use of martech is no longer constrained by only the innovations conceived of by the centralized team; anyone in marketing can apply their imagination to harness martech in new and novel ways. The best way to discover great ideas is to have a large volume and a wide diversity of ideas explored.
- Learning — We learn by doing. If the centralized team are the only ones “doing” martech, they’re really the only ones learning from it. But the more everyone in marketing actively works with martech, the more widely distributed that learning becomes.
- Adaptivity — While embedded martech delivers efficiency and control with a centralized team, absorbed martech layers on greater adaptivity by encouraging everyone across the marketing organization to experiment with new ideas and technologies. Different teams try different tools and tactics, better tailoring martech to their specialized needs. And the company as a whole benefits from a more evolutionary engine of marketing innovation.
Balancing Martech Centralization & Decentralization
Now, self-service doesn’t mean abdicating all centralized responsibilities and surrendering to a lawless, every-marketer-for-themselves pandemonium. You must provide underlying structure and support so you’re actually capturing the bandwidth and creativity of your wider marketing organization — without losing more energy to entropy than you gained from bringing more actors into the system.
This is the balancing act between centralization and decentralization that was described in The New Rules of Marketing Technology & Operations.
You generally want to centralize technology infrastructure that has — or should have — low variance, especially in its data (i.e., a system of record), such as your CRM, your CMS, your DAM, your CDP. (Hmm, could a rule of thumb be that if it’s a popular industry acronym, you should probably centralize it? Call it Acronym’s Law?)
As I joked in my MarTech keynote, martech decentralization is not an Oprah-esque giveaway where everybody gets their own CRM.
But there are plenty of scenarios where different individuals or teams within the marketing department can benefit from adopting specialized SaaS tools — or creatively adapting centralized tools — to self-service their particular needs in a decentralized fashion, for use cases that can have high variance:
- A content marketing team using their own editorial calendar solution.
- An ABM tiger team experimenting with a publisher’s buyer intent service.
- A sales enablement team using an interactive content tool to create assessments.
- A market research team using a gift card delivery service for participants.
- A field marketing team using a lightweight event registration system.
- A product marketing team using a mobile video recording and editing tool.
- A local marketing team testing an SMS-based campaign in an emerging market.
Out of the thousands of apps on the martech landscape, many are ideal for these specialized use cases that are further out on the edge of the marketing organization.
On the human side, the centralized marketing operations team must establish and enforce global laws for these decentralized activities. These include actual legal requirements, such as GDPR data privacy compliance. But they also include company-specific edicts that are essential to protecting the brand and the operational integrity of the business.
Yet you don’t want to become so broadly prescriptive that you end up choking off the very distributed creativity you’re trying to unleash. You want plenty of room for decentralized case law to develop organically, where different teams learn what works and doesn’t work in the context of their localized missions.
The 8 P’s of Self-Service Martech
To advance to the absorbed stage of martech maturity — and to achieve the right balance of centralization and decentralization in marketing operations — you need a solid framework for managing self-service martech at scale.
You’ve heard of the 4 P’s of marketing, naturally: product, price, place, promotion. They’re the foundation of marketing (and still as relevant as ever).
I propose the 8 P’s of self-service martech.
Admittedly, the label is a play off of the original 4 P’s. (Hey, if 4 P’s of marketing are good, then 8 P’s of self-service martech must be twice as good, right? It’s math!) But the eight factors that I’ll describe are, in all seriousness, what is required to implement self-service martech as an institutional capability.
I’ll break them down into two clusters around technology and people.
4 TECHNOLOGY FACTORS OF SELF-SERVICE MARTECH
1. PLATFORMS (THE COMMONS). First, you need software platforms as the foundation of your martech stack that are truly open, designed to easily let other apps and data sources integrate with them. This gives you the technical ability to support other decentralized martech tools while maintaining well-groomed, centralized systems of record (“the commons”).
Thankfully, one of the three big trends in martech is that all of the major marketing clouds are moving past the old suite vs. best-of-breed dichotomy to truly embrace open platform ecosystems.
However, not all integrations are equal. Consider the 4 layers of app integrations when evaluating your choice of platform: data, workflow, UI/UX, and governance.
2. PARTITIONS (MODULAR DESIGN). When multiple self-service people work in parallel on the same platform, you will often want to partition them into separate spaces, so as to avoid collisions without the central marketing ops team having to continually mediate everyone’s activities. It’s a kind of “sandboxing” strategy.
On a DXP/CMS platform, this can mean assigning teams publishing rights to different domains or directories on a website — or maybe just to independent landing pages or blog posts. In a marketing automation platform, it can mean managing separate subscription lists or workflow sequences (but usually with global rate limiting constraints). With a CDP, it can mean linking new data sets to master customer records, but not overwriting core fields (at least not without an explicit review and approval process).
3. PERMISSIONING (GOVERNANCE). With multiple people working on a common platform, it’s also important to be able to set granular permissions with access control. Who can add, view, edit, or delete different records — maybe even specific fields within those records — in a central database? Who can trigger different actions in a system of engagement? Who can approve different decisions within a workflow?
A security best practice is to restrict permissions to the “least privilege” necessary for someone to perform their work. In certain circumstances, this may also mean just-in-time access, where permission is granted for a limited period of time, only when it’s required for a specific task. This kind of technical governance isn’t so much about protecting yourself from bad actors — hopefully rare — but about preventing accidental harm from inadvertent mistakes. It keeps a self-service environment safe.
4. PERCEPTION (MONITORING). Admittedly, I was stretching for a word that begins with “p.” By perception, I really mean monitoring. In a self-service environment, most martech-powered activities will happen without people explicitly asking permission for each one. Decisions to act are decentralized, and that’s a good thing.
But it’s important for the marketing ops team to monitor martech-powered activities, even after they’re already in flight, to detect (“perceive”) unusual patterns or signals of something going astray. The platforms you’re using as a common foundation should provide some of this visibility, with dashboards and audit trails.
It’s a reason to consider standardized platforms even for things such as workflow management (e.g., Workato) or low-code app development (e.g., Quick Base or OutSystems). Individuals have self-service freedom to build what they want on those platforms, but the centralized platform provides built-in transparency across all of them.
You’ll likely want to supplement your platform-based monitoring with independent monitoring tools, such as SaaS operations software (e.g., Blissfully or Torii), website and app monitoring software (e.g., Pagerduty), and CX monitoring software (e.g., Decibel Insight). You should also collaborate closely with IT and cybersecurity teams around broader monitoring and threat detection.
But technology factors are just half the equation of self-service martech…
4 PEOPLE FACTORS OF SELF-SERVICE MARTECH
5. PERMISSION (EMPOWERMENT). This is different than “permissioning” that we discussed above. That’s the technical mechanics of access control. Permission is management actively encouraging employees to use self-service martech. Permission is empowerment.
It’s giving people across the organization license to experiment with martech capabilities — and embracing the trial-and-error process of discovery. It’s giving them flexibility to allocate their time and budget on martech-powered ideas. It’s giving them authority to make judgment calls — within reasonable boundaries — on the responsible use of the technology.
6. PREPARATION (ENABLEMENT). Of course, having permission to do things isn’t enough. It’s also necessary to teach (prepare) people for how to do them with marketing enablement. This begins with training and documentation on how to use martech, both the specific platforms adopted by the centralized marketing ops team and more general digital marketing education (e.g., HTML, SEO, data analytics, introductory programming, etc.).
But good enablement goes beyond one-way, passive learning, encouraging marketers to share their experiences and insights with each other, by contributing to an internal wiki, participating in martech “office hours,” presenting their work at company “science fairs,” and engaging in other methods of peer-to-peer learning. Connect with peers outside your organization too, through meet-ups and industry conferences — ahem, MarTech — to exchange ideas and gain fresh perspective.
7. PRINCIPLES (GUARDRAILS). “With great power comes great responsibility.” By empowering the entire organization with self-service martech, it’s important to establish clear boundaries and guardrails that guide people to make the right decisions in how they apply this technology. This includes black-and-white rules around data privacy compliance (i.e., thou shall not import contact data without explicit consent) and brand standards (i.e., thou shall not create a new logo with one’s own personal color palette and font preferences).
But more valuable than a laundry list of detailed rules — more than 10 and people will have a hard time remembering them all — is defining principles that embody the true spirit of your brand and culture. HubSpot’s Customer Code is a great example of this. These are tenets by which decentralized teams can make good decisions in the context of an infinite variety of particular situations that uphold the ideals and reputation of your brand.
8. PASSION. The final ingredient in creating a thriving self-service martech ecosystem is passion. The central marketing ops team must be passionate about empowering the rest of the organization to use and experiment with martech. They must be martech teachers more than martech police.
Senior management must be passionate about driving this decentralized transformation — and be committed to supporting people through sometimes bumpy learning experiences and the failed experiments that are inevitable in the exploration of new ideas.
Ultimately, marketers across the organization must be passionate about acquiring these new martech-powered skills and pushing beyond their comfort zone. Technology changes faster than organizations do — Martec’s Law — and the only counterbalancing force is a voracious appetite for continuous learning.
Platforming marketing with self-service martech is a way to accelerate the democratization of technology in marketing for greater innovation and adaptability in a fast-changing world.
