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.
Just a quick reminder, our open house on thought leadership in the technology industry is tonight (Thursday) at 5 PM in the Foster City, CA office. Recommended for any product marketer or product manager who's interested in this topic.
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.
As I said in my last blog post, we're looking for feedback on the questions we're asking about thought leadership in the technology industry. At the same time, we realized that it has been a while since we held an open house in Forrester's Foster City office. (If you're not aware, we did a few informal sessions for product managers and product marketers, to give people in that role an opportunity to talk amongst themselves about topics of interest, sprinkled with whatever useful information an analyst like myself can provide.) Suddenly, a spark leaped across the two neurons carrying these separate ideas.
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.
Two recent articles from The New York Times illustrate why, for innovation to work, you need to keep updating your playbook.
Serious Games And Biochemical Research
When a team of researchers at the University of Washington wanted to unlock the puzzle of protein folding – a complex process that moves faster than we can observe – they decided to crowdsource the investigation. The team posed the question as a serious game, a medium that sometimes produces better answers than what people normally envision as the process of crowdsourcing.
Instead of just throwing out the question (How do our bodies build these proteins?) to an anonymous audience that may or may not have been motivated to answer it, the researchers built a game, Foldit, that simulated the protein-building process. The motivations were no different than any game: the satisfaction of beating the game at some level; the score that both rewards you for your current level of accomplishment and dares you to do better; the public standings that inject another level of competition beyond beating your last score. Humans can be very competitive creatures, even when the only rewards are intangible, which is why certain types of serious games often stimulate more participation than other approaches to a problem. (Check out the book Drive by Daniel Pink for one explanation of this behavior.)
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.
All next week, colleague Dave West and I will be at Agile 2010. On Monday, I'm doing a workshop on the effect of Agile in technology companies, in the rest of the organization beyond the development team. IT professionals might see a lot of similar effects in their organizations, too. The workshop is chock full of exercises, including at least one serious game. So, expect some Agile fun in the Orlando sun.
At the end of the week, Dave is doing a presentation on the new trend toward product-centricity in IT organizations. How do you combine two disciplines, Agile and productization, to achieve even better outcomes? Dave's a great speaker, so if you're going to be at Agile 2010, you'll kick yourself if you miss his session.
As Forrester analysts, we're always available to our clients for inquiries. If you're in Orlando with us, we'd be glad to try to set up an inquiry face-to-face instead of the typical phone call. Drop me a line at email@example.com if you're interested in meeting while we're at Agile 2010. See you there.
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.)