Having just been through an onslaught of work related to the Forrester Wave™ evaluation on Zero Trust eXtended ecosystem platform providers, I think that it’s worthwhile to put some guidance out there that might help folks as they interact with analysts (well, me, mainly, but maybe it will help with others, as well). And a disclaimer: I don’t actively work with folks at other analyst firms, so take my humble advice here with a grain of salt; every analyst is a bit different, and each firm has its own way of doing things.

Do’s:

  1. Have a specific set of slides for the briefing. Focus on the way you solve whatever problem you solve. I want to know how your specific solution helps the end user be more secure.
  2. Move quickly through the company stuff. Yes, I want to know about your company and the super awesome folks that work there, but in truth, I am most focused on how your solution does what it does. Introduce the folks and the pertinent facts about the company in less than two slides and move on.
  3. Keep a cadence. If you really want to engage and work with an analyst, then you have to keep the pace up. If you brief me once a year, expect a once-a-year interaction. Some of us do a few hundred of these during the year; we get saturated with all of the interactions with those groups that do keep a regular cadence, and that means that if you don’t keep up, it’s likely something important gets lost in the mix.
  4. Any company can do a briefing (with me, at least). There is a big market out there and many different ways to address the problems we face; if you have a better mousetrap, please brief me. It doesn’t cost you a thing but time (but please see point No. 1 here before doing the briefing).
  5. Set yourself up for success. If you don’t have folks that know the analyst interaction game, hire some or get in with an agency. The value that both of us get from this interaction comes from everyone being on point, and the skills needed to do this right can’t be overstated. Honestly, if you don’t have the specific experience and talent on staff, GET IT. And in my opinion, and from what others tell me, PR is different from AR. Don’t confuse the two.
  6. Do your research. We have specific coverage areas, and we publish research along those lines of coverage. It’s best you know what those areas are, and the best way to do that is to do your own research on the analysts you want to interact with. Do your homework, and know what the analyst cares about.

Don’ts:

  1. Just jump on a briefing and wing it. Don’t do that. It’s a waste of an opportunity for both of us, and to be frank, it makes me doubt how well things run at the company when something like a briefing isn’t handled professionally.
  2. Go nuclear. If your company is in on a Wave or some other evaluation and things don’t go your way, don’t take the nuclear option. Analysis is not personal, and we do months and months of analysis on a variety of items to come to that final evaluation point. If you go nuclear, it won’t work out the way you want, I promise you. If you have facts or something that is specific enough to possibly influence a change, then great, work through the proper channels and be professional, and let’s see where it goes.
  3. Confuse an investor deck with an analyst briefing. Investors look at the company and all the ins and outs of whether or not that potential investment might be worth it for them. They have specific criteria they are looking for; it’s different from what I or most other analysts I know are looking for. I have no money, seriously. So don’t try and brief me with an investor deck; I won’t invest (and technically, that would be illegal anyway, and I don’t look good in an orange jumpsuit), and most of the stuff an investor is looking for is way out of the vector of what I care about.
  4. Bash the competition or say you have none. If your approach to justifying the validity of your solution is based mostly on how crappy the rest of the market is and you spend your time just bashing the competition, that isn’t a good way to go about it. Sure, point out flaws in other solutions and discuss how you do things better. But don’t spend either of our time talking about how terrible everything else is. And no matter what, you have competition in some way. You may have the best mousetrap, sure, but somehow, someway, you have a competitor, period.

The last thing that I think is worth being aware of is that the purpose of the evaluative reports we do is to help our end users know more about what solutions might help them solve their problems. For me, I don’t do research on vendor solutions with the idea that my end goal is to rank them based on how nifty their technology is. I feel a sense of duty to make sure I spend time separating the use cases and details of those solutions based on their ability to help solve a problem. I honestly couldn’t care less about who comes out on top; it’s all about the benefit of that solution to those folks that are going to use it at the end of the day.