Cauvin

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: Click the orange "Feed" button at the top left corner of the page. Click the "Subscribe with Bloglines" button at the top right corner of the page. Click the "click here to register" link on the right side of the page. 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.

Here is a roundup of my series on Google product management: Google Product Management Series - An introduction to the series. Google and Agile - How Google employs agile product management. Google and Usability - How Google focuses on users and usability. Google and Word of Mouth - How Google relies on word-of-mouth marketing. Google and Focus - How Google is losing focus and jeopardizing its brand. 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!

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

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.

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.

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

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

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

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.

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.

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

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

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.

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

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: 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? 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 a...

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: Lasting impressions of your site come within the first 50 milliseconds of viewing it. 60% of traffic to commercial web sites comes from search engines. '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. To be most effective, your web site should convey information in the simplest, quickest way possible. 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.

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.

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

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.

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

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

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.

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

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.

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.

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.

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

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.

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

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 .