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.
• Drafted the interview guide. We now have a list of questions that we'll ask the interviewees, including both vendors and 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.

A few quick observations on what we've seen at Agile 2010 this week: