Marketing as an object-oriented program?

I ran across an inspiring blog post this week by Jacques Spilka of Whatsnexx, titled Complexity killed marketing automation! (The if-it-bleeds-it-leads school of blog post headlines.)

Jacques made two insightful points:

1. Marketing automation programming can get complicated fast

Juggling gets exponentially complex

First, he cut right to the quick of the challenge of marketing automation: for marketing automation to be really effective, it needs to be wielded by the marketer, not by the marketing automation expert.

Most marketing automation packages require fairly extensive setup and configuration, frequently done by high-priced consultants. (It’s no accident of strategy that IBM, arguably primarily a technology services company, acquired enterprise marketing software provider Unica.)

“The purpose of automation is to simplify and speed up processes — not complicate things!” writes Jacques. But as marketing automation providers continually add new and disparate features, such as merging in more social media capabilities, the “automated” solution can unintentionally become more complicated to wield than the processes that you originally wanted to automate in the first place.

This complexity can dampen the actual adoption of automation — even if a company has installed an amazing marketing automation platform, they may only be leveraging a small sliver of its capabilities.

Of course, Whatsnexx offers its own marketing automation solution that proposes to address this challenge, so Jacques does have an ulterior motive for making this point. But the statement of the problem they’re trying to solve rings true.

2. If marketing is being programmed, can we use an object-oriented paradigm?

Jacques describes their solution as customer state marketing. (Akin Arikan did a nice post on them last year.) If you have some software engineering background, your synapses may already be firing associations with state machines, and that seems to be part of Whatsnexx’s intention.

According to Jacques, the key benefits of their approach are:

  1. Scenarios display the characteristics of object-oriented programming
  2. Scenario programming is procedural

Whoa. Let me do a double take.

We’re reading a blog by a marketing solutions provider — selling to marketers — that is touting the characteristics of object-oriented programming as one of the benefits it provides customers. That’s pretty bold. I mean, I just recently wrote that marketers should learn how to program, but to have a marketing technology company trying to sell a “better” programming paradigm to marketers is kind of striking.

Yet it resonated with me instantly. (And apparently with Akin too.)

To quote a bit from Jacques’s post:

For programmers, [the above two benefits] are significant. For everyone else this sounds like some foreign language — definitely very obscure. Let me put it another way:

1) Scenarios are self-contained. They know how to behave in response to external stimulus (i.e., an event). This stimulus occurs randomly, and the scenarios will automatically respond to the event according to the rules contained in the scenario itself. The scenario only knows what it needs to know in order to respond to the stimulus, and contains all of the information necessary in order to carry out its functions properly (i.e., actions), such as sending the appropriate email.

2) Scenarios follow simple rules, and have a simple program flow and limited branching options. This makes it easy to design state-based event/action program flows that govern how and when a scenario responds to a random customer event.

Design Patterns

If that’s not pitching to a new generation of marketers — and marketing technologists — I don’t know what is.

Even if the net functionality that Whatsnexx delivers is similar to traditional marketing automation systems, the power of a paradigm can’t be denied.

Thinking about the modern marketing function as a large-scale object-oriented program stirs the imagination — at least it does for me — and suggests a number of intriguing new ways to organize and coordinate the multitude of moving parts in marketing’s environment.

Just as object-oriented programming dramatically changed the development of software — without directly changing what that software was able to do — such object orientation could have a big impact in the way that marketing automation processes are conceived, implemented, and maintained.

Following the object-oriented train of thought, I can’t help but ruminate about how object-oriented design patterns might be adapted in the context of marketing-as-a-system. Maybe there are marketing analogs to Adapter, Decorator, Singleton, and Strategy patterns. Or maybe there are entirely different pattern concepts — but patterns nonetheless — that can help structure and standardize this space.

It is unlikely a panacea for marketing complexity, but it could be a better architecture for managing such complexity. I don’t know if Whatsnexx actually delivers on this promise — I’ve only read a few of their blog posts and browsed their web site — but I give them full props for promoting a brilliant way to frame “programmable” marketing.

Share

Comments

  1. HI Scott,
    I appreciate your elaboration on my post. As to your question “I don’t know if Whatsnexx actually delivers on this promise”, the reality is even better than the theory. Imagine doing what used to take you 40 hours in just two hours; making a change that used to take several hours in just a few minutes; allowing the user to make last minute changes (20 in one particular case) just before the go live date. This is my new reality.
    Thank you for the great coverage of my blog post. I look forward to your next post.

  2. Jim Murphy says:

    Hey Scott,
    So if I understand what you’re proposing here, you’re preaching to the choir. Marketers spend so much time segmenting customers and developing profiles, etc… All good stuff. But profiling situations or scenarios really resonates with me as well. I think marketers have done this kind of manually up til now, basically relying on intuition (ie. it’s Valentines day, let’s do a sales promotion.) But there are scenarios large percentages of us go through in our life (the exact same scenarios) that don’t adhere to a calendar (ie. getting married, having children, graduating high school, etc..). These won’t all happen at the same time for everyone, but the odds are, they will happen. What’s kind of cool about that is that we all leave a data footprint behind – in our social media profiles, comments online, surveys we fill out, purchases we make, etc… That footprint can be instrumental in predicting when any one person might be headed toward a scenario. Each scenario would indeed have it’s own rules (ie. birth of a child would likely set the stage for annual sales promotions or losing a loved one (grim, I know) would have a very different set of rules, perhaps even limiting communications during a time of mourning). I love the analogy to object oriented programming, because each scenario does indeed have properties (happy occasion, sad occasion, formal occasion, etc…) and methods (limit communication, offer a special deal, etc…) that are unique to each object, I mean scenario.
    While I love the analogy, I always worry about putting these powerful frameworks in the hands of just any old marketers who just want to ‘set it and forget it’. Ideally I see this being very powerful if marketers nurture the scenario models, constantly testing and learning.

  3. Jim Murphy says:

    Great stuff. I keep thinking about this… My earlier comments focused on macro-events or life-events. But I think while that still applies, the post was focusing on micro-events that occur on the site, for example (ie. someone buys an Sony TV above a certain pricepoint). There could be scenarios set up for those types of purchases that would have properties like price, brand, size, etc…) and methods that check for accessories deals, schedule email communications, increment points balances, etc..). That’s all probably a little more immediately feasible than the life-stage events 😉

  4. We all know that necessity is mother of invention. At least, in the most cases. For example, the move from computer language C to object-oriented language C++ was based on failure to manage huge amount of source code mapped to functional specifications. But, where can we see the same kind of necessity in … marketing, ok in marketing automation systems. It seems that by introducing “Marketing as an object-oriented program” we multiply entities beyond necessity (“Entia non sunt multiplicanda sine necessitate”)

  5. antbogarin says:

    Object oriented css exists.

    And mappings of these patterns would be:

    Singleton: id classes (probably)
    Strategy: css4 selectors, calc(), invert(),…
    Adapter: schema.org (semantic data) and ARIA roles
    Decorator: css specifity levels

    Anyway i am not a css expert. 🙂

Leave a Reply

');