Sunday, July 31, 2005

E-Mail Sensitivity

Have you ever forwarded an e-mail without the permission of the person who sent it to you? If so, you may have violated e-mail etiquette:

"If somebody sends you information or ideas by email, you should not assume that you have their permission to reproduce that information in a public forum (discussion group, USENET newsgroup, chat site etc.) Email is one-to-one for a reason: it is designed for personal communication. Unless you are explicitly told otherwise, always assume that email you receive has a big 'PRIVATE' stamp on it -- so don't spread it around! Even simply forwarding an email to a friend could under certain circumstances be considered a breach of trust by the original sender."

Saturday, July 30, 2005

Facilitation Book

If you want to dramatically improve your facilitation skills, read The Art of Facilitation: How to Create Group Synergy by Dale Hunter, Anne Bailey, and Bill Taylor. It won't just help you interview prospective customers, it will also help you facilitate group meetings.

Friday, July 29, 2005

Importance of Facilitation

I've mentioned in previous posts that facilitation plays an important role in product management. I will go further now and venture that facilitation is the single most important skill that a product manager must possess.

When a product manager visits a prospective customer and conducts a one-on-one interview, you strive to understand the prospect's situation and problems. You must facilitate the prospect to obtain this understanding. You have to listen, but you can't just capture a laundry list of grievances. No, you actually help her think of all the important facets of her situation and get to the root issues that affect her.

The best way to measure your effectiveness is not by gauging how much you have learned, but by how much the prospect has learned. You've used the Socratic method to teach the prospect.

Thursday, July 28, 2005

Use Cases: Requirements or Design?

When a product manager writes a market requirements document (MRD), she typically includes a section with use cases. Use cases describe how actors interact with the product to achieve goals.

Use cases typically come in one of two forms. A use case diagram merely depicts the actors and use case names without detailing individual interactions with the product. Text use cases are narratives that detail actor interactions with the product.

Since use cases come from the user perspective and treat the product as a black blox, they play a useful role in requirements documentation. But do use cases communicate requirements or design?

Craig Larman, in Applying UML and Patterns, answers that "use cases are not exactly requirements or functional specifications, but they illustrate and imply requirements in the stories they tell." I agree with Larman but would like to draw attention to some distinctions.

The names of the highest-level use cases of a product communicate functional requirements. Such names should reflect the highest-level goals that stakeholders are trying to achieve to overcome the problems they face. A functional requirement states what the product must do to solve or avoid a prospect problem. Since use case names imply what the product must do, or at least help the user do, to solve a prospect problem, it follows that the names of the highest-level use cases represent functional requirements. Therefore, use case diagrams that depict the highest-level use cases are appropriate in a requirements document.

However, text use cases do not represent pure requirements. When we describe how a user interacts with the product to achieve goals, we venture into product design. For example, if you specify that the user of a TV presses a button to turn it on, you have already gone beyond requirements and into solution space. Not only have you prescribed a particular solution for switching on the TV, you have assumed that turning on the TV is a necessary step in achieving the user's real goal, which is watching TV. Fleshed-out text use cases are not appropriate in requirements documents (except perhaps to provide background information about how customers currently achieve their goals without using the product, or perhaps to illustrate one possible way the product might meet the requirements).

Wednesday, July 27, 2005

Market Requirements Documents

What is a market requirements document (MRD)? An MRD is a document that product managers compose to communicate the requirements for a product based on market research. At a minimum, it should describe the stakeholders, the problems they face, and the functional and nonfunctional requirements that the product must satisfy to solve the problems.

Consistent with the agile product management services we provide at Cauvin, Inc., we encourage our clients to help us develop MRDs iteratively. By iterating on the requirements, we help clients avoid unexpected discoveries late in the product development cycle. Such unexpected discoveries often lead to product failure.

Tuesday, July 26, 2005

Convergence of Technology

