How to Develop a Marketing Message

I’ve had a few marketing inquiries of late so I thought I’d devote a post or two to some of my favorite marketing topics: messaging and the marketing mission.

This post’s on messaging. Surprisingly, when you Google “how to develop a marketing message” you don’t find much. It’s an area I’ve put a huge amount of thought into during the past 20 years, so I’ve decided to share my tips here.

Messaging isn’t rocket science. It’s largely a question of two things: audience and discipline.

Know Thy Audience
The first thing you need to know when building a marketing message is to whom you’re speaking. Quick quiz: which of the following target audience statements provides you with clear guidance in building a message?

• Global 5000 CIOs and line-of-business executives
• General managers of online products at publishers
• Directors of security in IT organizations

Trick answer: I think both 2 and 3 are clear. I think is 1 is appalling and it’s shocking how often you encounter it. If you’re at a startup and your target audience is “global 5000 CIOs and line-of-business executives” (note my clever attempt to basically slide in “everyone”) then you have a strategy problem, not a messaging problem. Sometimes what sounds great at the strategy offsite sounds a lot worse the following week. When that happens marketing has the obligation to tell the company that the target audience isn’t sufficiently focused. So go back, re-work the strategy, and find a target audience that’s precisely defined enough to be reachable.

Marketers typically make a few mistakes in defining the audience: defining it too broadly (per the above), over-reaching, and speaking low.

Over-reaching results from marketing’s optimistic tendency to assume sales will call quite high in the target customer’s organization. So, for example, they assume sales is speaking to the CIO when they are actually talking to the director of data warehousing. (I used to have a slide a Business Objects that said the CIO’s business card says “chief information officer” on it and not “director of data warehousing.”) So be realistic in assuming who you’ll be able to reach when defining your audience.

Speaking low happens because product marketers have technical backgrounds and typically just love talking about the product and how it works. Senior executives, on the other hand, don’t care about how the product works; they care what it does, and specifically how it can help them solve their top problems. Remember this truth: you are delegated to the level at which you speak.

So in the unlikely event that one of your salespeople actually gets to the real CIO, if he starts talking about “aggregate awareness” and “hypercube data structures,” I can guarantee that the following will transpire.

“Joe, please stop a second, Joe. Thank you. Thank you so much. It was so kind of you to come by today. From what you’re saying it’s clear to me that you need to be talking to Bob, our director of data warehousing. Please go contact Bob – I’m sure he’d love to know this important information – and please don’t let the door hit your ass on the way out.”

Once you know who you’re speaking to, then you need to walk a mile in their shoes to understand them. Read their books, blogs, and periodicals. Rub elbows with them at their conferences. Try to pass what I call the cocktail party test – how long can you last at one of their cocktail parties before they realize you work in software, not their industry? Your goal: never.

The typical way to avoid this messy and difficult work is to frame the audience too broadly as “business and IT executives” and then safely assume that everyone cares about “increasing revenues” and “reducing costs.” You can spare yourself a lot of work in so doing, but you’re also sparing yourself from creating a compelling, relevant message.

Ironically, I’d note that over-reaching and speaking-low are actually offsetting errors so many marketers work their whole careers never knowing they’re making them. Ideally, make neither mistake, but if you’re going to make one, then be darn sure to make them both.

Question Lists
Once we know who we’re speaking to, we need to figure out what to tell them. This is largely a matter of hard work and discipline: the hard work to think about the best answers to a rather basic set of questions, and the discipline to hone those answers down to the shortest possible form and to not attempt to be all things to all people.

Those typical questions include:

• What problem(s) does it solve?
• Why would I buy it?
• Why is it different from the other seemingly identical ones? (Intra-category differentiation.)
• Why is it different from the usual approach?
• Who else uses it in my industry and/or to solve my problem?
• What is it? (Positioning.)

What goes wrong in this seemingly simple exercise?

• Leading with features. I can’t tell you how hard I had to work to beat “schema independence” out of some of our sales people. Yes, it’s important. Yes, we do it. But it absolutely cannot be word 15 out of our mouths when we meet with customers.

