Disclaimer: This blog post is hyper focused on tech communities and may not be relevant to communities in other industries.
Continuing the learnings from LavaCon, I wanted to write about another interesting question that came up during the workshop in Portland last year.
Protecting trade secrets and your product’s “secret sauce” in ingredient level content? How do you manage proprietary information on a public community?
The easy and quick answer is, You Don’t!
Community means public content
This question defies the base idea of content shared with your community. Sure, you can lock down your community, to allow only customer access to it. Whereby I may ask you, how do you manage customer churn amidst your community members? – I thought so: not at all. Neither did I.
There are two key thoughts I want to lay before you to ponder, before I move to give you some alternative answers to content security. I know, not everyone is willing to accept No as an answer. But at least give me a chance to explain myself.
My Two Core Beliefs:
- Your community can work miracles at shortening your sales cycle, onboarding new customers, improve your customer retention and lower your customer service queue. If you don’t believe me, google Customer Service Community ROI calculations for tech companies. Or better yet, attend my SDX workshop in Portland in June. Locking down your content from google and the public will short circuit all those efficiencies for your company.
- Your R&D team should be 1-2 years ahead of your current product development team. Therefore, public access to your most up to date tech documentation will never curb your market viability. Neither should it impact your competitiveness in the market. If this is not the case, you are already fighting a losing battle.
Ultimately, my belief is that anyone thinking that their documentation is the weak point in keeping trade secrets has a flawed thinking. I have yet to work for a company that does not offer a free trial of their software. Others have seen disgruntled customers sharing the product or documentation with a competitor. Better yet, competitors buying your software as a “fake” customer. Believe me… your community documentation is NOT the weak link.
Anyway. This is a not a product management blog, so let’s get back to content strategy.
If you are still thinking you need to have some kind of a security clearance in place for your technical content, I have two options for you. Please note, I am sure there are hundreds of other options out there. These are the two I have seen and used before and I think they offer a good enough solution to this problem, should you find yourself in a pinch.
Publish to multiple platforms
Publish to multiple platforms based on sensitivity levels. Granted as a Community Manager some of this drove me insane. But publishing toolchains can be seamlessly integrated in your content management platform. This can give you editing and version control in one platform, even if the content was pushed to multiple channels.
Let me give you an example. At EMC (back in 2015) we had several tiers of content access. All content was authored in the same CMS, but based on its security clearance (Level 0 – Level 5) it got published in different channels. Level 0 was considered public and published to the community without issue. The majority of documentation was Level 0. Level 3 was for customer-restricted documentation, and included release notes with bug fixes and known issues; this content required a customer logon account to view. Levels 4-5 were considered sensitive and were restricted to Partners and Employees only, respectively.
The distinction was straightforward. We published security risk documentation (such as exploits and hacking issues) as Level 5, so that only the highest level admins at each customer and our internal experts had access to it. Keeping the access levels very tight on high security issues. This method worked for us. The benefits of this dual publishing method included safety on highly sensitive content. While also facilitating public content in a varied and plentiful. This method benefitted sales, customer service, training and our customer retention teams.
User Roles and Tags
If you want to keep publishing to one platform (say your community) – which I highly recommend – you can use tags and user access (roles) level to organize your content. It is also a great way to provide user access to specific topics or tags. Or in this case, sensitive content. Some community platforms (not all) provide content tagging and community role features. The latter lets you set access and functionality limitations for community members. One example I have seen done well, gives different permissions to software admins and software users within the community.
For example, an Admin had access to deep product level documentation. Users however, only got access to generic user related documentation. This cuts down on exposure risk for sensitive product info (and for all intents and purposes also avoids clutter in your Knowledge Base). It also made any deep technical content unavailable for viewing by the public without a community membership.
The latter method may not provide an uplift or shortening of the sales cycle, but it is still very powerful when it comes to customer service, trading and retention issues.
What methods have you used to manage your customer’s security clearance and access to deep technical content?
Additional blogs from this series include: