The open cloud manifesto is published on the web (www.opencloudmanifesto.org) since late Sunday and is announced by various press releases from the contributing vendors today. Strongly supported by IBM, a major group of thirty six companies signed already this document. Although Amazon, Google, Microsoft, and Salesforce.com are missing, the manifesto might mean a milestone in market adoption and vendor strategy of cloud computing along these three major strategy tasks.
Task 1: Spreading Excitement and Gaining Trust - Done
Everybody was excited about the new technical possibilities. The vendor’s communication was about gaining trust and convincing potential customers of a real value for serious business.
The biggest news in the tech industry the past week has been the rumored IBM acquisition of Sun Microsystems. Like everyone else who follows the tech industry I have spent more than a few hours trying to get my head around all the competitive implications. Needless to say the rumor has made for some interesting hallway conversations, not to mention some lively debates among analysts in the office.
First, let me belatedly acknowledge Luke Hohmann, who ranted eloquently about traditional requirements at his P-Camp session several days before I started this current screed. His observation was Hemingwayesque in its pithiness: "Requirements suck." Mine is more Faulkneresque, using an idiom ("stink on ice"), undoubtedly with a colorful origin that no one remembers.
The second reason why traditional requirements stink on ice is, ultimately, a question of perspective:
Development teams build technology for people who are wholly unlike themselves.
No team has the resources to live side-by-side with the people for whom they're building the technology. The users don't have the time or inclination, too.
Most development teams rarely interact with people on a different floor in the same building, so living side-by-side with the target users wouldn't be an automatic mechanism for osmotic transmission of insight.
Therefore, development teams generally view requirements in their own terms, and not the world as the end user sees it.
I've had to put blogging on the back burner for the last week because one research document, covering how product managers can use social media (blogs, Wikis, forums, etc.) as a new source of product requirements, underwent mutation, and then mitosis. Now, it's three separate documents, each of which demands all the empirical and stylistic discipline that Forrester demands. In short, I've been busy.
However, now that two of the three documents are drafted and in the capable hands of my research director, I need to vent. The target of my ire isn't the tribble-like spawning of new documents, which at the end of the day, is the right call, and has made the author much happier with the final product.
No, what's really churning in my guts is the inevitable outcome of talking to people about product requirements, writing about how to improve them, and re-visiting the topic during the editing process.
This Saturday's convocation of product managers, P-Camp 2009, was an outstanding event. Great presentation and great conversation. Many thanks to Rich, Luke, and everyone else at Enthiosys for organizing P-Camp, and to all the sponsors for making it happen.
Here are a few take-aways from the presentations I attended:
In response to the last couple of posts about invention and innovation, Jennifer says:
While this is an interesting thread to read, and can definitely cause many long hours of debate sitting in front of the fire with our pipes et al, it seems that it might be missing the mark with product management.
Yep, I agree. Which leads me to the next point I wanted to make in this series:
Inventors in development need innovators in product management.
While the two groups often don't get along very well (product managers are naysayers, development is just doing its own thing, etc.), the partnership between them is essential. Someone with a cool idea and enormous technical skill is usually the first person in a new product group, or a new startup company. However, that inventor can benefit immediately from someone who's a professional reality checker and opportunity finder--a product manager.
Last Wednesday, the part of Forrester that runs the Leadership Boards sponsored a dinner in the Boston area for product managers and product marketers. (This was part of the regular activity for the new Technology Product Management Council.) And wow, was that a good conversation.
The good news is, the research agenda is on the right track. From social media to product requirements, from the PM job description to general best practices for PM, from Agile in the tech industry to how people become thought leaders, we seem to be picking the right topics.
The bad news is, I have a lot of research to do. But that's only bad news as long as I'm not doing it.
However, that wasn't the best part of the dinner, which was when we Forresterites shut our big yaps. The product managers and product marketers had a lot to talk about themselves, comparing experiences in profession that doesn't give many opportunities to talk across organizations. Fostering and participating these missing conversations was one of the reasons I wanted to join Forrester in the first place.
Except that despite being poor and having many of his inventions unrealized, a hundred years later we're still using Tesla's work rather heavily. This says something about his pure success as an inventor, with or without massive market capitalization.
...And I agree. Yes, our electrical distribution mechanisms use Tesla's AC, not Edison's DC. Yes, Tesla's coils became a component of other inventions, such as radio transmitters and medical devices. And yes, arguably, Tesla is a vastly underappreciated inventor.
It's not clear when it happened, but at some point in the history of the technology industry, people lost the distinction between invention and innovation. While insisting on the difference between the two words may seem like a minor semantic difference, it's as fundamental as distinguishing between speed and velocity as the same thing. In fact, mixing up invention and innovation is potentially as dangerous as confusing chemicals and medicines, if you prescribe one when you really need the other.
Tesla, Shmesla Both Nikola Tesla and Thomas Edison were inventors. However, Edison was the better innovator. Fannish biographies of Tesla that complain about history's indifference to Tesla's genius are missing the point. Even if everything Tesla had invented exceeded Edison's in brilliance, Edison was much better at getting his inventions developed, sold, and distributed. (Throw in Tesla's unproven inventions, like the death ray and ion-powered aircraft, too, if you want.)