The Heretech

Mind your own business

On Twitter, Jim Holland asked an excellent question: "Should CEOs also act as chief innovators?" (Click here to read the article that inspired Jim's message.) My short answer is, start with the assumption that the answer is an unequivocal No.

If the CEO isn't able to focus on minding the business, who is? Many brilliant inventors do not have the skills to be captains of industry. And even if they had the skills, these wannabe-CEOs might inadvertantly let their personal investment in the technology distort their perspective on the business. For example, if you're not making the big money you expected, is the problem that the product lacks key features, or that you've failed to market or sell it correctly?

Obviously, it'd be silly to argue that no one could ever juggle both roles, because there's no small number of people who have succeeded at being the CEO/inventor. (Whispered aside: as a mental exercise, try not to mention Steve Jobs the next time you're in a discussion of this topic.) My argument is, your chances of success increase if you start with a different model in mind, and work your way backwards to the CEO/inventor.

Please spread the word about the requirements survey

We're trying to make our requirements survey as successful as possible, which depends in large part on getting as many people to take the survey as possible. Here's where we humbly beg for your help.

Please distribute this link to the survey to anyone you think has experience with, and opinions about, requirements documents and the requirements process:

http://deploy.ztelligence.com/start/survey/survey_taking.jsp?PIN=15TQ9CMTFTDDZ

Again, all responses remain confidential, and participants get both our thanks and a copy of the final research.

[Cross-posted at The Forrester product management blog.]

Google Wave makes smart design decisions early

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 Forrester product management blog.]

Beware of the naked man

Christopher Cummings makes a good argument for skepticism about many overheated claims about social media. You'd think that any overheated claim would inspire skepticism, but that ain't necessarily so.

In fact, you might write a history of the last century's overheated claims that never came to fruition, from Soon we will all be living in the dictatorship of the proletariat to In a generation we'll have permanent colonies on the moon and Mars to Dotcoms have re-written the rules of economics. People hope that the people making these overheated claims are visionaries, not idiots, or just opportunists exploiting the latest enthusiasm. Sometimes, they're actually right.

Obviously, we're going through a hothouse phase in the development of social media, when all kinds of speculation grow like kudzu. Chris takes special issue with the idea that social media will replace most face-to-face connections, or should replace them. For product managers, the risk is relying too much on social media for insights about customers.

Yes, social media done correctly in the PM sphere can help us hear about customer pain points, monitor the competition, and engage key influencers in the marketplace. But it comes at a cost that few seem willing to talk about.

I'll disagree slightly with that statement. Chris' target may be the claim, certainly overheated, that social media will entirely replace the traditional forms of requirements. If that's the case, we're not in disagreement at all. I'm a strong advocate for adding "inbound" social media to the requirements mix--heck, I wrote a three-part series on the topic--but I don't think that new media will elbow the old media out of the picture.

A lot of the traditional requirements sources were just as impersonal as a blog, discussion forum, or social networking site. In fact, they were even more impersonal, and in many cases, even more misleading. If only the specificity about enhancement requests in "I have a customer (IHAC)" e-mails matched their urgency. (If only you could have confidence in the urgency.) If only the enhancements recorded in the bug database were less cryptic.

In fact, if you were to replace the phrase social media with e-mail, you'd get something that a product manager might have written 15 years ago.

Face-to-face contacts aren't all they're cracked up to be, either. They have a very important place in requirements. In fact, they're irreplaceable. Any executive who thinks that you can do product management without face time with real users, buyers, and stakeholders is an idiot. Worse, the executive in question is contributing to the mistakes that cost technology companies time, money, and good will.

But executives are right in pressing for cost-effectiveness in requirements-gathering. If you have the opportunity to get supplementary information at a lower cost, why wouldn't you take it?

The big issue is how requirements gathering via social media should work. It's a new discipline, which is another way of saying, "It's going to take effort, time, and skill to do it right."

Here's one part of the discipline that's critically important: social media habits change by demographic. You certainly can't project your social media habits onto those of car dealers, research scientists, and accountants. By demographic slice, people participate more or less, have different goals, and vary in how much they participate in certain activities (contributing, commenting, collecting, etc.).

Therefore, if your requirements research depends on finding a lot of automotive engineers hanging around Facebook, you're out of luck. They don't "hang around" anywhere, in the physical or the electronic world. An automotive engineer who spent the day exposed to social media would be a major oddball, on the order of the title character of Randy Newman's old song, "Naked Man."

However, automotive engineers do use social media in other ways, so learning the inbound social media discipline is hardly pointless. I can tell you from both personal experience, and observing people trying to make social media work in this capacity, that it's damn hard to do right. But so is spending a day digging through the bug database for all the enhancement requests you've ignored during the last two releases.

The Heretech, episode 15: Cindy Alvarez on market development

Cindy Alvarez, ace product manager and fellow blogger, tells us why it's hard for tech companies to build a products that are easy to use. We also discuss product manager's responsibilities for identifying new markets. 

Plus, a review of a fascinating book about a highly successful tech company, and the requirements survey is underway!  Copyright (c) 2009 Tom Grant.

Best practices for requirements

We're doing a major research project on the state of product requirements in the technology industry.  To make this project as successful as possible, we need your participation in either or both aspects of it, the survey and the examples. (Whichever works for you.)

What's in it for you? When the final research document is done, we'll give you a copy. We also promise to keep any information you provide confidential.

The survey
We just launched the survey at the following link:

http://deploy.ztelligence.com/start/survey/survey_taking.jsp?PIN=15TQ9CMTFTDDZ

If you have approximately 20 minutes to spare, we're interested in hearing how you collect, write, review, and circulate requirements in your organization. Also, please feel free to forward this link to anyone you think would be interested in participating in this survey.

The examples
We've been building a library of examples of requirements documents. (And thanks to everyone who has sent us their samples already.) We don't need to see the actual words, just the structure of the document. In other words, we want to see your template, not the actual contents of a completed requirements document. Fake or redacted data is good, too, if you use a requirements application.

We're being deliberately vague about what a "requirements document" is, since we don't want to lead the witness. Your examples will tell us what you think the fundamental requirements documents are. What do the key stakeholders and consumers in your organization need?

If you're willing, please send your examples directly to me, tgrant@forrester.com.

[Cross-posted at The Forrester product management blog.]

15 years of increasing clutter

Most of the comments I've seen on this 15-year retrospective of Yahoo's main page have focused on the aesthetics: "Wow, we've come so far since the dark ages of web design!" All props to the creative services people, since they've had to struggle with the increasing visual complexity of the page.

The Ur-entry page had one purpose: help me find things. Now, it packs into limited browser space a whole lot more, including...

• Things I use (e-mail, weather, and a few other things)
• Things I'd never use (horoscopes)
• Things that they've helpfully provided, but are no help to me (today's top searches)
• Things that are completely mysterious to me (what the heck is Shine?)
• Things that I might use someday, but don't matter to me now (yellow pages)
• Things that irritate the hell out of me ("newsvertisements" about TV and movies)

