Although I’ve stretched my response to the conversation I had with the folks from Wesabe over far more days – and by “days”, I mean “weeks” – than I’d intended, I wanted to touch on one other turn taken in the conversation that I’m fairly passionate about.
The topic, of course, is transparency. I’m a firm believer that transparency is, in general, a very good thing and engenders loyalty, trust and a lot of other positive feelings. It’s been my experience, as both a developer and a consumer, that organizations can make an awful lot of mistakes as long as they’re accountable for those mistakes and make them right.
This is an area where I’ve always thought that Wesabe has excelled. The entire team is (almost insanely) responsive – do they actually have time left to get any work done? – to support requests, forum chatter and even obscure blog posts. Moreover, it’s not token responsiveness; they’re actually listening to what’s being said and engaging in the conversation so that they can drive a real set of requirements from the discussion.
During our conversation, though, I started to think that maybe the team wasn’t being as transparent as I thought. I can’t speak for them, but I got the impression that maybe they were thinking the same thing – at least to a degree. For example, with respect to the search issue I mentioned in my last (-ish) post, the problems had existed for a very long time and people had been complaining about it for a very long time. A similar sentiment seems to be swelling around support for CSV files. Perhaps if Wesabe had stepped up and offered more visibility into what they were working on instead of these problems, some of the users’ frustrations could have been avoided.
This isn’t to say that transparency is always the right way to go. Like most things, there’s a happy medium in there somewhere. There are some very good reasons to mask a user’s visibility into the process. One that leaps to mind is competitive advantage. I’d never expect, or even want, Wesabe to offer transparency at the expense of their own well-being as a company. Hell, that just hurts both of us.
Transparency is also a useful tool for managing expectations and it has uses on both the positive and negative sides. Tell users more about what’s going on when the roadmap does not include features and fixes that users are requesting. As with Wesabe’s search, understanding why it’s not getting fixed may alleviate some of the pain. Conversely, less visibility manages expectations better when working on a spectacular new feature that might not work out as expected. Providing too much visibility risks disappointment, in this case.