Reading a number of articles recently on convergence, I've noticed a confusion between convergence of product categories and convergence of underlying technologies.

On the one hand, we have traditional marketing gurus such as Al Ries insisting that convergence of product categories is just as much of a myth now as it was before. On the other hand, we have articles describing all of the different areas in which convergence seems to be taking place. My belief is that both sides are right. Underlying technologies are converging - or at least combining - to create new product categories.

For example, companies are developing new phones that can link to fixed-line, Wi-Fi, and mobile networks. To be sure, several different technologies combine in these phones. But the extent to which these phones will be successful in the marketplace depends on making these technologies work seamlessly with each other. Thus the product category will be something new like "the anywhere phone", and the success of the category will depend, ironically, on how well the products hide the underlying technologies.

Monday, July 25, 2005


You may have heard of neuromarketing. Neuromarketers analyze subjects' brain activity to determine the best ways to market products to them. Neuromarketing enables us to "see" what a subject is thinking and feeling rather than rely on the subject to report it truthfully.

I am coining a new term: "neurorequirements". Neurorequirements are requirements formulated in terms of the brain states of users.

Product managers strive to formulate requirements in precise, measurable terms. As I mentioned in my article, "How to Guarantee Product Failure", an ease of use requirement might:
  • Specify a typical user’s prerequisite skills and experience
  • Place a limit on the number of user gestures (keystrokes, mouse clicks, etc.) it should take to accomplish a functional task
  • Place a limit on the amount of time that it will take a typical user to perform the functional task
As neuroscience progresses, it may at some point be practical to formulate requirements in terms of the emotional states of users. For example, we may be able to add ease of use requirements that limit the amount of frustration a typical user feels when using the product, as measured by the user's neural responses.

Sunday, July 24, 2005

Samuel Johnson Quote

"Nothing will ever be attempted, if all possible objections must be first overcome." - Samuel Johnson.

This quote is for those who sit around complaining but never actually take the initiative to change their situations. You'll always find a reason to avoid acting.

Saturday, July 23, 2005


Time-boxing is a technique that helps us direct energy on our priorities. When working on a tight schedule towards a goal, we often face tough choices about how to allocate our time. With time-boxing, we set time limits for performing tasks and stick to those limits by eliminating "fluff". Eliminating "fluff" requires constantly assessing whether each step we are taking to complete our tasks is absolutely necessary.

Let's say you're cleaning the floors of your home before guests come over. You want to mop the hardwood floors and then apply a no-odor finish. Your guests will arrive in a half hour. You decide to time-box the cleaning of your floors to 20 minutes, because you still have some other preparations you want to complete before the guests arrive. You then allocate 10 minutes to mopping and 10 minutes to applying finish.

As you start mopping, you realize you won't be able to mop thoroughly within the 10 minute time-box. What do you do?

By time-boxing your tasks, you have forced yourself to face a tough decision. You have to decide whether to do a less-than-thorough job mopping and applying finish, eliminate from your plan the applying of finish, or re-examine your assumptions even more radically. In the end, you might decide to do a thorough mopping of the most visible areas of the floor, followed by applying finish to that same area. If you're able to complete these tasks sooner than expected, you might consider cleaning and finishing the remainder of the floor. No matter what you decide, time-boxing has enabled you to recognize, and adjust for, your scheduling mistakes before the possibility of achieving your goal has evaporated.

Time-boxing works particularly well in conjunction with iterative processes.

Friday, July 22, 2005


Finally, a suite of office products packaged as a web application:

I haven't tried it, but it looks reasonably impressive from the examples.

Thursday, July 21, 2005


Psychographics play an important part in product management. While most people are familiar with demographics, it is often psychographics that drive product definition and marketing decisions.

Demographics break a population down by such straightforward attributes as age, gender, and ethnicity. Often, demographic information is readily available from census data and other sources.

