Skip to main content


Showing posts from July, 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."

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.

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.

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 functiona

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 .

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


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 term

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.


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


Finally, a suite of office products packaged as a web application: I haven't tried it, but it looks reasonably impressive from the examples.


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

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&quo

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.

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

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?

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 mark

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 no

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,

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 decid

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.

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, includin

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.

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

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

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 .

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.

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

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 mig