Cauvin

When you think about it, New Year's Eve is just about the worst night of the year to go to bars. I live in downtown Austin and frequent the numerous bars that are within walking distance of my loft. But tonight I will studiously avoid them. I can go to bars any night of the year. If I can arrange to meet, or just bump into, friends, I'll usually have a good time. New Year's Eve is no different except: Bars that don't usually have a cover charge will stick you for $25 - $100 just to get in the door. There will be many more drunk people throwing up in the streets and getting into fights. The lines to get in the bars, and the waiting time to get drinks, will be longer than usual. Parking (which wouldn't affect me) will be difficult to find. I plan to go to some relatively low-key house parties instead.

Intel is planning to drop its "Intel Inside" branding effort. Intel has built a powerful brand by portraying their products as "powering", and being the "intelligence" within, computers and electronics. They are moving more into the consumer electronics space, but I'm not sure why they are dropping their simple and effective slogan. Perhaps consumers associate the slogan exclusively with computers? Or maybe it's the rebranding disease that Al Ries has mentioned?

On her Managing Product Development blog , Johanna Rothman wrote an entry about scheduling the implementation of mixed software/hardware products (hardware with software embedded in it). She recommends implementing a "pass" through the system as quickly as possible and iterating thereafter. In other words, instead of implementing a component at a time, implement just enough of each component to get a usable (if only for one usage scenario) product integrated and running. Don't develop the hardware and software independently and integrate at the end. Instead, integrate the hardware and software in an iterative or continuous fashion. This approach is consistent with agile development . I added a brief comment to her entry recommending that the product development team iterate on the requirements as well as the implementation. In other words, incorporate agile product management in the process.

An acqaintance of mine, Luke Hohmann , founded Enthiosys . The company consults with its clients to help develop successful product strategies and innovations. Cauvin, Inc. focuses on market understanding but leaves product design to others. One of Enthiosys's specialties, on the other hand, is innovation games . Innovation games are group activities that help a company design its products (though some of the games also help with uncovering customer needs). They resemble focus groups but are more imaginative and directed in their approach. Understanding the market for your product and formulating design-free requirements serves as a foundation for innovative solutions. That's our focus at Cauvin, Inc . To deliver, you also need expertise in the designing and innovating that builds on this foundation. If you're an executive looking for design help, don't hire us. But a company like Enthiosys might be able to help.

Up until about three years ago, I had never ridden city buses in Austin. About fifteen years ago, my friend P.K. asked me if I'd try riding the bus. I said, "Sure, it will be educational". It took me twelve years to finally get around to doing it. This sort of consumer behavior is common. You can't just ask someone what they will do and get reliable answers. Fortunately, skilled product managers are familiar with principles that apply generally to branding and market research. Certain kinds of product names work better than others. Certain kinds of survey questions result in more reliable responses than others. Anyway, for the past three years city buses have been my primary mode of transportation. P.K. probably will never know; I haven't seen her in thirteen years.

I recently proposed to a prospective client that I do a market study using three research methods: Market survey One-on-one interviews Silent Observation ( ethnography ) The first method is quantitative, and the second and third methods are qualitative (at least in the context I proposed). The expense of the study is an issue, so we explored ways of scoping back the project. I am a firm believer that quantitative and qualitative research methods complement and strengthen each other. It's hard to conduct a meaningful market survey without the benefit of some one-on-one interviews. It's also hard to understand the relative extent of problems uncovered in one-on-one interviews and ethnographic studies without a survey. I also think that, if you have conducted sufficient qualitative research, you can draw reliable (yet somewhat subjective) conclusions from surveys even without a "scientifically valid" sample of responses. Thus, in general, I believe it'...

Kathy Sierra has another great post on her Creating Passionate Users blog , this time shedding light on how difficult it can be to conduct reliable market research.

Most products are minor conveniences and have a negligible impact on your life. Others transform your life, breaking the patterns and routines to which you're accustomed. Here are some products that have transformed my life: Motorola mpx200 - mobile phone that runs the Windows Mobile OS. I rarely have a need for paper anymore. Whether it be contact information, directions, appointments, or grocery lists, I carry them with me on my phone (which synchronizes them with my computer). Google Desktop - software that enables Google searches of files and e-mails on your computer. Within seconds I can recall just about anything I've written or received electronically. Red leather sectional - for years, I had just a futon in the "living room" portion of my loft. With my red leather sectional, I can now entertain guests comfortably; watch TV comfortably without swiveling the TV towards my bed, and host business meetings at my loft. Rice cooker - I now almost always have a tu...

So if CRUD use cases don't belong in requirements documents, what use cases do you include in their place? First, I should reiterate that CRUD use cases may still be appropriate outside of a requirements document, such as in a design specification. As I've mentioned , once a use case author begins fleshing out text use cases with steps, she is engaging in design, anyway. Second, when a product manager is tempted to include CRUD in a requirements document, he should instead specify the user's larger goal. Presumably, information somehow needs to get into the system and stay up to date. Why? What does having that information enable the system to do for the user? An example of a larger goal is Generate Periodic Financial Reports. In that example, the user doesn't want to enter information; she just wants her reports! The product manager still has to capture nonfunctional requirements relating to the accuracy and timeliness of information in the system. A useful appr...

When documenting use cases for a software product, some product managers specify ones such as: C reate Employee R etrieve Employee U pdate Employee D elete Employee Such functions are called " CRUD " use cases. If your product manager is specifying CRUD use cases in market requirements documents, your product manager probably doesn't understand requirements. Recall that use cases represent functional requirements insofar as they convey user goals. In the example above, users enter and view information about employees. But what is the user's goal? Why on Earth would anyone want to enter information about an employee? Users actually don't want to enter such information . The user wants the information to be accurate and up to date and probably to be able to examine it. But creating, updating, and deleting employees is a burden to the user. A fantasy solution would obviate the need for the user to enter such information. Therefore, the Create Employee, U...

We've all experienced problems with starting meetings on time. Consider this passage from one of my favorite facilitation books, How to Make Meetings Work : The only way meetings are going to start on time is by starting them on time. Waiting five minutes at one meeting will lead to a ten-minute delay the next. And pretty soon everybody will be timing their arrival according to their personal estimates of when the meeting really will begin. If you start meetings on time, people will get the idea that when you say ten-thirty, you mean ten-thirty and not ten-forty-five. (If it's ten-thirty and only a few people have arrived, let them decide when to begin the meeting. Maybe they will think it's a waste of time to begin before certain other members are present.) The book also describes some specific approaches to dealing with latecomers.

Does your product manager "test" the product requirements she specifies? No, I'm not asking about testing the product, I'm asking about testing the requirements for the product. What is "requirements testing"? Requirements testing is a way to assess the clarity and completeness of product requirements by conducting thought experiments. These thought experiments sometimes expose ambiguity or oversights in the requirements. Types of requirements testing include: Walk through product usage scenarios . While mentally walking through usage scenarios , ask yourself whether you could satisfy all the documented requirements yet still end up with a frustrated user. Design a product test. Imagine how you would test the product to determine whether it satisfies the requirement. Keep in mind the distinction between testability in principle and testability in practice . Even if it's not practical to directly test whether the product satisfies the requir...

Over a month ago, Jerry Aubin wrote an entry in Seilevel's Requirements Defined blog about my contention that organizations tend to overemphasize functional requirements . I have to admit that I wasn't entirely clear about this topic. See the comments section of Jerry's post for a clarification.

I alluded to this gem in a previous entry : "If a programmer is indispensable, get rid of him as quickly as possible." Gerald Weinberg wrote these words in The Psychology of Computer Programming , published in 1971. It singles out programmers, but it probably applies outside of the software realm and to many other roles on a product development team. In a 1998 interview , he elaborated: "Over and over I've seen organizations suffer enormous costs when something tragic happened to an 'indispensable' programmer, or when that programmer started making demands because management 'couldn't do without him' (or sometimes her). The lesson is elementary risk management—which unfortunately many organizations still don't practice. To reduce this risk, you don't have to actually get rid of the programmer, but you do have to get rid of the indispensability." Weinberg is one of my favorite authors on leadership and facilitation.

One of my favorite experiences is to go out on the balcony of my downtown loft , sit down, and drink Promised Land Milk . The milk comes from hormone-free cows, and Promised Land offers several different flavors. The strawberry and chocolate milk are very rich; they almost taste like melted ice cream.

Most products have some sort of documentation or user manual. Is it appropriate to include in product requirements specifications about the content of such documentation? Is there such a thing as documentation requirements? You certainly can specify documentation requirements. Keep in mind, however, that when you do so, you may not be paying sufficient attention to what really matters to the user. (And there's some question as to whether you properly can even call such specifications "requirements".) This issue is almost identical to whether you should document support requirements separately, or whether support is part of your product . Ideally, a product would have no documentation whatsoever. Documentation only benefits the user insofar as it decreases the learning curve and amount of effort it takes to use the product on an ongoing basis. A holistic view of the product treats documentation, training, and support as part of the product. When you treat the prod...

Check out Scott Sehlhorst's recent entry on his Tyner Blain blog . He touches on the all-important need for a requirements analyst to ask, "Why?" Tony Chen, President of Seilevel , contributed a comment in which he introduced the concept of the "rationale" for a requirement. See the comments section of the entry to see the discussion unfolding about the meanings of "requirement", "rationale", and "design".

With exposure to some of the traditional branding companies, I've noticed a problem with inward branding . When you decide on a strategy to shape your company's image, you want the image to be one that resonates in the marketplace and ultimately yields profits. But what should your image be? How do you go about deciding what the image should be? Some market strategy companies work with the management of the company to align the company's image with the management's personality. I recently interacted with a market strategy company on branding and found that they did a good job facilitating a dialog with the founders of the company. The founders enjoyed talking about themselves and envisioning the company's image reflecting their personalities. Yet the bottom line is what will resonate with customers. If your strategists focus mostly on the company, rather than on the customers, you are dealing with The Uninformed Strategist . The branding such strategists recom...

Sam Decker touches on remarkability in a recent entry on his Decker Marketing blog . If you are too "pushy" in your sales and marketing, he writes, you fail to create intrigue . Intrigue about your company or product tends to stimulate interest and generate word of mouth. It struck me that the problems with offering discounts relate to intrigue, or lack thereof. When you offer discounts, you may initially generate some word of mouth. Unfortunately, you also undermine any intrigue your product may have, because offering discounts (or at least publicizing them) is being "pushy".

Al Ries's most recent column  in AdAge.com touches on the notion of contradicting instincts . Most people, including executives, consider much of marketing to be common sense. We're all consumers, so we all know how we respond to products, names, logos, advertisements, and PR, right? So we're all experts on what works in marketing, no? Actually, psychology tells us that there's a lot we fail to perceive about ourselves, and that a lot of what we perceive about ourselves is skewed. We have a lot of "blind spots". And it's obvious that what works with us doesn't necessarily work with others. So the notion that we're all experts on marketing by virtue of our extensive experience as consumers is flawed. Here's the money quote from Ries's article: "When management has a marketing problem, it turns to its marketing department and says, 'We’ll do it my way because marketing is just common sense.' And no one has more common se...