When it comes to home improvement, I'm barely competent. My biggest hurdle is ignorance: when I was growing up, no one in our family was a do-it-yourselfer. Unless I had the opportunity to watch the handyman, electrician, or plumber fixing a problem, and that person was patient enough to let me observe, I had zero experience with these tasks.
Fast forward to a couple of years ago, when I signed up for installing hardwood floors in our home. Friends had said that it wasn't as hard as it looked, and the staggering quotes from contractors provided the incentive for forging ahead, despite my ignorance.
After buying the tools and digesting the instructions, I started on the first room. My first attempt was a hilarious escapade, which resembled a horizontal variant of Jenga more than anything that you could describe as "home improvement." After taking a break for a few days, I figured out where the project had gone wrong, made adjustments, and finished the room.
You might be surprised to find out how worked up I can get about an issue like switching costs (a.k.a. lock-in). It's a question worthy of at least a little emotion, since it affects the fortunes of technology companies: Under what conditions would a customer switch to a different vendor for the same product or service?
The question has returned with a vengeance with the increased adoption of SaaS and PaaS technologies. Tech vendors are happy to use the cloud as an easy way to attract customers, as long as it doesn't turn into an equally easy way to lose customers.
What gets my dander up is the simplistic, puerile way in which people sometimes discuss this issue, particularly in regard to SaaS implementations. Here are a couple of examples.
Cost Of Switching
How do the switching costs of an on-demand solution compare to an on-premise alternative? Clearly, the cost of switching from an on-demand solution is not zero, and yet you still find in some discussions of SaaS the assumption that customers will leave willy-nilly. Nor is the cost of switching the same as an on-premise solution, but you'll find people speaking about the two as if they presented the same migration and implementation challenges.
We're now in Phase II of our first venture into Agile Research Development, an investigation of thought leadership in the technology industry. Phase II is when we start the actual primary research, and again, we're looking to the community for their help and guidance. The story so far:
Published the development document, which explains how we'll proceed. Supporting documents, such as this overview of Agile Research Development, are also part of the project dossier.
Incorporated feedback from the community into the development document. Many thanks to everyone who provided suggestions and criticisms of the original research plan, as described in the development document. In fact, if you haven't read the comments on the development document, I strongly recommend that you do. There are some real nuggets in there about a thought leadership, a topic of vital importance to tech vendors, their partners, and their customers.
How You Can Help
First, we need another round of review. This time, we're looking for your feedback on the interview guide. Are these the questions you want answered? Have we missed anything? I've annotated the interview guide to explain some of the reasoning behind the current draft, which is my way of getting the discussion going.
Google's decision to pull the plug on Wave was hardly surprising. Not only did Wave stumble out of the gate and then never quite get its footing, it violated a core principle of software as a service (SaaS): It's the application, stupid.
If you're going to be in the SaaS business, you need to deliver an application that's attractive, comprehensible, and usable immediately. Not after a horde of developers built a library of interesting widgets. Not after a quasi-beta program in which the product is really in production, but you just choose to call it beta. Not after potential users scratch their heads for days, wondering what the heck this Wave thing is supposed to do, and then sell their equally perplexed colleagues on its purported value. Deliver value now is the cardinal rule of SaaS.
On-Premise Strategy For An On-Demand Application
Wave's product strategy resembled a traditional on-premise strategy, in which you built the platform first, and then added an application to it. In the cloud, the product strategy moves in exactly the opposite direction: application first, then platform. A classic example is the Salesforce portfolio, which started with a highly capable CRM application that was easy to implement. Later came the platform, Force.com, on which customers and partners could build customizations and adjacent applications.
Today was our first official update to the research plan (a.k.a. the development document) for our project investigating thought leadership in the technology industry. A quick refresher: this particular piece of research is our first venture into Agile research development, which (1) applies Agile principles to our research, and (2) opens the project to the community to participate in the research process from start to finish. In other words, we're using the newly-launched Forrester Community as the forum where the voice of the customer will speak directly to us about our research as we're doing it.
You can see the current development document, including the updated text and the comments that inspired those changes, here. As promised, we're also maintaining a change log for tracking these changes over time. (The development document is also versioned, so we can look back on the history of edits through that mechanism, too.)