Cauvin

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 wa

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 bu

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