From this perspective, the 15-year overview of Yahoo entry pages is a window into Yahoo's business strategy, as it mutated from a search provider into a content provider.

Lies my Dev Manager told me

Wow, Guy Kawasaki has been working with an eager-to-please group of development managers. For every one of his "Top Ten Lies Of Engineering," I can remember hearing the polar opposite of every exaggerated, half-true, evasive, or downright untrue statement that Kawasaki cites. Not opposite, in the sense of true, but just untrue for different reasons.

My point here isn't to cast doubt on Kawasaki's experience, but instead to say, your experience may vary. Less obliging development managers have a different motivation for dissembling, (avoiding commitments that they may not be able to keep, deflecting responsibility for problems away from the development team, etc.)

Kawasaki: "We're about to go into final testing. "
Grant: "We can't give  you an exact release date."

Kawasaki: "Even my mother can use it."
Grant: "Didn't you read the release notes?"

Kawasaki: "Our beta sites really love the product."
Grant: "An extensive beta program would jeopardize the release date."

Kawasaki: "We'd save time if we'd just start the whole project over from scratch."
Grant: "If we start ripping out code that we've already built and tested, there's no way we can stick to the release date."

Kawasaki: "This time we got it right."
Grant: "It's going to take several iterations to get the feature right."

Kawasaki: "It works on my computer."
Grant: "Of course it doesn't work on that computer. It's not a supported configuration."

Kawasaki: "We have great testers and a great bug-tracking system."
Grant: "With this kind of release, you can't expect us to predict when the bug count will stabilize."

Kawasaki: "I don't know much about sales or marketing."
Grant: "Sales and marketing don't know Bo Diddly about development."

Kawasaki: "What I'm doing is scalable."
Grant: "We haven't done the complex performance and scalability testing needed to give you exact scalability parameters."

Kawasaki: "This will take five minutes to fix."
Grant: "This will take five days to fix, and another day or two to test."

Ask me anything

As a Forrester analyst, I talk directly to product managers, product marketers, product VPs, development managers, CEOs, you name it. Sometimes, I discover that people in these roles don't know the full range of research, data, and other services that Forrester provides to them as our clients. Therefore, I thought it would be worth a quick post about one of these services, inquiries.

Have a question? Set up a 30 minute inquiry and we'll do our best to answer it for you. Since my research covers a bundle of related topics--product management, product marketing, requirements, Agile, social media, product strategy, etc.--the questions sent my way usually fit into these categories. I also get no small number of questions that fall naturally into the penumbra of these topics, such as market development, innovation, standards, and tools. Here are some recent examples:

• What are the best practices for getting the most out of the PM team?
• How do technology companies organize and staff product demo teams?
• Where is Agile adoption today in the technology industry?
• Has anyone been successful in using social media as a source of innovation?
• How can we add a product management function in our services company?
• What's the adoption of SaaS-based public services?

You pick the format for the response, e-mail or phone call.

If I get a question that's not in my bailiwick, I'll help our Inquiries team steer the question to the right people. For example, Tim Harmon is usually best for SMB-related topics, while Jennifer Belissent covers international markets.

To arrange an inquiry, you can use your Forrester account to log into our web site and pose your question. (Every research document has a similar link to the inquiry request form.) Alternately, you can use the inquiry@forrester.com e-mail address to contact the Inquiry team.

So, fire away.

[Cross-posted at The Forrester product management blog.]

Showstopper SaaS requirement: Leverage SaaS

Napoleon once condemned overly-cautious generals by saying, "If you're going to take Vienna, take Vienna." You can apply the same principle to software-as-a-service.

Dan Olsen's excellent presentation on product management for SaaS products--a topic dear to my own heart--is really a plea for seizing the opportunity that SaaS provides. Among other potential benefits, Olsen points out that SaaS gives you a window into customers. How do they use the product? What's the normal adoption pattern? Is there any warning behavior that indicates someone might stop using the product?

The problem is, these capabilities don't come for free. Tracking features are like any feature: they take development resources. However, here's a good test of what kind of company you really are. If you think your girlfriend is like a fickle paramour, happy only as long as you keep showering gifts (i.e., features), you'll never invest in tracking features, because customers won't ever see them. ("Why did you buy something for yourself, when you could have bought something for me?")

I hope that you work for a different sort of company than that. At some point, you need to step back and reassess. SaaS gives you the kind of sudden insights that, in a different type of relationship, are only possible through long, expensive therapy sessions--unless you don't care if the other party decides one day to leave.

Playtesting is more than usability testing

In an earlier post, I noted how some best practices for designing boardgames apply to the technology design process. Today, I'll throw in another analogy that might explain why the user experience for high-tech products often falls short of the mark.

Games people play
People who think up boardgames face difficult design challenges. Not surprisingly, they don't get it right on the first try, or even on the fifteenth. Since the criteria for making a top-notch boardgame are difficult to meet, designers "playtest" their games repeatedly. Objective opinions are important, so this QA process involves as many "playtesters" as possible.

Each criterion is important. Obviously, games need to be fun, not just tedious die-rolling or card-playing exercises. What makes a game subjectively fun, however, depends on several elements. To delight your audience, the game has to pose an interesting challenge. People often deride Monopoly, for example, because it doesn't pose any interesting choices. Roll, move, buy property or pay money, repeat for several hours.

The game also needs to be balanced, obviously, so that one player doesn't easily crush the others. Balance has subtle aspects, such as keeping the game competitive even when someone pulls out ahead (the "runaway winner" problem, or its flip side, the "beat on the leader" problem).

Another challenge is replayability. Some games don't provide different possible outcomes, or give room to explore different strategies, to merit more than one play. While chess may not appeal to everyone, it's undoubtedly one of the most replayable games, allowing for different strategies in the opening moves, middle game, and endgame.

