[This is the first in a series of posts about businesses that weren’t for a variety of reasons. You can read about others in Projects and Ideas.]
In October 2016 I spent a few months with my friend and former board member/employee Jake Baillie looking into building a service that would offer a cloud computing estimation/calculator to help laggard/non-tech organizations migrate to the cloud.
Outside of tech-savvy organizations (ie, the vast majority of them), IT skills are uncommon, so what is the best way to help a business understand the financial and other considerations in moving to the cloud? We decided to focus on storage, which is arguably far more commoditized than compute and other hosted services. At a product level, we would build a storage calculator that would abstract features from AWS, Azure, Google Cloud and others, allow users to enter their requirements and return a reasonably accurate estimate of costs.
These leads would be fed to various cloud providers, and over time we could offer additional advertorial in the form of email marketing, PPC and sponsored white papers. Finally, if the business generated sufficient activity, we could be in a unique position to understand customer trends/demand before vendors did. This quasi-econometric data could be packaged and sold as a stand-alone product. This graphic illustrates the flows of data and revenue:
The key issues to focus on quickly became clear:
Cloud providers: start with AWS, Azure and Google Cloud but also include SoftLayer, Rackspace and VMware for reference. What we learn from industry heavyweights can give us insight to niche providers down the road. Very quickly it becomes evident how technical ‘normalizing’ and abstracting these services becomes. Providers use their own nomenclature as features (or attributes or products or services or whatever you want to call them) are nuanced (see below), so three providers is more than enough to help with a proof of concept.
Technical feature abstraction: the initial focus on storage defined our universe, but with ever increasing features, one requires seemingly arbitrary delineations. For example, do we include EBS volumes? If we focus only on storage, in a narrow sense we don’t care about EBS. But logically of course we do. And how is this abstracted across other providers? Very quickly this gets deep into DevOps and a bit of philosophy. Below is our first cut at working to abstract services. It’s a bit subjective and was exhausting/painful given that I was leaning on Jake for most DevOps knowledge [I wasn’t able to embed comments which provided reference to docs. If you want those happy to make the gsheet available].
Segment users: carving up a market by organizational size, industry and functional need is really messy. Size is a proxy for (broadly speaking) sophistication– a ten person law firm will likely use a consultant for IT needs versus a 200 person firm that employs its own staff. Some industries may be early adopters and others have regulatory or compliance requirements.
Thinking like the customer is critical, so functional needs seek to translate tech-laden language into a set of business needs. For example, it’s easy to guesstimate how much patient paperwork a small medical practice generates, but how does that translate to GBs of storage over time? And what business processes does the small medical practice perform? Can they be generalized for all clinical fields? How does practice size impact these processes? What about in-place processes like electronic health record services? Is the customer currently using an onsite solution, does latency matter, what about encryption, geographic redundancy, archival/infrequent access and so on and so on.
You can imagine the permutations when looking at 5+ attributes to define market segments. We could either boil the ocean or perform additional research by talking with a broad set of potential customers. I liked the idea of digging deeper into markets where regulatory burdens exist–it is much less noisy, allows for greater margin opportunities and provides a straw man of what to build.
Customers: who pays us for leads and how? Leadgen is a tried and true business, but would it work outside of consumer e-commerce? With B2B services, the time to purchase is likely not immediate and the referral/lead will certainly help influence the purchase decision, but by how much? It’s likely the customer spend will ramp up over time. Does this mean we’d expect a fee based on percentage of spend over time? Then we would have a significant lag between referral and payment. Don’t like that for a variety of reasons. What about a per lead fee? Maybe a good idea in the early days until we have a model with data.
Would customers be AWS/Google/Azure? It’s not like they are hurting for business and a self-provisioning model works pretty well. None of them currently offer this kind of affiliate program. The vast universe of VARs/integrators/PaaS/IaaS seemed a more compelling value proposition, but who? Using attributes to segment the market we could derive a manageable list and begin to pitch.
In sum, the market opportunity is sufficiently large and the business model has been tested. Much of my thinking in pursuing this venture was minimal use of capital–it’s basically CMS supported by a very well-designed schema/cost calculator. The idea is in no way a tech play; it’s straight-up leadgen and acquisition cost is key. Some of these play to Jake’s strengths in SEO and DevOps, but I don’t bring much apart from an idea and enthusiasm.
Turning to product, we’d have to iterate on dozens of customer profiles, each derived from the parameters below. This caused me a lot of pain because I know/care so little about the guts of DevOps. Or maybe we were unnecessarily making it more complex than need be. Then barriers to entry are lower, inviting more competition, and forcing us to spend more to keep up. This could mean raising outside money, which I don’t like for this business. So I sort of ended up full circle.
In sum, I still feel there’s a very real opportunity here to identify and market to non-tech businesses, helping them to cloud services. But Jake and I don’t have unfair skills to make this happen. And I fundamentally cannot get (that!) excited about spending all my waking hours for 4+ years obsessing on cloud vendor pricing. So, Idea One is out to pasture, and ready for cultivation with the right execution. I’d love to know your thoughts/experiences.
Post-employment 