Pelz-Sharpe on Analyst Relations

A few months back, Alan Pelz-Sharpe of CMS Watch posted an interesting write-up entitled Advice for Vendors Dealing with Independent Analysts. I thought I’d highlight it here for two reasons:

  • It provides a rare, reverse-look at vendors through the lens of analysts, a bit like a doctor writing up how to be a good patient.
  • After two decades of dealing with industry analysts from the vendor side, I — perhaps surprisingly — generally agree with the advice and I have some commentary I’d like to share on it.

Here are Pelz-Sharpe’s 12 rules, along with some Kellogg color.

1. Don’t assume the analyst is out to get you. Color: too many people assume analysts take sides and, in general, I believe they actually try not to. So while you may notice analysts not taking your side, you probably won’t notice that (good ones, at least) aren’t taking your competitors’ side either.

2. Your reputation precedes you. Color: the software world is small, the software marketing world smaller, and the analyst world smaller still. Your company’s reputation and your own precede you in walking into the room. Ignore this at your peril. Instead, try to build credibility over time through honest, credible communications and responsive turnaround.

3. The technology customer is king. Color: analysts love to talk to customers. So you should not only respond quickly to reference requests, but ideally work at a company that actually has happy customers, so it’s both easier to find references and you can do things that analysts will find unusual — like giving them un-chaperoned access to customers at your user conference. Almost any vendor can find/manufacture 5 happy customers out of 1000 and chaperone an analyst safely through the minefield of the other 995. Very few say: “go into that room full of customers and talk to anyone you want; yes, you’ll hear a few grumbles, but overall I think you’re find them very happy.” I’m pleased to say at Mark Logic that we do the latter.

4. Don’t threaten analysts. Color: this is probably the one way to get an analyst to take sides. Remember years ago when CA declared war on Gartner? Take notice of Alan’s comment that nasty emails are “the coward’s way” of dealing with conflict. Those who know me may laugh, but I’ll say it anyway: never send a nasty email. (OK, outside the company at least; I’m still working on the inside-the-company part.)

5. Don’t quote your own press releases or other analyst reports as evidence. Color: this is just plain moronic and I’m amazed by how often I see it either attempted or done. Also, remember that while it’s a bit non-intuitive, most analysts deliberately do NOT read each other’s work as a way of both insuring independence and avoiding plagiarism claims. So it’s bad idea for even more reasons than you might think.

6. Never say “we provided an X% ROI to our client in less than six months, etc. Color: this is the one point I’d quibble with, but in general I’d agree — not for the reason Alan states — but because most vendor ROI claims lack credibility because the analyses are simply not well done. They lack rigor, ignore opportunity costs, tend to count only incremental costs, and make a dozen other basic errors such that I — as a buyer — wouldn’t give them the time of day. To agree with Pelz-Sharpe, I do think that the lower level the technology, the more the ROI argument is in fact **for the category** and not for the vendor. In short, while I believe it’s possible and often desirable for marketers to invest in high-quality ROI analyses, I think it’s equally important not to overmarket them (i.e., your mileage may vary) and not to attempt to differentiate unless the analysis is specifically focused on competitive differentiation. (In which case, I’d argue that should be more of a total cost of ownership analysis that assumes roughly equal benefits as the competition, so the differential ROI is actually coming from a lower TCO.)

7. Don’t kiss my ass. Color: while I agree with his point overall, I’ve known many an analyst who appreciated a fun dinner and a nice Bordeaux. Much as in dating, I’d argue, the issue is what you expect. I expect to have a good time, to enjoy at least some of the Claret, and hopefully to make a new business friend — but nothing else. So I say offer the fine meal — or the simple one as your guest prefers — and spend some time getting to know one other. But don’t expect 5 mm of magic quadrant improvement per Robert Parker point above 95. That’s not the way it works; expecting such is offensive.

8. Don’t ask me for advice. Color: I just love this point. While there are times when it’s important to get analyst input and buy-in up front, most people seem to get it quite wrong. Were I an analyst, nothing would scare me more than a vendor who says: we don’t know what it is and we don’t know how to position it — but what do you think? To which my response would be: “Hey buddy, it’s your full-time job and if you mean to tell me that you can’t figure out your strategy in six months why do you expect me to do it in ten minutes?” Put differently: “Do you have a strategy or not? While I will most certainly have an opinion about your strategy (if you have one), frankly, nothing scares me more than its complete absence.”

9. A demo should actually demonstrate something. Color: totally agree, and hard to add much here.

10. Make sure you understand how your product works. Color: this is another point I just love. It’s scary how many product marketers want to brief people on products about which they understand relatively little. Remember the Dale Carnegie-ism: if you want to speak about something you should know 10x more than you’re audience. You should not be presenting at the limit of your knowledge; your knowledge should be much deeper.

11. Understand the difference between a fact and an opinion. Color: I’d agree and offer the analyst community a friendly reminder that this cuts both ways. An opinion isn’t a fact just because it’s mine — or, for that matter, yours. I’d also add that vendor commitment to a strategy is a fact (provided you can validate it’s true since many vendors claim commitment to N different strategies and ergo none). But, once verified, commitment to a strategy is fact; whether a given strategy will work is opinion.

12. Understand that customers implementing your systems have a very different perspective to share. Color: while I understand his point, I think that great companies to go great lengths to understand their customers and partners experiences and opinions about the product. So, to me, this point goes without saying, but I’d add that I am more than ready to discuss what we are hearing our customers and partners telling us and we should be allowed to do so (if only to show the degree of gap or non-gap in our knowledge).

He closes with an “extra credit” rule — don’t believe your own hype — where he adds the following sage advice on not living in a vacuum.

We know it’s your job to be passionate about your company, about its product, and its services.
We understand it’s your job to help sell this vision and to educate us all. But make the effort to really understand your competitive landscape too. Don’t live in a vacuum. Analysts don’t. I applaud your enthusiasm, and I wish you and your colleagues the best of luck, but I wish all your competitors the same too.

Thanks to Alan for a great post. I hope vendors everywhere read it.

3 responses to “Pelz-Sharpe on Analyst Relations

  1. Daniel Tunkelang

    Dave, great stuff. You might enjoy this open letter I recently published and sent to some of the leading enterprise providers and industry analysts in the information access community. Curious how you’d stack it up against your/Petz-Sharpe’s 12 rules.

  2. Thanks Daniel. While I agree with your problem statement (i.e., that information access community could be doing a much better job at market education), I’m not so sure the answer is work more closely with the academic community. In one way, I think information access technology is already too scary / mumbo-jumbo / black-boxy for most business executives (e.g., Autonomy’s Bayesian messageing) so I think this might actually compound the problem. That said, I don’t have a better solution so I’d say your idea is worth a try. We already participate a bit with the academic database community (e.g., SIGMOD, VLDB) so I’d add them to your list.

  3. I like point #3. I went to a vendor user group and talked to lots of their ISVs. During a management briefing I pointed out that what I heard that day went counter to what they were just telling me about priorities. I haven’t been asked back to that vendor’s user group for the past two years :-)

Leave a Reply

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