Branded Features: Resist the Temptation

Software startups seem drawn by sirens to brand their features. Hey, Apple does it.  Think:  Siri, Facetime.  Microsoft tries it:  Cortana.  Starbucks even brands a cup size:  Venti.  So if they can do it, we should too, right?

Wrong [1].

49557741_s

But it’s so cool.  Imagine it’s a long time ago and we’re about to launch the first DBMS with stored procedures [2].  Shouldn’t we call them Intelliprocs™ as opposed to plain, old stored procedures?

Then our competitors won’t be able to copy Intelliprocs!

Wrong.  If that’s what you want, get a patent, not a trademark.

Oh, well, then our competitors won’t be able to call them Intelliprocs.

That’s correct.

But we’ll make Intelliprocs the industry term and we’ll  be widely acknowledged as having created both the term and the feature.  Customers will ask competitors if they have Intelliprocs, too!  It will be like going to Peet’s and asking for a Venti latte!

Wrong.  In fact, calling them Intelliprocs and trademarking it virtually guarantees that won’t happen.  The industry will be forced to call them anything but Intelliprocs.  Furthermore, Intelliprocs sounds stupid, and no self-respecting database architect is going to call them that.

By the way, we’re a small company.  Most prospective customers are yet to hear of us here at Sybase [2], so we’re going to dilute our branding efforts.  Instead trying to make people know that Sybase means fast relational DBMS, we’re going split our efforts between that and getting them to first learn the term Intelliprocs and second that Intelliprocs come from Sybase.  That’s three branding efforts when we should be putting all our wood behind one arrow.

Plus, where does it end?  If we call stored procedures Intelliprocs, should call fast commit QuickCommit™, on-line backup ContinuBack™, optimistic locking OptiLock™, group commit GroupFlush™.  You’ll need a thesaurus to understand us when we speak.  And to what end?

If we want the industry to use our language and to know that we invented [3] these features, we should give them common, descriptive names so that others will use them, and then we can market — to the industry and its influencers — the fact that we were the first to deliver them.  That’s how you get known as an innovator.

We’ll save money by not having to register all those marks in 47 countries around the world.

Speaking of international, descriptive features names translate better into other languages than branded names.  If you think we’ll be hard to understand when we speak English, imagine how hard it will be when we’re speaking French, Greek, or Mandarin — with all these untranslatable, English-rooted, branded feature names popping up every two seconds.

We’ll be in a way better position, legally, when it comes to defense.  If we name stored procedures descriptively, it will help us if someone else claims our name is their mark.  We’ll just argue, correctly, that it’s a descriptive name and not a brand.  The more “brandy” we name them, the harder that is to do.  So our branding strategy should be to have one brand, Sybase, and then name everything (e.g., products, features) else descriptively.  It the best marketing, and the best legal, strategy.

Last of all, remember branding first principles.  It’s Jell-O brand gelatin.  Levi’s brand denim jeans.  Kleenex brand tissues.  Zoom brand videoconferencing.  Tinder brand dating.  While you certainly can brand features, the primary purpose is to name and differentiate your company’s offering from the other ones.  Branding is not first and foremost about features.  It’s about companies.

So, if you’re not a multi-billion-dollar company, then maybe you shouldn’t emulate the marketing strategy of one.  If you take a breath, pause, and think about what it means to create branded features — to your branding, to your comprehensibility, to your industry leadership, to your international operations, to your legal strategy (and associated costs) — you’ll decide to pass on branded features every single time.

# # #

Notes

[1] This post is a fresh take on a post I did in 2006 entitled On Branded Features, which actually uses the same example.

[2] This is a fictitious conversation about a real example.  Sybase was the first relational database to introduce stored procedures.

[3] See note 2.

[4] Closer to reality, first brought to the relational DBMS more than invented.

All trademarks are the property of their respective owners.

 

7 responses to “Branded Features: Resist the Temptation

  1. Erudite as always. Talking about stored procedures made me feel young again :) perhaps my Prince of Wales check, double-breasted suit will be back in fashion.

  2. Pingback: Does Apple Have Too Many Branded Features? | Product Marketing Hive - PMMHIVE

  3. Totally agree. I seem to recall that for about 5 minutes, Host Analytics had something called the “PDEX Engine”, which had to do with Polyglots. I’m pretty sure a polyglot is what happens to my stomach after I eat In-N-Out Burger.

  4. There are good reasons to brand a feature: when you need to call out that your feature is unique: Hypercube with Anaplan is great marketing. It also gives the company something to rally behind.

    As for polyglots… I get those with Chipotle.

    • Branding one feature, e.g., Endeca’s MDEX engine, Anaplan’s Hypercube, or Apple’s Siri are all great examples of branded feature. However, the common problem is when a startup tries to brand 10 features all in a half-hearted way. IntelliThis, SmartThat, IntuiThis, QuickThat … the names are not distinctive, there is no real wood behind the branding arrow, and it turns your marketing into undecipherable gibberish. Can it be right? To your point, yes. Is it often done wrong? Abso-absolutely. One tip on doing it right — don’t brand a feature, brand a major [architectural] component as per Bill’s example.

  5. Pingback: Three Marketing Lessons from The Realm of Politics – Kellblog

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.