• Failure to make concessions (also known as the “dessert topping and a floor wax” problem). When you introduce a product people struggle to figure out what it is, how it fits in, and what it can and cannot do. Marketers, on the other hand, hate to make concessions. The result: marketers position the product as all things to all people and the customers lose interest because they can’t understand the offering. You cannot sell the cheap, expensive, high-end, low-end, complex, simple, single-machine, massively clustered, search engine / CMS / database.

• Answering the wrong question. I can’t tell you how often I get “how” answers to “what” questions. Encourage your sales team to listen to the question and answer precisely. For example, when asked “what does it do” do not answer “how does it work” no matter your enthusiasm for the algorithm.

• Talking too much. There was a time in IT sales when chest-thumping the unique feature(s) of your product was the key to success. That time is long past. Today, you must demonstrate an understanding of the customer’s problem and map your capabilities to solving it. That means using your mouth less and your ears more. As goes the sales adage: you have two ears and one mouth; use them in that proportion.

• Imprecise language. I can’t tell you how confusing it is when our salespeople say “unlike other search engines, MarkLogic does X.” MarkLogic isn’t a search engine; it’s an XML content server, a type of special-purpose DBMS. So the sloppy “unlike” undermines a lot of hard work in product category definition. (Correct example: unlike other DBMSs, MarkLogic is designed and optimized for XML content.)

• Failure to use analogy. Not using analogies in marketing is like not using the oars on a rowboat. (Get it?) Marketers should sweat blood trying to create clear analogies for their products. My all-time favorite comes from the anti-virus world: “finding SMEG is like catching smoke in a butterfly net.” (That one gives me goose bumps.) I’m also a big fan of the car/boat: floats like car, drives like a boat – which, by the way, provides a reasonable analogy for XML document support in relational databases.

For a concrete example, let me share the answers to some basic questions for MarkLogic Server in the context of a VP of online products at a publisher.

• MarkLogic accelerates the creation of information products. Ultimately, it provides you with agility. (Note multi-level benefit structure.)

• MarkLogic differs from the usual approach of trying to bolt together an RDBMS and a search engine by combining – in one product – everything you need to build content applications from both a database and search perspective. It’s a clock/radio, not a radio wired to a clock.

• MarkLogic is an XML content server, a type of special-purpose DBMS.

• MarkLogic lets you load, query, manipulate, and render XML content.

• MarkLogic helps solve the problems involving content integration, content repurposing, content delivery, custom publishing and search and discovery.

Personally, I love the “problem list” because it sets a problem agenda for the ensuing conversation, and not a feature agenda. “We solve problems X, Y, and Z. Do any of those of interest you? Oh Z does, great, let me tell about customers 1 and 2 who faced problem Z and solved it with MarkLogic.”

This approach keeps you on “your turf” (talking about things you do well) but allows the customer to guide you to the intersection of “your turf” and “their problems.”

Message Trees for Memorization
Because the ultimate purpose of a marketing message is to serve as a blueprint to guide collateral and sales tool creation, web content creation, and real live sales conversations, you need to make the messaging something that everyone can remember. That’s one reason I like question-lists: because you can decompose the message into short answers to a series of basic questions.

But sometimes, you will have a lot to say. For example, let’s zoom back to 1996 and examine the intra-category differentiation of BusinessObjects 4.0. We had plenty of whizzy features:

• Aggregate awareness
• Dynamic microcubes
• Multi-pass SQL generation
• A new semantic layer designer
• A new security utility
• A repository for BI information
• The first integration of query, reporting, and OLAP techniques
• Usability-tested, hyper-friendly UI
• One-step query panel

But how can you remember nine features? You can’t. Most people can remember three things, not nine. Here’s the million-dollar trick. Remember nine things by structuring them into three groups of three. This is what I call a (ternary) message tree.

