Are Struggling Companies More Likely To Adopt Social Media?

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.

At the same time I was finalizing the material for the B2B Social Media workshop my colleague Laura Ramos and I conducted yesterday in Foster City, and will conduct next month in Orlando. In doing so, I couldn’t help but notice I have a lot of Sun examples of social media done right. IBM holds it’s own, but in the tech industry specifically Sun and Dell are the poster children of social media marketing, and both have been struggling mightily.

A couple of years ago I was on a panel with Toby Redshaw of Motorola, who in the course of discussion confidently declared that the only way to get a Web 2.0 initiative off the ground was to fire the CEO. Since then I have seen just that over and over again: the firms looking to implement Web 2.0 tools for social media marketing -- as well as employee collaboration and productivity -- are those with a “motivated” CEO, typically one who is fresh on the job. The CEO fresh on the job does not typically find himself at the most successful company.

Which brings us back to Sun and IBM. Let’s take a quick look at their homepages as they stood in August of 2008 (the orange boxes are mine). Notice anything? One has community and social media all over the place while the other offers just a hint. So which one is acquiring which? And is this more than just coincidence?

[Cross-posed from Strategic heading.]

 

Traditional requirements stink on ice, continued

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.

By necessity and habit, development teams think and speak in terms like features, projects, and releases. Occasionally, users may use this language to make themselves understood to you, but it's not the terms that define their world. They want to do their jobs more quickly and successfully, and  then go home and think about something other than inserting a table of figures into a Word document.

Traditional requirements both reflect and reinforce this language barrier. Obviously, at the end of the day, you do need to go back to your cubicle and work on features. However, at some point in the process of designing, building, and releasing technology for people unlike you, you need to speak and understand their language, not yours.

To illustrate, here's an archetypical exchange between an ISV and a customer:

Customer: "We've been asking for this feature for a while. When will we get it?"

Vendor: "Very soon now. Meanwhile, what do you think of this feature? We think it's a great idea."

Customer: "Sure, it looks interesting."

Vendor: "Cool, because we're hoping to get it into the next release. We thought you might like it."

While there are many, many things going wrong in this conversation, for our purposes, the chief problem is linguistic. Both parties are guilty of speaking the vendor's preferred language, without making it clear how it translates into the customer's. Asking where the ion flux regulator appears in the product roadmap doesn't clarify why it's important to have one in the first place. Nor does it help understand whether the etheric vortex stabilizer helps solve the same problem for the customer, or anything at all.

Here's when some Agile aficianados are jumping out of their chairs to say, "Oooh! Oooh! Let me tell you about personas and user stories!" I largely agree that these Agile-approved requirements media can go a long way towards understanding the customer. However, they're not complete solutions for two reasons:

• The medium often constrains the understanding. For people whose Agile approach involves a lot of Stickie notes or index cards, it should not be a shock to hear that minute tiles of information, as useful as they are, do not always automagically transform into a beautiful, accurate, or complete portrait of the target user. At least in practice, that is.

• The sources of information still deserve some skepticism. You might drop the jumbo Word and Excel documents for personas and user stories, but you still may be extracting information from an unrepresentative sampling of users.

Social media are not a panacea for this language problem, or any other congenital defect that afflicts traditional requirements. Nonetheless, there are ways to use social media to help crack the language barrier.

Mandatory caveat: As in other situations, it's possible to use social media badly here. For example, giving users the ability to vote on feature ideas is a wonderful thing. However, keep in mind that this new channel of communication you are allowing them to speak your language more clearly, without necessarily improving your ability to speak theirs. In fact, some vendors' parochial use of social media resembles what many Americans do when confronted with someone who doesn't speak English: "Maybe you people will understand us IF WE JUST SPEAK MORE LOUDLY."

[Cross-posted at The Heretech.]

Traditional requirements stink on ice

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. Let's be honest: usually, they stink on ice.

I like that idiom because it evokes a truly epic scale of odiousness.If, in the depth of winter, when everything liquid or semi-solid freezes, and the great slab of ice on which you're standing leeches all the warmth and life out of you, slowly killing each of your senses in turn you're smelling something foul, it must be really foul.

No single post can hope to capture the complete odiousness of traditional requirements. I'll space this philippic across at least a couple of post, but let's start with the most obvious problem, and  the destruction that it wreaks on sensible product decisions, not to mention the working relationship between product management and development.