Are you experienced?
As important as these individual criteria are (including a few more I haven't mentioned), game design isn't simply addressing each of these items in a checklist. Many bland games meet all of these criteria, but just don't provide that great of an overall experience. (The old warhorse Settlers of Catan is my favorite example.) Other games might not be perfect on every score, but they're still a hoot to play. (On my top 10 list, Cosmic Encounter fits that description.)

The best games provide an experience. For example, party games like Pictionary or Apples To Apples are all about creating an experience (often unintentionally hilarious) that's more important than who wins. If Pictionary didn't give every team a chance to win, however, the experience would suffer.

And in many cases, the experience is actually a byproduct of the rules. Boggle, for example, makes a task that no one would do on their own, arranging random letters into words, into something that can be pretty fun.

In thinking about the experience you want to create, it's important to keep in mind the person for whom you're creating it. For someone who occasionally watches a WWII documentary on The History Channel, Axis & Allies might create the right kind of experience. For a more die-hard history buff, a more detailed simulation of World War II, such as Europe Engulfed, would be a better choice.

I put a spell on you
By now, you probably see where I'm going with this. Technology products need to meet particular criteria, too. Don't force the user to make too many clicks to perform a simple task. Don't overwhelm the user with too many choices. Make it clear which part of a multi-step task the user has reached, and how to move backwards and forwards in that sequence.

Meeting these criteria might make a product tolerable, but you won't necessarily have created a good experience for the user. You may also have overlooked the sort of experience that fits the user. For example, most workflow tools have highly complex UIs that appeal to a particular kind of technical user who wants a very big palette of states, actions, decisions, and outcomes. Business users, on the other hand, want a more paint-by-numbers approach.

Creating the right experience can pay off, as Apple has shown repeatedly. Just as attractive components helped the "Eurogame" phenomenon, the aesthetic appeal of Apple's hardware generated enthusiasm among people who otherwise saw desktop computers and cell phones as an unfortunate necessity.

But even Apple's experience isn't for everyone. Until the Mac OS included a dual-boot capability, Apple's coolness factor didn't convince software engineers to buy their hardware. Now, Apple has created a particular user experience for that technical audience which shares only a few elements with the consumer market. (And Apple still might have blown this opportunity through bad design decisions.)

Already, we've seen signs that technology products don't get the testing they deserve. In some technology companies, usability testing is, to be frank, is either cursory or non-existent. Even when engineering teams ask users for their feedback on particular UI components, they're probably missing the much bigger picture. If you want to capture and keep users, you're going to need to do more rigorous "playtesting," with the goal of creating an overall experience.

How to fail with Agile

Someone should make a poster out of the main points of this article, and sell it at Agile 2009. Only someone who has been around the software development block several times would recognize the sure-fire ways to undermine improvements to the development process like, Replace a plan document with a plan “in your head” that only you know.

Market development: horizon or mirage?

The recession has sharpened the points of a dilemma that technology vendors were already facing: Do cleave closely to our existing customers, or try to expand outwards? Do we try to sell more into existing account in familiar markets, or do we look for new markets where people are struggling with business problems that look congruent with the ones we're solving for our existing customers?

With no obviously correct choices, vendors experiment, to the point where they see real opportunity, or decide that the exercise is going nowhere. But how do you know if you've invested enough into the experiment to get a reliable result?

Adobe runs a good business, but its stock still takes a dive
A good example of a technology company that could stick closely to its existing customers, or fan out to find new ones, is Adobe.  Having long ago identified its core market, creative departments and web site teams, Adobe might not have an obvious place to go. However, maybe it doesn't need to. As long as Photoshop remains the standard for image editing, Dreamweaver remains the web developer's tool of choice, Acrobat is the default cross-platform document format, and Flash retains a strong position against threats like Silverlight, Adobe will continue to get license renewals and accrue new customers.

Unfortunately for Adobe, Wall Street doesn't see the world through the same lenses. Even positive coverage from market observers failed to keep Adobe's stock from plunging from a high of approximately $45 per share last fall to under $20 per share in March. Since that nadir, the price has bounced back a bit, to around $30 a share today.

Here's how positive the coverage was, during this collapse of Adobe's stock price:

• Michael Goodman at TheStreet.com,  in "Adobe Has Its House In Order," praised Adobe's cost-cutting measures. Adobe was behaving like one of "the winners will be the companies that scale back operations in concert with what they're experiencing, not how they wish it to be.
• For months, The Motley Fool has pointed to Adobe as an outperforming technology stock.
• In May, SmartMoney.com featured Adobe as a top pick among technology stocks.

At this point, the management of a company in Adobe's position might conclude, "Holy moley! If we can't get our stock price up by making smart business decisions, and holding on to a reliable customer base, we have to find new customers!"

How big can the application development circle be?
Undoubtedly, new customers would be good, but where to find them? Adobe has at least one idea of how to expand its customer base: get more people who actually contribute to web applications to be users of the tools. Flash Catalyst is designed for the web designers who are not coders, but who build the application flow, user experience, and general UI conventions. After creating the basic application framework, a developer can add the necessary code to enforce business rules, handle weird edge cases, and other tasks.

That's great, but maybe it doesn't go far enough. Perhaps Adobe should be pushing to go further, involving not just the people who build prototype applications, but the business users who have to live with the results. Give that butcher, baker, or candlestick maker a cleverly-designed interface for specifying what kind of application to build, and the tool puts together the pieces. Voila! You've just expanded Adobe's licensed user base to include a whole lot of people who might have spontaneously combusted if they had come into direct contact with tools like Photoshop or Illustrator.

Or, perhaps, this user-generated application is a pipe dream. After all, vendors have tried before, but you wouldn't necessarily give Microsoft Access or even Intuit's QuickBase platform to any random business user. Maybe this kind of tool is possible, but the cost/benefit ratio of building one isn't really there for Adobe. Extending a development tool to include non-coders is already an impressive achievement, so it might be a bit unfair to Adobe to ask them to do more. On the other hand, it's just that kind of push to do more than originally planned that leads to some of the best inventions.

Whatever the ultimate answer may be, the first step into this direction, adding web designers to the mix of rich application developers, is not in and of itself a good measure of how far the idea might go. Who knows, web designers might be wholly unenthusiastic, but end users might be overjoyed to be included. Enthusiasm and adoption might not proceed along a straight line with an unvarying slope.

Herein lies the chief peril of market development. Invest too little, and you may miss important opportunities. Invest too much, and you may discover that you've been chasing a mirage.

[Cross-posted at The Forrester product management blog.]

The Heretech, episode 14: Israel Gat on Agile adoption

In this episode, Israel Gat illuminates the ways in which Agile adoption depends on organizational and cultural factors. We also muse about Helmut von Moltke, 19^th century military Agilist. (Go look it up!)

Plus, a brief review of an even briefer document about innovation in “knowledge-creating” companies, and a heads-up about some upcoming survey research about product requirements and Agile adoption. Copyright (c) 2009 Tom Grant

Blame the user, not the cloud

Nothing about cloud computing makes it any easier or harder for people to behave recklessly. That seems to be the moral of the Twitter security breach story, now that we're past the initial, self-referential Twitter posts ("OMFG, Twitter guy shows how insecure the cloud is!!!").

Of course, the cloud magnifies the likelihood that someone will break into your e-mail account. The core problem isn't webmail per se, but the fact that people post personal information that makes it way, way easier for hackers to guess your password.

Shocking that someone who should know better made this mistake? Maybe. From another perspective, it's oddly comforting. People who aren't in the tech biz, such as car dealers, dentists, real estate brokers, and taxi drivers are no more prone to human foibles than social media propellerheads.

Ebay loses track of its product

If this analysis of eBay's current revenue slide is accurate, the basic problem of the world's premiere electronic garage sale is that it's trying to be a mini-mall instead. Sort of.

Ms. Steiner, in an interview, attributes the fall-off in audience to eBay’s “identity crisis.” At the highest level, the site has switched from trying to promote itself as a place for a full range of merchandise to one that emphasizes used and off-season goods. There are other changes as well, she notes, that are not only confusing buyers but also alienating many of the site’s sellers. EBay is increasingly changing its rules to favor bigger sellers over mom-and-pop dealers and individuals clearing out their attics. For example, items from high-volume dealers appear higher in search results.

In other words, they've lost focus on what sort of product or service they provide. The various ways in which eBay has tried to shift its attention to the small retailer are manifold, such as the "Buy It Now" feature.

It seems inevitable, in hindsight, that other online storefronts would emerge, making eBay's bet on the small retailer a bit risky. (Particularly since the user experience for the shopper on a site like Amazon can be a little easier to use, and a lot less cheesy-looking, than eBay).

Ebay is an amazing web application, handling millions of transactions every hour. That's not a formula for an enormous amount of flexibility, however, in what the application can do.

Here's where the product management function is critical. Yes, says the product manager, we might make money in a lot of different markets. However, our current product is very good for a particular market, and if we can't morph it into something that's going to capture and keep a lot of new business, it may not be worth pouring money into an inherently risky venture. (Or, if it's a risk worth taking, having a plan B is still a good idea.)

