What is RSS?

For those of you unfamiliar with "RSS" and "feeds", they refer to a way of subscribing to blogs and other information sources. By subscribing to feeds and using a feedreader, you can easily keep up to date with all of the blogs that interest you and read just the new entries that appear in them.

To subscribe to my blog and begin using a feedreader, do the following:

1. Click the orange "Feed" button at the top left corner of the page.
2. Click the "Subscribe with Bloglines" button at the top right corner of the page.
3. Click the "click here to register" link on the right side of the page.
4. Complete the registration process.

Or, simply click here and complete the registration process.

Since I began reading blogs using RSS feeds and a feedreader, I have doubled the information I read in a given amount of time. If you have any questions, feel free to send me an e-mail.

Google Roundup

Here is a roundup of my series on Google product management:

1. Google Product Management Series - An introduction to the series.
2. Google and Agile - How Google employs agile product management.
3. Google and Usability - How Google focuses on users and usability.
4. Google and Word of Mouth - How Google relies on word-of-mouth marketing.
5. Google and Focus - How Google is losing focus and jeopardizing its brand.
6. Gmail Delete Button, Revisited - A follow-up to an old entry on the existence of a delete button in Gmail.

Hope you enjoyed the series!

Gmail Delete Button, Revisited

On his ack/nak blog, Bob Corrigan wrote about how Gmail has at long last added a delete button so that you can delete e-mails you no longer want to keep. I've implied in the past that Gmail's lack of a delete button was actually the result of a great requirements insight.

However, so many users have demanded the delete button that Google finally added it to Gmail. It's an interesting case, though, because it's likely that the vast majority of users who clamored for it have no concrete and practical reason for it. For example, Corrigan doesn't claim that the unnecessary e-mail affects his ability to find wanted e-mails or have caused him to run out of storage space. Instead, he writes vaguely that he doesn't want unnecessary e-mails "in his stack" and even that he may be a little compulsive about it.

I do believe there are some practical reasons for the delete button, such as keeping e-mail from exes out of sight from current significant others who may have access to your e-mail. Nonetheless, in the end, Google had to accept that largely emotional (perhaps even irrational) factors affected the usability of their e-mail product.

No-Parking Signs

Last year I discovered an interesting tidbit about no-parking signs in Austin. When the city installs a new sign, they scratch the date of installation on the back of the sign.

This seemingly trivial fact helped me get several parking tickets dismissed.

I had found a legal parking space without a meter or sign across the street from my downtown loft. I parked my car there so that guests could use my reserved space in the parking garage. Since I mostly walk and ride the bus, I left my car parked on the street for a week or more.

One day I was walking home from the bank, and I noticed that there were several parking tickets on my windshield. I then noticed that they had installed a no-parking sign during the time my car had been parked there!

I went to court armed with a photograph of the back of the sign showing its date of installation, and the judge summarily dismissed the ticket.

Google and Focus

The single most important messaging principle, according to marketing guru Al Ries, is to "own" a word in the customer's mind. In my mind, Google stands for "search". While I use Google Local, Gmail, and Google News, I don't speak of "googling" my maps, "googling" my e-mail, or "googling" my news. I "google" - i.e. search for - keywords.

With the proliferation of new products, Google is losing its focus. It is trying to position itself more broadly as the "world's organizer of information", but that message is not as meaningful and precise as "search".

An article from the BBC discusses this issue and hints that Google may be at its peak.

Google and Word of Mouth

Evelyn Rodriguez' notes on Google product management barely mention it, but Google's marketing primarily consists of generating "network effects" (word of mouth). I don't think I've ever seen any conventional advertising for Google or for any of its products.

An example of a successful marketing program was for Google's web-based e-mail, called "Gmail". During the lengthy beta phase, and even to some extent now, you had to receive an invitation to sign up for Gmail. Google granted users a certain number of invitations that they could pass on to their friends and co-workers.

You might think that the best way to market a product is to make it as available as possible. Some reverse psychology comes into play, however. It quickly became somewhat of a status symbol to have a Gmail account, to the point that people were selling Gmail invitations on eBay.