Wandering in the informational desert
What are the most frequently used sources of requirements in the technology industry? According to our surveys, the results are anything but surprising to us veterans: (1) customer meetings, either face-to-face or over the phone; (2) bug database entries; (3) enhancement requests transmitted through e-mail, often via mailing lists. Customer meetings are also the most trusted source of insight, because they provide far more information than a vague "I have a customer" e-mail from someone in Sales, or a bug report that conveys more frustration than information.

Of course, as "useful" as customer meetings are, they're hardly frequent enough to create a statistically significant sample. People should be skeptical, when the N is small, of how representative the customers are of the larger market, and how reliable the conclusions based on this information can be. Scheduling a few more conference calls, or getting leave to visit another customer on-site, will not provide enough empirical fuel to launch to slip the surly bonds of skepticism.

All of which leads to statements we've all heard before:

"He strongly

• holds the opinion of the last customer to whom he spoke."

• "This customer is full of spurious requests. How much can we trust their judgment?"

• "I've spoken to as many customers as you have. What makes you a greater expert on customers than me?"

• "We don't have time to keep going back to these people to see what they really want."

And so on, truly ad nauseum.

Therefore, one of the virtues of social media as a new source of insight into product decisions is the sample size. Would you rather base the next 12 months of development on an hour's conversation with five key customers, or information collected from hundreds of customers posting on discussion forums and blogs?

Certainly, there are lots of potential ways to misuse social media in this fashion. Aggregate information may be miles wide, but inches deep. Collected sloppily, the sample may be just as skewed as the handful of customers with whom you normally deal.

Still, it's hardly a courageous leap to say that social media provide some useful information that can bear on product decisions. At the very least, these other sources of information can supplement the traditional stuff.

When we return, be prepared to hold your nose as we wade through the other problems with traditional requirements. 

[Cross-posted at The Heretech.]

Outstanding P-Camp this weekend

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:

• Agile is having a huge impact on product managers, not to mention the rest of the organization, outside development. I'd venture to say that the effects on how product managers and product marketers work--not the products and services on which they work--is bigger than anything I can remember, including the Internet.

Social media (blogs, Wikis, etc.) are also shaping how PMs work, though the exact contours of these changes are pretty indistinct at this point. Some companies, such as Chordiant, are willing to take big gambles on the power of social media, doing things like exposing their roadmaps to an unprecedented degree, in the name of building stronger relationships with their customers.

• Everyone's all a-twitter about Twitter, the channel of social media that got more attention than anything else. However, Twitter received this disproportionate attention because of its novelty, and all the questions about its proper use that it raises. We'd be wrong to conclude that it's overshadowing other social media in its actual use for product management and product marketing.
• PMs need to talk to one another. That's nothing new, but the scope and quality of conversations at P-Camp showed the real need for PM professionals to compare notes. When a relatively novice product manager asked me for advice about career development, part of my answer was, "Read the blogs, and ask questions in the comments sections. For the time being, it's the easiest way to learn from your peers."
• There's a lot of room for innovation in this profession. Since the PM profession is still evolving, individual PMs have a lot of opportunity to find creative solutions. For example, serious gaming presents an alternative to traditional requirements collection. (For an example of serious gaming in action, see Enthiosys' "Buy A Feature" site.)

Finally, thanks to everyone who attended my talk on Agile's effect on tech company structure and operations. I'll be sending them to the conference organizers for posting. There was a lot of ground to cover in a short presentation, so if I sounded a bit like Frasier Crane  on speed, my apologies.

[Cross-posted at The Heretech.]

Invention, innovation, and product management

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.

I'll have more to say later about the sources of ideas for both invention and innovation. For this morning, since I have to run in a minute, it's enough to point out that the frequent frictions between development and product management are not only unnecessary, but pernicious. Tech companies need to bring new products and services to market as quickly as possible, which is really another way of saying, "We need really good inventors and innovators."

That may seem like a small semantic difference, but it's really a critical conceptual clarification. Too often in this industry, excellent inventors style themselves to be innovators, which they're not. Happily, they work with product managers (and product marketers, and consultants, and arguably a lot of other people involved in the diffusion of inventions), who are more than glad to help. If the two groups aren't working well together, the core problem is often the organization's ignorance of the invention/innovation distinction.

Methinks spring has sprung

