Cauvin

When you think about it, New Year's Eve is just about the worst night of the year to go to bars. I live in downtown Austin and frequent the numerous bars that are within walking distance of my loft. But tonight I will studiously avoid them. I can go to bars any night of the year. If I can arrange to meet, or just bump into, friends, I'll usually have a good time. New Year's Eve is no different except: Bars that don't usually have a cover charge will stick you for $25 - $100 just to get in the door. There will be many more drunk people throwing up in the streets and getting into fights. The lines to get in the bars, and the waiting time to get drinks, will be longer than usual. Parking (which wouldn't affect me) will be difficult to find. I plan to go to some relatively low-key house parties instead.

Intel is planning to drop its "Intel Inside" branding effort. Intel has built a powerful brand by portraying their products as "powering", and being the "intelligence" within, computers and electronics. They are moving more into the consumer electronics space, but I'm not sure why they are dropping their simple and effective slogan. Perhaps consumers associate the slogan exclusively with computers? Or maybe it's the rebranding disease that Al Ries has mentioned?

On her Managing Product Development blog , Johanna Rothman wrote an entry about scheduling the implementation of mixed software/hardware products (hardware with software embedded in it). She recommends implementing a "pass" through the system as quickly as possible and iterating thereafter. In other words, instead of implementing a component at a time, implement just enough of each component to get a usable (if only for one usage scenario) product integrated and running. Don't develop the hardware and software independently and integrate at the end. Instead, integrate the hardware and software in an iterative or continuous fashion. This approach is consistent with agile development . I added a brief comment to her entry recommending that the product development team iterate on the requirements as well as the implementation. In other words, incorporate agile product management in the process.

An acqaintance of mine, Luke Hohmann , founded Enthiosys . The company consults with its clients to help develop successful product strategies and innovations. Cauvin, Inc. focuses on market understanding but leaves product design to others. One of Enthiosys's specialties, on the other hand, is innovation games . Innovation games are group activities that help a company design its products (though some of the games also help with uncovering customer needs). They resemble focus groups but are more imaginative and directed in their approach. Understanding the market for your product and formulating design-free requirements serves as a foundation for innovative solutions. That's our focus at Cauvin, Inc . To deliver, you also need expertise in the designing and innovating that builds on this foundation. If you're an executive looking for design help, don't hire us. But a company like Enthiosys might be able to help.

Up until about three years ago, I had never ridden city buses in Austin. About fifteen years ago, my friend P.K. asked me if I'd try riding the bus. I said, "Sure, it will be educational". It took me twelve years to finally get around to doing it. This sort of consumer behavior is common. You can't just ask someone what they will do and get reliable answers. Fortunately, skilled product managers are familiar with principles that apply generally to branding and market research. Certain kinds of product names work better than others. Certain kinds of survey questions result in more reliable responses than others. Anyway, for the past three years city buses have been my primary mode of transportation. P.K. probably will never know; I haven't seen her in thirteen years.

I recently proposed to a prospective client that I do a market study using three research methods: Market survey One-on-one interviews Silent Observation ( ethnography ) The first method is quantitative, and the second and third methods are qualitative (at least in the context I proposed). The expense of the study is an issue, so we explored ways of scoping back the project. I am a firm believer that quantitative and qualitative research methods complement and strengthen each other. It's hard to conduct a meaningful market survey without the benefit of some one-on-one interviews. It's also hard to understand the relative extent of problems uncovered in one-on-one interviews and ethnographic studies without a survey. I also think that, if you have conducted sufficient qualitative research, you can draw reliable (yet somewhat subjective) conclusions from surveys even without a "scientifically valid" sample of responses. Thus, in general, I believe it'...

Kathy Sierra has another great post on her Creating Passionate Users blog , this time shedding light on how difficult it can be to conduct reliable market research.

Most products are minor conveniences and have a negligible impact on your life. Others transform your life, breaking the patterns and routines to which you're accustomed. Here are some products that have transformed my life: Motorola mpx200 - mobile phone that runs the Windows Mobile OS. I rarely have a need for paper anymore. Whether it be contact information, directions, appointments, or grocery lists, I carry them with me on my phone (which synchronizes them with my computer). Google Desktop - software that enables Google searches of files and e-mails on your computer. Within seconds I can recall just about anything I've written or received electronically. Red leather sectional - for years, I had just a futon in the "living room" portion of my loft. With my red leather sectional, I can now entertain guests comfortably; watch TV comfortably without swiveling the TV towards my bed, and host business meetings at my loft. Rice cooker - I now almost always have a tu...

So if CRUD use cases don't belong in requirements documents, what use cases do you include in their place? First, I should reiterate that CRUD use cases may still be appropriate outside of a requirements document, such as in a design specification. As I've mentioned , once a use case author begins fleshing out text use cases with steps, she is engaging in design, anyway. Second, when a product manager is tempted to include CRUD in a requirements document, he should instead specify the user's larger goal. Presumably, information somehow needs to get into the system and stay up to date. Why? What does having that information enable the system to do for the user? An example of a larger goal is Generate Periodic Financial Reports. In that example, the user doesn't want to enter information; she just wants her reports! The product manager still has to capture nonfunctional requirements relating to the accuracy and timeliness of information in the system. A useful appr...

When documenting use cases for a software product, some product managers specify ones such as: C reate Employee R etrieve Employee U pdate Employee D elete Employee Such functions are called " CRUD " use cases. If your product manager is specifying CRUD use cases in market requirements documents, your product manager probably doesn't understand requirements. Recall that use cases represent functional requirements insofar as they convey user goals. In the example above, users enter and view information about employees. But what is the user's goal? Why on Earth would anyone want to enter information about an employee? Users actually don't want to enter such information . The user wants the information to be accurate and up to date and probably to be able to examine it. But creating, updating, and deleting employees is a burden to the user. A fantasy solution would obviate the need for the user to enter such information. Therefore, the Create Employee, U...

We've all experienced problems with starting meetings on time. Consider this passage from one of my favorite facilitation books, How to Make Meetings Work : The only way meetings are going to start on time is by starting them on time. Waiting five minutes at one meeting will lead to a ten-minute delay the next. And pretty soon everybody will be timing their arrival according to their personal estimates of when the meeting really will begin. If you start meetings on time, people will get the idea that when you say ten-thirty, you mean ten-thirty and not ten-forty-five. (If it's ten-thirty and only a few people have arrived, let them decide when to begin the meeting. Maybe they will think it's a waste of time to begin before certain other members are present.) The book also describes some specific approaches to dealing with latecomers.

Does your product manager "test" the product requirements she specifies? No, I'm not asking about testing the product, I'm asking about testing the requirements for the product. What is "requirements testing"? Requirements testing is a way to assess the clarity and completeness of product requirements by conducting thought experiments. These thought experiments sometimes expose ambiguity or oversights in the requirements. Types of requirements testing include: Walk through product usage scenarios . While mentally walking through usage scenarios , ask yourself whether you could satisfy all the documented requirements yet still end up with a frustrated user. Design a product test. Imagine how you would test the product to determine whether it satisfies the requirement. Keep in mind the distinction between testability in principle and testability in practice . Even if it's not practical to directly test whether the product satisfies the requir...

Over a month ago, Jerry Aubin wrote an entry in Seilevel's Requirements Defined blog about my contention that organizations tend to overemphasize functional requirements . I have to admit that I wasn't entirely clear about this topic. See the comments section of Jerry's post for a clarification.

I alluded to this gem in a previous entry : "If a programmer is indispensable, get rid of him as quickly as possible." Gerald Weinberg wrote these words in The Psychology of Computer Programming , published in 1971. It singles out programmers, but it probably applies outside of the software realm and to many other roles on a product development team. In a 1998 interview , he elaborated: "Over and over I've seen organizations suffer enormous costs when something tragic happened to an 'indispensable' programmer, or when that programmer started making demands because management 'couldn't do without him' (or sometimes her). The lesson is elementary risk management—which unfortunately many organizations still don't practice. To reduce this risk, you don't have to actually get rid of the programmer, but you do have to get rid of the indispensability." Weinberg is one of my favorite authors on leadership and facilitation.

One of my favorite experiences is to go out on the balcony of my downtown loft , sit down, and drink Promised Land Milk . The milk comes from hormone-free cows, and Promised Land offers several different flavors. The strawberry and chocolate milk are very rich; they almost taste like melted ice cream.

Most products have some sort of documentation or user manual. Is it appropriate to include in product requirements specifications about the content of such documentation? Is there such a thing as documentation requirements? You certainly can specify documentation requirements. Keep in mind, however, that when you do so, you may not be paying sufficient attention to what really matters to the user. (And there's some question as to whether you properly can even call such specifications "requirements".) This issue is almost identical to whether you should document support requirements separately, or whether support is part of your product . Ideally, a product would have no documentation whatsoever. Documentation only benefits the user insofar as it decreases the learning curve and amount of effort it takes to use the product on an ongoing basis. A holistic view of the product treats documentation, training, and support as part of the product. When you treat the prod...

Check out Scott Sehlhorst's recent entry on his Tyner Blain blog . He touches on the all-important need for a requirements analyst to ask, "Why?" Tony Chen, President of Seilevel , contributed a comment in which he introduced the concept of the "rationale" for a requirement. See the comments section of the entry to see the discussion unfolding about the meanings of "requirement", "rationale", and "design".

With exposure to some of the traditional branding companies, I've noticed a problem with inward branding . When you decide on a strategy to shape your company's image, you want the image to be one that resonates in the marketplace and ultimately yields profits. But what should your image be? How do you go about deciding what the image should be? Some market strategy companies work with the management of the company to align the company's image with the management's personality. I recently interacted with a market strategy company on branding and found that they did a good job facilitating a dialog with the founders of the company. The founders enjoyed talking about themselves and envisioning the company's image reflecting their personalities. Yet the bottom line is what will resonate with customers. If your strategists focus mostly on the company, rather than on the customers, you are dealing with The Uninformed Strategist . The branding such strategists recom...

Sam Decker touches on remarkability in a recent entry on his Decker Marketing blog . If you are too "pushy" in your sales and marketing, he writes, you fail to create intrigue . Intrigue about your company or product tends to stimulate interest and generate word of mouth. It struck me that the problems with offering discounts relate to intrigue, or lack thereof. When you offer discounts, you may initially generate some word of mouth. Unfortunately, you also undermine any intrigue your product may have, because offering discounts (or at least publicizing them) is being "pushy".

Al Ries's most recent column  in AdAge.com touches on the notion of contradicting instincts . Most people, including executives, consider much of marketing to be common sense. We're all consumers, so we all know how we respond to products, names, logos, advertisements, and PR, right? So we're all experts on what works in marketing, no? Actually, psychology tells us that there's a lot we fail to perceive about ourselves, and that a lot of what we perceive about ourselves is skewed. We have a lot of "blind spots". And it's obvious that what works with us doesn't necessarily work with others. So the notion that we're all experts on marketing by virtue of our extensive experience as consumers is flawed. Here's the money quote from Ries's article: "When management has a marketing problem, it turns to its marketing department and says, 'We’ll do it my way because marketing is just common sense.' And no one has more common se...

Johanna Rothman has a recent entry on making processes independent of people. I almost cringed when I read it. I do agree that you want to avoid a situation in which any particular person on a team becomes indispensable. (In fact, Gerald Weinberg recommends firing a person who is supposedly indispensable. More on that recommendation in a future entry.) But the most efficient and effective processes are those that leverage the unique mix of skills that exist on a team at any particular time. You lose that advantage when you make processes completely independent of people.

"Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." - George S. Patton

A few friends and colleagues have linked to Evan William's Ten Rules for Web Startups . My initial reaction was to ignore the link, but eventually I got around to reading them. I was pleasantly surprised to find this gem about descriptive naming : "Get a good, non-generic name. Easier said than done, granted. But the most common mistake in naming is trying to be too descriptive, which leads to lots of hard-to-distinguish names." The reason I keep harping on this point is that Evan is right - the tendency to choose descriptive names for a product or company is one of the hardest instincts to overcome .

On his FusionBrand blog , Nick Wreden writes that Al and Laura Ries's book The 22 Immutable Laws of Branding has a "dumb branding title", because the laws of branding are not immutable. Well, I suppose he's right, strictly speaking. It's definitely a bold claim to describe 22 laws and pronounce them immutable. What I think Nick neglects to recognize or acknowledge, however, is the Rieses' point that new generations of marketers tend to repeat the mistakes of the past. As I've mentioned, much of what product managers do is recommend marketing strategies that contradict natural instincts . So it shouldn't be a surprise that the community of marketing experts needs to firmly remind the novices that it's not "different this time".

An article by Robert R. Johnson in CMO Magazine supports my contention that product revenue is not a reliable metric for evaluating a product manager's perfomance . The article makes a number of points beyond what I've mentioned, including the fact that it's difficult to trace long-term increases in product revenue back to original strategy recommendations. Nonetheless, at least for strategic marketing activities, I'm highly skeptical about Johnson's suggestion that we can decompose marketing initiatives and measure their success in isolation. Indeed, Chris Lynn comments: "Viewing a marketing initiative in isolation or as a component of a greater whole do not represent mutually-exclusive alternatives." Hat tip to Steve Johnson on the productmarketing.com blog .

Some of you may protest that I'm going too far with keeping requirements solution-free, but . . . . The internal monitor on my laptop computer stopped working, so I've been using an external monitor at 1024 x 768 resolution. I am used to 1600 x 1200 resolution. I noticed how much it affected my productivity and my overall frustration level. The realistic solution to my problem is probably to get my original screen fixed or buy another laptop with a high resolution screen. But what's the underlying problem ? And what's the requirement ? I would argue that the requirement is not to get a screen with a certain resolution. Indeed, if I could have a much smaller laptop and not suffer from any of the resulting inconveniences, I'd be even happier. The problems are the increased frustration and lower productivity. So the requirements should include a set of ease-of-use constraints on usage of the computer. It just so happens that getting a laptop with a high-resolution...

Interesting recommendation from The 22 Immutable Laws of Branding : In "the law of the shape", Al Ries and Laura Ries recommend that the logotype for a brand be "designed to fit the eyes". The ideal aspect ratio, they argue, is for the logotype or brand symbol to be 2 1/2 times as wide as it is high.

John Moore has blogged about what he calls the " Law of Remarkability ". It refers to Seth Godin 's theme and states that "remarkable things get remarked about". Word-of-mouth marketing is the rage these days as we've experienced The Fall of Advertising and the Rise of PR . You're off to a great start marketing your product (or, more accurately, stimulating your customers to market your product for you) if you put something remarkable in your product.

For those Austinites who don't already know, I am now on Dodgeball . Dodgeball is a text messaging service that enables you to conveniently share your location with your friends.

Another good MarketingProfs.com article . This one touches on the issue of selling technical products to decision makers who are not technical. I've touched on this subject in my posts about low-hanging buyers and buyer tension .

Bob Kaden has a spot-on article on MarketingProfs.com about how companies underestimate the value of market research.

Jeff Schneider makes a good point in his latest blog entry . If your "product" is software that your company uses as infrastructure to build other software systems, you need to consider the entire portfolio of systems when determining the requirements for the infrastructure.

I've mentioned use cases on a number of occasions, but equally important is the concept of scenarios . A use case is a sequence of interactions that the user makes with the product to achieve a goal. Think of a use case as encompassing any number of scenarios. A scenario is specific instance of a use case with a very specific goal. For example, if your product is a car, one use case for the product would probably be Drive Car. The Drive Car use case encompasses infinitely many specific scenarios, including one in which a customer drives the car from her home to the Walmart on the other side of town. All of the specific circumstances are part of the scenario, including how fast she drives, how many stop lights she encounters, etc. Thinking about (and actually testing) scenarios gives your team a concrete and tangible idea of what your customers will experience when they use your product. It also forces your team, particularly the product manager, to consider what scenarios th...

Seth Godin has some interesting thoughts about home pages . The main thrust of his entry is that successful home pages are rare, because they try to strike a nearly impossible balance between: 1, Explaining to the uninitiated. 2. Retraining the veterans. 3. Getting out of the way of the power users. Godin recommends finding ways of avoiding having users go through home pages. When Squidoo comes out of beta, perhaps we'll see what he means.

I will be taking Thanksgiving and the weekend off from blogging. I will resume blog posting Monday.

As I mentioned yesterday , you should include customer support in your product's use cases . You should include in product requirements constraints on these use cases . Some constraints will likely specify the maximum amount of time and effort it should take a user to carry out the use cases . The amount of time and effort should encompass the user's possibly resorting to contacting customer support. Consequently, the corresponding tests your team creates for your product should also encompass customer support. Lay out key usage scenarios that are likely to stimulate the user's need for customer support and walk through not just the direct usage of the product, but also the support calls the customer will make.

Your product is valuable only insofar as it solves, and doesn't create, problems for customers. It's nice when your product is so easy to use, and so robust, that customers never have to call on anyone for help or support. Such products are rare, however. Given that customers will need support when they use your product to solve their problems, support is part of the customer experience. Support is not a goal in itself, however. Assume that your product's existing use cases and constraints will encompass calls to customer support.

Recall that: "Dormant problems are those of which your customers are not aware, and to which they will be oblivious until you present them with a new way of doing things." Not only do customers suffer from an inability to recognize dormant problems, industry experts are often unaware of them as well. An industry expert typically is entrenched in existing ways of doing things, and therefore can easily be the victim of tunnel vision. If you are an executive who believes that your company has all of the industry expertise it needs in-house, think again. It may be that the fresh perspective of a product manager skilled at uncovering the needs of customers - but not necessarily possessing significant industry experience - will reveal prospect problems you never considered.

When I bought my condo in downtown Austin, the sales agent identified himself as the person "marketing" the building. Was he doing market research? No. Was he formulating key messages for marketing programs? Well, a little bit. Was he producing brochures and other collateral? No. It seems to me that some people like to say they are in "marketing" even if they're really salespeople. (Not that there's anything wrong with being in sales.)

Fans of the game Sudoku may enjoy the site my friend Rayfes shared with me today. You can choose among varying levels of difficulty, and you can configure it so that you can use the grid as a sort of scratchpad to apply whichever system you wish to solve it.

Good excerpts from Ries and Trout's The 22 Immutable Laws of Marketing : The target is not the market. That is, the apparent target of your marketing is not the same as the people who will actually buy your product. The target of Marlboro advertising is the cowboy, but the market is everybody. Do you know how many cowboys are left in America? Very few. (They've all been smoking Marlboros.) These excerpts come from "The Law of Sacrifice" chapter. Typically, your best marketing strategy is to focus on a narrow segment of the market. Ironically, if you select the segment carefully, you may end up having a much broader appeal than if you try to be all things to everyone.

Al Ries has an article  in AdAge about rebranding efforts. The gist of the article is that advertising agencies have a natural tendency to, and vested interest in, rebranding your company. Excerpts: "What leads cities, states, countries and companies to concoct meaningless, unmemorable slogans? I believe the culprit is 'creativity.'" "Every day of the week, advertising agencies are hired to create new, compelling branding strategies and fired when these new, compelling branding strategies don’t work." "[Y]ou can’t win an advertising award with a campaign that is not new and different." When you hire an ad agency, they want to justify themselves by coming up with a new image for your company. If they trot out the same old slogans, they are limited in how creative and different their ad campaign can be. You're often much better off staying consistent with your established brand.

I've mentioned several times that it's best to choose brand names that are not descriptive of the product. Besides citing an article on a scientific study, I haven't explained why descriptive names are generally inferior. The main reasons stem from a concept mentioned in the article: incongruency (also known as incongruity ). Consider an excerpt from the article: "The researchers also wanted to examine the effect of these product names in connection with incongruency theory. This theory argues that people make judgments by evaluating new encounters against existing expectations. When encounters are incongruent with prior expectations, individuals put in more effort to resolve the incongruency." When you choose a descriptive name for a product, you miss an opportunity to engage the customer when she is confronted with the name. If, on the other hand, your product's name has nothing to do with the product, you create incongruency in the customer's mi...