Companies bombard prospective users with available products every day; why should a user consider trying a new product? If you hear about a product from someone you trust, you're much more likely to try it. You may also be intrigued if the product is somewhat "unavailable" to you, wondering if it must be so good that the company doesn't even need to make it readily available.

Google and Usability

Google doesn't just practice agile product development. The product management emphasizes users and usability in a variety of ways:

• Test marketing - Put early versions of the product in front of prospective customers and internal employees to determine and improve the usability and usefulness.
• Humility - Solicit ideas from anyone and everyone; don't assume you already have the answers.
• Observation - Examine what users actually do, whether the terminology in the product is understandable, and how efficient the user experience is.
• Defer other considerations - Worry about helping the user first, and how to profit from it later.

I'm not sure if I agree with the last approach. While it's to some extent true that you can usually find a way to profit from an extremely popular product (such as by placing ads on it), Google seems to have been somewhat lucky in this regard. With all of the products Google has developed - Gmail, Local, Groups, etc. - has any of them yielded income significant relative to what Google gets from Google AdWords on its search page and other people's sites?

Google and Agile

Does Google practice agile product management? Yes!

We see from Evelyn Rodriguez's notes that Google's product development process includes:

• Iteration - Quickly and repeatedly produce a working version of the product for review, improving it with each iteration.
• Experimentation - Work on high-risk products and "research" the market demand and requirements by releasing the products quickly for feedback.
• Expedient solutions - Initially favor simple, good-enough solutions over complexity or perfection.
• Small teams collocated with product manager - Form teams of three developers and one product manager. Scale up to larger projects by dividing large teams into smaller "modules".
• Sparse documentation - Document requirements and design, but don't spend too much time up front.

You may be able to glean an overarching theme from the practices above: the most reliable market understanding comes from putting real products in front of users. Keep in mind that these practices don't obviate the need for a product manager, as evidenced by the fact that Google has a product manager for every three product developers. You still need someone who:

1. Has the facilitation skills to elicit and interpret feedback from users.
2. Understands branding principles and how they influence product requirements.
3. Clearly distinguishes problems from solutions.
4. Champions the needs of the market.

We at Cauvin, Inc. practice agile product management.

Google Product Management Series

This entry marks the first in a series on product management at Google.

Evelyn Rodriguez attended a presentation back in January 8th, 2003 on product development and management at Google. Marissa Mayer, a product manager at Google, gave the presentation. Evelyn published her notes so that we can all benefit.

The notes are chock full of tidbits on how to release useful and reliable products quickly, how to ensure your products are easy to use, and how to cultivate innovation. In future entries, I will examine the strengths and weaknesses of Google's philosophies and practices.

Anthony Chen on the "Doneness" of Requirements

Tony Chen wrote Tuesday in Seilevel's Requirements Defined blog about when requirements are "done". I have written many times about how design, implementation, and testing inevitably lead to changes to the product's requirements. Tony touches on this phenomenon:

"We prefer a model that lets the phases of the development cycle overlap such that it effectively becomes an iterative model. Once a critical mass of requirements are complete enough that the technical team can begin making design decisions (typically 20-30% of the way into the overall requirements effort) the design phase begins. Our experience shows that there will always be some design issues that impact the requirements so it is better to work them out simultaneously rather than trying to perfect the requirements document in advance."

Tony is implicitly endorsing an agile product management approach, though I'm not sure he would want to use those words to describe it.

Shatner at his Silliest