Here's the view from my desk at the Forrester office in Foster City.

Can we talk?

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.

"Why, with this invention..."

Apparently, if my goal in last week's post about invention and innovation was to spark discussion, bringing up the Edison/Tesla rivalry was the right thing to do. For example, here's a excerpt from Richard Lessman's comment:

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.

However, none of that necessarily helps technology companies, which frequently confuse invention and innovation, understand how to be more successful businesses. Six years passed between Tesla's invention of his eponymous coil and the first demonstration that it could be part of an economically viable technology for "wireless telegraphy." More years passed before radio transmitters and receivers enjoyed widespread adoption.

Needless to say, that's not the time-to-market that modern technology companies hope to achieve. Rather than focus on innovation--spreading the practical application and adoption of an invention--some technology vendors conclude that they need to keep tinkering with the invention.

The unstated assumptions sound a lot like Victorian notions of science and technology, at least in the popular culture of the age:

• New technology grants immediate power. Think Captain Nemo and the Nautilus, which destroyed warships with impunity. Verne gave almost no details on how Nemo got the material and labor to create the Nautilus in the first place.
• New technology finds widespread application, somehow. Never mind the details like, say, how the telegraph went from "What hath God wrought?" to an international communications system. Even modern histories bleep over the "go-to-market" for the telegraph, as if technology merely flowed of its own accord into the spaces where it's needed.

Of course, Victorians were in love with science and technology. Fervent admirers don't care about the unlovely process of what happens before the premiere. What captures their imagination is the moment their object of desire steps onto the stage, with all the glory of success, and none of the homelier efforts that preceded it.

While this conceit might work in a technothriller, the missing details matter a great deal in the technology industry, where good ideas don't always succeed. Invention and innovation aren't mutually exclusive, so tech vendors need to invest in both to succeed.

Separating invention from innovation

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.)

The story of Edison and Tesla should be iconic for today's technology industry, but it's not. Instead, many (perhaps most) technology companies act as though invention is all they need. When they face challenges--from competitors, the economy, or customer rejection--these vendors reflexively turn to invention as the solution. Increase features in the product, add new products, add new service offerings--these are inventions that, ipso facto, people will not necessarily adopt.

Ingres, Shmingres
Over the years, I've worked with a few veterans of Ingres who voiced a complaint that sounds a lot like the grudge Tesla fans hold against Edison. Ingres, they believed, was the better database, far superior in features and design than its chief competitor, the Oracle RDBMS. Y'know, they may be right--and that conclusion, however justified, would be irrelevant. Oracle's advantages, such as its famously aggressive salesforce, decided the issue.

You might conclude from the Oracle-Ingres battle that the technologists and salespeople just need to keep on executing for the company to be successful. For a variety of reasons, innovation is much trickier.

Inventions Are Not Projectiles
For example, Development can't just throw new technology over the wall to Marketing and Sales, and expect good things to happen. Someone always needs to mediate between Development and Sales. In the technology industry, that job function is spread across product managers, product marketers, sales engineers, and people in other roles. Activity in this middle layer needs to flow both ways, tuning the invention to better fit the market, as well as getting the invention sold and implemented.

Once you disentangle invention from innovation, many fallacies of the technology industry fall out. For example, being the first to market with an invention isn't necessarily the best strategy. To go back to the computer game industry for a moment, LucasArts often followed in the draft of other companies that invented new types of games (air combat simulators, graphical adventure games, etc.). Learning from their competitors' successes and mistakes, LucasArts was often happy to be the second to market.

So, the next time you hear someone praised as an innovator, ask yourself, Is this person really an inventor? And if so, who helped turn the invention into an innovation?

[Cross-posted at The Heretech.]

Our research is your research

The management here at Forrester prods us analysts regularly to keep our research agenda in line with our clients'. In that spirit, I've been on a personal campaign to hear, as directly as possible, what questions you'd like answered. You might not know what's already on our list, so it's also an opportunity to get a sneak peek at upcoming projects.

I've been contacting people who downloaded my research, as well as visiting clients in person. (Which is one reason I'm going to be in the Boston area this week.) I had a dope-slap moment this morning when I realized, duh, I should be asking through the blog, too.

So, whether you're a Forrester client or not, let me know what kind of research for product managers and product marketers you'd like to see. If you're in the Bay Area, I'd be glad to visit you in person. If not, let's talk on the phone.