BusinessWeek has an interesting article about how traditional focus group studies have fallen out of favor. Noteworthy excerpt: "Some of the new solutions displacing focus groups don't rely on consumers to sort through their feelings at all. Instead, companies get more useful feedback just from watching daily life."

More than five years ago, I worked at a software consulting company. One of my colleagues was an excellent facilitator. Let's call him "Ron". One of our clients was, in the estimation of most of my co-workers, a very tough customer. Let's call him "Jack". It seemed it was always Jack's way, or the highway. At one meeting, we proposed a way to solve a problem the client was having. Jack, in categorical terms, rejected the proposed solution. My colleagues heads sagged as it was obvious what was going through all of our heads, "There is no way we can change Jack's mind." However, within five minutes, Ron had Jack enthusiastically endorsing the proposal and treating it as if were his own idea. I can't even remember what Ron asked and said to change Jack's mind, but the experience left me with the realization that facilitation is a powerful and grossly underestimated tool.

Peter Drucker died Friday at the age of 95. Drucker was a leading authority on how to recognize market opportunities and systematically take advantage of them. One of the key insights I learned from reading one of his books, Innovation and Entrepreneurship , is that disruptive technology is just one among many sources of innovation. Drucker maintains that entrepreneurial companies can reduce risk by pursuing opportunities purposefully and systematically. For company executives, the significance of Drucker's insight is that creative ideas are only a very small part of a successful venture. You need to conduct market research to identify opportunities, and there is a scientific approach to this market research.

