“If a bird walks like a duck, swims like a duck, and quacks like a duck, I call that bird a duck.” — James Whitcomb Riley
Many marketers are in such a hurry to talk about topical issues that they forget the duck test: if it walks like a duck, swims like a duck, and quacks like a duck, then most people will conclude it’s a duck. Philosophers teach that such abductive (or should we say, abducktive) reasoning can lead to incorrect conclusions — and it can.
But here in marketing, we draw a different conclusion from the duck test. It’s how most peoples’ minds work so we shouldn’t fight against it. There are two common ways that marketers fail the duck test and we’ll cover both of them — and what to do instead — in this post.
Deny Thy Father and Refuse Thy Name
Many marketers are eager to pretend that their product is the latest in-vogue thing (e.g., AI), and can get so busy dressing it up in the latest tech fashion, that they generate more confusion than sales opportunities.
It’s like a replay of the clichéd movie scene:
Man: Who are you?
Woman: Who do you want me to be, baby?
When someone asks your company the equivalent of “who are you?” [1], you need to answer the question and that answer needs to be clear.
Remember, the enemy for most startups isn’t the competition. It’s confusion. The easiest thing for a prospect to do is nothing. If we talk and I leave confused, then I’ll just write off the wasted half-hour and go on with my day.
Consider an answer like this [2] [3], to the question “what is MarkLogic?”
I mean great question. We ask ourselves that all the time. It’s actually hard to answer because there’s nothing else like it. Answering that is like trying to explain the difference between a Cessna and a 747 to someone who’s never seen an airplane. Our marketing people call it an XML Server, but that’s not a great description.
What is it really? Literally, it’s what you get when you lock two search engine PhDs in a garage for two years and tell them to build a database. You know, it looks like a database from the outside, but when you pop open the hood — surprise — you find that it’s built from search engine parts. Search engine style indexing. And it’s schema-free like a search engine so it can handle unstructured, semi-structured, and, of course, structured data as well. Let’s get into those exciting distinctions in a minute.
This thing — whatever you want to call it — it’s the Vegomatic of a data: it slices and dices and chops in every conceivable way. In the end, I think what makes it hard to understand is that it’s basically a hybrid: half search engine, half content application platform, and all database.
Is that clear?
As mud. What’s wrong with that answer?
- It’s confusing
- It’s long
- It’s navel-gazing (let’s talk about me)
- It’s bleeding on the customer (sharing internal troubles)
It’s a horrible, horrible answer.
Now before you stop reading, perhaps thinking that this is one specific, dated case study, let me say that I could easily write such a parody for about a quarter of the few score of startups I work with today. This is not some ancient example from another world. This is a current problem for many startups, but I’m not going to parody any of them here [4]. Might you suffer from this problem? Go listen to some Gong or Chorus recordings, particularly high funnel (e.g., SDR) and/or discovery calls, and see if anything resonates.
Now, let’s contrast the previous answer with this one:
It’s an XML database system, meaning it’s a database that uses XML documents as its native data modeling element. Now, what did you want to do with it again?
What’s nice about this answer?
- It’s short
- It’s clear
- It’s correct
- It leaves an opportunity for follow-up questions [5]
But the really nice part of this answer is that it puts focus back on the customer. The direct cost of all the previous blather is confusion. The opportunity cost of all that blather is you waste precious time you could have spent listening to the customer, learning more about their problem, and trying to decide if you can solve it.
So why didn’t some of our sellers want to give the second answer? They didn’t want to say the X word. XML was cool for a while, but that quickly passed and XML databases were always distinctly uncool. So, some sellers would rather spend five minutes tap dancing around the question rather than directly answering it.
What followed was almost always a difficult conversation [6]. But the flaw in tap-dancing was simple: the customer is going to figure it out anyway [7]. Customers are smart. If it:
- Stores data like a database
- Builds indexes like a database
- And has a query language like a database
Then — quack, quack — it’s a database.
That’s the first way marketers fail the duck test. They’re afraid to say what the product is for fear of scaring people off. But there’s another way to fail the duck test.
Confusing Products and Solutions
The second way to fail the duck test is to rotate so hard to solutions that you basically refuse to say what the product is. You end up dodging the question entirely.
Customer: So, what is it?
Vendor: You can use it to build things, like a deck.
Customer: That’s great, but what is it?
Vendor: You can use it to assemble things, too, like a bed.
Customer: Sure, but what is it?
Vendor: And you can use it for disassembling things too.
Customer: Wait, it’s a drill isn’t it?
Here we have the prospect playing twenty questions to figure out what the product is. Yes, we all know that customers buy solutions to problems [8] and Theodore Levitt’s classic example of customers buying 1/4″ holes, not 1/4″ bits.
But don’t take that in a fundamentalist way. If the customer asks, “what is it?” the answer is not, “a thing that makes holes” but, “a power drill with a 1/4-inch bit.” If they ask why ours is better, we say that our bits are titanium and don’t break. “Feature” need not be a four-letter word to remember that the purpose of the drill is to make a hole and, transitively, that the purpose of the hole is to build a new deck with the ultimate benefit of quality family time.
The point is: knowing what solutions (or use-cases) we want to target does not eliminate the requirement to have strong product messaging. Particularly in unexciting categories, we will need to lead with use-cases, not product superiority, category formation, or market leadership. But, inevitably, even when you lead with use-cases, you will get the question: what is it?
And a short, clear answer – as we discussed above – not only gets the customer what they want, but it lets us have more time for listening and discovery. I see many companies where they rotate so hard to use-case marketing that their product messaging is so weak it actually interferes with discussions of the use-case.
For example, say the product is a data streaming platform (DSP) and the use-case is industrial monitoring for manufacturing facilities. Let’s assume that data streaming platforms are not a hot category, so there aren’t a lot of people out shopping for them. That means we’re not going to target DSP shoppers with a product-oriented superiority message, instead, we are going to target people who have a problem with industrial monitoring.
But when one of those people asks what it is, we’re not going to say, “a thingy that helps you do industrial monitoring.” Instead, we’re going to say, “it’s a data streaming platform, many of our customers use it for industrial monitoring, and here’s why it’s such a great fit for that use-case.”
That is, we map to the use-case. We don’t redefine the product around the use-case. We don’t try to use the use-case to avoid talking about the product. Doing so only confuses people because eventually they figure out it’s not an industrial monitoring application, but a data streaming platform that can be used for industrial monitoring. Unless we are clear that it’s a platform being used for a use-case, then we fail the duck test.
In the end, you will get the right answer if you always remember three things:
- Customers are smart
- Time spent in hazy product explanations confuses customers and robs time from discovery
- If it walks like a duck, swims like a duck, and quacks like a duck — then, for marketing purposes at least — it’s a duck.
# # #
Notes
[1] That is, “what is it?”
[2] I swear this is only partially dramatized, and only because I’ve assembled all the fragments into one single response.
[3] This is circa 2008. Presumably much has changed in the intervening 15 years.
[4] I obviously don’t use more recent examples as a matter of both confidentiality and discretion.
[5] An obvious one might be, “so if it’s a database, does it speak SQL?” (To which the answer was “no, it speaks XQuery,” which could lead to another loop of hopefully tight question/answer follow-ups.)
[6] Because, simply put, nobody wanted to buy an XML database. Gartner had declared the category stillborn around 2002 with a note entitled XML DBMS, The Market That Never Was. The way we sold nearly $200M worth of them (cumulatively) during my tenure was not to sell the product (that nobody wanted) but to sell the problems it could solve.
[7] And when they do, they’re not going to be happy that you seemingly tried to deceive them.
[8] Or hire them to do jobs for them, if you prefer the Jobs To Be Done framework.
