Cauvin

"Uncovering psychotherapy emphasizes facilitating clients' insight into the roots of their difficulties." Imagine you're a psychotherapist. Patients comes to you complaining that they are unhappy. You don't just ask them what's wrong. You probe into their backgrounds, their situations, and why what they describe makes them unhappy. In product management, we do much the same thing. We interview prospective customers to understand their backgrounds, situations, and problems they face. We listen, but we are not passive. To get to the root problems that our product can help solve, we have to ask the right questions and not stop at what a prospect initially says is the problem. By the end of an interview, the prospect should have greater insight into her own situation.

Don't ask your prospective customers if they "like" a product name or, worse, if they think the name is a "good" one. What they like doesn't matter. Since they aren't familiar with naming and branding principles, their opinion about what constitutes a good name, though interesting, is irrelevant. Instead, ask: 1. Have you ever seen or heard the word? 2. When you read or hear this word what does it bring to mind, if anything? 3. Would the word be easy for you to learn to spell? 4. Is the word easy for you to pronounce? Your prospective customers are qualified to answer these questions, and the answers are directly relevant to the quality of the name.

Here is my definition of "requirement": "A requirement specifies the least stringent condition that must hold to solve or avoid a prospect problem (problem that a prospective customer faces)." Note that a requirement, under this definition: Is possible, in principle, to test. Does not specify a design or solution. Correlates unambiguously to a problem that a prospective customer faces. UPDATE: You can find a comprehensive model of requirements concepts here .

As I mention in my article on requirements , it is important to specify the "what" instead of the "how" when documenting product requirements. Specify the criteria you would use to evaluate whether the product is likely to succeed in the market, but give as much latitude as possible to designers and implementors to develop a product that satisfies the criteria. Looking to the more general issue of problem-solving helps us understand why this advice is so important. Most problem-solving books emphasize the importance of a clear definition of the problem and creative brainstorming. The idea is that the best and most innovative solutions to problems often result from being open minded. When you are unable to think of a problem independently of solutions to it, you hinder your ability to thoroughly understand the problem and creatively address it. That said, exploring solutions to a problem can actually help us gain a more thorough understanding of the problem and i...

Reading Seth Godin's blog , I just came across a reference to this article about product naming. Researchers performed several somewhat scientific experiments to determine the consumer response to names that are unrelated to the product. Their conclusion? "[C]onsumers react positively to imaginative names even if they are not particularly descriptive." As tempting as it is to choose a product name that describes what the product does, it is often not the best choice.

In her Origin Of Brands blog , Laura Ries notes the success of GoDaddy, a domain name management company. For those of you who are unfamiliar with Laura Ries, she is the daughter of renowned marketing expert Al Ries. Laura points out how good the "GoDaddy" brand name is: "GoDaddy is hip, simple and cheap. The name is strange and has no relevance to the category. But again shocking and unique names work exceeding[ly] well on the Internet (Google, Yahoo!, Amazon) and it is the opposite of the sto[d]gy Network Solutions name. And GoDaddy avoids being the worst kind of brand name, a generic name like LowCostDomains.com." Often the best brand names are those having no pre-existing meaning and no relation to what the product does.

A few days ago, Random mentioned Gmail and the controversy over whether the concept of deleting e-mail is obsolete. It's an interesting exercise in product management. With Gmail, Google has tried to address the real requirements relating to e-mail. The ability to delete e-mail messages is not itself a requirement. Deleting e-mail messages is one possible solution that addresses two important requirements: 1. Ease of finding old messages of interest. 2. Scalability (not running out of storage space). Deleting e-mail messages is actually a poor way to satisfy these requirements, since it helps only marginally with finding old messages of interest and places burden on the user to keep a tidy inbox. Gmail makes searching old e-mail messages as easy as a typical Google web search, and provides so much storage space that it's difficult to run out. Gmail thereby satisfies both requirements without burdening the user with e-mail deletion.

In the realm of software development, agile and iterative processes have been in vogue for a number of years. For those unfamiliar with the concept, agile processes contrast with waterfall processes. A waterfall process looks like: 1. Define the requirements the product must satisfy. 2. Analyze the requirements and produce models of the domain. 3. Design the product. 4. Implement the product. 5. Test the product. The hope is that you perform each step so thoroughly that any retracing or repetition of steps in the process is minimal. Unfortunately, vast amounts of real-world experience shows that waterfall processes fail. It goes without saying that testing typically reveals mistakes developers make during the design and implementation steps, resulting in some redesigning, re-implementing, and retesting. However, the most significant failure of the waterfall process stems from the fact that requirements are practically impossible to define adequately up front. Customers do...

Visiting MarketingProfs.com today, I was disappointed to see that my recent article, " How to Formulate Marketing Messages ", is no longer in the top 10 list of popular articles. It had hovered between number 2 and number 7 for about six weeks. I have posted a copy of the article on Cauvin, Inc.'s site .

Familiarity has powerful effects on the ease of using a product. For example, consider a pointing device for a computer, whether it be a mouse, a touch pad, or a trackball. Someone who has exclusively used a mouse and never used a touch pad will almost certainly encounter difficulty and frustration when they try to use a touch pad. But after a sufficient time using the touch pad, she may actually grow to prefer it to a mouse. This concept applies to just about any product, including computer operating systems, e-mail software, toothbrushes, and even food. Ease of use, therefore, depends not just on the person but on how familiar they have grown with the product. A product may intrinsically be easier to use than a competing product, but temporarily be more difficult for some users. As a consumer, whenever I have encountered this situation, I have generally felt a strong inclination to learn the unfamiliar product. I face short-term frustration, but the long-term benefits often are well...

When debating terminology, I have several times run across the issue of prescriptive versus descriptive rules. A prescriptive rule states how people should use a word; a descriptive rule states how people do use a word. For example, many people pronounce " nuclear " as "new-cue-ler". Webster's has even accepted this oddity as one among several pronunciations. But does Webster's inclusion of the pronunciation mean that it is "correct" to pronounce the word that way? I don't think so. The inclusion of the pronunciation is descriptive; they included the pronunciation because it describes how a significant portion of the English-speaking population pronounces the word. They are not endorsing the pronunciation. Interestingly, the same sorts of issues arise in the rules of games. I have debated rules of poker, for example, with people who insist the rule they follow is "correct" because everyone seems to play that way. But when I loo...

A lot of job postings for product managers mention experience in a particular industry as a qualification for the position. I believe that the best product managers are the ones who don't need any experience in an industry to perform their jobs effectively. Let's imagine a product manager who has extensive industry experience and knowledge. As with any product manager, her job is to continually understand an ever-changing market. She will be unable to perform her job effectively if she lacks the skills to interview prospective customers and quickly and thoroughly learn their situation and problems. Yet if she has these skills, then her pre-existing industry experience and knowledge are superfluous, since she should quickly be able to gain the knowledge. It is also a product manager's role to communicate her understanding of the market to the sales, marcom, and development teams. Our experienced and knowledgeable product manager, therefore, should impart her knowledge to th...

A lot of friends are surprised I haven't started a blog. I have a tendency to pontificate and pretend I'm an expert on everything, so you'd think I'd have been one of the first people to start a blog. Well, I still am not ready to start a full-fledged blog. Believe it or not, I'm really not sure I have enough to say. A successful blog requires regular updates with interesting content. I want any blog I start to be successful, since there's little point in expressing opinions if no one reads them. So I'm starting an experimental blog. This message is the first in the experimental blog. I want to understand the different capabilities of blog frameworks, and the best way to learn is to actually use them. [UPDATE: It looks like I'm ready to go live with this blog. Reader comments and suggestions are welcome!]