Last night, I was spending time with friends at one of my favorite downtown Austin hangouts, Kenichi. Since it opened a few years ago, it has generally been one of the trendier restaurant/bars in Austin. It's a good place to go if you want to observe fashion trends. I've mentioned that a "uniform" seems to be in fashion for men at any particular time, whereas women's clothing trends are more varied. I noticed last night that many of the women had sequins on their clothing. Sequins seem to be the rage in women's fashion.

On MarketingProfs.com , Meryl K. Evans and Hank Stroll write about designing your web site to convert visitors into buyers. Based on reader input, one of the guidelines they suggest: Provide needed information within three clicks (and respond quickly to questions). You can think of the three-click rule as an ease of use requirement on your web site.

One of my favorite requirements stories is from the Practical Product Management class that Pragmatic Marketing's Barbara Nelson teaches. She broached a brief discussion on requirements , and the issue of user interface requirements somehow came up. Students in the class disagreed over whether it was appropriate to include user interface design details in market requirements . One of the students confidently stated, "If the customer tells me he wants the button to be blue, then that's the requirement. Period." The student thereby boiled two important issues down to one statement: 1. Is a user interface design detail a requirement? 2. Should a requirements analyst passively accept customer specifications? Readers of my blog know that I answer "no" to both of these questions. The requirements analyst should ask, "Why? " I.e. what problem will the blue button will solve? The process is actively facilitative and gets beyond design d...