It seems weird that, if we're in the middle of a recession, and people are trying to scrape two nickels together, the place where they might sell a few spare items is not doing well. However, economics depend on more than just supply and demand.

Where science breaks if something's awesome enough

Totally off-topic, but if you share my sense of humor, you may find this edition of Dinosaur Comics hilarious.

Immersion therapy

Friend-of-the-blog Adam Bullied has a great article on "industry immersion" in the latest issue of Pragmatic Marketing's magazine. The follow-up article should be, "Getting your company to give you the time needed, and reward you for doing a good job of it."

My brain is full. Please stop talking.

In many blogs, some of the most interesting content is in the "About Me" section. Such is the case with Cindy Alvarez's blog on PM issues.

Here's a striking quote from Cindy's account of how her background shapes her approach to product management:

I chose to major in psychology at Harvard because I was interested in the theory of multiple intelligences, which posits that intelligence consists clusters of skills that allow people to excel at certain types of tasks.

This notion, simple as it is, suggests a simple yet revolutionary rule: not every audience is alike, and the product feature set and interface need to work for the audience you have.

Cindy is making a very important observation here: you need to think about what's in the customers' brains as much as what's in their wallets.

Cognitive load is one of those aspects of human psychology and intelligence that product managers and product marketers both frequently overlook. When considering how users learn about a product, through demos, web site content, documentation, or just poking around, you need to consider the learning process as much as the product capabilities. Humans, as is true of any animal, have a finite capacity to process new information. If you try to shove too much into the brain all at once, some of the information will leak onto the floor.

Unfortunately, many people in the technology industry forget this basic limitation. Your product can do a lot, so why not tell your audience everything it can do? Presumably, you'll impress people with its vast capabilities, while at the same time making the competition look puny and weak.

Meanwhile, the people watching the demo, or clicking through the UI, don't care about everything you're telling them. Even if they did, not all of it will stick.

The cognitive load gets even heavier when you make this presentation of new information a translation exercise to boot. It's hard to learn anything in a foreign language, because your brain is processing the new information and handling the translation. Your product's impressive array of features and capabilities is a foreign language that the user, buyer, or implementer needs to learn to see how the technology can solve their problems, and how it will fit (or not) into their existing work habits.

The trick, therefore, is finding the right economy of product information. If you don't know your customers well enough so that you can prune the information you present down to their essentials, best of luck to you in your business. You'll probably need it if your competition does a better job of communicating within the constraints of cognitive load better than you do.

Follow that man!

If you're not following anyone on Twitter yet, and you're interested in product management and product marketing, start with Jim Holland (@Jim_Holland). For PM issues, he's the most active Twitterite on PM issues, and he's a good pointer to other PM-related Twitter activity.

Plus, there are a couple of tags, #pmv and #prodmgmt, that help you pinpoint tweets of interest.

The misuse of social media

The "inbound social media" research grew to massive proportions, then underwent mitosis to become three separate documents, because it's difficult to encapsulate the discipline of using social media. Like any new field, social media are fraught with both opportunity and risk.

In the particular application that I was investigating, social media as a new source of requirements data, people can commit the same mistakes with this new source of information as they have with the old ones. For example, important players in the product development process often make decisions based on the customer with whom they last spoke. An equally common temptation is to listen to customers who echo what you want to hear, and disregard the rest.

In the best possible circumstance, you get a single person who appears representative of a larger user population, gives you credible insights, and even articulates their needs clearly. The obvious problem is that you're only listening to  one person, who will never be 100% representative of the larger population. That's especially bad if the population contains distinct segments of people with different needs, habits, and skills, and you have to build something that fits the bill for more than one of these cohorts.

If you're not taking advantage of the opportunity to use social media to collect more data than you could through traditional, labor-intensive methods  (for example, customer meetings), you're missing a big part of the reason for paying attention to social media in the first place.

And if you don't believe me, take a look at this item from The Guardian about how British businesspeople went gaga over a single 15 year-old intern's analysis of how teenagers use social media. To be fair, both traditional and social media contributed to the buzz around the document. But that's the point: you can repeat all the mistakes of old media when using new media.

[Cross-posted at The Forrester product management blog.]

A PC is not an appliance, Bastille Day edition

Over the weekend, I tried out Netflix's Internet-delivered movie option. After installing Silverlight on my home PC, I fired up a movie.

Ten minutes into it, I had to stop. Every few seconds, the audio would skip ahead, meaning that you lost a word here, half a word there, which for me reached a fingernails-on-the-blackboard level of annoyance. I regularly watch shows on Hulu, which does not have this problem, so the Netflix experience suffered by comparison, too.

I'm telling you this anecdote not to rail against Netflix, or Microsoft Silverlight. I'm absolutely cool with the idea that there are kinks to be worked out. Maybe Silverlight has an issue with the 64-bit version of Vista, or there's some background process on my PC that's messing with the audio.

The real point I'm trying to make is this: Even as a tech-savvy person, I have no inclination whatsoever to diagnose and fix the problem. Multiply that lack of enthusiasm by at least a factor of ten for people who don't have the same level of experience and knowledge with PC issues, and could care less to learn about them.

I'm sure that either Netflix or Microsoft will fix the audio skipping problem. (A quick search revealed that I'm not the only one who's experienced it.) However, once again, a technology that should be as reliable and simple as turning on your television and flipping channels is anything but.

The Heretech, Episode 13: Dave West on Agile adoption

Dave West, fellow Forrester analyst, tells us how and why Agile adoption has spread. We ponder the ailments of software development that inspired Agile, and we discuss the overlap among Agile, Lean, and other methodologies. Plus, a thumbs up to a good PM blog, and news of social media research. Copyright (c) 2009 Tom Grant

Picking the right social media for requirements

All three parts of the series on social media as a new source of requirements data are now published. The first shows how product teams can use social media to create reach more accurate conclusions than traditional sources of requirements (customer visits, enhancement requests, customer advisory boards, etc.) alone can provide.

