In light of John Simonds' timely post on The Differences in Briefing IT Analysts and Press, I thought it might be useful to provide some tips on briefing analysts on open source. I won't reiterate too many of the main points from John's post since he was right on the mark throughout. Plus, my perspective is that precedent and accepted best practices which have proven effective previously are sufficient in covering the basics, but there are certain areas/topics/subjects that can really hurt the quality of a briefing with an open source vendor if they aren't addressed efficiently or worse yet, at all.
Of course, no two briefings are the same and there are plenty of reasons to deviate and/or improvise according to the situation. Nonetheless, if your company has an open source powered business model and are interested in communicating it's value proposition there are several points to keep in mind:
- Don't assume in depth knowledge about open source. Even if vendors who brief any of us at Entiva can safely make this assumption, it's useful to avoid doing so across the board. Of course, we're by no means the only analysts who keep track of this area, but if you're not certain it helps to find out how much is known about open source before glossing over important facts, info, events, etc. This is obviously a moot point if you have enough prior experience with the individual/firm.
- Demonstrate how you're more than open source in name only. Demonstrating a firm comprehension of what it takes to build and run an open source company will help when it comes time to develop a personal evaluation of a company's future prospects. As humans, analysts are still prone to developing an individual take on if a company has what it takes to succeed over the long haul. Making your commitment to open source lucid isn't necessary for silly idealogical reasons but in order to convey concrete synchronicity with messaging as an open source vendor.
- Don't regurgitate product literature. Product and company highlights are always welcome, but copy/paste work from sections of a website isn't necessary. If that sort of information is relevant to the content of the briefing, it helps to have links to that material referenced in an pre-briefing email with the presentation attached to it.
- Take time to mention community. Yes, you are running a for-profit business and the concept of making more money than you spend hasn't changed much since the dawn of the human enterprise. However, what separates you from a proprietary company is that fuzzy concept called community. Accordingly, it helps to hear about the progress, growth and potential of that community. Believe it or not, this matters as much as customer wins, partnerships and new releases.
- Mention how the open source model benefits you and your customers. Regardless of the hype surrounding the "realization" that CIO's don't really care about open source, only about utilizing technology to solve business problems. Open source does enable companies to pass a significant amount of added value to customers, whether the buy side realizes it or not. As a result, analysts can stand to hear some details about how this is happening. If an open distribution model lowers barriers to product evaluation which gives way to a shorter sales process, paint that picture with real-world examples instead of leaving it to the imagination. We might know what open source is supposed to do, show us how this might be happening with respect to your business.
Are there more points of note? Yes. Are most solely applicable to open source vendors? No. For example, from doing some talking around I've found that briefings which allow room for conversational type inputs tend to be more effective for all parties involved. Still, with the varying intricacies of the open source mode yet to be ingrained in the collective subconscious of the IT analyst community, it helps to assure the whole equation is being conceptualized and absorbed during the course of a briefing.
Comments