I was doing some weight training a few minutes ago and had the TV on. I watched an advertisement for Kyocera Mita; the company sells printers, copiers, and fax machines. Kyocera Mita has a major campaign marketing their products as "people friendly". I don't know whether they found the right message. I also don't know whether their products are truly easy to use. But I am impressed with their marketing campaign, because it seems focused and consistent. The music, the smiles on the faces of business people, the tag line, and just about everything else about their advertisements conveys the ease of use message.

I've mentioned before that one of the best ways of understanding the market for your product is to conduct one-on-one interviews with prospective customers. How a product manager facilitates this discussion is critical to obtaining useful information. One reason facilitation is so important is that prospects often want to give you advice or tell you what the market wants. The purpose of an interview, however, is to understand what the prospect needs, not to find out what the prospect believes the market wants. So one aspect of facilitation is steering the discussion so that the prospect tells you about her situation and the problems she faces. A prospect is an expert on her situation and problems, not other people's situations and problems.

Here is a passage from page 51 of the classic book, Exploring Requirements , by Gause and Weinberg: [A] university dean said, "We need a way to attract more students." The dean never said why they needed more students, and each faculty member hearing the statement formed a different idea. Some thought "more students" meant getting more outstanding students. Some thought "more students" meant being able to support more teaching assistants in certain departments. Still others thought "more students" meant the dean wanting to fill the vacant dormitory space. After arguing for months about the best way to get more students, the faculty finally learned what the dean really wanted: to create the impression in the state legislature that the school was doing a higher quality job by increasing the rejection rate of applicants , so the university appropriation would increase. Once this goal was understood, the faculty approached a solution in several ways...

Jennifer Rice has another thought-provoking entry in her What's Your Brand Mantra? blog , this time about positioning and customer perceptions. I read her blog regularly but didn't notice until today that she's a fellow University of Texas graduate. Anyway, the entry touches on different ways of interacting with customers to understand their perceptions and what messages will resonate with them.

You Passed 8th Grade Math Congratulations, you got 10/10 correct! Could You Pass 8th Grade Math?

Jennifer Rice has a recent entry in her What's Your Brand Mantra? blog about naming. She suggests a process of mapping names to product or company benefits. Naming is funny because everyone thinks they're an expert on it, but few people actually have any real expertise. As far as I can tell, almost all of the real authorities agree - Al Ries, Laura Ries, Seth Godin, Barbara Kahn, Elizabeth Miller, to name a few - that you should generally avoid descriptive names . Names that bear no relation to the company, product, or attributes are often best. You want the name to be a blank slate so that branding creates the meaning over time. For this reason, the approach of mapping names to benefits doesn't make much sense to me. The whole point of marketing is to create such a mapping, preferably where none already exists.