The second document distills the lessons learned from attempts to use social media in this "inbound role" into a methodology, PLOT (persona, location, options, test). Since the choice of which social media can best answer particular kinds of questions isn't immediately obvious, I devoted the third document to that topic alone.

During the research for this series, it became glaringly obvious that there is a major dividing line in the type of information that product teams collect and analyze:

• Product-centric, which related directly to the company's products and services. How many people have voted for a particular feature is a good example.
• Problem-centric, which depicts the customer's world. The patterns in how organizations adopt particular kinds of solutions, for example, is vitally important for product teams, even though the best form of that information makes no reference to the vendor, or even the supporting technology, whatsoever.

Shown here is a graphic that summarizes the kinds of requirements information that falls into these two categories. To borrow a phrase from William James, the breadth of social media options appears, at first glance, as a "blooming, buzzing confusion." This distinction between product-centric and problem-centric issues is the first of several filters needed to select the right social media outlet to answer a particular question.

This distinction is also critical for determining whether the company's current investment in social media can be at all useful for the product team. Already in many technology companies, Marketing's enthusiasm for social media inspires skepticism in Development. In the worst cases, it's almost as if someone were to propose to John Calvin, "The papacy has some interesting ideas about transubstantiation. Why don't we look into them?

This product/problem distinction helps decide whether the existing social media channels will be of any use to the product team. In some cases, they certainly will be. In others, either the company will need to build additional social media tools, or the product team will need to look outside the company's web presence altogether.

[Cross-posted at The Forrester product management blog.]

A PC is not an appliance

Yes, there are definite pros (i.e., flexibility, upgradability) that counterbalance that big con. However, it's still a major pain in the gluteus to spend 45 minutes trying to get something to work that should be as simple as plug in the microphone, fire up the VOIP software, and start recording.

I'm picking on a particularly immature part of contemporary PC technology (Skype, audio editing tools), but the point still applies. As frustrating as the DVR at home might be, my recording of The Colbert Report doesn't have compatibility problems with the recording of the movie Bottle Rocket.

And why in the name of all that's holy is audio editing such a dark art on the PC?

Twitter without the airbrushing

