It seems counterintuitive that business would reject a completely free service. Business Technology’s resident U.S. blogger Keil Hubert explains how that word ‘free’ can dredge up horrible associations.
In honour of Bastille Day, I want to take a moment to explain why CIOs and IT leads tend to be deeply suspicious of free products and services. There’s an actual connection here between the two topics, and I’ll explain if you indulge me for a few paragraphs.
Back in June, I met a fellow named Todd [1] who works in the marketing department at Bloomforth, a tech start-up based out of the US East Coast. Todd and I were kicking around some social media marketing ideas one afternoon when our conversation came around to the importance of having storytelling skills. Todd had (at my request) shared a few anecdotes with me about how much he enjoyed being part of a vibrant new start-up. He asked if those stories would inspire me, as a theoretical customer, to have a better impression of their product. I advised him that his workplace impressions (while assuredly true) likely wouldn’t have a positive impact on me. I explained that I’d lived through the first Dot Com Bubble, and I’ve worked my fair share of start-ups. I told him that what I wanted – what would resonate with me as a customer – were stories that resonated with my own situation. ‘Tell me about a peculiar situation that you’ve found yourself in, and how you eventually resolved it.’ Get your listener to see him- or herself in your hero’s shoes, I said, and that’ll help to solidify an emotional connection between the two of you.
Todd mulled my advice over, and responded: ‘A few months ago we were out in the local small business community talking to owners about their shops and explaining how we could fit in with what they are doing. One of the people we talked to owned a small retail store… We were explaining that what we offer is free to use for her and she immediately put up her guard asking us how it could be free. She said that it sounded like a scam.’
I knew exactly why he’d encountered that reaction. I’d have reacted the exact same way at first.
‘It’s funny that when you try to offer people something for free they immediately assume that they are getting ripped off. Anyway, we explained that there are different bundles that cost money based on the size of their business, but that she could sign up for free because her store was small enough.’
I told Todd that I empathized with both his position and with the small business owner’s. I’ve been on both sides of the equation, and I know where they’re both coming from. The problem lies in how each person visualizes the product – and how that unintentionally triggers deep-seated anxieties.
From the service provider’s side, letting new customers take your awesome new product for a free spin seems like a great way to create a happy customer for life. You let the client play with the product to their heart’s content, explore all of its features, and grow to love it. That’s why so many developers offer trial versions of their standalone products that are free to download and are fully (or nearly fully) featured. Once you’ve taken the product for a spin, you realize how useful it is and cheerfully sign on as a customer.
It’s even easier to do this with a cloud-based solution like Bloomforth’s. Their strategy of letting very small customers use the actual production product for free makes a lot of sense. They’re already running a data centre structured to handle hundreds or thousands of simultaneous demanding clients. They have ‘slack’ in their production capability – extra storage and processing cycles that aren’t being used. Why not let some very small users make use of that extra capacity? It costs them effectively nothing, it’s easier than supporting a standalone demo version of the product, the client gets real value out of the experience, and hopefully the client will grow to depend on the product and will naturally become a regular paying customer as their business evolves. I’ve known a great many start-up owners who took the same approach, and it worked out very well for both them and for their customers.
So, why would Todd’s small retail shop owner balk at getting on board with his free-to-play offer? Most likely, I argued, because she’s been down this path before and has been badly burned by it. I’ve been there too, and I’m reflexively suspicious about offers of ‘free’ services. I’ll offer the curious case of Microsoft’s SharePoint as my favourite example.
For disclosure’s sake, I’m using Word 2011 (v14.4.3) to write this column. I’ve been a paid-up user of Microsoft’s Office suite since version 4 back in the early 90s. I still reminisce about the (relative) speed and efficiency of Word v5.1 from the old Macintosh System 7 days. Yes, I spent quality time with competing word processors over the years (I especially miss Write Now v4) and I often switch over to Apple’s Pages application, especially when I’m traveling with my tablet. But I come ‘home’ to Word for long-form work. It’s like a comfortable old wool coat that fits just right. I don’t harbor any animosity for the fine folks from Redmond.
That being said, I spent years working very hard to keep Microsoft’s SharePoint Server the hell out of my data centre.
If you’ve never dabbled in SharePoint land, here’s the gist: it started off as a web-based access tool for organizing your records. Whereas a traditional file server was the computer equivalent of a metal filing cabinet, the SharePoint service was like a chipper young clerk who acted as the intermediary between the user and the file cabinets. Once you put SharePoint into the equation, users wouldn’t go directly to the cavernous and often-confusing records stacks to file and retrieve documents; they’d get everything though the clerk. Said clerk could also keep track of multiple versions of a record, could check file out to different requesters at different times, and could do other helpful tasks on-demand. I’m simplifying the technology greatly, but the analogy is close enough.
Back when SharePoint was new (circa 2001), the organization I was running IT for simply didn’t have the sophistication to stand up a web front-end for document management like SharePoint. My web developers could barely write simple HTML, and couldn’t troubleshoot server problems to save their lives. I couldn’t afford to push new tech on the crew I’d inherited; there was only one sysadmin on the entire team who could stand up a simple Apache web server. We therefore spent the first few years concentrating on executing the basics; walk before you sprint.
By the time I’d replaced all of the original web support people with actual trained techs (around 2004-ish), SharePoint was becoming popular within our industry segment. My peers at other locations were starting to stand up their own SharePoint servers just to see how well they worked. I asked my new web team to go interview their counterparts and come back with a frank assessment of whether or not it’d be worth it for us to try standing up a SharePoint box of our own. The word they brought back was… damning.
To be sure, Microsoft’s ‘free’ product worked as-advertised. Many users were quite fond of the SharePoint user interface and its core features. The IT directors, though, were much more grim about SharePoint’s place in their server farm.
‘It’s a tar pit,’ one director complained to me over a maudlin late night drink. ‘Once you put your data into the damned thing, you can never get it out again. Documents get… changed. No matter how you try and export your data, you can’t ever get your original content out. Ever. It’s a trap.’ [2]
I followed up with a few other peers and got much the same story. The version of SharePoint that Microsoft was offering us was an insidious Trojan horse (of sorts). Once people started using it, all sorts of critical corporate information would be entrusted to their server. That was just fine, so long as you never tried to stop using it; taking the server offline meant losing all of those critical records forever (assuming that they weren’t backed up elsewhere). I looked at that and said, ‘No thanks.’
A few years later, SharePoint became so popular commercially that our national headquarters announced that they were planning on replacing all of the company’s file servers (nationwide!) with a universal SharePoint solution. It was an ambitious plan (to say the least), but it was decided at echelons well above my pay packet. If that was where the CIO wanted to take the enterprise, I thought, so be it. We’d convert faithfully when the time came. As for when that’d be… the head office set a target date for testing that was a few years out. Since the head office had a track record for late deployments, we all mentally tacked on a few extra years (and turned out to be right on the money).
During the run up, though, several prominent users complained bitterly to me that they wanted a local SharePoint service right now, damnit! I’d field requests from department heads about once a quarter demanding that IT stand them up a local SharePoint service. It wouldn’t cost us any money thanks to our Enterprise Software Agreement with Microsoft, they said, so what’s the problem? Why were us nerds being such sticks-in-the-mud over something so innocent and useful? Were we just opposing their desires out of spite? Because we were all jerks? [3]
As I explained time and again to the angry customers, there were two critical flaws in their argument. First, I didn’t have a spare employee to put on SharePoint Administration duty. Someone would have to actually build all of the sites and sub-sites, and make all the services play nice with the rest of the network resources. That was a full-time gig, and I was already short data centre staff positions.
Second (and most importantly), the national office’s deployment plan carried with it a non-negotiable warning: whenever the national SharePoint service got rolled out, all site-unique SharePoint services were to be immediately terminated – there would be no assimilation of existing servers, and all data entrusted to site-unique servers would be lost. Any implementation that we did locally would be like loading our precious cargo on an artillery shell… it’d be perfectly safe all throughout its flight, but it would be irretrievable lost at the end of its ballistic arc. How much critical business data were the customers prepared to lose, I asked, just for the sake of playing around with a cute web front-end to the file servers that we already had?
The national SharePoint solution eventually rolled out about the same time that I was leaving. I heard that my successor embraced it wholeheartedly, and received generally positive reviews. Good on ‘em, says me. Hope it works out.
As for the ten-year run-up to that deployment, yes: I fought a lot of people who wanted us to put our critical business records into a black hole. I took a hard line against going down that path, because I had very strong evidence suggesting that the risk of losing access to our critical records was simply too great. We had regulatory requirements to meet, and the prospect of losing official records was simply unacceptable.
I started this column referencing the Bastille – the fortress-prison in Paris that the anxious citizenry assaulted on 14th July 1789 to seize its supply of armaments and to free the prisoners held there under lettres de cachet – royal orders that could imprison a person without trial or appeal. To my mind, the SharePoint server always reminded me of the infamous French prison, in that once you consigned a subject (or, in this case, an electronic record) inside it, you weren’tever going to get it out without violent action, and with a high probability of unavoidable collateral damage.
Yes, that’s a bit dramatic, but it explains the perspective. As an IT lead, we’re tasked with ensuring the confidentiality, integrity, and availability of our critical business data. That last element – availability – compels us to make sure that we maintain control over our records storage solutions, so that we can guarantee that our information will be available to our users when and where they need it. That’s why we get so paranoid about trusting our production data to solutions over which we have limited or no control. If we can’t get to our records for any reason, then we’ve failed at our primary responsibility.
That’s what I explained to Todd. I advised him that the best way to win over a curmudgeonly customer like me is to make it clear up-front that users will always be able to export their critical data in its entirety from his system. No exceptions. Make it an ironclad commitment to the user community that his company will never hold the users’ data hostage, will not corrupt it into an unusable format, and will not delay its release when demanded. Make those guarantees, I said, and you’ll overcome the vast majority of twitchy users’ objections to trying the ‘free’ version of the service. Todd grasped the idea immediately, and I trust he’ll put the advice to good use.
I really do think that the heart of the problem is how we, as customers, come to visualize abstract and concept technical services. When I received my first field reports in on the early SharePoint experiments, I immediately thought of a prison (instead of some other convenient metaphor).
We think of prisons as structures controlled by the state. When a person moves into a prison, they cannot leave unless the gaoler allows it. They might be roughed up by other inmates or by guards at any time. People rarely come out of a prison stay in the same state that they arrived in. When a person moves into a hotel, on the other hand, they can check out at their leisure. The hotel staff won’t lock them in their room, and is expected to go to great lengths to ensure that the guests aren’t bothered. In both cases, you’re talking about entrusting a person to a room for a length of time. Once version is repugnant and should be avoided at all costs; the other version is enticing and inviting.
The critical first step is overcoming customer dread is to realize that your customer’s vision of your product or services is fundamentally different from yours. That’s how a fellow like Todd will make his living as a professional storyteller. When his customers (quite naturally) form an initial mental model of his small business cloud service as a metaphorical prison, he’ll need to ‘spin’ the narrative to evolve the customer’s mental model to something far less disquieting. Changing that operating metaphor is often the first crucial battle in the long campaign to win the customer’s loyalty.
[1] This ‘Todd’ is actually a Todd; all of my anonymized characters are ‘Bob’, but this particular chap was kind enough to let me attribute our conversation to him. Thanks, Todd.
[2] The fellow made SharePoint sound like a software implementation of Insmouth. I hoped that he was… exaggerating.
[3] Yes, those questions were actually asked.
POC is Keil Hubert, keil.hubert@gmail.com
Follow him on twitter at @keilhubert.
You can buy his books on IT leadership and IT interviewing at the Amazon Kindle Store.
Keil Hubert is a retired U.S. Air Force ‘Cyberspace Operations’ officer, with over ten years of military command experience. He currently consults on business, security and technology issues in Texas. He’s built dot-com start-ups for KPMG Consulting, created an in-house consulting practice for Yahoo!, and helped to launch four small businesses (including his own).
Keil’s experience creating and leading IT teams in the defense, healthcare, media, government and non-profit sectors has afforded him an eclectic perspective on the integration of business needs, technical services and creative employee development… This serves him well as Business Technology’s resident U.S. blogger.