A common mistake in companies is to target "buyers" who have no actual authority to buy. With a complex business-to-business sale, for example, the customer stakeholders who are most enthusiastic about, or familiar with, about your products often don't make the purchasing decision. It's tempting to sell to people who already understand your product and what it can do for them. In some cases, the people who understand your product's benefits are the ones who will use your product. In other cases, it's IT people at the customer site who are developing internal solutions similar to your product. Unfortunately, your prospective customer's receptionist, though he may use the product, probably doesn't have the authority to purchase it. Your customer's IT people may understand what your product does, but they often are competitors, not buyers . Don't be lazy. Sales and marketing is about educating the stakeholders who have the authority to buy,...

In yesterday's entry , I listed some factors that can indicate an organization's excessive emphasis on functional requirements . I also mentioned that this overemphasis has a negative impact on product development. Why? The overarching reason that overemphasis on functional requirements negatively impacts development is that it shows the product manager dipped into design and failed to document true requirements . For example, a skilled requirements analyst might specify an ease of use constraint as a limit on the number of user gestures it should take for a user to accomplish a functional goal. A product manager who dips into design might instead describe a user interface, couching the description in a series of functional specifications. By dipping into design, the requirements analyst has lost sight of the underlying problem the product is supposed to solve or avoid. In the example, she has lost sight of the metric that determines whether the product is easy enoug...

I've mentioned before that there are two kinds of requirements , functional and nonfunctional . What I didn't mention is that most organizations place too much emphasis on functional requirements . How can you tell if your organization overemphasizes functional requirements? If your organization bothers to document requirements (whether in an MRD or other document), examine them. If you find any of the following statements apply, then your organization probably is overemphasizing functional requirements: Is there a laundry list of product features ? Are there more use cases than constraints on the use cases? Is there a multi-page section labeled "functional requirements"? If any of these statements apply in your case, then your organization likely fails to understand the difference between functional and nonfunctional requirements. In a future entry, I will explain why the overemphasis on functional requirements has a negative impact on product development...

One of my clients recently hired a marketing firm to help execute the strategies that Cauvin, Inc. recommended. The firm distributed a questionnaire to my client. In turn, my client had each of his partners and employees answer the questionnaire. I initially was slightly irked that the marketing firm had ignored the extensive market analysis we provided to them. The market analysis already addressed all of the questions in the questionnaire. Why should we have to answer the questions again? My client remarked that it would be useful to fill out the questionnaire anyway. When I thought about it, I realized he was right. Seeing how he, his partners, and his employees answer the questionnaire will reveal whether they understand and buy into the strategy I've recommended. It seems that this sort of "test" is a good idea for all product teams. It enables you to measure the extent to which your employees understand the vision and are on the same page. That way you can ...

On her Creating Passionate Users blog , Kathy Sierra has another good entry . This time she contrasts old marketing techniques with new ones. My favorite is where she contrasts focus groups (old way) with ethnographic learning (new way).

Living in downtown Austin and observing the patrons of the numerous bars here, I've come to the conclusion that fashion is easy for males. In any fashion era, the males who go to the trendy bars tend to wear the same outfits. Sometimes, it's almost as if there is a "uniform" that they wear, with perhaps some variations on it. You can usually go to Gap or Express and find the uniform. I think the uniformity of it is silly, but I've come to accept it. For females, it doesn't seem as simple. There doesn't seem to be a "uniform"; originality consistently seems to be a bit more trendy than a single style.

Recall the second question I promised to answer: "How do you determine the 'negative price' of a service?" Negative pricing is a technique by which you base the price of a product or service on how much it costs for the customer not to use it. How do you go about determining how much it costs for a customer not to use a service? Your prospective customers have a current way of doing things that will change when they use your service. Clearly define the problems that these prospective customers face in their current situation. Detail the effects and implications of these problems. Quantify the effects in terms of monetary cost. You may have to define conversion factors that enable you to convert, for example, time to money. Add up the costs, and you have the negative price of your service. Obviously, this process is not an exact science. Trying to assign a monetary value to a customer's time or happiness is difficult. But the point is that your service...

I promised yesterday that I'd tackle a couple of questions posted in a comment . The first question was, "How do you determine what questions to include in a survey?" Well, that's of course a complicated question that depends on the product, the market, and situation. However, as I've noted previously, the questions you want answered often aren't the questions you should include in a survey. The reason is response bias . In addition to some of the traditional advice for avoiding response bias , keep in mind that: The most interesting findings often come from correlating responses to more than one question. Including one or more open-ended (fill-in-the-blank or essay) questions allows for unanticipated answers and findings. You will cause respondents to answer randomly or systematically if you include too many questions in your survey. No matter how much you want them answered, it's pointless asking questions to which your respondents don't kn...

Commenting on an entry I wrote last month, "Sandra" asks: "So, how does one determine what question belongs in a survey and one that doesn't and how does one determine the 'negative price' of a service?" That's two questions: How do you determine what questions to include in a survey? How do you determine the "negative price" of a service? The answers to both questions are complicated, but I will do my best to tackle them over the next two days.

Back in April, one of the recommendations I made to a client was to name its product "Cubit". A cubit is a unit of measurement equal to 45.72 centimeters. But the primary reason for choosing the name was that very few people have ever heard or seen the word. We brainstormed over a hundred names and rated them on predetermined criteria. Then we took the top 25 rated names and came to a grudging consensus on the name "Cubit". Since then, almost every time one of us tells someone the name of the product, they ask, "Why did you name it 'Cubit' "? At first, this reaction disturbed my client. Six months later, my client recognizes that this reaction may actually be a positive sign. Indeed, I've referred to scientific studies showing consumers react positively to imaginative names. You want to pique the consumer's curiousity. You're in a battle for his mind, and you won't win if you fail to engage it.

