My dislike of slide presentations is vehement and long-standing. Even so, my consulting duties often lead me to critique vendors’ slide decks, hoping to make them a little more tolerable. Most of the precepts I rely on in these exercises can be encapsulated in “C” words:
- All messaging needs to be Clear, Compelling, and Credible.
- Credibility depends upon, among other factors, Consistency.
- All collateral should be Cleanly Copy-edited.
- A presentation should always be tailored for the specific audience and purpose (it’s not a crazy stretch to call that Context).
And at the risk of drowning in excessive Cs, slide decks are a primary venue for a recent post topic: Short lists of Concise Claims.
Let’s talk a bit about that tailoring. Some things are shown only to very specific audiences. For example: Read more
It is often necessary to produce a short list of concise claims. A large fraction of all PowerPoint slides fit that model. So does the list of news in, for example, a typical product press release.
Making such lists is hard, for at least three unavoidable reasons:
- Individual claims should be concise, clear, credible and compelling. This is a very tough standard to meet.
- Ideally, lists of claims would both be fairly complete and tell a coherent story. That’s a difficult challenge as well.
- Different parts of your audience respond well to different things. No one set of words will please, interest or convince everybody.
Even so, many claims lists are yet worse than they need to be.
To create or improve a claims list, it helps to establish goals by asking
- “Who are we trying to persuade …
- … of what?”
and also to check resources by assessing:
- “What proof points do we have to support our case?”
In the case of a product upgrade, answers often resemble: Read more
This is the first of a not-very-organized series of posts on two related subjects:
- What are the keys to success?
- Which efforts are (how) likely to be (how) successful?
Most of my posts can be said to touch on those areas, especially the latter one. But in this series I’ll try to be more direct about it.
Useful background may be found in:
- The strategic worksheet, perhaps my best-received post ever. Many companies and individuals tell me they have profited from working through it.
- The less well-known execution worksheet that followed it.
- My recent post about kidding oneself, Pitfalls for Pollyannas.
For a new company in a new enterprise IT product category, the path to success may be oversimplified as:
- Achieve early/visionary/bleeding-edge adoption.
- Then achieve substantial adoption in several niches.
- And then achieve either substantial adoption in many niches or …
- … dominance in at least one niche.
Q. What’s the primary difference between used car and computer salespeople?
A. A used car salesman KNOWS that he’s lying.
– A joke that was old in 1995
The technology business is difficult, so it’s natural for technology vendors to make mistakes. Many of these fall into two broad categories:
- Garbled or otherwise ineffective messaging. See, for example, this blog’s overlapping sections on marketing communications, technology marketing, and especially the layered messaging model.
- Over-optimism, in partnering, sales, marketing and development alike. That’s the subject of this post.
In particular, vendors commonly overestimate their (current and future) competitive positions. This isn’t just for public consumption; often, they fool themselves as well. Popular forms of overestimation include (and these overlap heavily):
- Overestimating the prevalence of specific use cases. In a classic example, Mike Stonebraker and others on the early Vertica team seemed convinced that — 20 years of contrary industry experience notwithstanding — most analytic RDBMS users would be content with star schemas. They were wrong.
- Underestimating the requirements for product completeness. This is the flip side of the same error. You know all those features that the other guys have and you haven’t gotten around to building yet? Those features were built because of (actual or anticipated) customer demand.
- Underrating the competition’s current and future product. Vendors frequently think that their features and performance characteristics are unique, and may long remain so. They’re usually wrong, except in the case of features that convey little market advantage.
- Underestimating the work in maturing a product. In 1993, Sybase held a press conference in New York to announce that Version 1.0 of a new C-oriented application development tool would surpass all competition in performance and reliability, after a 3-month beta cycle.* I scoffed; the company took umbrage; my relationship with them went from bad to worse. And the tool? That failed so completely I no longer remember its name.
The dictum Fake it ’til you make it bears a certain relevance here, all the way down to its Alcoholics Anonymous associations.
From time to time over the past 30+ years, vendors have described to me pricing schemes in the vein:
- Calculate a measure of your customer’s business improvement, for example cost savings, revenue increase or marketing lift.
- Take a fraction of it for yourself.
That sounds like a risk-sharing win-win kind of deal, in which your customer’s costs perfectly mirror the benefits achieved.
The naive form of that argument is wholly ridiculous, however; what customers pay you is only a portion of their total cost of ownership, and in most cases not close to the majority. The plan has more fundamental problems too, and experience shows that it rarely works in practice.
Last May, I summarized and explained my standard pricing advice by:
- There should be 2 or more simple pricing algorithms, so that …
- … the price for any given customer is the lowest of those choices.
Generally one pricing algorithm will be suited for most of your customers, while the others will be meant for minority or edge cases. …
Core reasons for that approach include:
- Simplicity. Your salesman on the account should be able to quickly determine which pricing approach will apply. The prospect should be comfortable that there won’t be hard-to-foresee “gotcha” charges.
- Fairness and match to use case. For any particular prospect, there probably will be a pricing scheme that fits well.
- Competitive flexibility. Nothing in this strategy puts much of a floor or ceiling on your pricing. You can do whatever you think is economically best.
Benefit-sharing pricing, by way of contrast, can be simple or fair, but it has great trouble being both at once. So if you propose it, messy negotiations will ensue.
For example, suppose that Tweedledee Inc. mirrors Tweedledum Corp. in all ways but one: Tweedledee uses your best competitor Humptyware, while Tweedledum runs the far inferior Dumptysoft. Thus, if Tweedledee implements your Frabulizer, their rate of rattle-breakage will drop from 2 percent to 1; but if Tweedledum buys it, their rate will drop from 10 percent to the same 1. Should and will Tweedledum really pay you 9 times as much for the same thing as Tweedledee? Not a chance. So if you try to price on the basis of measurable outcomes improvement, you’ll probably just get into a huge price negotiation mess.
I do see one scenario in which I might consider benefit-sharing prices — when you’re in a messy price negotiation anyway, and benefit-sharing could close the gap. For example, if you want $1 million for what you claim will be a $20 million benefit, and the customer offers $750,000 for what they more conservatively estimate as a $10 million outcome, you could let the last $250,000 ride on some agreed-upon metric tracked over time. But even that is a questionable stratagem, in that it amounts to a bet that your salesman’s optimism will actually prove to be correct.
Bottom line: Keep your pricing simple, which it isn’t if it depends upon your customers’ internal operating metrics.
I consult to ever more stealth-mode companies, so perhaps it’s time to pull together some common themes in my advice to them. Here by “stealth mode” I mean the period when new companies — rightly or wrongly — are unwilling to disclose any technological specifics, for fear that their ideas will be preempted by rival vendors’ engineering teams (unlikely) or just by their marketing departments (a more realistic concern).
To some extent, “stealth-mode marketing” is an oxymoron.* Still, there are two genuine stealth-mode marketing tasks:
- Recruit employees.
- Prime the pump for post-stealth marketing.
Further, I’d divide the second task into two parts — messaging and outreach. Let’s talk a bit about both.
*I am reminded of my late friend Richard “Rick” Neustadt, Jr., whose dream job — notwithstanding his father’s famous book on presidential power — was to be a US Senator. So he needed to punch his military duty ticket, and got a billet doing PR for the Coast Guard. (One of his training classmates was Dan Quayle.) His posting was to a classified base, and so his PR duties consisted essentially of media-mention prevention. But I digress …
As I wrote in a collection of marcom tips, the pitch style
“We’re an awesomely well-suited company to do X.”
- In stealth mode, when you don’t have anything else to say …
- … but not at first product launch, when you finally do.
For small start-up companies, this message is most easily communicated through highlights of the founders’ awesome resumes, for example:
Our CTO personally stuffed and dyed the yellow elephant for which the Hadoop project is named.
But that still begs a central question – how do you describe what your stealth-mode company is planning to do? I.e. — in the quote above, what is the “X”?
A common question I’m asked may be paraphrased as:
- We have differentiated technology, and have been marketing on that basis.
- Our best sales cycles are the ones driven by line-of-business executives — for example Chief Marketing Officers — rather than IT.
- So (how) should we message with a business rather than IT focus?
My standard three-part answer is:
- You should at all times have a complete messaging stack that spans all relevant audiences. This is something I’ve been advocating for years. Please see for example my recent post summarizing many of my thoughts on strategic messaging, and the more detailed posts to which it links.
- The choice of what to emphasize in sales should be made on a meeting-by-meeting basis, with adaption on the fly as discussions unfold. This is so obvious it hardly bears saying. Of course your sales teams should be prepared for business and technical discussions alike. Of course your sales executives should understand which emphasis is called for when.
- You should alternate over time between benefit-oriented and technology-oriented emphases in your marketing. I’ll expand a little on that point below.
This blog is based on two precepts that also guide my consulting:
- In enterprise software and similar businesses, messaging is the core of strategy.
- Messages must be robust enough to withstand deliberate competitive attack.
Let’s spell that out.
Messaging is the core of strategy
The enterprise software business, in simplest terms, is about the building, marketing and selling of software. Messaging is central to all of those activities! In particular:
- Selling boils down to two main processes, one of which is delivering sales messages. (The other, of course, is managing prospect relationships.)
- Marketing is mainly about developing and delivering messages. (Most of the rest is lead generation.)
- Development’s job is to make great sales and marketing messages be true.
If we add another level of complexity, the story changes only a little. Read more
|Categories: About this blog, Marketing communications, Marketing theory, Technology marketing||3 Comments|
A common subject of my consulting is naming, and specifically naming the category of product or technology something goes in. Clients are well aware that no market categorization is ever precise. Still, words must be chosen, collateral must be prepared, and talks must be given to rapturous* audiences. Here are some of my go-to techniques.
1. My most precise tip starts from a classic naming dilemma:
- If we call it something entirely new, nobody will know what we’re talking about, or why they should care …
- … but if we say it fits in an old category, then how do we differentiate it?
Increasingly, my advice is to pick a name that’s “half new”, usually in the form of a two-word phrase that overlaps partially with the name of an old product category the new thing sort of resembles.
In some examples from my own work:
- ClearStory Data emphatically does not want its service called “business intelligence”, as doing so might denigrate the novelty of ClearStory’s innovations. A big part of how ClearStory beats traditional BI is in the intelligence of its data handling. Voila! With a nice bit of double-meaning, ClearStory’s secret sauce is now described as “data intelligence“. Edit (May 2014): “Data intelligence” has held up as ClearStory’s top message.
- Platfora’s latest release focused on data sets that — after Platfora assembles them for you — are sort of like time series but also somewhat like event streams. “Event series” was the winning name. Edit (May 2014): Platfora reports that that choice worked out well.
- Tokutek, whose main differentiation is performance, makes storage engines for MySQL and quasi-storage-engines for MongoDB. What should we call them? “Performance engines” fits the bill, at least for the “not exactly a storage engine” MongoDB case. Edit (May 2014): Tokutek hasn’t really stuck with that term.
2. A principle underlying that tip is that connotation is as important as denotation. The reactions that category names evoke can be as important as their literal meanings, especially since those literal meanings aren’t very precise anyway.
Returning to the examples above: Read more
Paul Graham got into a flap by saying that strong accents interfere with founders’ entrepreneurial success. The key section makes it sound like his point is you have to be able to pitch in (fairly) fluent English:
Conversations are more of a problem, as I know from my own experience doing office hours. We talk about a lot of subtle points at office hours. … And I know I don’t get as deeply into things with the groups that don’t speak English well. I can feel it happening; we just can’t communicate well enough. …
A startup founder is always selling. Not just literally to customers, but to current and potential employees, partners, investors, and the press as well. … And yet a lot of the people you encounter as a founder will initially be indifferent, if not skeptical. They don’t know yet that you’re going to be huge. You’re just one person they’re meeting that day. They’re not going to work to understand you. So you can’t make it be work to understand you.
At least in enterprise IT, however, I’d say that there are four points, not just one. You — and by “you” I mean the CEO, the CTO, and any contributor in sales, marketing or product management — should be able to:
- Pitch in (fairly) fluent English.
- Listen in (fairly) fluent English.
- Pitch in (fairly) fluent techspeak.
- Listen in (fairly) fluent techspeak.
My reasons for saying that start:
You can’t sell effectively without listening. This is one of the basic facts of business, yet shockingly many people forget it. You can’t pitch effectively without understanding how the prospect frames what she hears, and you can’t judge that unless you listen to what she says.
You can’t listen at maximum effectiveness without selling. Of course, that depends greatly on what you’re listening for. But commonly your goal in a conversation is one or more of:
- Make a sale.
- Pave the way for a sale.
- Prioritize product enhancements.
- Learn how to change your marketing pitch.