If you thought you'd already seen William Shatner at his silliest, think again after you watch this clip of him performing Elton John's "Rocket Man". (Apparently, this segment aired in 1978, but I'd never seen it before.)

Google's Business Model

Mark Cuban appeared on CNBC the other day and succinctly described how Google makes money. He also pointed out a gaping technical hole in their business model that may jeopardize Google's earnings going forward.

According to Cuban, the vast majority of Google's revenue comes from Google AdWords. Google describes AdWords as follows:

"With Google AdWords you create your own ads, choose keywords to help us match your ads to your audience and pay only when someone clicks on them."

Owners and administrators of web sites can allocate space on their pages for Google to place the ads that advertisers create. They receive a portion of the revenue generated when someone clicks the advertising links. Google receives the rest of the "click revenue".

Cuban drew attention to the fact that competitors can game this system. I.e., a competitor to an advertiser can write an automated script that repeatedly "clicks" the link, thereby causing the advertiser to pay huge sums of money to Google for worthless clicks (clicks by a machine that will never purchase anything). If this problem becomes pervasive, companies will no longer want to advertise with Google, and Google's primary source of revenue will dry up.

More on Requirements Document Proliferation

Yesterday, I wrote about the proliferation of so-called requirements documents in some product development organizations. Cote added a comment that strikes at the diseased heart of what causes organizations to engage in this document proliferation. Be sure not only to check out his comment, but the entry on his blog that explains his thoughts in cogent detail.

MRDs, PRDs, FRSes, and SRSes

Another manifestation of this high and low level requirements business is the proliferation of different kinds of requirements documents. Let's review:

MRD - market requirements document (a.k.a. "marketing requirements document")
PRD - product requirements document
FRS - functional requirements specification (a.k.a. "feature requirements specification")
SRS - software requirements specification

Some organizations incorporate several of these kinds of documents in their product development process. But what are the differences among them?

Some people argue that MRDs are at a "higher level" than the other documents. I have argued that this high versus low level distinction makes little sense. But if you examine the terminology of these different kinds of documents, it reinforces the notion that there is a lot of confusion when it comes to requirements.

First of all, a requirement is a requirement; why would you have different documents describing the same thing?

Second, what is a "functional requirements specification"? Does it strip the nonfunctional requirements from the full requirements? Or does it somehow translate nonfunctional requirements into functional requirements, in which case it's really decomposing the requirements into design specifications? If so, why call it a "requirements" document?

Third, what could possibly be the difference between a market requirements document and a product requirements document? Shouldn't products be driven by market needs? Okay, sometimes the needs and constraints of stakeholders outside the market (e.g. internal stakeholders) should play a part. But shouldn't a single document capture the balance of needs, rather than two separate documents written by separate people?

In the final analysis, there may be some merit in some cases to producing different requirements documents. But I think that it mostly exemplifies the confusions about requirements - particularly the distinction between requirements and design.

It Matters How You Make Money

It may seem obvious, but it matters how you make money from your product. That is, when you are researching, defining, and developing your product, you can't dedicate all your effort to solving problems that your prospective customers face (no matter how urgent and pervasive those problems may be). If you want to make any money from your product, you have to formulate a profitable business model.

One key part of formulating your business model is understanding how your customers will pay. Sometimes your paying customers are users of the product; sometimes the "customers" are third parties such as advertisers or partners. Besides deciding on who will pay, you also must research them to understand:

1. How much they will pay. How much money do they have? How much money do they make? If confronted with a real buying scenario, will they pull the trigger?

2. How they will pay. Do they have access to on-line payment systems (e.g. PayPal)? Do they require CFO sign-off? Do they have and use credit cards? What do they use to pay for similar products?

As you can see, market research isn't just important for understanding users, but also for understanding the other stakeholders that play a role in the payment process.

Snap Decisions

Nature.com has a an article about the nearly instantaneous judgments people make when visiting web sites. Here are some of the most interesting points in the article:

1. Lasting impressions of your site come within the first 50 milliseconds of viewing it.
2. 60% of traffic to commercial web sites comes from search engines.
3. 'Ccognitive bias' plays a role in the lasting impact from initial impressions; visitors continue to use a web site to "prove" to themselves that their initial decision was right.
4. To be most effective, your web site should convey information in the simplest, quickest way possible.
5. A couple of corporate web site guidelines: put your company logo on the top right and a search box on the top left.

A product manager can help ensure that your marcom team (or outside web designers) take these lessons into consideration.

More on Prototypes

A couple of entries ago, I linked to a post by Seth Godin in which he argues that prototypes should be better than the finished product. Godin was referring to prototypes meant to impress (e.g. in a presentation to an investor). Obviously, if you are showing a prototype to prospective customers to get feedback on usability and requirements, you want the prototype to be as representative of the user experience as possible.

Rose Bowl Replay

Here is a video clip I shot from my balcony ten minutes after the end of the Rose Bowl. Of course, the streets in downtown Austin were completely empty just ten minutes beforehand.

Seth Godin on Prototypes

Seth Godin has some interesting thoughts on product prototypes in a recent blog entry:

"Too many times, I've gotten excited about an idea and created a conceptual prototype. And almost every time, people, smart people, didn't get it.

Here's my new prototype rule of thumb: your prototype has to be better (better build quality, faster interface, better lighting, whatever) than the finished product is going to be. That's what people expect anyway--they see your prototype and take off 20% for reality."

It seems counter-intuitive (or at least in some sense deceptive) to make your prototype better than your finished product, especially if you're a person who likes to set expectations low and over-deliver. But Godin may be onto something.

Michael Antman on Naming

In this MarketingProfs.com article, Michael Antman argues that the name you choose for your company and products can be a contentious decision but is not very important in the final analysis. He cites numerous examples of names that bear little or no relation to the company/product to make his case.

He argues forcefully and makes great points, but I think he may come to the wrong conclusion. It's true that many successful brands and products have names that are not descriptive, but that fact argues for the importance of nondescriptive naming as much as for the proposition that names are not important.

Kaden on Focus Groups

Robert Kaden has an article on MarketingProfs.com about market research. In the article, he wrote the following about focus groups:

Think about a two-hour focus group. Is this state-of-the-art? The moderator asks the questions and respondents to give their top-of-mind responses. At the end of the group, after all the moderator's probing and projective techniques are exhausted, marketers get their two hours' worth of information (or four, six, or eight hours when multiple groups are conducted). Usually, they think they've learned something. Mostly, they get the same superficial understanding of their brands and products that the competition gets in their focus group studies. No wonder so many brands look the same. They are all firing from the same gun!

In light of Susan Abbott's thoughts on focus groups, I am open to the idea that group synergy can somehow yield benefits that other research methods don't deliver. However, Kaden correctly points out that most focus groups yield only superficial information.

High and Low Level Requirements

I've seen some references in product management and requirements discussion forums about a supposed distinction between "high" and "low" level requirements. I have three main thoughts on this matter.

First, the distinction, if examined literally, doesn't seem to make sense. A user has certain problems she wants solved; requirements state the least stringent conditions that must hold to know that you've solved them. I don't consider problems as being either high level or low level, so why would there be "requirements levels"? Imagine saying to a user, "Oh, that's just a low level problem, so let's not worry about it now. I'm just documenting high level requirements." What?

Second, I believe the valid distinction is between requirements specifications and design specifications. If you specify user goals and constraints on those goals, you stay at a "high level", and you are documenting requirements. If you specify how the user will interact with the product in order to satisfy those goals and constraints, however, you are certainly getting into low-level details. But then you are specifying design, not requirements.

Third, both high and low level specifications are important. Denying that low-level specifications are requirements by no means diminishes their importance. It just helps to understand when you're doing requirements and when you're doing design. At Cauvin, Inc., specifying market requirements for a product is part of our product management services. We leave product design for design experts.

Bud Select

In a recent entry, Laura Ries ridicules Budweiser for brand extension, particularly its "Bud Select" brand:

"The other Budweiser extensions (Light, Dry, Ice) suggest flavor variations. Bud Select suggests that all the other flavors of Budweiser, the 'unselected' ones don’t measure up."

Any brand extension is already questionable, but when a new extension implicitly undermines existing brands, it's hard to see any justification for it.

Unreliable Answers

Seth Godin has an entry reinforcing the idea that the questions you want answered often aren't the questions you should ask.

Rose Bowl

I am a UT graduate and love to play (flag and touch) football, but I've never been a huge UT football fan. Nonetheless, Wednesday I hosted a Rose Bowl viewing party. I had a little over ten people over, and all enjoyed the excitement of the game. Even aside from the game itself, it was an interesting "downtown" experience. There were almost no cars on the street during or immediately after the game. However, we watched from the balcony of my downtown loft as the streets clogged with cars and people within minutes, with horns honking incessantly and lots of cheering. It was a fun night.

Embrace Hatred of Your Product

Rick Nobles has a great article on MarketingProfs.com about focus and branding. Nobles contends that hatred of your brand or product is often a sign that your marketing message is working:

"A brand trying to appeal to everyone isn't a brand at all, just a watered-down commodity. And a commodity never attracts a raving fan—it attracts indifference. In a crowded marketplace, indifference will kill you.

So don't fear the hate. Embrace it. Maybe in your next brainstorming meeting, don't ask how can you appeal to X. Ask how you can annoy the hell out of Y."

It's a worthwhile exercise: when formulating or evaluating your marketing messages, ask whether they will offend somebody or turn them off. If they won't, then you probably haven't focused your messages sufficiently.

Progress towards the "Everywhere Phone"

Recall that "convergence" is the notion that product categories tend to merge, and that "divergence" is the notion that product categories tend to divide into separate categories.

My take on convergence is that technologies tend to converge or combiine, but in a manner that creates new product categories. I have noted the "everywhere phone" as an example we may see in the future. An "everywhere phone" is a phone you can use anywhere there is a connection, whether that connection is over wires, wi-fi, or a cellular network. We're getting closer to seeing such a product now that wi-fi phones are coming out. An important future step will be the ability to seamlessly switch the medium during a phone conversation; e.g. switch from wi-fi to cellular within the same call.

Susan Abbott on Focus Groups

On her Customer Experience Crossroads blog, Susan Abbott writes about focus groups and other market research methods. She links to this piece in the New York Times pointing to a growing view that focus groups are not very effective. Abbott's take on the issue seems to be that focus groups often have limited effectiveness, but that in some situations they are useful.

Here are some key excerpts from Abbott's entry:

"The best surveys build on insights gathered using qualitative methods."

"[C]onsumers are not experts on their own consumption patterns. If you want consumption patterns, you get shopping data from AC Nielson or a competitor. Or you ask people to keep a consumption diary. You study your own sales data. There are many methods."

"The focus group was responsible for gazillions of insights that have improved all our lives in the past fifty years or so. However the term itself has become imprecise and almost meaningless outside the professional research community."

"The focus group is not the only tool, and not even the only tool available for qualitative insights. Just like a construction project, you need the right tool for the job. But even the right tool, in unskilled hands, will not build you a house."

I agree with Abbott, but I worry that executives are too quick to use focus groups to the exclusion of other methods.

Problems and Requirements

As usual, Pragmatic Marketing's Steve Johnson hits the nail on the head with some observations about product requirements. Here is but one excerpt:

"One more point about market facts: we're not interested in what features customers say they want as much as an articulation of problems they have. Customers will ask for more of the same while continuing to struggle with problems. Great product managers observe the problems and report them to development... in the form of requirements."

You have to ask, "Why?" to go beyond what customers say they want and to understand what problems to solve for them.

Solutions in Search of Problems

A frequent mistake in business is to take what seems like a great potential solution and fit a product around it. For example, you might develop, or learn about, some great technology, and then build a product around it. Unfortunately, no matter how promising the technology, your product won't be successful unless it solves real problems in the marketplace.

Yet there is something comforting when you have exclusive knowledge about a technology. It creates a barrier to entry; a product that depends on the technology may be immune to competition, at least for a time, if no one knows about the technology, or if it is difficult to learn.

So you shouldn't necessarily dismiss "cool" new technology merely because it is a "solution in search of a problem". But you have to make sure you understand the market for any product centered around it. You need to understand whether the product solves real problems, that the problems are pervasive enough to appeal to a sizable market, and that people will be willing to pay to solve them. Most important, you have to recognize that people probably don't care about the technology itself, just what it does for them.

Seth on Inertia

Seth Godin has a series of blog entries (here, here) about "inertia", which is my term for the reluctance of customers to try new things. I touched on this concept in my entry about predicting behavior. Inertia is most likely to be an issue with dormant problems.