Psychographics break a population down by the problems that drive their buying decisions. The only way to truly understand your market is to understand its psychographics. Gathering psychographic information requires interviewing and surveying prospective customers.

So what is the proper role of demographics and psychographics in product management? Focus on the psychographics to understand your maket. When you segment the market for your product, segment it along psychographic lines. Correlate demographic attributes with psychographic attributes, and then use demographics to help you determine the size of each segment.

Wednesday, July 20, 2005

Marketing "Flesh" at Church

Easter Day about four years ago, I attended a church (whose name escapes me) that was extremely successful in attracting high school age men and women. It seemed that the majority of attendees were high school age and, judging by the smiles on their faces, they seemed happy to be there.

I observed my surroundings to learn just what had attracted all of these young people, and I concluded that the key to the church's success was the "hiring" of young male ushers. I concluded that young male ushers attracted the young women to the church, and that the young women who attended in turn attracted young males to the church.

Many marketers assume that the way to attract customers is to hire scantily-clad women to promote the company. My church "study" was by no means scientific, but it struck me that marketers tend to make sexist assumptions when using "flesh" to sell products. This church, instead of "hiring" attractive females, had "hired" males to attract the women. The result was a congregation popular among males and females alike.

Tuesday, July 19, 2005

Pricing Quote

“Cheap is the last refuge of a product developer or marketer who is out of great ideas.” - Seth Godin, Purple Cow. Via the Brand Autopsy blog.

Monday, July 18, 2005

Convergence Article by Al Ries

Laura Ries posted a copy of an article on convergence. It originally appeared in the Financial Times, but requires a paid subscription to view it there.

Laura's father, Al Ries, wrote the article. Al Ries is a renowned marketing expert that has written many books, including Marketing Warfare, Positioning: The Battle for Your Mind, and The 22 Immutable Laws of Marketing: Violate Them at Your Own Risk (each co-authored by Jack Trout). He more recently has co-authored some books with his daughter.

"Convergence" is the notion that product categories tend to merge rather than divide into separate categories. An example is all of the recent talk about computers and media devices combining. Al Ries firmly contends that the opposite is true - product categories tend to diverge.

Sunday, July 17, 2005

Names Should Be Blank Slates

In previous entries I've harped on the counter-intuitive point that the best product names frequently don't have anything to do with the product or what it does. For example, I stated in one entry:

"Often the best brand names are those having no pre-existing meaning and no relation to what the product does."

Now Seth Godin writes in a recent entry:

"It seems as though the abstract quality of a name or a logo (both blank slates) is not as important as what you do with it. This advice doesn't hold for non-abstract names or images, naturally. But those are worth less, in my humble opinion."


Saturday, July 16, 2005

Popping Pills

Why is it that every time someone goes to the doctor they come back with drugs? I was talking to a friend the other day. She had just come back from a visit to the doctor. Her ailment was painful, but one that her body would naturally heal. Yet her doctor prescribed strong pain medication that made her unable to function effectively at work.

We seem to live in a society in which no one (even doctors) accepts that sometimes the most healthy response to an ailment is to let your body heal itself. Sure, when you invest the time and money, it's unsatisfying to discover that it was unnecessary to visit the doctor in the first place. But isn't letting your body heal itself, even after a visit to the doctor, sometimes the best course of action?

Friday, July 15, 2005

Artificial Precision in Nonfunctional Requirements

Now that I've outlined the difference between functional and nonfunctional requirements, I want to home in on what matters in nonfunctional requirements.

I once wrote in a market requirements document (MRD):

"The number of user gestures required to configure a controller and control history should not exceed 6400."

This requirement was an ease-of-use constraint on a functional requirement specified earlier in the document. It limited the number of mouse clicks, keystrokes, and any other "gestures" the user would have to employ to achieve the functional goal.

How did I come up with the figure '6400'? Did I have any real market data to support it?

