Scooblog on Corporate Transparency – Part 3: What Customers Stand to Gain

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.

Feedback Opportunities

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.

Comments (11)

  1. Mark Mullin says:

    This is an interesting series – and I think you make a pretty good business case for the MSFT blogs

    That said, I think there’s an element missing from your trust assessment, or at least an erroneous assumption –

    1) Many people do not actually peruse the source code of open source projects, but they are in an environment where, for the larger projects, they can safely assume that source has been perused by a wide number of people. A concern with closed source from any company, regardless of how skilled the developers are, is that there are issues of institutional blindness, stuff that’s that way because it’s always been that way. No knock at msft intended, we sell closed source too and we’re just as guilty – nor am I recommending you open source your business assets, only that you recognize what the actual value is in the relationship. The trust is in the community itself, not in any individual. I don’t trust Linus, heck, he used <urp> Minix </urp> as his model – I do trust the aggregate horde of crazies that now plays in that space

    2) Open source is tested in a very open environment, i.e. there is a vast mixture of players from the sophisticated enterprise to the completely clueless – I trust the mixture of this environment – while msft does make a lot of pre-release stuff open to the developer community, much of the pre-release efforts are more tightly focused, and therefore the community that’s ‘vetting’ this new product is more homogenous, and probably less like me – so I trust it a little less

    3) The relative openness of the msft blogs do much to compensate for this, and it has to be compensated for, because not even msft can afford the open source free for all, in terms of the raw cost to support it or the negative impact on the business model – if there’s anything that has significantly raised my confidence across the msft product line, its the fact that there are many blogs that talk about the good, the bad, and the ugly in frank terms. As long as those blogs continue msft can remain an org you can be reasonably confident in.

  2. Josh Ledgard says:

    I love when comments lead right into my next entry. 🙂 What do you mean by more "tightly focused pre-release efforts"?

  3. Mark Mullin says:

    I mean msft has a list of key reference customers (a few of which have been clients of mine) on which a fair amount of attention is focused during beta – this seems to be a major proving ground for enterprise apps (e.g.) Exchange, but also focuses on enterprise adoption of things like .net

    Now, this is a better approach than the old popularity contest of old exemplified by apple in the late 80s, early 90s (if we think you’re cool you’re in otherwise go fish) but it has a couple of key weaknesses

    1) In terms of a basic product rollout, you’re getting it from the enterprise viewpoint – probably getting beat up more than you should on things like SMS deployment, following existing protocol – probably not getting beat up enough on all the edge cases – that’s the basic problem – you don’t see enough edge cases

    2) You do open up access to the larger unwashed masses (of which I am one, so I tar myself with my own brush) but you basically let us fend for ourselves. This has been changing over time with the various ‘casts on the web, but the effort is to make one size fits all work, which leads to the same problem that you have with enterprises.

    What would make me happier than the current modus operandi ?

    Seek out and incorporate pathological edge cases, and let the larger community know who they are (not neccessarily by name, just the criteria matter) so we can see that we’re within the curve and don’t worry that it’s us thats the edge case.

    Imagine a volcanic island – the center, the volcano body and summit are your standard enterprise customers – that’s the big iron money shot component, with all the risks/rewards you already know – but in a lot of products, there’s more surface area as that island slopes off fron the center to the sea than there is on the mount itself. Find the edge cases that define the outlines of the island, and work just as hard with them, even if you are effectively underwriting someone elses software development, without the chance of return you see on the big guys. The return comes when the rest of us folk see that we’re safe, because we’re between the summit and the sea. Then you’re not kicking us in the rump for a long time trying to get us to adopt.

    Finally, don’t choke off the blogs – I read and sometimes comment on Stan Lipton’s and Herbs blogs from time to time – before those guys I thought managed C++ was the stupidest thing I’d heard of. Now that I’ve had a chance to hear what they have to say and see them wrestle with the issues, I still think the ideas a little ‘off’. But not stupid – not by a long shot.

    Summarizing – trust for me comes because I think that the pre-release program has already fallen in all the potholes I might face – they call more threads – they mix more ATA/STA junk. They’re more performance critical – whatever, just so I can look at the space and know I live within it, not worry that I live outside it

  4. Josh Ledgard says:

    Great comments. I feel better hearing your explanation that we are getting closer to the right track. The MSDN feedback center was a good first step. The next step could be a wider availability of our pre-releases.

    This year will also see the release of a VS Standard and Express SKUs that are not targeted at the enterprise customers. After this I’m not sure what other steps could be taken to shed light on the edge cases that is not already being done.

  5. Mark Mullin says:

    Wider availability does no good without actively pursuing the edge cases – statistically speaking, you just end up with useless overlap – and even if you get lucky, you can’t prove it, which is that vital part of this whole trust thing – nice pr move, but useless beyond that

    Finding the edge cases isn’t free – assume that it’s the smaller firms that are pushing the edges – you have something to offer – a firm gets early access and interaction with the experts – this is fundamentally worth money – msft gets an edge case

    Simply put – you already have efforts that actively work to develop relations with large enterprises – how about using a web site or the developer partnering program to actively seek out edge cases within the larger community of smaller (and often more adventurous) developers – you should get more than enough candidates to pick a good set of cases. I’ll bet you a nordy bar that this will get you enough candidates you can pick and choose the best. Or make a contest, or monitor who takes the prerelease and busts it in new and novel fashions (but make sure they can 1) determine that they have done this, and 2) let you know

    Yes, y’all are getting steadily better, but improving won’t come from blindly seeding pre-releases to the known universe, you have to work to find the fringes of it –

    On the ‘bust in novel fashion’ there is one trick we use that does fine, and if it fits in our budget it fits in yours – when somebody triggers the ‘oh my god the speed of light just changed’ error handlers, they get told they’ve won 100 dollars – we hear about it quick, let me tell you! (yes, web deployments are critical to keep the expenses down 😀 )

    Anyway, that’s my 2c, I look forward to your next column