Before continuing on I suggest reading Part 1 and Part 2 of this series.
Measuring Customer Gains of Your Transparency
Before digging into the subjective measurements I’d like to post a couple of disclaimers.
Transparency is not something that every customer will take advantage of. Every customer should have the ability to do so, but only a select group of your early adopters/influencers/fans/”whatever you want to call them” will take rabid advantage of your efforts. Others will simply take comfort knowing the information is available to them should they need it one day. Some customers might not even find out about your efforts even if they are built right into the product ala the MSDN Product Feedback Centers being linked from Visual Studio 2005.
This does not mean your work will not be rewarded. Winning over the hearts and minds of industry influencers is a key to building a strong community to your product and transparency is a tool that can help you do this if done correctly.
Does being transparent about Foo by doing Y give your customers an opportunity to have their concerns heard in time to make a change for their benefit? How much of the feedback are you going to have a chance to listen to given the timing? In the Raymond Chen case I mentioned before there is no opportunity for feedback. In the case of the triage video there is a marginal opportunity to provide feedback, but only on the few issues discussed.
For an example of timely transparency you can follow the C# team’s trek towards adding Edit and Continue into Visual Studio 2005. In 2003 a roadmap was released that showed the lack of E&C in C#. It started a few conversations that spilled over into the blogs of C# team members. Then we created the MSDN Product Feedback center for Whidbey and guess what the #1 requested suggestion was? We would have most likely eventually released E&C for C#, but you might not have seen it in Whidbey if we hadn’t been as transparent about our intentions as early as we were.
This is just one highly visible example of how being transparent early enough can provide opportunities for constructive discussion with your customers that leads to good feedback and a change of plans that works out in the best interest of the community. So you should ask “If I’m transparent about this am I opening up an opportunity for feedback?”
Does the information you are thinking about opening up help your customers prepare for an impending product release? Does it help them make the choice about which pre-release builds of your software they should start playing with in order to prepare? How much does this information help your customers feel satisfied with their decision to purchase your latest release because they knew what to expect before day 1? Did you remove the surprise of known issues and teach people early on how to work around them? Sharing advanced information about the timing of an upcoming release could score a 5 for being very helpful to your customers.
Are you teaching your customers anything useful? Are you educating them on how to use your product once it is released? Are you giving customers insight into how things are done in your organization that they could build on and leverage to make their lives simpler. This goes back to the CoC philosophy of “napsterizing your knowledge”. How effective is the post/video/item in question at sharing your knowledge?
I don’t know how many times I’ve heard the phrase “I trust open source software because I can see what’s inside if I want to. I can prove it isn’t doing me any wrong”. I doubt many of the people that say that even bother to ever download and crack open the source, but that doesn’t shift the perception that openness can equate to trust and trust can equate to a higher level of satisfaction with a product. If you are more satisfied with the product and you trust the company more then you probably feel more of a connection to the product than you would otherwise. Yes, I consider higher satisfaction a customer gain.
Which would instill more trust… hearing, through a press release that a new piece of software had been alpha and beta tested monthly by a set of special customers or having that opportunity open to you and everyone else personally? Do you trust a product more if you know that you can contact the people who built it directly or if your only opportunity for a direct connection is on hold with customer support?
Explaining your workflow, why decisions where made, and even how bugs are triaged can help make people feel more connected to your product. Source code is not the only thing that can instill trust. Being transparent with your intentions will help as well. Would customers only trust good news when they know there is bad news to be heard as well? Be careful and honest with people should you choose to filter what customers see. How will the content you are considering to publish help seed a connection of trust with your customers? How much of your ride are you willing to share with customers?
Part 3 Concludes
Ok, I’ve tackled definitions, fears, and customer gains. Stay tuned for Part 4 that includes a brief comparison of corporate transparency to the OSS version and the final wrap.