With writer’s block out-of-the-way it’s time to finally finish this story. I apologize in advance for not polishing this more, but the stops and starts have caused problems. And I either push this out now or who knows when it will see the light of day.
Let’s start with our value proposition. When my partner first mentioned his consulting engagement he had a great story to tell. He’d interviewed the client’s CEO who said “I told them I wanted the systems backed up every day, but I have this feeling it isn’t happening”. When he asked the office people who were supposed to be running the (VAR-developed backup procedures) they said “The CEO thinks we are backing up the systems every day, but it isn’t happening”. This was also the height of fear and (justifiable) worry about security of desktop systems, and few customer PCs were being reliably patched, running and updating Anti-Virus/Spyware/Malware software, etc. And customers were paying VARs for Time and Materials to come in periodically and update software, remove malware, etc. This was an unpredictable and often large expense. So turning a very unpredictable IT expense, unconstrained security problem, and endless headaches into a predictable service seemed like a business opportunity . Give us $99 or $129 (or whatever, depending on package) per user per month and we take care of the rest. So we decided to go for it.
The customers we were targeting were small businesses, those who didn’t have IT staffs of their own. We initially targeted 5-25 users, though we took on some “Friends and Family” with fewer users (e.g., my wife’s Horse Boarding business) and were in discussions with potential customers in the 25-50 range. Small business is a notoriously hard nut to crack, which is why you don’t tend to see dominant players in the market. But that also makes it a place one can target without getting bulldozed by the Microsoft’s, SAP’s, Oracle’s, etc. of the world. Oh they target small businesses to various degrees, but their success rate is poor. For example Microsoft’s efforts in this 5-25 user category have pretty much all fallen flat. bCentral was abandoned. A few years later another attempt was made as “Office Live Small Business”. It too was discontinued. Two attempts at small business accounting software have come and gone. Now Microsoft is targeting this market with Office 365, and the jury is out on if they will finally succeed. However, niche offerings such as Quickbooks do well, and so we looked to incorporate those into our service.
We also discovered that small businesses could be quite complex. A principal often owned multiple businesses and didn’t want complete isolation (e.g., he might use a single email account with multiple addresses). While the general employee base had yet to discover smartphones (recall this was circa 2005) often the principal had (the Pam Treo line was particularly popular). Or try to imagine the shared calendaring problems of handling two fractional business aircraft where the owners, pilots, aircraft, etc. all had to be involved in scheduling. People think small business is much simpler than large enterprises, and they are, but often not by the magnitude most assume. A small medical clinic has to conform to HIPPA every bit as much as a huge hospital chain.
We did talk about an alternate service offering, remote management of desktops for example, but concluded that was something for the future. Or how another company might emerge to do this as a competitive approach to ours. We found some nascent attempts, but they didn’t really seem like threats. We also considered how Microsoft’s efforts to automate patching and address security and other cost of ownership issues might eventually eliminate much of the problem we were trying to address. Well, here we are eight years after our initial discussions and while Microsoft has addressed many of the problems (good automated patching, building anti-malware into the system, etc.) third-party software is still years behind. The situation, though significantly improved, hasn’t really changed. This is pretty much what we expected, and didn’t believe it harmed our overall value proposition though we clearly understood our message would have to mature just as the PC software ecosystem matured. In that regard we seem to have gotten it right as the Cloud, VDI, etc. finally seem to be living up to the promise that we’d anticipated.
As you read through the previous two blog postings you probably were thinking you saw things we could have avoided doing in the first release of the service offering, and as I’ve mentioned before on some level you are right. But now imagine an environment where, for example, we hadn’t implemented the virtual machine system (VDI) for running (semi-) arbitrary apps. No Quickbooks? There are one or two users per company (often including the principal) whose desktops can’t be locked down. No CRM solution? There goes all the sales people’s desktops. Etc. So how do we offer any value proposition around patching, backups, security, etc. when a significant portion of the desktops at the customer live outside our solution? We couldn’t. And so we solved for all the key general business software and even could have handled vertical industry software.
In fact we really only had one out-and-out failure scenario, the Graphic Designer at one of our customers. There was just no way to run Photoshop on a server and make it usable via Terminal Services. Recall that we are talking 2005 with Windows Server 2003 and technology for accelerating graphics (RemoteFX) wasn’t added to Terminal Services for another 7 years, with Windows 2008 R2 SP1 in 2011! That user was allowed to have a non-locked down PC, though they still did non-Photoshop work through Terminal Services.
So with that out-of-the-way it’s good to describe one of our big mistakes, how the initial system was developed. As I’ve mentioned previously we started with a plan that required just a website and ended up building a full automated ordering, billing, provisioning, etc. system. When we started we contracted out the web work to a developer who had experience in tech support and had done web development work. Unfortunately as our needs changed we stuck with the same developer. That was mistake 1(a). Then when we realized as we moved on to some more advanced work that it was stretching his abilities we considered replacing him, but instead helped him a bit and things seemed to improve considerably. Not replacing him when we realized he was struggling was mistake 1(b). Then when we realized he was struggling again we were going to replace him, but we were so close to the finish line and had no prospects to replace him that we decided to tough it out. We knew we were going to rewrite the stuff for Phase 2 anyway, so we just needed to get to launch of the service asap. That was mistake 1(c). Finally we concluded it just wasn’t ever going to be done, so we let the contractor go and I dropped all my other duties and became the full-time developer. It took me about a month to clean up and rewrite a lot of the modules so we could launch the service. And every time I looked at another module I asked myself how I could have let this happen. I should have just written the system myself. Of course then we would have had a similar problem on the operations side.
Our failure to fire the contract developer early and find an alternate way to build the system, either by doing it ourselves or finding a more appropriate contractor, is the thing that my partner and I beat ourselves up about the most. Would it have changed the outcome? Probably not. But we would have either failed faster (and thus spent less money to do so), or ended up with an asset we could have gotten a little of our investment back by selling, or changes path, or…. For example our automated provisioning was something a lot of people were looking for, but the code we had from the contractor was not something we could have gotten $0.02 for. I’m guessing (and I’m fairly confident) that if I’d written the code then we could have sold it for at least what we invested in the company.
Now to the two real business issues. Let’s start with the cost structure.
When you looked at our cost structure you could basically break it down into four major buckets:
- Microsoft Licensing (particularly the Service Providers License Agreement or SPLA) model and costs
- Data Center Cost of Operations
- Support
- Everything else
First we’ll dig into the Microsoft SPLA. I haven’t looked into how it works today, but it remains a real issue for people trying to create services. The SPLA is Microsoft’s model for how a service provider licenses its software for renting out as part of a service. It’s complex, but essentially you are paying a fee per month per (named) user for each piece of software (and sometimes functionality within software). The problem for us was really around what Microsoft made available under the SPLA, how they priced it, and the lack of any way to transfer existing licenses into the SPLA world.
Pricing first. Because this is a rental model it makes no sense to tie it to a specific software version. That is, you rent Microsoft Office not Microsoft Office 20xx. In Microsoft’s packaged product world this is done via something called Software Assurance (SA). With SA you pay a certain amount per year and get any new versions that come out during the terms of your contract. For this Microsoft charges a premium compared to just purchasing a specific version of the product. Well, SPLA pricing is based on SA pricing. There is only one problem with this, small businesses don’t (or at least didn’t at the time) buy Software Assurance. Not only that, but small businesses would typically not upgrade for much longer than Microsoft assumes in its pricing further raising the effective cost. That is, SPLA pricing was based on the life of a product being some number of months (say 30, though I don’t recall the actual number) but a typical small business might go twice that before buying a new version of Office. So a business comparing the cost of going into Staples and walking out with Microsoft Office Professional to the cost of renting it from us would discover that they paid tremendously more to rent it from us. And that was before adding in our cost of operations, support, G&A, etc.
But it gets worse. Microsoft doesn’t license everything under the SPLA. Using Office once again as our example, they only licensed Office Standard and Office Professional. One could not license individual Office applications like Word, nor could you offer Office Small Business under SPLA. So now our customers were comparing the much lower priced Office Small Business Edition price at Staples et al to being forced into Office Professional from us.
Third was that Microsoft offered no way to credit a user for already having a packaged product license. So let’s say a company had a bunch of PCs running Office 2003 and they were now investigating using our service. They were going to pay to re-license Office 2003 even though they already owned it. That they would automatically get Office 2007 when it came out for no additional cost was nice, but they just couldn’t get past the idea that they were paying twice for Office 2003.
So from the start Microsoft’s licensing policies handicapped us tremendously. While we knew pretty early on that the SPLA presented us with challenges we didn’t know how serious this would be until we started actively marketing our service. Early research indicated that we needed a $99 per user entry point, and we figured out we could offer this even with SPLA’s issues. Later we would discover how deeply some people would dig into our pricing, and discover how much they were effectively paying Microsoft. And as I looked into how we might build a second generation system I made an interesting discovery. I’d done a design for a much lower cost data center and was trying to see how it impacted our ability to offer a much lower price of entry. Plugging in various lower costs of operations into our business model produced far less improvement than I expected. Finally, out of frustration, I just zeroed out our operations costs and to my surprise we still weren’t profitable much below $99/user. Further analysis showed that because the SPLA model had no scalability built into it we eventually became nothing but a means of transferring money to Microsoft. There was no opportunity to charge for our added value!
From the start we’d considered moving away from a pure Microsoft software offering in order to lower our cost structure. For example, we could offer Open Office instead of Microsoft Office as part of an entry-level service offering. The problem was that customers weren’t aware of Open Office and we didn’t feel like our business model offered a way to sell them on the idea. This theme, that we were taking on a huge customer education problem in everything we did, is important. It would become key to our decision to shutter the business.
What fascinated us about SPLA pricing becoming such a dominant factor in our cost structure and deliberations is that we’d always expected the cost of operations to be our pain point. After all, we were creating a service. And indeed our initial design and use of a Managed Hosting company was a cost problem. And it was going to get worse. First of all our initial offering benefited from “Friends and Family” pricing, But future systems would not. We’d anticipated that, but hadn’t anticipated that they were changing their business model in a way that would impact our assumptions. In particular, they pretty much eliminated their hardware rental model in favor of a lease model (essentially transferring the financing of hardware from their balance sheet to their client’s balance sheets). Finally, they just weren’t geared towards being what we would today call a Cloud Data Center.
As I mentioned in one of the earlier posts we found that we were duplicating a lot of the services that in theory we were getting from the Managed Services Provider. Patch Management? I was doing it. Anti-Spyware? I was doing it. Anti-SPAM? My partner was doing it. etc. We realized that they were expensive and we weren’t getting much for our money. So we looked at moving to another hosting situation. We found much cheaper alternatives for raw hosting. I designed a storage and backup system that quite literally would cost us 1/10th what we were paying the managed hoster. We’d always had a problem with the managed hoster’s Internet connectivity (a historical artifact that I won’t go into), and the new hoster solved that by offering connectivity through multiple network providers. Basically, we were excited about the opportunities for creating our second generation hosting environment. Unlike the SPLA situation, this is something that was really within our control.
In our initial business modeling we were shocked to discover how dominant support costs would be. The problem was that given how new the environment was to the customer they would need lots of handholding. This would be particularly true in the first few months after a customer moved to our system. Then we expected that someone inside their organization would have enough expertise to help new users, and our support costs would drop. Still we modeled high costs because we couldn’t be certain of when (or even if) and by how much they would actually drop off. We invested in the trouble ticket system and wrote knowledge base articles early on so we could point users at those. We tried to refine the line between what constituted included support and what would be paid time and materials assistance. We looked at innovative ways to farm out support (e.g., people who would help do migrations). But through to the end support remained our big unknown. It was the one thing that the more we succeeded the closer we might be driven to failure, each new customer demanding attention from us that potentially we couldn’t deliver on. We could add machines to handle the load fairly quickly. We’d automated things tremendously. But we couldn’t add trained support people quickly or economically. Particularly if we succeeded wildly.
The rest of our costs were the usual and we kept them low. I mentioned at one point that our business model was to avoid taking on fixed costs, employees, etc. My partner’s brother was our accountant and his firm gave us friends and family rates. We shared an office. We answered our own phones (and hosted our own Asterisk-based PBX, which we also offered to customers as a service). We incorporated rational customer acquisition costs into our plan, including compensation for third parties such as VARs who brought us customers. There is nothing here that really stands out other than to say that we were very complete in modeling and understanding our overall cost structure yet quite frugal about spending that wouldn’t move the business along.
Even as we discovered potentially fatal roadblocks, like the SPLA situation, we pressed on. We knew we were pioneering Software-as-a-Service and that the world would change as we did so. I made the rounds at Microsoft, including with senior executives such as Bob Muglia, explaining what we were trying to do and where Microsoft was killing us. In some cases (basically technical issues) they offered assistance, but I didn’t walk away with anything on the business front. I didn’t expect to. What I expected was to get Microsoft thinking about these issues so that once we were successful I could come back and really press them to make changes. The Microsoft people were really interested, from the Terminal Services development team to the SPLA licensing guys to executives such as Bob. Now granted I had contacts, for example a long history with Bob, that made this easier. But the SPLA guys, for example, didn’t really know about that history. They were just interested in talking to one of their customers.
Sadly I had less luck with other software companies. Intuit, for example, was totally uninterested in discussing the licensing roadblocks they’d put in front of companies trying to host their products. At first I thought it was me, but then a competitor called to ask me if and how we were going to host multi-user Quickbooks. I discovered from her that no one had figured this out, and that Intuit hadn’t been interested in talking to anyone about it. I’ve said it before and I’ll say it again, Microsoft was way ahead of other software companies in trying to address the hosting market. But we knew others would eventually have to come around.
With our system ready to go and a path forward understood, or at least the roadblocks well understood, we launched our service. For the first few months we knew this would be largely experimental in nature because we didn’t know exactly what would work. And we’d previously shelved our attempts to hire a VP of Marketing and Sales, which I’ll get to shortly.
Initially I concentrated on search-engine optimization and search advertising while my partner concentrated on following up on inquiries, converting trials into paid customers, working with VARs or other potential partners, and a test direct mail campaign. We learned a lot, much of which I’ve already mentioned (e.g., potential customer’s really latching on to the fact they’d already paid for Microsoft Office and not wanting to pay a second time). We also learned that startups weren’t a good target for offering because they had a different focus on costs. The CEO of one startup told us quite simply that they were willing to take the risk of losing data or having machines infected with viruses rather than burn through their cash to protect against those possibilities.
And we learned that search advertising wasn’t all it was cracked up to be. At the time people talked in terms of “pennies per click”, but that was already no longer true. One issue we had was that keywords that might be uniquely associated with a business such as ours had absolutely no search traffic. Literally it was so bad that Google would shut down our campaign for lack of results. So we had to look at keywords that lots of others were competing for, like Anti-Virus or Backup. The only directly applicable keywords with reasonable activity were things like Hosted Exchange. These kinds of key words were going for several dollars, to even $15-20, per click! Ads that did a good job describing what we offered got light clicks while ads that offered a more general description of us solving a problem got heavy clicks. But those heavy clicks were at the expense of being poorly qualified. Paying $20 just to have the person hit “Back” in the browser when they read the first few lines of our website was quite discouraging. We got better at this as time went along, and also focused more on SEO instead of paid advertising, but it was also another lesson in the maturity of the market.
Customers weren’t looking for the solution we were offering. That was a lesson we got from studying which keywords were being searched on. It was also a lesson we learned from our direct mail campaign. Indeed the strongest interest we got was from IT professionals, such as VARs, who were looking for ways to offload the headaches their customers were causing. We’d always expected this community to become a channel for our product, so we started to focus more attention on it.
As we approached the need for another capital infusion we reflected on everything we’d learned. We came to one key conclusion, that given customers weren’t looking for a solution like ours we were going to have to educate them. And that was going to be a multi-million dollar effort, not something we could self-fund. As we thought about how much money we’d need to raise, and what it would mean for our ownership and control of the company, we realized it made continuing on unattractive. My partner was willing to put in one more chunk of money to see if we could reach a more attractive position before accepting outside investment. I was semi-willing, though I was being asked to return to Microsoft and was really tempted by the opportunity. We decided to pull the plug rather than throw good money after bad.
As I look back there is a lot we did right and a lot we should have done differently. Conceptually we got to a great place, even though the code was pretty much throw-away. Had we started with the volume market as our target initially we would have made a number of different decisions. We probably wouldn’t have taken on the consulting customers and their distraction. We wouldn’t have put development of a complex system into the hands of a web developer (and I would have really led the development effort). We would have accepted outside investment (which we were offered, but turned away), both to have a proper development and operations team and dedicated marketing/sales personnel with substantial funding for a marketing campaign.
Or we could have stuck to the original vision for a modest cash-generating business and probably done quite well.
The truth is we had one of the greatest experiences of our work lives. It was fun. We learned a huge amount. We tried some very unconventional things. We got in early (too early sadly) on what is now one of the hottest areas in computing.
I’d do it again. Hopefully with a better ending.
Hal's (Im)Perfect Vision 