Kathy Sierra has a great post about the way great concepts get watered down during the product development process. It's true that practical realities necessarily affect the viability of a product, and whether product requirements are possible to implement. Yet sometimes it's a lack of creativity and determination that cause great concept products to fail.

Over the years, I've had good luck selling used items over the Internet. I've never taken out a classified ad in a newspaper, but I've posted messages to the austin.forsale newsgroup many times. Sometimes I have to persistent, reposting the messages several times over the course a month, but I have always been able to sell the items I've advertised.

To benefit the company, it's not enough for a product manager to understand the market and specify product requirements and marketing strategies. The product team (designers, developers, marcom, and sales) have to live and breathe the market understanding. You might, for example, hand a positioning and messaging document to marcom so that they know the key messages to include in brochures and to highlight in all of their PR efforts. What happens, unfortunately, is that marcom quickly forgets the recommendations and inserts their own content. Being an effective "messenger for the market" requires you to communicate on a regular basis with your team members. It means one-on-one meetings with members in which you build consensus for your recommendations. It means presentations in which you present and discuss your recommendations instead of just handing people documents.

Yesterday I posted a link to the AustinPMMForum, a Yahoo group for Austin product management and marketing professionals: http://finance.groups.yahoo.com/group/AustinPMMForum The group's moderator, Bjorn Aannestad, recently led a session (which I unfortunately did not attend) on the topic of measuring a product manager's performance. His presentation included PowerPoint slides that included some of the material from this blog . He graciously credited me and this blog for that material. Thanks, Bjorn! Members of the site can log in on the web and go to the Files section of the group to access the presentation. The file name is 'PdM Performance 051012.ppt'.

Austin product management and market professionals have a Yahoo group: http://finance.groups.yahoo.com/group/AustinPMMForum Here are the first few sentences of the group's description: This peer group is composed of Product Marketing Management Professionals in Austin, Texas who are delivering technology-based products to any market space. The goal of the group is to provide a structured learning and networking opportunity by addressing topics faced by Product Management and Product Marketing professionals in a collaborative setting. The group's members have meetings from time to time.

I just finished skimming through a study guide for the Project Management Institute's (PMI) Project Management Professional and Certified Associate in Project Management exams. They are certification exams for project managers. Mind you, project management differs greatly from product management, but there is some overlap. What a scam! One of the first things the study guide states is that "you cannot rely on real-world experience" to pass the exam. You have to buy expensive study guides and/or take expensive training courses to prepare yourself for the exam. I would venture to say you could be the greatest project manager in the world and still fail the exam. It seems that this sort of BS is typical of certifications .

Apparently, I wasn't clear in my recent entry about using market research to enhance the credibility of business plans . Merely attaching a market research report to a business plan doesn't add much, if any, credibility. The author of the business plan has to base it on the research. In particular, the results of market research should shape the following sections of the business plan: 1. Pro forma. Market size projections and price assumptions should come from, or at least be validated by, research. 2. Marketing plan. Buyer profiles and messaging recommendations should feed into the marketing plan. 3. Product description. Market research should drive the definition of the product. Thanks to "mark" for raising this issue.

Seth Godin writes a long entry in his blog about naming products and companies. First, he reiterates his opinion that descriptive names make poor brand names: "It quickly became clear, though, that descriptive names were too generic, so the goal was to coin a defensible word that could acquire secondary meaning and that you could own for the ages. That's why 'Jet Blue' is a much better name than 'Southwest' and why 'Starbucks' is so much better than 'Dunkin Donuts'." "The entire point of 'secondary meaning' is that the first meaning doesn't matter at all (especially since you picked a name with no meaning to begin with). Over time, a surprisingly short time, your unique word, especially if it sounds right, will soon be the one and only word." Then, he lays out new guidelines: "Find a name that came up with close to zero Google matches." "The structure of the words, the way they sound, the memes t...

Check out this interesting optical illusion .

One of Cauvin, Inc. 's current clients is a start-up. The founder of the company writes business plans for a living, so naturally he wrote the business plan for his company. A key reason for hiring us was to give credibility to the overall business plan. We conducted a market analysis and provided him with a report, which he attached to the business plan. A business plan that doesn't base its premises on solid market research does little more than speculate about: How the company should market the product The size of the market for the product What the product should do If you're a CEO, one of your responsibilities may be to pitch the story about your company's products to investors. You'll have a lot more credibility, and have a more convincing story, if you have solid market research to back it up.

If you've been reading this blog for a while, you probably know by now that I consider Al Ries to be the master of positioning and strategic messaging. If your unfamiliar with his writings, you might be interested in Eric Sink's examination of The 22 Immutable Laws of Marketing . You can find it here .

Every once in a while, I feel compelled to dig up a classic quote from Al Ries. Today I found this gem in Ries and Trout's The 22 Immutable Laws of Marketing : No matter how complicated the product, no matter how complicated the needs of the market, it's always better to focus on one word or benefit than two or three or four. Following this advice requires a great deal of discipline.

