Thursday, June 30, 2005

Product Management is like Therapy

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

Wednesday, June 29, 2005

Test Marketing a Product Name

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.

Tuesday, June 28, 2005

Definition of "Requirement"

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:
  1. Is possible, in principle, to test.
  2. Does not specify a design or solution.
  3. Correlates unambiguously to a problem that a prospective customer faces.
UPDATE: You can find a comprehensive model of requirements concepts here.

Monday, June 27, 2005

Why Solutionless Requirements Are Important

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 its effects. So it is not necessarily wrong to explore solutions and perhaps even in rare cases suggest or dictate them as product manager. However, at some point along the way, you should still have defined the requirements in a manner unbiased by preconceived solutions.

Sunday, June 26, 2005

Science of Brand Names

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.

Saturday, June 25, 2005

"GoDaddy": A Successful Brand Name

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.

Friday, June 24, 2005

Gmail and Deleting E-Mail

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.

Thursday, June 23, 2005

Agile Product Management

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 not know exactly what they want, and even the most skilled product manager cannot elicit all of a product's requirements without trial and error. Implementing the product and demonstrating it to prospective customers almost always results in the discovery of new requirements or the recognition of errors in the original requirements.

Agile processes, in contrast, assume up front that retracing is inevitable, so they incorporate iterations in the process. With iterations, you perform the steps to yield a working version of the product for review. You then revisit the steps, incorporating the discoveries you've made and fleshing out further functionality. To help maintain discipline, you may time-box the iterations, meaning that you set a fixed amount of time to complete each iteration, and schedule the tasks to complete within each iteration accordingly.

Unfortunately, while product development teams have at least attempted to use agile processes, most companies do not formally include product management in the iteration cycle. Companies assume that the product manager's role in defining product requirements ends when he "throws them over the wall" to the designers and developers. This practice defeats a large part of the purpose of agile product development.

At Cauvin, Inc., we urge our clients to incorporate our product management and market research services in an agile product development process. Even if we can't integrate directly with a client's process, we at least produce our deliverables (product requirements, market segmentation, buyer profiles, messaging recommendations, etc.) iteratively, starting with templates and incrementally fleshing them out on a weekly basis. That way we can ensure that clients receive the information they need, in a format they can use.

No Longer in Top Ten

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.

Wednesday, June 22, 2005

Familiarity and Ease of Use

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 worth the effort. But other people are much more reluctant to invest the time and effort to realize the long-term benefits. In fact, some people don't even seem to understand the distinction between intrinsic and temporary ease of use.

A product manager faces some interesting questions with such products. To what extent should the product features enhance intrinsic ease of use versus catering to those in the market who want a familiar user interface? Perhaps the product manager should segment the market as follows:

"Adventurous Learner" - excited to learn a new user interface for its own sake
"Pragmatic Learner" - willing to learn a new user interface for long-term benefit
"Reluctant Learner" - requires prodding to learn new user interface
"Resistant Learner" - will actively resist learning new user interface

This market segmentation helps the product manager to formulate ease of use requirements that ensure the product's user interface will appeal to a sufficiently large market. The company can bring in product testers that represent each of the target segments.

I realize that these observations resemble those in Geoffrey Moore's Crossing the Chasm. A difference is the emphasis on user interface rather than on disruptive technology.

Tuesday, June 21, 2005

Prescriptive versus Descriptive Rules

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 look up the rules in an authoritative source, such as Hoyle's Rules of Games, I sometimes find that the "official" rules differ from the common way in which people play.

I favor acting according to prescriptive rules rather than descriptive rules. Discrepancies between prescriptive and descriptive rules typically arise from ignorance - a larger and larger number of people who aren't familiar with a traditional rule begin to behave differently until few people even know what the original rule was. I want my rules to be based on full knowledge of both common usage and history, which sometimes means dismissing common usage as based on ignorance.

Monday, June 20, 2005

Domain Experience

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 these teams. Once she has done so, she has effectively made herself obsolete unless she is uniquely qualified to learn more about the market. Again, the ability to extract and impart new information, not reliance on experience and knowledge, are the key qualifications.

Instead of requiring "ten years of experience in the industry", hiring managers should focus on the facilitation and analytical skills necessary to be an effective product manager. Experience in a particular industry is little more than a crutch.

Sunday, June 19, 2005

Experimenting

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!]