Well, I did base the figure on some real data, but the point is that the exact figure doesn't matter very much. The most important thing we can do in specifying the nonfunctional requirements of a system is to define the kinds of measurements we would perform to verify the system solves problems in the marketplace. Knowing the kinds of measurements enables product designers and developers to understand what it means to improve the product, even if they don't know precisely when it's good enough.

Thursday, July 14, 2005

What are Functional and Nonfunctional Requirements?

Recall the 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)."

Product managers distinguish between functional and nonfunctional requirements. In my article, "How to Guarantee Product Failure", I briefly allude to this distinction.

A functional requirement states what the product must do to solve or avoid a prospect problem. It might state, for example, that an air conditioner should maintain a constant temperature in a room.

Nonetheless, functional requirements do not by themselves fully specify what it takes to solve or avoid a prospect problem. How constant should the temperature be? How easy should it be to set the thermostat? Nonfunctional requirements complete the picture by supplying the answers to these kinds of questions.

A nonfunctional requirement attaches measurable constraints to a functional requirement. A nonfunctional requirement might specify that the amount of time it takes for a user with a given skill set to set the thermostat will not exceed five seconds. Or it might might specify that the air conditioner will keep the temperature within one degree of the thermostat setting.

Wednesday, July 13, 2005

Requirements Quote

"A problem well stated is a problem half solved." - Charles F. Kettering, US electrical engineer & inventor (1876 - 1958)

From the Quotations Page, via Cote.

Tuesday, July 12, 2005

Evaluating a Product Manager's Performance

In a previous entry, I argued that companies should not evalute a product manager's performance flatly in terms of product revenue. How should, then, a company evalute a product manager's performance?

One way that Steve Johnson mentions on the productmarketing blog is in terms of the number of on-site visits to prospective and existing customers. The Pragmatic Marketing folks advocate basing bonuses on the number of on-site visits. I believe that on-site visits (in particular, one-on-one interviews) with customers are the single most effective way for a product manager to gain an understanding of the market. I have observed also that companies tend to underestimate their value.

However, I don't believe on-site visits quite get at performance. On-site visits are a means to an end. That end is an in-depth understanding of the market that a product manager successfully communicates to developers, sales, and marcom. If developers, sales, and marcom then do their jobs right, the product will likely succeed.

A company should evaluate a product manager's performance in terms of how well she communicates an understanding of the market to the development, sales, and marcom teams. I propose that a company can measure this performance by surveying the staff of those departments, asking them how well the product manager has imparted information about the market. Ask sales how well the product manager has profiled the different buyers. Ask development how effectively and convincingly the product manager has communicated the requirements. Ask marcom how clearly and credibly the product manager has defined the key messages to use in marketing programs.

Monday, July 11, 2005

Product Design Example

My recent entry on whether it is appropriate for a product manager to dictate user interface design generated several comments. Random proposed a hypothetical example to help clarify the issue. He wrote (punctuation edited):

"Here is a hypothetical case. Assume all the customers have browsers that support Java Applets. So the Applet UI would work in the given market. Assume you are building a Web app of some kind. Assume there are three different people in the role of product manager, product designer, and software developer.

Who decides whether the UI is HTML or applets? How is it decided?"

I would say the product developer plays the most direct part in determining whether the UI is based on HTML, applets, or some other technology. However, all three roles play a part.

The product manager formulates the requirements in completely UI-neutral terms. The product designer specifies the UI without dictating what technology to use to realize the UI. The product developer decides on the technology that will implement the UI the designer has specified.

However, a great deal of cooperation, feedback, and iteration are nonetheless necessary to make this process work.

A product manager can formulate requirements all he wants, but it may not technically be possible to satisfy them. The product designer may not be able to conceive of a user interface that satisfies an ease of use constraint, for example. The product manager and designer must therefore cooperate to formulate requirements that are realistic.

