Thoughts on New Year's Eve

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's New Branding

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?

Scheduling Product Development

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.

Innovation Games

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.

Predicting Behavior

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.

Complementarity of Qualitative and Quantitative Methods

I recently proposed to a prospective client that I do a market study using three research methods:

1. Market survey
2. One-on-one interviews
3. 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's important to conduct both quantitative and qualitative research regardless of the scope of a study. When scoping down, instead of eliminating one or the other methods, you're better off doing them all but doing less of each one.

Sierra on Research Methods

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.

Life-Changing Products

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 tub of cooked rice ready to microwave.
• Panasonic plasma monitor - I'm hooked on the HDTV experience, and I could never go back to my 24" TV.

Sometimes I like to "rough it", go without all of these products, by camping in Big Bend or the Guadalupe Mountains. When I'm home, though, these products make my life much different than it was five years ago.

Alternative to CRUD

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 approach is to have the use cases represent on-going, end-to-end processes instead of discrete tasks the user performs. That way they encompass the nonfunctional requirements and any data administration that product designers decide to include in their design.

For example, consider a Pay Employees use case that encompasses not just one round of payroll, but the process of paying employees during the lifetime of the company. Such a process contends with the hiring and firing of employees, and changes to employee titles, salaries, and marital status. Attach nonfunctional requirements to the use case that constrain the accuracy and timeliness of the information and limit the amount of time and effort users are engaged in carrying out the process (including the administration of information).

CRUD is Crud

When documenting use cases for a software product, some product managers specify ones such as:

Create Employee
Retrieve Employee
Update Employee
Delete 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, Update Employee, and Delete Employee use cases are not requirements and need not appear in requirements documents.

Enabling users of a product to perform CRUD functionality is sometimes the most realistic design choice. Specifying such a design in terms of use cases is helpful. However, chances are that the appearance of CRUD in a requirements document suggests your product manager doesn't understand the distinction between requirements and design.

Starting Meetings on Time

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.

Requirements "Testing"

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 requirement, there should be some way to devise tests that indirectly do so.
• Design a fantasy solution. Consider the problem that a requirement is supposed to address. Think of the most desirable solution to the problem, no matter how unrealistic it is. If the requirement doesn't allow for this solution, then it contains design assumptions that you should purge from it. For example, for ease of use requirements, imagine the user could use telepathy or psychokinesis to accomplish her goals.

Keep in mind that, even if product managers use these requirements testing approaches, product development and testing will inevitably expose unanticipated requirements. These approaches are not a substitute for agile product management.

Aubin on Functional Requirements

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.

Fire Indispensable Personnel

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.

Contentment is Promised Land Milk

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.

Holistic Requirements

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 product holisitically, the requirements constrain the whole package. Thus constraints on ease of use (e.g. the amount of time it takes a user with a given skill set to accomplish functional goals) encompass the user's experience with the product, documentation, training, and support.

Holistic requirements are almost essential if you really want to satisfy the user, because they capture what really matters to the user. The user doesn't care about documentation, training, or support, they just want to learn how to use the product as quickly as possible, and for it to be easy to use thereafter.

If you specify requirements on the documentation for a product, do so only after you've captured the holistic requirements.

Lively Discussion about Requirements

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

Inward versus Outward Branding

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 recommend are unlikely to resonate in the marketplace or generate profits.

You're better off if the strategists do outward branding. Determine the image of the company by doing some solid market research and gaining a solid understanding of the problems prospective and existing customers face. Formulate your key messages using the approaches described in my article, "How to Formulate Marketing Messages".

Better yet, though, make your inward and outward branding converge. To be successful, the management and the rest of the company have to buy into the image and the branding. They have to live and breathe the customer experience. To be credible, your products must embody the key messages you communicate to the market.

Allow your strategist to build internal consensus for a market-driven brand. Then your inward and outward branding will be the same.

Intrigue, Pushiness, and Pricing

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

Marketing is Not Common Sense

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 sense than the CEO, right?"

Rothman on Processes and People

Johanna Rothman has a recent entry on making processes independent of people. I almost cringed when I read it.

