Posted by Tom Grant on July 30, 2009
Which business problems will Google Wave address?
A few weeks ago, I watched the Google Wave launch video with a mix of interest and nervousness. A big part of my reaction was shaped (warped?) by my experience doing product management and product marketing for collaboration and content management products. While I didn't launch myself at the screen yelling "Noooooooo!" (in slow motion), I did worry that Google might walk straight into an all-too-familiar minefield of competing solution areas.
Collaboration and content management pose a classic problem in requirements and design: Which solution do you want to target? If you build a product without prioritizing among all the different business problems that it might address, you'll build a very "horizontal" product that satisfies no one. Or, worse, it makes perfect sense to you, but everyone else struggles to see how it will best work for them.
Customization in Google Wave
The very horizontal application demo application in the launch video bore an unsettling resemblance to other UIs for collaboration and content management (CM) that I've seen over the years. Unlike the UI for a word processor (like the one for Google Apps), the face of collaboration and CM tools twist and flex to the shape that organizations strongly want them to take. Remove this, add that, change how this works, make this piece run by itself in a portal, etc.
Which leaves the product team with a dilemma: Do you build something that works really well for a particular solution area (say, the loosey-goosey world of ad hoc collaboration), but not for others (for example, the highly structured processes needed for single-source, multi-channeled publishing)? Or do you build something that's highly configurable and customizable, and let the customers and partners do the morphing?
While I'd pick the second option, it has its risks. Prominent among them is forgetting to prioritize this kind of plasticity early in the product's lifecycle. With every month of coding, the product gets more resistant to your later efforts to build in customizability.
Having seen how much customization is built into Google Wave, I'm both relieved and impressed. Google already has a very big community of early adopters using the APIs and protocol to build plug-ins to accommodate a variety of use cases. From these humble beginnings, developers will build more sophisticated customizations. Will these rise to the level of capability need to address business problems like corporate risk management? We'll have to wait and see.
Google's other dilemmas
Customization isn't the only dilemma that the Google Wave team will face. For perfectly good business reasons, someone will ask, "Can I keep my content stored in my own repositories, and just use Google Wave as a collaboration and management layer above that storage?" The huge architectural questions that poses will force Google to say, "Yes, that's the business we want to be in," or, "No, that's not our core business."
Note that the choice is more about business than technology. Google is full of smart technologists, but its resources aren't infinite. Depending on the solution area, Google would have to acquire a different mix of domain expertise, marketing resources, partnerships, and sales muscle. I'd bet that the mix needed for most solution areas would not look very attractive to Google. Making a smart technology choice, up front, ensures that Google has the flexibility to choose among these options.
[Many thanks to Lars and Jen Rasmussen for yesterday's Q&A on Google Wave. If you're interested in being an early adopter, sorry, they told us that they already have the first 100,000 registrations. However, it's still worth signing up, if for no other reason than to tell Google how many people are interested in Wave, and how they'd like to use it.]
[Cross-posted at The Heretech.]