These statistics about Twitter are fascinating. (Here's some additional analysis.) We see Twitter without the circle of fawning admirers, with her make-up removed, being herself at home. She still looks pretty good, without the hype and glitz.

The statistic that will appeal to the cynics and skeptics: 15% of the people who follow more than 2,000 people are social media marketers. Yeah, I kinda suspected that there were more than a few people playing the You Watching Me Watching You game.

The rest of the numbers are what you'd expect from a relatively new social media outlet, so there's  no reason for Twitter to blush. Half of all users aren't active? A significant number of blogs are also inactive, dead, pushing up the daisies, rung down the curtain and joined the choir invisible.  A minority of users create most of the activity? Not exactly a shockeroo. I'd be very suspicious of the numbers if they showed a different picture.

The most interesting statistic for me, as a hybrid social/computer scientist, is the take-off number of 150 followers. That's the threshold where people where you, and the people who know you, have a real network going. It's also where people who don't know start thinking you're worth noticing.

And for you product design wonks out there, APIs really matter. Twitter's success owes a lot to applications beyond www.twitter.com.

The moral: You don't need to claim that Twitter has changed the world, or that Twitter now overshadows all other social media, to believe that Twitter is a success.

Why use cases matter: Memex

Suppose you're a company like Memex, in the business of providing software to police departments. Given the nature of the work, almost any electronic assistance might be preferable to the alternative. Would you rather do a quick search on all information about a suspect whom you're interviewing, or dig through file cabinets and desk drawers for information that might not even be there?

The temptation of lazy design
Law enforcement's need for electronic assistance might tempt software developers to be lazy. As anyone who has built an application for a specialized purpose (tracking donations, handling equipment requests, pooling notes about patients, etc.) knows, it's easy to create a bare-bones UI and the underlying database. It's a lot harder to make it usable, and to build in the application logic that the real world demands. And then there are the inevitable customizations...

A quick analogy: I decided to put in a drip watering system for some plants in the back yard. Someone could have handed me a box full of random hoses, PVC pipe, and connectors, and left me to figure out how to make use of it all. While some of the hoses might have been good for someone else's garden, they don't match the layout of my plants. If I don't have the right tools--for example, a wrench to tighten some of the couplings--basic aspects of this household project will be a lot more challenging.

Instead, I bought a kit. It wasn't perfect for my needs, but it got me started a lot faster and more successfully than the approach I was tempted to take, buy the components that, in my earnest newbie ignorance, I thought would work together.

The benefits of starting with the use case
Let's leave the peonies and get back to the felonies. Again, you might throw together a UI that lets you enter incident reports, search on related crimes, and report on the closure rate of investigations. However, making the application usable takes real work, including paying careful attention to how people in law enforcement actually work.

That's what made me very interested in finding out all I could about Memex's applications. The UK-based company hired Peter Ship, a former investigator in the murder unit of London's Metropolitan Police, to advise them on their product design. The company also worked with local police departments to provide further information and validation of how to fit the technology to police work.

Whenever you take this kind of use case work seriously, you wind up emphasizing features that you might not have been expecting to be as important as turn out to be. For example, the decision to design the application around the needs of an inexperienced investigator, potentially the weakest link in the chain leading to prosecution and conviction, prompted Memex to invest in a "Validate With Advice" capability. Based on the police department's own guidelines for how to handle particular situations, the system makes important suggestions to the investigator. For example, if the incident report falls into a category of crimes (smash-and-grab thefts, domestic violence, etc.) that the department is giving special attention, the Memex application can tell the investigator how to prioritize this investigation, and what next steps to take.

This particular example also shows how use case analysis can help development organizations make tough decisions. To make the Validate With Advice feature work, you need a rules engine that's flexible enough to accommodate a lot of departmental guidelines, and simple enough so that the non-technical users who best understand these rules can define them in the application. On top of that, to get people started, the application needs some canned rules that resemble the sort of guidelines that most departments will enforce. That triple combo of capable rules engine, interface for business users, and pre-defined rules is a big development effort, frought with potential pitfalls--exactly the kind of project that many development teams would try desperately to avoid.

Room for creativity and coolness
Sometimes, people in the tech industry grumble that a too-slavish dedication to use cases reduces their creativity. However, Memex's design team shows how the use case can be the springboard to very useful features with a high coolness factor.

Many investigators use a link chart to depict a web of relationships among the facts of a crime. Witness A saw Suspect B in location C. However, we know that 10 minutes earlier, Suspect B was across town using an ATM. So how did he get to C in time to commit the crime.

Memex's tools build this kind of link chart on the fly. Autochart is pretty cool to see on its own, but it's especially cool to see how it works in conjunction with search. An investigator who has doubts about Witness A might search across repositories to find more information about that person. As pertinent facts emerge--for example, all the other times this person provided an eyewitness account of a crime--that the investigator might add to the link chart. Over time, the picture that emerges isn't a machine-generated set of pointers between bits of data, but a carefully-constructed narrative, based on the facts and the investigator's judgement.

Someone who hasn't taken use case analysis seriously might still create a link chart, but it's more likely than not to be a half-assed attempt, designed more for demos than actual use. The connection between the link chart and search is exactly the sort of capability that would be missing in the marketware version of the feature.

I have a gut feeling that people building vertical-specific applications like Memex's might be doing a better job of use case analysis than many "horizontal" technology built for a general audience.  No matter how horizontal or vertical your product might be, the Memex case shows how very, very specific use cases can lead development teams to resist lazy design and make the right design choices.

Pity the poor journalist

For the last several years, I've been watching how print and broadcast journalists have responded to the rise of social media. It's darkly comic to see, for example, a columnist at The Washington Post sneer at bloggers, and in the same daily edition, another WaPo writer plug their Twitter account. The journalistic profession''s troubled relationship with the social web is also one of the best case studies in how not to use social media.

Newspapers have had the worst time of it. While newspapers in particular have blamed their business problems on the Internet, they certainly helped create many of those problems. Rather than extending their business to include social media, US newspapers largely fought the trend. As a result, they've entered the news-oriented social media too late, and generally unconvincingly. (Why exactly would I follow Nicolas Kristof on Twitter?)

Case in point: The Washington Post's decision to fire columnist Dan Froomkin for reasons that remain unclear. The interesting part of the story is how quickly The Huffington Post hired Froomkin. While that doesn't portend an exodus of op-ed writers to sites like The Huffington Post, it's interesting to see how easily Froomkin made the transition. As did his regular readers, who won't be reading Froomkin at the Post or any newspaper's site.

The question of how successful the news-oriented social media outlets have been at complementing or supplanting some of the functions of traditional print and broadcast media is far beyond the capacity of this one little blog post to handle. It's still worth noting how people in the business of content can badly fumble their handling of social media.

Access granted

Zoho now provides a simple mechanism to convert a Microsoft Access prototype into a web application. In other words, Zoho has now provided what Microsoft never did.

I'm still baffled by Microsoft's unwillingness to take this step. Sure, Microsoft wants to keep you in their technology stack, but the path from Access to any web-based application platform, including Microsoft's technologies, hasn't been clear, or easy. Instead, a bunch of little vendors built their own Access-to-web-app converters.

You'd think that Access would have an interest in promoting this migration path, if that's what keeps people using Access as a prototyping tool. For example, a few years ago, I started building a prototype in Access for what would eventually be a MySQL/PHP-based departmental application. Soon into the project, I realized that the work put into the Access database structure was largely wasted. Oh well.

Oh captain, my captain

Christopher Cummings agrees with Saeed Khan's assertion that the product manager is not the CEO. Saeed's original post is here. We also discuss this topic in this week's podcast.

CC proposes an alternative metaphor, captain, that may be marginally better than CEO, but not ideal. (He admits as much at the end.) At the very least, claiming captaincy is, politically speaking, more than a little dangerous. The product manager plays an increasingly strategic role in technology companies. However, self-coronation as captain, CEO, squad leader, capo, or anything similar invites backlash.

Primus inter pares? I'd only think of using that term because not everyone speaks Latin. Still, they could look it up, and claiming to be first among equals might also sound a bit insulting. Best to say that you have your domain, and I have mine. Sort of like the two different consuls in the Roman republic, which is more obscure than a commonly-used Latin phrase, and that much safer.

Should Google be the next Microsoft?

Google has announced its new Chrome operating system. Yay.

I was tempted to stop there, because there's actually very little we can say, at this point, about Google's announcement. The temptation to speculate, prognosticate, and extrapolate is powerful, to be true, but it's worth taking stock of the unknowns before we say much more.

Netbooks may be both an opportunity and a limitation
Google is right to see the rise of netbooks as a springboard for its browser-based OS. Certainly, netbooks are the one part of the PC market that's seeing growth. However, not every consumer who already has a laptop will necessarily buy a netbook. Corporate IT department are not rushing to buy employees a duplicate or replacement computer, just because netbooks are new, useful, or inexpensive.

In truth, a netbook is not a perfect replacement for a PC. As my Forrester colleague J.P. Gownder puts it, netbooks are a different form factor, which addresses a particular set of needs. There are other needs that a netbook won't meet. A netbook is perfect for my mom, but I couldn't see doing my old job (PM) or my new one (analyst) with one.

Yeah, yeah, I know, the Chrome OS is not predicated on netbooks alone. Since a lot of the "five minutes after the game" quarterbacking focuses on netbooks, I had to say something.

The Chrome OS depends on Chrome
The bigger dependence, of course, is the Chrome browser, which isn't exactly taking the browser market by storm right now. The Chrome OS may add to the reasons to use the Chrome browser, but that doesn't automatically mean that users will be convinced by those reasons, or even understand them. Which, of course, makes pronouncements about the death of the traditional operating system a wee bit premature.

Not all users may be overjoyed with this strategy
Google certainly has gained a lot of users for their productivity applications. However, they still lag far behind Microsoft Office in number of users. The reasons are many, and pretty obvious: My company isn't comfortable with sensitive data outside the firewall. We long ago standardized on Office, so don't ask me to certify a new set of tools from scratch. Google Apps doesn't do [insert feature], and that's a piece of functionality that's important for me. And so on.

Inherently, some desktop applications are more "displaceable" than others. It's going to take a while to see how many users will abandon their desktop applications users for Chrome-based alternatives.

Not all governments may be overjoyed with this strategy
Hey, does anyone else remember the Microsoft anti-trust battle? The one based on the assumption that it's a bad idea to let a vendor that's in the operating system business develop applications that are tied too closely to that OS?

Google is moving in the opposite direction than the path Microsoft took, starting with the application, from the applications to the operating system. However, the same concerns apply, with an added twist: how much user data Google maintains, and what they do with it.

Sometimes, the phrase "Google product strategy" can be an oxymoron
Google's "idea factory" approach to its product portfolio has its pros and cons. On the pro side, a smart, dedicated, energetic team can pull together an interesting new application or platform technology rapidly. Google employees have the freedom to explore new ideas, so invention does not always have to wait on the rest of the organization.

However, this approach doesn't make it easy, or perhaps even possible, to have an overarching product strategy. For example, the fit between Wave and other Google products is not altogether clear. (Particularly since many product groups didn't have any idea what Wave was, until the public announcement.) If the success of the Chrome OS depends on some constellation of applications, and there are gaps in Google's offering, how quickly will Google fill them? Or even realize that the gaps exist?

Where does the Chrome OS fit into the bigger world of cloud computing?
Complementing these questions about the relationship between the ChromeOS and the desktop, there's another set of questions, yet unresolved, about where Google fits into the evolving world of cloud computing. Does Chrome mean that Google is locking itself into an increasingly exclusive cloud strategy? Is it going to throw a lot of effort into recruiting other vendors to write Chrome-based applications? (You can ask that last question about both the desktop and cloud vendors.)