I do agree that you want to avoid a situation in which any particular person on a team becomes indispensable. (In fact, Gerald Weinberg recommends firing a person who is supposedly indispensable. More on that recommendation in a future entry.)

But the most efficient and effective processes are those that leverage the unique mix of skills that exist on a team at any particular time. You lose that advantage when you make processes completely independent of people.

Patton Quote

"Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." - George S. Patton

Top Ten Rules for Web Startups

A few friends and colleagues have linked to Evan William's Ten Rules for Web Startups. My initial reaction was to ignore the link, but eventually I got around to reading them. I was pleasantly surprised to find this gem about descriptive naming:

"Get a good, non-generic name. Easier said than done, granted. But the most common mistake in naming is trying to be too descriptive, which leads to lots of hard-to-distinguish names."

The reason I keep harping on this point is that Evan is right - the tendency to choose descriptive names for a product or company is one of the hardest instincts to overcome.

"Dumbass" Branding?

On his FusionBrand blog, Nick Wreden writes that Al and Laura Ries's book The 22 Immutable Laws of Branding has a "dumb branding title", because the laws of branding are not immutable.

Well, I suppose he's right, strictly speaking. It's definitely a bold claim to describe 22 laws and pronounce them immutable.

What I think Nick neglects to recognize or acknowledge, however, is the Rieses' point that new generations of marketers tend to repeat the mistakes of the past. As I've mentioned, much of what product managers do is recommend marketing strategies that contradict natural instincts. So it shouldn't be a surprise that the community of marketing experts needs to firmly remind the novices that it's not "different this time".

Marketing ROI

An article by Robert R. Johnson in CMO Magazine supports my contention that product revenue is not a reliable metric for evaluating a product manager's perfomance.

The article makes a number of points beyond what I've mentioned, including the fact that it's difficult to trace long-term increases in product revenue back to original strategy recommendations. Nonetheless, at least for strategic marketing activities, I'm highly skeptical about Johnson's suggestion that we can decompose marketing initiatives and measure their success in isolation.

Indeed, Chris Lynn comments:

"Viewing a marketing initiative in isolation or as a component of a
greater whole do not represent mutually-exclusive alternatives."

Hat tip to Steve Johnson on the productmarketing.com blog.

Laptop Screen Size a Requirement?

Some of you may protest that I'm going too far with keeping requirements solution-free, but . . . .

The internal monitor on my laptop computer stopped working, so I've been using an external monitor at 1024 x 768 resolution. I am used to 1600 x 1200 resolution. I noticed how much it affected my productivity and my overall frustration level.

The realistic solution to my problem is probably to get my original screen fixed or buy another laptop with a high resolution screen. But what's the underlying problem? And what's the requirement?

I would argue that the requirement is not to get a screen with a certain resolution. Indeed, if I could have a much smaller laptop and not suffer from any of the resulting inconveniences, I'd be even happier.

The problems are the increased frustration and lower productivity. So the requirements should include a set of ease-of-use constraints on usage of the computer. It just so happens that getting a laptop with a high-resolution screen is probably the most practical way to satisfy that requirement.

Aspect Ratio of Logotype

Interesting recommendation from The 22 Immutable Laws of Branding:

In "the law of the shape", Al Ries and Laura Ries recommend that the logotype for a brand be "designed to fit the eyes". The ideal aspect ratio, they argue, is for the logotype or brand symbol to be 2 1/2 times as wide as it is high.

Law of Remarkability

John Moore has blogged about what he calls the "Law of Remarkability". It refers to Seth Godin's theme and states that "remarkable things get remarked about". Word-of-mouth marketing is the rage these days as we've experienced The Fall of Advertising and the Rise of PR.

You're off to a great start marketing your product (or, more accurately, stimulating your customers to market your product for you) if you put something remarkable in your product.

Dodgeball

For those Austinites who don't already know, I am now on Dodgeball. Dodgeball is a text messaging service that enables you to conveniently share your location with your friends.

Selling Technical Products

Another good MarketingProfs.com article. This one touches on the issue of selling technical products to decision makers who are not technical. I've touched on this subject in my posts about low-hanging buyers and buyer tension.

The Case for Marketing [sic] Research

Bob Kaden has a spot-on article on MarketingProfs.com about how companies underestimate the value of market research.