If you’re on the vendor side of the industry it will help you to know what analysts actually do – and by that I mean the whole range of activities. Knowing this about an analyst will give you a clue to at least three things:

1. How influential he/she can be.
2. What your company or your competitors may hire them to do. (In AR you are often asked advise on which analyst to choose for what).
3. When and whether to brief them about new products/services and/or invite them to conferences.

So here’s a structured list of things that I personally do or am hired to do, with a few things added which I know other analysts do, but which I’ve never done. I’ve divided it into sections for the sake of clarity.

Technical Activity

• Get hired as a consultant to advise on areas of expertise. In my case consult on software development, software architecture, BI & data warehouse, software audits, IT security and ecommerce.
• Get hired to assist in product selections.
• Actually design and develop systems. Few analysts do this, but I make a point of staying active. Right now I’m doing the development work on this blog and a few other web sites. This means I really do know LAMP (Linux, Apache, MySQL & PHP) and also CSS, XML and other acronyms we all know and love.
• Get hired as an expert witness. I’ve done this twice in about 15 years. Some analysts are on expert witness lists with lawyers, but I’m not.
• Get hired by VCs, investors or even vendors to do technical due diligence on technology products. This is always an independent audit and usually involves providing opinions both on the technology and its potential in the market place.
• Get hired by vendors to assist in product development. This is infrequent, but it does happen. Most analysts don’t have the technical breadth and knowledge to do this, but a few do. This is always done under non-disclosure. If you even whisper that you did the work to anyone you’ve broken a confidence.
• Benchmarks. This means carrying out benchmarks and in some instances even formulating them. Very few analysts get to do this. It’s specialize. In my case I profited from doing some performance measuring work with Hewlett Packard and this gave me a grounding in benchmarking, so I have done such work.
• Sit on advisory boards. If an analyst sits on an advisory board they should declare this whenever they write about the company or mention its products. When sitting on an advisory board you simply provide advice on the basis of your experience. I’m not currently on any advisory boards but in the past I have been on the advisory boards of the following start-ups: Reasoning, Clear Commerce, Tantau, 180 Software & Vieo.

Research Activity

• Visit Vendors Web Sites. When trying to understand a new technology area I go to every vendor web site I can find. If I have time I visit a vendors web site before a briefing. Vendors build their sites primarily for customers, but as an analyst you quickly learn to read between the lines of every web page. “So they mention but two customers; what does that tell you?”
• Do briefings. Most analysts I’ve talked to are like me. They do briefings with a number of large companies that they follow. They accept briefings in technology areas that they are currently focusing on and they’ll take a look at anything that interests them. Some (like those working for Gartner) have to focus more tightly than that.
• Attend analyst conferences. I could attend at least four times as many as I actually do. The problem is the travel time. Sometimes conferences clash. The larger vendors know to check on each other so that clashes are avoided, but smaller vendors sometimes forget to do this and suffer accordingly.
• Scan the news/Internet. I used to read industry magazines and journals and even collect them. Once I had 5 years of Byte magazine; every copy. Then Byte magazine ceased to be Byte magazine. Now I get everything from the Internet and the business press. Analysts have their favorite sources. With me it includes my back catalog of writings. You can go back to an area of technology 5 years later and discover that the fundamentals are still the same.
• Read Books. I use books to get a hold on technology areas where I have no grounding. The information is better structured than on the Internet (except for the Wikipedia, which is a fabulous resource for a surface understanding of just about anything).
• Do surveys. I only get involved in quality surveys. I wish I did more quality survey work – you end up with very good user perspectives. Naturally the IDC-type of Analyst company is steeped in this activity.
• Technical Activity. All the technical activity mentioned in the first section above feeds into research.

Production Activity/Delivering Information

• Communications Testing. Larger vendors pay analysts to do message testing. I’ve already mentioned something of this in the Pre-Brief posting. here I can add the fact that sometimes more than one is hired to get a consensus view – especially when you are trying to do something difficult like “create a new category. Some analysts understand marketing well and some do not.
• Collateral Review. Reviewing the marketing collateral that a vendor uses, including doing reviews of vendor web sites.
• Partnering. Advising on possible partners or partner strategy.
• Blog Postings: Just as I’m doing here. I blog about anything. If it’s about IT I may mention a vendor positively or negatively to illustrate a technical point.
• Short Reviews: Some blog postings turn into short reviews (positive or negative). It’s free for vendors to link to them, but I don’t guarantee to keep the posting forever available. You can’t pay me to do a posting. You can buy the rights to reprint, if you want to use one of my postings directly on your own site or as marketing collateral. That should be the case for all analyst blogs. I used to write short reviews, but now I only blog.
• Product Reviews: I used to do these too – sometimes scoring products against a set of criteria. Some analysts, like Philip Howard at Bloor Research specialise in these, but I stopped doing them a long time ago.
• White Papers: These are best done as thought-leadership views of a technology area. This is something I specialize in, because I like investigating a technology area from a conceptual level, modeling it and then crystallizing a practical description from it. You can include a product description within such a paper as an illustration, but if it turns into an essay of praise for a product it loses all credibility.
• Competitor information: This normally involves assembling a broad set of competitive information for a given vendor to help them to compete, written in a form that can be used directly by their sales force. The analyst has the advantage that they can get information that the vendor might find it difficult to get in any other way.
• Reports: These can be published as books or as a series of regular bulletins that are structured to fit in a loose-leaf folder. I’ve not written in this way for a long time. Many analyst companies have products of this kind. They serve both the user and vendor community with such writings.
• Book: Few analysts write books. Nevertheless, my friend (and analyst) Jon Toigo has written many. He’s almost established a monopoly on disaster recovery literature and was lucky enough to have it all ready to roll before 9/11. I’ve written a couple of books – but not to earn money. Analysts can’t easily earn money from writing books, but books create credibility.
• Presentations: This used to be my major activity until I moved out to America and got fewer engagements. I used to present on just about anything anyone asked me to do.
• Pod Casts: I’ve only done two of these and I don’t do them on my own account, but I will in time. HaveBlogWillPodcast. No more than 5 minutes, please.
• Webinars: I’ve done quite a few of these for vendors; never as endorsements, always as thought-leadership pitches, which vendors can follow with a discussion of their product/service.

I don’t know if that’s everything, but I think it is. If not I’ll update it over time.

Note that I didn’t explain how analysts actually carry out research. That’s because there are different approaches. On the next posting in this series, I’ll explain how I do it.

Note: This posting is one in a series of postings that deals with the topic of dealing with analysts. Click here for links to other postings in the series.