Serious technical challenges lay ahead
The browser-based OS is a new frontier frought with many interest technical challenges. Even with its impressive collective brainpower, Google won't solve them overnight.

And these are only the off-the-top-of-your-head questions. I'm sure that new ones will emerge.

Believe me, I'm not trying to be a wet blanket here. Google may very well succeed, and it may be a good thing for the industry that it does. However, it's way too early to conclude that either Chrome or traditional operating systems will "win," or if it's even an either/or question.

When 109 is too small a number

Jorge Barba posted a list of 109 innovation-stopping phrases. Come on, people, you can think of more! Here are my additions:

• There's no time! (You might call this the Jack Bauer excuse.)
• Where's the supporting evidence? (Often stated by people who steadfastly refuse to provide any evidence for their position.)
• Customers don't know what they want.
• Customers don't know a good innovation until they see it. (Sometimes used to quash good ideas, when used as a synonym for the previous excuse.)
• You have no appreciation for what Development does. (While it may be true, this statement does not ipso facto invalidate the idea.)
• The CEO hates that sort of thing.
• But we have to invest our precious resources in beating the competition. (Rather than trying to differentiate yourself from the competition.)
• That's a pretty long-pole project. (Sometimes a synonym for, "I wouldn't enjoy working on that project.")
• We'll take that under consideration. (As opposed to, "Let's talk about the next steps.")
• If this works, we'll be heroes! (Which raises the question, why is a heroic effort required?)

Are G-Men missing the G-Spot?

Yesterday, I ranted a bit about how Twitter is getting an amount of press that's disproportionate to its importance, relative to other forms of social media. While that result is unfortunate, and perhaps misleading for people who are building budgets for their social media strategy, it's not all that pernicious. People may later regret their behavior during a media bacchanal, but they've only hurt themselves, or a single company, in the process.

When the US government joins in the festivities, I start to worry.

The U.S. Government Accountability Office (GAO), the government unit known as the "investigative arm of Congress," has launched a presence on YouTube and Twitter. Chuck Young, GAO's managing director of public affairs, says the video and microblogging sites aim to help the agency keep people informed about GAO's work.

You may wonder, how harmful could that really be? Just another sign of the millenials making themselves felt in Washington, DC, just as they did in Obama's campaign. Heck, it's just another channel of communications to help citizens know what their government is doing, right?

Wrong. What the US government says, and when it says it, and what happens to its statements, is a matter of public importance. Here are a few examples:

• During the Iraq War, both government employees and contractors have regularly left sensitive information on unsecure file servers.
• Researchers working at NASA, NOAA, and other government agencies were under pressure not to release findings that contradicted the Bush Administration's policies on climate change, contraception, stem cell research, the state of the economy, and other issues.
• Historians at the University of Illinois found alterations in documents on the White House's web site that covered the early phase of the Gulf War.

And these are just recent examples. By no means is hanky-panky with government documents limited to periods when Republicans were in the White House. Nor are incidents limited to the executive branch, or even the federal level of US government. Rightly, Americans get upset when the government mishandles important information, no matter who does it.

Which brings us to Twitter and YouTube. Both of these outlets are fine for public officials to use, as long as there is no long-term danger to the integrity of the information itself. Again, we're talking about when it was communicated, what it included, and whether or not it changed.

Twitter and YouTube do not follow the guidelines that restrict how government organizations handle, preserve, and (when appropriate) destroy public documents. Through no one's bad intentions, US government information, from the GAO no less, might disappear from Twitter's and YouTube's servers. Someone might accidentally delete the information, or scrub it from the system during a clean-up of content that hasn't been accessed for a long time. (Like, say, a video from the GAO.) Obviously, the more the US government fails to maintain its own backups of this information, the worse the problem is.

How a government official uses social media is a big part of this week's news cycle. After Sarah Palin's resignation, she posted an explanation of her decision on her Facebook page, and she has been responding to critics on Twitter. She was already a fairly active user of both media, where she regularly spoke about issues that, because of ethics inquiries, have already landed in the courts, and may do so again.  Who, then, is responsible for the integrity of these communications?

Government should think creatively about how to reach citizens. While Twitter and YouTube are easy ways to reach a big audience, they also raise questions about the trade-off between popularity and reliability.

The Heretech, episode 12: Saeed Khan on the PM role

Saeed Khan of the "On Product Management" blog identifies the dangers of defining product management the wrong way. Plus, a quick review of some inspirational material about the political aspects of a PM's life. Copyright (c) 2009 Tom Grant

Not everyone is all a-Twitter

Cindy Alvarez makes a much-needed observation: Twitter is not self-evidently interesting or useful to everyone. The fact that 90% of Twitter content comes from 10% of Twitter users may not be a hard ceiling, so the real topic of her post is, "How might the proportion of Twitter contributors increase?" While you might not agree that the 90-10 rule is a problem that needs solving, it's important to remember, as a Twitter enthusiast or skeptic, that most Twitter users don't see the value in tweeting.

Cindy's best quote comes from the comments section of this post:

I think Twitter puts a bigger burden on the user to figure out “what do you want from this” and I think that’s fine - but it would be great if they had more exposure to “What are the possibilities? How are other people using this? What are other peoples’ strategies for learning or publishing here?

In case you're wondering, I'm Twitter-neutral. I use Twitter regularly, but I'm not fetishistic about it. It has value for me, but I can't imagine an argument that might convince the majority of my friends and relatives to tweet.

In fact, I think we're rapidly approaching "fatweegue." People are talking about Twitter too much. In some recent discussions I've attended, Twitter got such disproportionate attention that every other form of social media became the things-that-are-not-Twitter, mentioned in an aside.

In fact, when listening to future presentations on social media, I'm very, very tempted to offer the speaker a $20 bill to avoid all gratuitous mentions of Twitter. If you want Andrew Jackson to be your friend, it must be absolutely impossible to make your argument without mentioning Twitter.

Update: Tweetcraft, a Twitter plug-in for World of Warcraft, doesn't expand the Twitter market. It's the Venn diagram depicting the intersection between two groups of enthusiasts.

You're a PM poopyhead

Jim Holland draws some lessons for PMs from participating in a kindergarten class. I'll add one more similarity between PM and K-12 teaching: don't take the job unless, up front, the institution is ready to back your authority.

Product management and marketing mix it up

For people in product management and product marketing, organizational questions—for example, Where should we report? What specializations of the PM role seem to work?—are always high on the list of hot topics. That statement is true of this week's Heretech podcast, to be posted later today, in which Saeed Khan and I spend a good deal of the interview discussing these issues. It's also true of the research that I do, including a recent study that revealed some interesting results about the relationship between product management and product marketing.

