Pioneering a new market and introducing an innovative technology in the process invariably results in customer confusion, usually driven by a fairly predictable “I’ve never seen one of those before” reaction:
- What is a relational database and why would I need one when IMS is doing just fine?
- What is a business intelligence tool anyway why would I need it in addition to ReportSmith?
- What is a data warehouse and why would I need one in addition to my operational databases?
- What is search engine optimization and why should it matter to my marketing team?
- What is server virtualization and why would I care?
- What is a social network and why (in the world) would I want to part of one?
One of my top marketing rants is that pioneering new markets is difficult enough that vendors shouldn’t make the task any harder by muddling their message along the way. While this would seem obvious, it happens all the time. Why?
- A diversity of internal opinion on how to describe the company and/or its product. This is normal.
- A lack of marketing leadership in establishing one clear “correct answer” that the company should follow.
- A lack of discipline in sticking to one message on the part of the field and/or marketing team members.
Invariably, when pioneering a new market, there will be a variety of internal opinions about how to talk about it. For example, as a technologist, I could honestly describe MarkLogic Server in any of the following ways:
- XML database
- XML server
- Content database
- Document database
- Unstructured database
There are pros and cons to each of these choices. While our media customers like the term “content,” it does not resonate with our Federal customers who see a data/content dichotomy as meaningless. For years, we were gun shy about calling MarkLogic Server a “database,” because that would tend to prompt a reaction of “oh, we have one of those, it’s Oracle, thanks for coming by.” So, for years we referred to MarkLogic Server as an “XML server,” attempting to follow the example set by Arbor Software who positioned its multi-dimensional database system as an “OLAP server.” Recently, we decided to come out of the database closet and, going forward, you will see us positioning MarkLogic Server, arguably more accurately, as a database for unstructured data.
But that’s not the point of this post. This post is about consistency. Note that we have quickly found 15 ways to position MarkLogic Server. {XML, content, document, semi-structured, unstructured} x {database, server, platform}. The question for marketing should be: which way is best. The question for everyone else should be: which one did marketing pick?
Why? Because it’s better to be consistent than better.
Imagine in your heart-of-hearts that you think “content server” is simply a better answer than “unstructured database” and you decide to use your own lingo instead. The first thing you might do wrong in this instance is bleed.
Customer: What is your product anyway?
You: Well, that’s a great question. It’s actually quite confusing and did you know that there are about 15 different things we could have called it. Marketing — and you know those guys — what’s the expression “if you can, do, and if you can’t do marketing” — ha, ha — well, marketing decided to position it as an “unstructured database” but I think that’s a bad answer, so I actually think of it instead as a “content server” because it really does serve content — and boy does it go fast — and some of my buddies on our DC team call it an XML database, but that’s bad because everybody knows that Gartner hates XML databases — ix-nay on the atabase-day, har, har — and it isn’t really all about XML, it’s really about marking up semi-structured information, you know? Uh, what was your question again?
The are many problems with bleeding on the customer:
- You’re talking instead of listening. Look how many words you took to answer the simple question of “what is it?”
- You’re confusing the customer, giving three or more different answers to one simple question
- You may think you’re making yourself look smart with a great analysis, but to a sophisticated listener, you are making yourself look dumb instead
- Most important, you are confusing the customer. He/she asked a simple question and you were unable to give them a simple answer. Quite possibly he/she had several follow-up questions in mind, all of which were forgotten during your stream of consciousness response.
The fact is that selling a new technology is hard enough that you shouldn’t make it harder through inconsistency and bleeding. It isn’t easy to understand what MarkLogic Server is and we don’t have the benefit of a category with 3-5 other vendors all evangelizing the same idea. If you’re in a similar situation, then you have to ask yourself: shouldn’t you make things as simple as possible, speaking precisely and consistently so we can make it as easy as possible for customers to understand our message?
If you agree, that means two things: (1) you need marketing to step up and choose: to define the standard vernacular –ideally in a conversational Q&A-style format — and then drive it into all marketing communications and (2) you need to lead by example in sticking to it. If you think marketing has chosen poorly, do not bleed on the customers (or fellow employees). Go raise your concerns to marketing. If you think there are common questions that need standard answers that are not yet addressed, then go to marketing.
When pioneering a new market, your primary competitor is confusion, and inconsistency is his ally.
The structuralist in my closet also wants to comment that difference plays an important role here:
XML Server:
How are you different from, say, an application server? Oh, you serve XML rather than applications! Oh, you actually serve applications that are based on XML? Okay, now I’m confused…
Database for unstructured data:
How are you different from other databases? Oh, semi-structured data? What’s that? Oh, and Oracle can’t do that easily? Hmm…
A good question will always be what do you do that is *different*. Demonstrating that you can do something *better* is obviously harder to qualify without quantifying, and metrics may intimidate customers. Also, over the years we have also learned to be skeptical of metrics because often they lie.
Hi Piers,
Thanks for your comment. I view answering both questions as necessary. That is, any company needs a simple, standard answer to both [1] what is it and [2] why is it different (and [3] what are the advantages of using it over most likely alternative and …)
The question I’m specifically not trying to address here is one of emphasis. For some companies (e.g., Business Objects in the 1990s) the right point to emphasize was differentiation — we would tend to lead with why we were better than Cognos because there was an active marketing of customers buying in category and they were evaluating both vendors and trying to determine which was best.
In a different phase, as market growth slowed and the problem because market expansion as opposed to share-leadership, we need to emphasize the benefits of using one question.
So my main points are [1] marketing needs to define standard answers to this, indeed, set of basic important questions, [2] sales and everyone else needs to use what marketing picked — trying to one-up your marketing team only leads to confusion, and [3] that, to your point, marketing also needs to decide which message/question/answer is the appropriate one to lead with in given situations.
As for unstructured vs. semi-structured, remember the corporate message needs to work with customers, prospects, investors, bankers, etc. — I could never say semi-structured to a banker, though I indeed say it customers. Most of them understand that I actually mean semi- and/or un-structured data when I say unstructured. (In fact, I’d argue there is NO unstructured data, but that’s a different post).
As for XML server, yes, I get your point. By the way, the product does include an application server, so it literally does serve XML. But remember, the primary intent of that positioning was to avoid the use of the D word.
As for database for unstructured data, it does provoke the questions you ask, which we are only too happy to answer.
Marketing is indeed a conversation and you want your messaging to point that conversation in the right way.
Best,
Dave
Hi Piers,
Thanks for your comment. I view answering both questions as necessary. Any company needs a simple, standard answer to both [1] what is it and [2] why is it different (and [3] what are the advantages of using it over the most likely alternative and …)
The question I’m specifically not trying to address here is one of emphasis. For some companies (e.g., Business Objects in the 1990s) the right point to emphasize was differentiation — we would lead with why we were better than Cognos because there was an active market of customers buying in the category and they were evaluating both vendors and trying to determine which was best.
In a different phase, as market growth slowed and the problem became market expansion (as opposed to share-leadership) we needed to emphasize the benefits-of-use question as the lead point. Think: “Soup is Good Food” vs Campbell’s is the Best Soup.
So my main points are [1] marketing needs to define standard answers to a set of basic important questions, [2] the company needs needs to use what marketing picked — trying to one-up your marketing team only leads to market confusion, and [3] that, to your point, marketing also needs to decide which message/question/answer is the appropriate one to lead with in given situations.
As for unstructured vs. semi-structured, remember the corporate message needs to work with customers, prospects, investors, bankers, etc. — I could never say semi-structured to a banker, though I indeed say it to customers. Most of them seem to easily understand that I mean un- and/or semi-structured data when I say unstructured. (In fact, I’d argue there is no such thing as purely unstructured data, but that’s a different post).
As for XML server, yes, I get your point. By the way, the product does include an application server, so it literally does serve XML. But remember, the primary intent of that positioning was to avoid use of the D word.
As for database for unstructured data, it does provoke the questions you ask, which we are only too happy to answer.
Marketing is indeed a conversation and you want your messaging to point that conversation in the right way.
Best,
Dave
Nice thread.
Being a Salesperson I like when Marketing sees itself as being at the front end of the sales process and not the back end of Product Dvpt.
Aside from creating demand, I expect Marketing to help me having the right words pre-positioned, which helps me establishing rapport with prospects quickly and efficiently.
So far, what I have been using is a set of cue cards (sometimes called Solution Devpt prompter – SDP-). These cue cards are built jointly by Sales and Marketing focusing on potential customer usages.
Strangely enough, being prepared that way doesn’t help me talking about the product. On the contrary, I feel better prepared to move off the solution so that I can explore impact and reasons for change. By keeping in mind a set of predefined sales ready messaging, I can diagnose better and focus on usage and benefits rather than features.
We make a living with disruptive technology but what we sell is a solution to something: getting rid of a pain, achieving a goal or satisfy a need. Marketing is the best positioned to factor the collective knowledge gathered during Sales calls and make it palatable for all. If the process eventually goes top-down, I believe it is fuelled bottom up.
Thanks for addressing these issues so openly.
Sincerely,
Denis
Thanks Denis. I like solution development prompters in general. In my experience, I have used them in an situation where reps have geographic territories and are thus forced to know a little about a lot — i.e., how an inherently horizontal piece of software helps banks with problem X and retailers with problem Y, etc. I’d argue the only better than SDPs is true expertise — i.e., with a vertical salesforce and a relatively small solution set, you can truly “solution sell” because your media salesreps (and consultants) work all day with media customers on those 5 or so problems. That said, SDPs on those 5ish areas are still useful for orientation, training, standardization, etc.