You're trying to decide on the key themes and messages to use in your product marketing campaign. As I mentioned in my article, "How to Formulate Marketing Messages" , you can use three approaches to identifying candidate messages: 1. Portray your product as an antidote to a prospect problem. 2. Highlight the strength within your product's weakness. 3. Attack the weakness within your leading competitor's strength. It just so happens that weaknesses and strengths often derive from a company's distinctive competence . A company's distinctive competence may be a patent, its personnel, or an established position in the marketplace. These competencies do not always directly benefit customers; sometimes a distinctive competence merely enables the company to better deliver some benefits to customers. When considering how to attack the weakness within your leading competitor's strength, keep in mind that your competitor's strength may simply...

In a Slate article , Paul Boutin examines the (at best) lukewarm reception to the Motorola ROKR. He opines that convergence - combining the functionality of multiple devices in a single product - isn't a formula for success: Motorola CEO Ed Zander recently defended his phone—and slammed the Nano—by saying, 'People are going to want devices that do more than just play music.' I think he's wrong. If Gadget A does one thing well and Gadget B does another, combining them doesn't make for an instant improvement. Perhaps convergence is yet another marketing instinct that product managers must battle ?

I mentioned in a previous entry that a significant amount of what a product manager does is recommend strategy that contradicts basic instincts. I listed four examples of such instincts. One of the instincts I failed to mention, however, was the seemingly unstoppable temptation to lower prices or offer temporary discounts to stimulate demand for a company's product. In most cases, a good product manager will advise the opposite - maintain a stable price that reflects the value of the product rather than offer discounts. I've mentioned that John Moore, in his Brand Autopsy blog , recommended that company executives visit the Brand Autopsy Discount Detox Center when they become addicted to price discounts. Skimming through one of my favorite classic books on marketing, Al Ries and Jack Trout's Marketing Warfare , I recently came across these passages (excerpted from pages 90-92): "Psychologist Robert B. Cialdini tells the story of a jewelry store in Arizona th...

One of my peeves has always been government-mandated licenses and certifications. Doctors, lawyers, accountants, and interior designers all require these kinds of certifications. In my opinion, such certification requirements have the following kinds of negative effects: Stifling innovation. Getting certified typically requires immersing yourself, sometimes for years, in established ways of doing things and thus discourages people who thrive on innovation. Shortages. Certifications result in exclusive "clubs" that prosper by keeping competition low. The "clubs" typically help define the certification requirements, and the members of the club have a vested interest in making the requirements stringent. Expense. With shortages come expense. When you restrict the supply of people providing a service, the cost of the service stays artificially high. A friend of mine who grew up in Mumbai (formerly known as Bombay), India told me that quality medical care is much ...

In my last entry , I mentioned that it should be possible to implement user stories within a short period of time. But then I asked, "[A]long what lines to you divide the user stories so that they are each sufficiently small?" You have two alternatives. One alternative is shorten the development effort by abbreviating the "span" of the story. Take a word processor as an example. Instead of a story encompassing the entire process of creating a new document, composing and editing its contents, saving it, and printing it, you might pick just one step. You might, for instance, choose composing the document as the user story, and leave out the creation of a new document, saving it, and printing it. I generally don't recommend this approach. The approach I usually recommend is to maintain the "span" of the story but simplify some of the steps in it. For example, still implement the functionality to create, compose, save, and print, but make it ...

Let's see how some folks define "user story": "A user story is a very high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it. A good way to think about a user story is that it is a reminder to have a conversation with your customer (in XP project stakeholders are called customers) . . . . [U]ser stories are small, much smaller than use cases. In XP a user story must be able to be implemented by two people in a single iteration/cycle, therefore if you’re working in one week iterations each user story must describe less than one week worth of work." A user story is thus similar to a use case but "smaller". It's smaller in the sense that it should be possible to implement within a short period of time. The final product that you deliver to customers will be the result of implementing many such user stories. Therein lies a challenge: along what l...

In a previous entry , I mentioned that, when you use an agile product development process, you deliver "a working version of the product for review" at the end of each iteration. I mentioned in a later entry that Alistair Cockburn criticizes organizations that claim to use agile methods but don't deliver product at the end of their so-called iterations. What does it mean to deliver a working version of your product to customers? What is the point of iterating if you "deliver product" after the first iteration? The crux of the matter is that you should be able to demonstrate at the end of an iteration how a customer would use your product to address customer problems. So "working version" doesn't mean one that is ready for sale to the customer, but just one that is ready for demonstration. For a software product, that demonstration might include showing some hard-coded mock-ups in place of screens developers haven't yet implemented.

Talking to a colleague on the phone about a month ago, I remarked that a significant amount of what a product manager does is recommend strategy that contradicts basic instincts . The basic instincts of marketing seem to include: Strive to make your product appeal to as broad and diverse market as possible. Ensure your product has all of the same features as the competition, plus more. Choose a name, logo, and web domain name that are as descriptive of your company or product as possible. Try to hide or play down your product's weaknesses. Yet these instincts are generally the opposite of how you should be managing your product. Instead of striving to appeal to as broad a market as possible, you often should carefully select a single segment that is sufficiently large and focus on it. Rather than worrying about me-too feature comparisons with competitors' products, you should concentrate on solving your target market's problems. Scientific studies show that nam...