• Power: aggregate awareness, dynamic microcubes, multi-pass SQL
• Deployability: security utility, designer utility, repository
• Ease of use: integration, friendly UI, one-step query panel

Twelve years later I still remember the PDE message from that launch.

Some people don’t like this approach because you end up grouping precise differentiated claims (e.g., aggregate awareness) under vague concepts such as power and then asserting that BusinessObjects 4.0 is “more powerful” tool than its competition.

I believe that objection is spurious because those who assert it miss the point that marketing is a conversation. In the end, you want the customer to draw his own conclusions at the “advantage” level (i.e., PDE) and you will support your contention that your product is the most powerful / deployable / easy by discussing the underlying features.

I don’t expect to assert that we’re the most powerful and have the customer say, “yes.” I expect the customer to say, “why?” That gives me the chance to support my assertion and all the while I’m practicing the “tell ’em, tell ’em, tell ’em” approach that all good salespeople, teachers, and speakers use: tell them what you’re going to tell them, tell them, tell them what you told them.

The Green Spots in Cheer
When discussing “features” it helps to have a mental model for features, benefits, and the like. Let’s use my favorite example to demonstrate, which I call FABC (feature, advantage, benefit, consequence):

• Feature: the green spots in Cheer detergent
• Function: they work through [amazing chemical process]
• Advantage: they make the towels whiter
• Benefit: your spouse kisses you when you get home
• Consequence: your children will be ostracized at the local swimming pool because their towels are less white than the other kids’

The next time you watch TV, hold off the Tivo, watch a few commercials, and you’ll invariably find a few “slice of life” advertisements that demonstrate the feature, advantage, benefit paradigm of marketing.

• Some marketers speak of feature, function, benefit marketing. I don’t like this because “function” encourages you to talk about how the feature works – i.e., to describe the amazing chemical process. While this is sometimes necessary, I don’t like assuming it into every conversation.

• One person’s feature is another person’s benefit. That’s why I use the term “advantage” to describe the result you get from a feature (or another advantage). In my model, advantages are stacked recursively up to the final one, which I call the “benefit.” Example: green spots mean whiter towels mean less insecurity means happier spouse means happier children means kiss when you get home. In this example, I call all the stuff in the middle the advantages stack and I call the top of that stack the benefit. That’s why I always tell marketers the ostensibly confusing statement: “don’t forget the kiss.”

• Here’s a technology example of the advantages stack: checkpoint feature in new debugger means easier to find problems with the software means more productive programmer means happier programmer means on-time project means faster time-to-market means competitive advantage means increased win rate means more sales means more profit means promotion for general manager. Personally, and this will tell you something about how warped I am, I think it’s fun to build these stacks and to figure out at what level your “kiss” (i.e., benefit) should be.

• Many salespeople believe that it’s not a benefit until it’s personal, so my kiss metaphor conveniently works well and, in the preceding example, it’s not a kiss until you get to the promotion for the general manager.

• Logically, I’d argue that there are three archetypal benefits (sex, money, and power) but it rarely works to walk that far up the stack and, in business, you will usually end up at money and then need to drop down a level or two to have a tangible linkage to your offering. (Cynics would argue there is only one archetype, money, but we won’t go there.)

• Don’t define “feature” too narrowly. Most features are regular features in the software, but “Tufte-designed user interface” (if you actually hired Tufte for design help) or 100-TPS capable engine (if you benchmarked at that speed) both qualify for my definition of feature.

Let’s go way back to 1987, when leg warmers were all the rage and for $10 you could see Jerry Garcia at the Keystone Berkeley, for our final example, taking a nice DBMS feature from that era: group commit.

• Feature: group commit

• Function: flushes the commit records from multiple users to the log file in a single I/O. (I slaved twenty years ago to distill this complex function to one sentence.)

• Advantage: enables high-volume online transaction processing (OLTP)

• Benefit: saves money by putting OLTP systems on minicomputers with RDBMSs instead of on expensive mainframes with IMS

• Consequence: lacking this feature, your system will bottleneck at 30 TPS