Similarly, a product designer can specify a user interface that no UI technology (HTML, applets, etc.) is designed to implement. The development team might have to write their own UI framework to implement what the designer specified. Writing their own framework might be a good thing, or it might unacceptably delay release of the product. The designer and developer must cooperate to specify a user interface that is possible to implement on schedule.

Ultimately, the product developer should determine which implementation technology to use. But the product manager's and designer's inputs drive the decision, and the product developer's expertise on what's feasible feeds back into the requirements and UI design.

Sunday, July 10, 2005

Negative Pricing

One important step in determining a price for your product is to determine how much it's actually worth. But what does that mean?

Your product is worth exactly the same amount as the cost of not using your product. Analyze the way prospective customers currently achieve the goals your product would satisfy and determine the costs they face in achieving these goals.

No, "negative pricing" does not mean paying your customers to use your product. It's the term I use for basing the price of your product on how much it costs for your customers not to use it.

Saturday, July 09, 2005

Performance = Product Revenue?

Should a company evaluate a product manager's performance in terms of product revenue (i.e. revenue generated by sales of the product)? I don't think so.

Certainly we want to hold a product manager accountable in terms of metrics that are relevant to the company's success. What could be more relevant than product revenue? Unfortunately, you can only hold someone accountable for that over which they have responsibility.

Sales, development, marcom, and customer support all play an integral part in making a product a success. A product manager interacts with all these departments. However, a product manager may perform his job perfectly, yet failure in any of these departments may still lead to low sales. It therefore doesn't make sense to evaluate his performance in terms of product revenue.

I can think of a situation in which it is fair to judge a product manager's performance in terms of product revenue: when the product manager has full managerial control, including hiring and firing authority, over every person working on the product - sales people, developers, and marcom folks. This situation is exceptional.

In a future entry, I'll describe how I believe a company should evaluate a product manager's performance.

Friday, July 08, 2005

Book: SPIN Selling

It's mainly a book detailing how to sell high-value products with a long sales cycle, but SPIN Selling enlightened me in two ways. Not only did it help me understand the perspective of a sales person, it also gave me some deeper insights into product management.

"S.P.I.N." stands for "situation/problem/implication/need-payoff". The idea is that you use a series of questions to uncover the customer's situation, the problems she faces in the context of the situation, the implications (monetarily and otherwise) of these problems, and what she needs to solve the problems.

Though the facilitative process the book details is for sales, many of the same techniques and principles apply to the one-on-one interviews that product managers conduct. I recommend the book.

Thursday, July 07, 2005

Product Designer?

Today's entry in Pragmatic Marketing's product management weblog links to an article by Jacques Murphy called "Software Design: Seeing vs. Thinking". The article raises important issues that product designers face when balancing the needs of simplicity and flexibility.

However, the article seems to assume that product managers play a direct part in designing the products they manage. I firmly believe that product design lies outside the scope of a product manager's responsibilities.

A product manager determines the requirements for a product, but not its design. Thus a product manager specifies what a product should do (functional requirements). She also places constraints on the product's behavior (nonfunctional requirements), such as how easy to use it should be. But placing constraints on a product's behavior does not mean specifying the product's design.

A product manager is uniquely qualified to learn what the market demands and translate this knowledge into product requirements. But only an ergonomist or user interface expert is qualified to design a product that satisfies these requirements. How many product managers are trained in user interface design?

Wednesday, July 06, 2005

"Marketing [sic] Research"

Some people say "market research". Some people say "marketing research". Which term is correct?

Well, maybe both terms are correct in some sense, but they mean different things. Common sense dictates:

market research - research into a market
marketing research - research into marketing

Webster's formal definitions agree with common sense:

market research - research into the size, location, and makeup of a product market
marketing research - research into the means of promoting, selling, and distributing a product or service

I suspect that most people mean "market research" when they say "marketing research".

Tuesday, July 05, 2005

Should All Requirements Be Testable?

