“Tell Us About Your Technology” and More Analyst Briefing Tips

After the epic post with vendor tips for analyst briefings, I had a lot of feedback and comments [and praise – mostly praise, naturally :-)]. One thing came up though: advice “tell us about your technology” is often exceptionally hard to follow.

For example, “Tech Go-to-Market: 6 Common Messaging Mistakes and How to Avoid Them” (Gartner access required) states that “if buyers find your sales and marketing materials to be confusing or contradictory, or if they can’t tell you apart from other vendors, they will no longer consider buying from you”, but also that “providers feel compelled to reveal every feature of their product in excruciating detail.” But, OK, how to actually say what you do CLEARLY?

Am I about to reveal a magic methodology on how to communicate what your tool does?

This very second?





On a more serious note, for now all I have is examples, some good and some bad. Lets consider some GOOD example for a change.

If you recall from “Demystifying Security Analytics: Sources, Methods and Use Cases”, we used the framework of DATA SOURCES | METHODS | USE CASES.

S M UC frame

In my view, this works brilliantly for many security tools [but likley not for all, since not all products analyze data to deliver their value]. Still, I think our framework has some lessons for other tools, and it can be genericized with a bit of thinking.

Perhaps something like this:

  • What specific problem is being solved?
  • What technology is being used?
  • How does the product architecture look like?
  • What controls/inputs should the user apply?
  • How it fits with the rest of IT?

In any case, enjoy this incomplete thought!

Related blog posts:

This is a Security Bloggers Network syndicated blog post authored by Anton Chuvakin. Read the original post at: Anton Chuvakin