A small chapter in a bigger story
Unfortunately, this latest research about these organizational questions puts me in a bit of a bind, since I'd like to share more of the results than I can.  Forrester always requires you to be a client to access our research, with minor exceptions. In the case of the just-finished study, "Best Practices For Product Management And Product Marketing Leaders," I'm really constrained. Members of the Forrester Leadership Board (FLB) for PMs asked us to do this study, which gets circulated among the FLB members, but not all Forrester clients. (It's one of the perks of FLB membership.) If there's a curtain between the general public and the typical Forrester research, there's yet another one between you, Dear Reader, and the FLB research.

Fortunately, we can always share a little bit of information from our research, even if we can't share everything. In this case, I'll share what we learned about one important organizational question: Should product managers and product marketers be part of the same department? Looking at successful PM teams, the answer is, Generally, yes.

What makes a successful team?
For this research, we deliberately picked successful PM leaders for our interviews. The adjective successful could mean a lot of things, and in our case, it meant...

• Tenure. The PM department heads whom we interviewed have been doing the job for at least a few years.

• Authority. These PM leaders handle important deliverables and activities, such as go-to-market strategy and product portfolio management.

• Accountability.  Along with real decision-making power over matters like product strategy, these PM groups bear responsibility for the business outcomes of these decisions.

In other words, you know you're successful when the company entrusts you with important things.

One group or two?
Since I started doing research on product management and product marketing, I've seen a lot of different organizational formulas. Sometimes, these two groups are separate. At other times, they're two sides of the same group. I've also seen these job functions broken down further, with the pieces scattered even more widely around the organization. We've also spoken with groups that have introduced new roles, such as solutions manager and community manager, that overlap with the product management and product marketing functions.

Therefore, when we reviewed our interviews for "Best Practices For Product Management And Product Marketing Leaders," we were genuinely surprised to discover that approximately 80% of our interviewees ran departments that combined product management and product marketing. That's a result worth italicizing.

These arrangements made sense, since product people look to the same information about business problems, use cases, personas, competitors, and other aspects of the market. This knowledge guides everything from broad-brush messaging to nitpicky feature/function priorities.

Of course, separating product managers and product marketers also makes sense. However, the habits of these highly successful PM leaders strongly imply that the unified department not only makes sense, but also works. There are lots of reasons why, including both external and internal ones. For example, if you're going to produce different content for different audiences—requirements for Development, demos for Marketing and Sales—that's ultimately based on the same customer and product knowledge, that process goes a lot more smoothly when you don't have two separate groups trying to stay in sync.

Two jobs, but what do you call the one department?
The success of the unified product management/product marketing model makes me wonder if there's a a good umbrella term for both of them. "Product professionals" doesn't quite do it for me, and we definitely don't want to confuse the two distinct functions, even if they wind up under the same management. I'm certainly open to suggestions.

[Cross-posted at The Forrester product management blog.]

Living in an Agile world

This short e-book by Steve Johnson, Rich Mironov, and Luke Hohmann nicely summarizes the issues for PM when the development team goes Agile.

The unbearable lightness of Bing

I'm trying really, really hard to get excited about Search Wars V: The Empire Strikes Back. You can't see or hear it, but trust me, I'm squeezing my eyes shut, furrowing my brow in conversation, and reciting the mantra of Why Search Matters. So far, no epiphanies.

Despite any lack of enthusiasm the general public may have in the Bing v. Google bout, the steady drumbeat of stories like "Bing Beats Google To The Punch, Launches Twitter Search" will continue. While I actually do have the occasional need to search Twitter content, I'm not likely to stop using Google as my default search engine any time soon.

So far, Bing just isn't compelling enough to make the switch. And how compelling can differences in search engines really be? Search is one of the most commoditized of all technology industry commodities, with few major leaps forward in the last several years. Sure, I care about the inclusion of new types of content. Adding Internet-available Word, PowerPoint, and Acrobat files made Google searches that much more useful. Occasionally, new capabilities in image search can help me find a picture that might be difficult, through words alone, to locate.

But, as of today, Bing and Google are too much alike to provoke me into making any new choices. Using lone wolf and cub as keywords, the web page results looked pretty much the same.  (Click here for Google, and here for Bing.)

Flipping over to the image search, I got an appreciation for Microsoft's slightly better hit results. You get more per page, and Bing hides the metadata until you mouse over the image. Clever, to be sure, but I bet that Google will provide some matching capabilities soon. (Click here for Google, and here for Bing.)

And when it came to video, Bing was less appealing. Mousing over the the video to play it in the thumbnail is kinda useful, but I'm usually pretty sure, from the single-frame preview, which video I want. (Click here for Google, and here for Bing.)

Obviously, it's a bit early to say for sure, one way or the other, if heightened competition will inspire new inventions in search technology. It'd be good if it did, since we've seen only marginal improvements in the last several years. So far, though, the epic battle is a bit of a yawner.

[P.S. My selection of lone wolf and cub as keywords wasn't completely random. I just watched the second movie in this iconic, over-the-top series about a former-shogun's-executioner-turned-assassin who pushes his infant son around medieval Japan in a baby carriage. So now you know at least part of what I did over the holiday weekend.]

Dupes duped by dupes

Could the planet-sized brains at Apple turn their mighty intellects toward the problem of duplicate iTunes library entries? I'm just saying...

The pirate who came in from the cold

Surely, a legitimate company's purchase of the Pirate Bay is one of the more twisted tech industry stories so far this year.

Open source is about more than just coding

I can't help myself. A small part of me really wants to see OpenOffice succeed. While it probably won't displace Microsoft Office in corporate America, there's the consumer, education, and government markets where OpenOffice might be a reasonable alternative.

So why, then, haven't people in these markets flocked to OpenOffice as a cheap Microsoft Office alternative? OpenOffice has been around for over a decade, so what's holding it back. Certainly, perceived quality has been one of the culprits.

Every once in a while, I try to be an OpenOffice user. And every time, I give up, just because the tools are too clunky. And I'm not the only one. Friends of mine who have worked at Sun, where using StarOffice (OpenOffice's progenitor) was mandatory, inevitably roll their eyes and groan whenever you mention either StarOffice or OpenOffice.

And then there's the other side of quality, technical issues like bugs and performance. You know, the sorts of problems that you don't really want to encounter in the productivity tools you use every day. As an open source project, however, OpenOffice is dependent on volunteers to test and fix bugs. All noble sentiments aside, that's not the best formula for a replacement for high-use, end user application.

When you read exchanges like this one on the OpenOffice QA forum, your optimism really fizzles out. Here's a sample quote from this discussion:

This Quality Management is (imo) the missing link. Nobody seems to be (or even willing to be) in charge of this...

So - we have a constantly growing number of bugs, developers who waste time to track those bugs down (while this was the task of QA) and QA  members, who get frustrated because bugs get not fixed (and lower their engagement within the project). I cannot help - but to me this seems as we have a problem.

Yikes.  And, as this 2005 article from the Guardian argues, it's not realistic to expect OpenOffice to ever get ahead of the quality curve.

Since 2005, other productivity suites, such as Zoho, have emerged. It's a shame that OpenOffice continues to sputter. (And, my doubts about the "5% of US Internet users" estimate aside, even 5% is hardly a major threat, especially after a decade of effort.)