When product managers specify requirements for a product, we strive to formulate the requirements in such a manner that they are testable. Companies obviously want to know when they have developed a product that satisfies the requirements; to this end we want to provide testable requirements. Yet sometimes it is not practical to test a requirement directly.

Take, for example, the requirements for a new, super-reliable model of car. We might specify that the car should last seven years without repairs as long as the owner maintains the car according to a certain maintenance schedule and doesn't have a collision. But it is not possible to directly test whether the product meets these requirements without producing the car and driving it for seven years.

The difference is between requirements that are possible, in principle, to test, and those that are possible, in practice, to test. As product managers, we should strive for requirements that are possible to test in principle. We can't ignore market demands just because it's hard to test whether a product satisfies them.

Monday, July 04, 2005

Roger's Free Food and Beverages Theory

I live in a downtown loft in Austin, Texas. One of the things I like best about living downtown is the density; there are a lot of things to do within walking distance. I receive a lot of invitations to happy hours and other organized events downtown. Free food and beverages are often at these events.

In fact, I've theorized that you can eat and drink for free every night of the week. It's just a matter of knowing where the event is and getting an invitation.

Sunday, July 03, 2005

Customer-Centric Messaging

In my article, "How to Formulate Marketing Messages", I describe three approaches to identifying possible marketing messages. As product managers, we are naturally tempted to focus on the attributes of our product when we communicate with customers. However, another approach is to focus on the attributes of the customers. In fact, we can often reformulate product-centric messages into roughly equivalent customer-centric messages.

For example, we might decide to position a new model of cell phone as "stylish". Such a formulation would be product-centric. A roughly equivalent customer-centric message would be to portray the users of the cell phone as "hip". In most cases, customers are much more concerned about themselves than they are about your product, so it makes sense to consider centering your messaging around them rather than around the product.

When you are formulating marketing messages, try wording them in at least two different ways:

1. Product is X.
2. Customer is Y.

You may find that the customer-centric wording is more powerful.

Saturday, July 02, 2005

Wisdom from Nietzsche

"The most fundamental form of human stupidity is forgetting what we were trying to do in the first place." - Friedrich Nietzsche

Friday, July 01, 2005

Conjoint Analysis

One of the most powerful and necessary tools available to a product manager or market researcher is conjoint analysis. Conjoint analysis helps you assess the relative appeal of various product features that would add to the cost of a product.

A recent project presented me with an ideal case for applying conjoint analysis. My company was doing market research for a client building condominiums at the northwest tip of downtown Austin. Floor plan mix (square footage and number of bedrooms of the various units), pool, concierge, finishes, storage space, etc. all contribute to the cost of building condominiums or to recurring maintenance fees.

To determine the relative appeal of each feature, I couldn't just ask prospective buyers to rate or rank them, since the appeal of each feature traded off against its cost. A buyer might have ranked a feature highly until he discovered how much it would cost. Furthermore, a buyer might have been willing to pay for each individual feature but might not have had the budget to buy all of them. Enter conjoint analysis.

I included in a survey two conjoint analysis questions. Each of them asked the respondent to choose among several pricing packages. Here is one of the questions:

"If you were to buy a condominium and had to select from the following configurations, which would you choose?"

a. 850 sq. ft., price $233,000, 1 bed/1.5 bath, stainless appliances, garage storage
b. 850 sq. ft., price $231,000, 1 bed/1.5 bath, standard appliances, garage storage
c. 1100 sq. ft., price $294,000, 2 bed/2 bath, stainless appliances, no garage storage
d. 1100 sq. ft., price $292,000, 2 bed/2 bath, standard appliances, no garage storage
e. 1400 sq. ft., price $384,000, 2 bed/2 bath, stainless appliances, garage storage
f. 1400 sq. ft., price $374,000, 2 bed/2 bath/study/2 story, standard appliances, no garage storage

After importing the responses to the conjoint analysis questions into Excel, I used the "Regression" statistical analysis tool to compute the relative appeal of each feature.