Thursday, August 31, 2006

Toyota Ultra versus Lexus

Example number 2298 demonstrating that marketing is not common sense:
Before launch of Lexus, if you had asked people if they would rather buy a Toyota Ultra or a Lexus, guess which brand they would have preferred by a large margin. The Toyota Ultra, of course.
Yet more wisdom from Ries and Ries.

Wednesday, August 30, 2006

Sam Decker on Surprises

I've blogged about surprise rewards and out-of-context user delights. On a related note, Sam Decker just blogged about "unexpected touch":

Now imagine if after a month after using iTunes, Apple knew which artists I liked and sent me a coupon for an upcoming local concert for one of my favorite artists. That goes outside what I ever expected when buying an MP3 player. That would be unexpected.
Doing the unexpected makes people talk about you and usually doesn't cost a lot.

Tuesday, August 29, 2006

Names and Stories

When choosing a new brand name, you should strive for one that is simple, spellable, pronounceable, not descriptive of the product, and that has a low number of Google hits. In The Fall of Advertising and the Rise of PR, Ries and Ries mention another one: choose a name that you can back up with a story:
A good name has story value. It suggests an idea that reporters can explore.
By choosing a name not descriptive of the product, you exploit an inconruency that stimulates cognitive dissonance in the mind of the consumer. This engages the consumer's brain, causing her to want to resolve the incongruency. In short, she wants to know the reason for the name. She likely will fabricate some reason of her own. This phenomenon is positive, as it makes it more likely the consumer will remember the name and associate it with something relevant to her.

Yet, for PR reasons, it's also a good idea to back the name up with a story. When a reporter asks you the reason for the name - and they will be likely to do so if the name is not descriptive of the product - tell them a story that calls to mind the key benefits of the product. Stories have great word of mouth potential.

Monday, August 28, 2006

Ries on BMW

In his latest Advertising Age column, Al Ries aims his "marketing focus" gun at BMW. Apparently, BMW isn't satisfied being the top-selling European car, so they are broadening their message.

Rather than just being about "performance", BMW is now touting its cars' fuel efficiency and safety. Not only does this new strategy lack focus, it isn't particularly credible.

Ries summarizes:

Any successful brand got to be successful by standing for something in the mind. Changing what you stand for is almost impossible unless you don't stand for anything at all. In other words, a brand that is nowhere in the mind is a brand that can be changed. A brand that stands for something in the mind is a brand that is forever locked into its position.
"BMW" means nothing if it doesn't mean "performance".

Sunday, August 27, 2006

Direct Navigation

Matt Bentley recently wrote an article in about direct navigation:
Simply put, direct navigation is when a user directly types a Web address into a browser.
Whatever your product or brand name, you can acquire a generic domain name conducive to direct navigation. Bentley gives several examples, including "" redirecting to Barnes & Noble's site.

Bentley enumerates three ways you can exploit the fact that people use direct navigation:
  1. Redirect from the generic domain to your main site.
  2. Set up an informational or education portal at the generic domain that contains links to your main site.
  3. Use the generic domain as your brand.
Option 3 is simply a bad idea. Generic or descriptive names make poor brand names, as I have repeatedly mentioned.

Option 1 has its pros and cons. It does direct interested prospects to your site. But it does so at the price of distracting from the brand name. You want customers to remember your brand name. Allowing them to type a generic name instead gives them a crutch that makes it less likely they'll remember or bookmark your brand name.

I have recommended option 2 to clients. Option 2 has the benefits of option 1 (albeit with a little more burden on the prospect) without distracting from the brand.

Saturday, August 26, 2006

Gloomy Future in Housing?

Economist Nouriel Roubini predicts a huge downturn in the housing market:
This morning's data on new homes sales, inventories of new homes and prices of new homes fully confirm and reinforce my analysis yesterday that this will be the worst housing bust - calling it slump is too mild - in decades. And since median home prices may actually fall on a year-on-year basis in 2007 - something that has not happened since the Great Depression of the 1930s - this may end up being the biggest housing bust in the last 75 years, not just 40 years as the Toll Brothers argue or 53 years as Countrywide argues.
He also believes that the housing slump will have a significant impact on the rest of the economy.

Friday, August 25, 2006

Simple PR-Based Marketing Program

In general, PR is the best way to build a brand. Here is an example of phases (in chronological order) of a simple PR-based marketing program:

  1. Establish a group of evangelists. Recruit a small group of "people with megaphones" (influencers such as bloggers, newspaper and TV reporters, and respected people in the field). Do everything you can do (e.g. training, etc.) to get them to use your product for free and become excited about it.
  2. Target key events. If possible, identify events at which attendees would find your product useful. For example, if your product is a cold beverage, supply it free at a small event that takes place in the hot sun. Try to provide them with something or some idea they will share with their friends after they get home.
  3. Focus on selling to a narrow subset of your market that will "drink the Kool-Aid". Start selling your product instead of giving it away for free. Target a location or demographic with a low barrier to entry, i.e. that contains people who it will be easy to convince to buy your product and to become excited about it.
  4. Get the media to do stories on your product. Call the local TV news stations. Call newspaper reporters. See if you can get Slashdot to publish a blurb about your product. The buzz you've already generated should already have gotten the attention of the media, so it should be relatively easy to get media coverage. Arm reporters with interesting usage stories from your product evangelists.

The idea is to tightly control the marketing rollout of your product in such a way as to maximize the positive word of mouth. Rather than try to blast your message to as many people as possible right off the bat, start small.

Thursday, August 24, 2006

What versus How

Over on the Requirements Defined message board, a guy who always seems to ask the right questions about product requirements is Marc Talbot. In a recent discussion, he questioned just how straightforward the traditional distinction between the what (requirements) and the how (design) is:

I'm Sony.

I want to entertain people (what I want to do).

I'm going to sell a new TV (how I'm going to do that).

Does that make everything related to the TV a design decision?

The What and How are very tightly coupled to the particular problem that you are choosing to solve, and making the decision on what problem to solve is the real trick.
This example very neatly illustrates how difficult it can be to distinguish between requirements and design.

Clearly, there is a huge leap between entertaining people and providing them with a television. The goal of entertaining people is so broad that Sony would want to constrain it. And it's a very important point that choosing the problems to solve determines the requirements. So the idea of entertaining people with a TV seems a reasonable constraint that falls within the realm of requirements.

Yet is it really?

"The product shall entertain its users" may be a functional requirement, but what about all of the associated nonfunctional requirements? What about all of the other problems users are trying to solve or avoid? What motivates them to watch TV instead of experiencing other forms of entertainment? Besides usability, availability, and other standard requirements, what about:

  • location - users want the entertainment at home (i.e. going to a concert or play won't cut it)
  • realism - users want realism in their entertainment (i.e. audio by itself won't cut it)
  • variety - users want to benefit from the various media that exist (i.e. being able to do things like attach a DVD player and watch DVDs is important)
Now, formulating these constraints in comprehensive and measurable terms is a challenge. It sure would be nice if we didn't have to bother gaining an in-depth understanding of why people want TVs. But it's just the sort of challenge the most talented and strategic product managers are ready to face.

Once we've fully understood and documented all of these constraints, a TV likely will be the ideal solution. But it might be a very innovative form of TV - so innovative that it would be the first in an entirely new product category. This sort of innovation starts with examining the true underlying requirements rather than assuming an established product category and its me-too feature set.

[This response is cross-posted on the message board.]

Wednesday, August 23, 2006

Elevator Stories

We all know about elevator speeches. You summarize your company or product in a few sentences.

But what about elevator stories?

Stories are great ways of engaging peoples' interest and stimulating them to remember your product. After you compose and memorize your elevator speech, how about composing and memorizing your elevator story?

The story might be something quirky about how you came to name your product. Or it could be a remarkable way that someone has used your product.

Everyone likes a good story.

Tuesday, August 22, 2006

Case Study in Brand Extension

Laura Ries writes about an interesting case of brand extension:
My last post praised Geox, the first breathable shoe. Mario Moretti Polegato, CEO and founder of Geox, has built a powerful global shoe brand by focusing on one word “breathable.”
But then Ries follows up:
Mario’s itch has led him to start a Geox fashion line featuring clothes that breathe.

But he is staying focused you might be thinking. The product is still breathable. Yes, but there is a great difference between shoes and clothes. It is a great divide that Geox will have great difficulty crossing.

Now, I do think that extending the Geox brand to clothes instead of just shoes has its risks and liabilities. But just how serious these risks and liabilities are depends on whether "Geox" means "breathable shoe" or just "breathable".

If it means "breathable shoe", then extending the brand to clothes is actually a form of rebranding. It's not just a matter of applying the meaning of "Geox" to another line of products. It actually changes the meaning from "breathable shoe" to something broader. Changing what a brand stands for is a dangerous move.

If "Geox" already means "breathable" instead of the narrower "breathable shoe", on the other hand, then applying the brand to clothes is a natural extension that does not change the meaning of "Geox". Ries seems to believe it is an unwise decision, but I'm not sure.

Monday, August 21, 2006

Packaging is Important

Don't get so focused on your product that you forget the total user experience. You may have a powerful and usable product, but if the packaging poisons the user's initial experience with it, it affects her overall impression of the product and your company.

In comment on a previous entry, I wrote:
Dell seems to have a pretty good metrics-oriented approach to improving their overall customer experience. With stopwatch in hand, they visit customers and observe as they unpack, set up, and begin using a new Dell computer. I imagine they include customer support calls in their observations.
Formulate holistic requirements and tests that encompass the entire user experience. That way you ensure things like packaging don't turn off your customers.

Saturday, August 19, 2006

Friday, August 18, 2006

Specifications and Manual Tests

On Tyner Blain, Scott writes about the importance of manual testing. One passage from Scott's entry stood out to me:
As an engineer, I know that we can specify tolerances, inspect components, and test assemblies to make sure that products are “within specification.” And all of this testing can be automated - just like automated software testing. But passing these tests doesn’t make a product good, it merely indicates that the product is “within specification.” Did the Japanese manufacturers have tighter tolerances? Yes. But did they have better designs? Yes. And those better designs were about more than miles-per-gallon and horsepower and torque.
This passage draws attention to the distinction between a "specification" and a "requirement". A requirement is a specification that captures what really matters to users and stakeholders. Other kinds of specifications exist (e.g. feature and design specifications), but in the final analysis they are irrelevant unless they solve users' problems (and avoid causing new ones). You can deliver a product "within specfication" but that fails to solve and avoid users' problems.

One of the reasons that some product managers have such a difficult time documenting true requirements - instead delving into design - is that they are too focused on the practical aspects of testability. Hopefully, your product manager writes requirements that are testable in principle. But if your product manager focuses on the expediencies of testing, such as whether it would be easy to automate testing of a requirement, then you will likely end up with a product that's "within spec" but doesn't address stakeholder needs.

Thursday, August 17, 2006

Godin Quote

This quote from a recent Seth Godin blog entry applies to marketing and to life in general:
Never underestimate the ability of the public to ignore you. They can and they will.
Don't be surprised when people to ignore you. Don't be frustrated.

Wednesday, August 16, 2006

Innovative UIs and UI History

On The Mac Observer, John Kheit wrote about the history of user interfaces (UIs) and explores various innovative new UI paradigms. The article contains descriptions of the paradigms and numerous links to demos.

Tuesday, August 15, 2006

What Problem Does MySpace Solve?

A lot of people just don't "get" MySpace. Why is it so popular?

A product manager tackles this question by asking, "What problem does it solve?"

The answer, I believe, is actually quite simple. MySpace solves the problem of keeping up with friends and family. More specifically, if you have a lot of friends and family, you most likely:
  1. Tend to forget about some of them unless you see them on a regular basis.
  2. Don't know what's happening in their lives without contacting them frequently.
  3. Don't feel "close" to them without seeing their faces when communicating with them.
Before such social networking sites as MySpace, to overcome this problem, you had to spend a lot of time and energy making phone calls, sending e-mails, updating a personal web site, and setting reminders for yourself to contact friends. With MySpace, your friends (or at least those who use it) stare you in the face when you log in. It's hard to forget about them. And it's easy to get a good idea of what's new in their lives simply by visiting their profile page.

If you haven't used MySpace, or don't have a lot of friends and family who use it, you probably don't recognize or appreciate the extent of this problem and its facets. The problem is dormant; users only become aware of it after they've fully experienced a new way of doing things.

Monday, August 14, 2006

XPM Followup

In following up on the original article and my comments on XPM, Barbara Nelson writes:
Extreme Product Management is meant to articulate the role of product management in embracing Extreme Programming. XPM is not about managing the sprints and iterations; when building products (not one-time projects), product managers need to operate strategically and bring in market facts.
If I'm interpreting her correctly, Nelson is concerned about product managers getting sucked into overly tactical activities such as micromanaging individual iteration deliverables.

I agree. As I've written, product managers often face this problem; there is a tendency for executives to make all of the strategic decisions and relegate the product manager to doing tactical outbound and implementation work. Consequently, companies' strategic decisions are made in a vacuum, without the benefit of market research and sound marketing principles.

Nonetheless, while a product manager should not be managing product development iiterations, I do believe she should be involved in each iteration that results in a user- or buyer-demonstratable deliverable. And, in general, the team should be structuring iterations so that most iterations result in such a demonstratable deliverable.

Indeed, I wrote late last year:
The crux of the matter is that you should be able to demonstrate at the end of an iteration how a customer would use your product to address customer problems. So "working version" doesn't mean one that is ready for sale to the customer, but just one that is ready for demonstration. For a software product, that demonstration might include showing some hard-coded mock-ups in place of screens developers haven't yet implemented.
Think of the product manager's involvement in these iterations as an ongoing dialog with developers about what matters to users and buyers. This dialog benefits developers and avoids the hazards of BUFR.

Sunday, August 13, 2006

Sam Decker on Piggybacking

Sam Decker writes about piggybacking:

The idea of piggybacking is to look at any marketing program and piggyback on it with another marketing message. Or, alternatively, piggyback every marketing vehicle to reinforce your main message (example: logos on delivery vehicles, URLs on receipts, etc.).
Marketers walk a fine line between piggybacking and turning customers or diluting messages. I like the way Decker recommends reinforcing your main message with piggybacking.

Friday, August 11, 2006

Extreme Product Management (XPM)

In the latest issue of, Barbara Nelson and Stacey Mentzel wrote about extreme product management (XPM). I'm glad to see respected product management folks write about this topic.

Nelson and Mentzel spell out many of the reasons that developers have opted for agile development methods. Some of these reasons are reactions to poor product management, such as unreadable requirements documents and constantly-changing requirements. And the authors explore various ways that a product manager can work constructively with teams that practice agile development.

Nonetheless, I have a couple of issues with the article.

First, the article defines XPM as:

XPM is using the minimum process and creating the minimum artifacts to deliver products people want to buy.
I find this definition unfortunate. The choice of words "extreme product management" renders it an obvious analog to extreme programming (XP). While part of XP is to generate minimal formal artifacts, it is much more. XP involves the application of many practices, including writing tests first, small iterations instead of a waterfall approach, frequent integration, and frequent releases. Any definition of XPM that fails to incorporate these concepts is misleading.

Second, the article seems to endorse an "agile waterfall" approach:

With a solid roadmap in place and stable market requirements, we should be able to review and complete market and functional requirements at the start of a project. Then, Development can iterate through implementation and testing while Product Management is preparing for the next release cycle. Since Development reaches a point where the entire release is designed, they can set a good target date and free Product Management to focus on promotions and the next big thing.
This approach fails to engage the product manager in one of the most important lessons of agile: requirements are almost never stable or completely understood. Product managers must iterate on the requirements in the same manner as developers iterate on the implementation. The end of each iteration yields the product manager something of tremendous value - a demonstratable version of the product that can reveal gaps in the requirements.

The product manager shouldn't just hand off the market requirements to the development team and re-engage after development has finished its iterations. Instead, after eliciting and documenting an initial set of requirements, the product manager should engage, at a minimum, after each iteration. She should revisit and update the requirements to reflect new discoveries. She should also recalibrate the requirements to reflect more educated estimates of how long it will take to implement them.

Read more about how and why we at Cauvin, Inc. practice agile (though not necessarily "extreme") product management here.

UPDATE: You may read a followup on this topic here.

Thursday, August 10, 2006

Requirements and Apple's "Time Machine"

Apple's Leopard OS will include a service called "Time Machine". It backs up users' files automatically and transparently so that users can restore their machine to any previous state.

The remarkable aspect of this backup service is its ease of use. Consequently, it is interesting to explore it from a requirements standpoint.

Remember why CRUD is crud? CRUD requirements assume that users actually want to create, update, and delete information. But users don't really want to create, update, and delete information. They want to access it to achieve some larger goal. Enabling the user to create, update, and delete information is one way to manage and make the information available, but it is by no means a utopian design.

Remember Gmail and the 'delete' button? Why on Earth would anyone want to delete e-mail? Notwithstanding some privacy concerns and obsessive-compulsive issues, what users really want is to be able to find, read, and respond to messages of interest. Deleting e-mail helps eliminate clutter that can interfere with these goals, but it's not an end in itself. Thus it is not a requirement.

Similarly, conventional requirements documentation for a backup service would include specifications such as:
The system shall enable the user to backup files.
Or a use case such as:
Create Backup
Yet these specifications and use cases do not represent real requirements. No user wants to backup files. They want to be able to restore files (or, better yet, just have their files available). Backing up the files is an unfortunate design necessity to which the user would prefer to be completely oblivious.

A product manager who represents these design specifications as requirements is doing the company a disservice. It constrains product designers' creativity. Instead of thinking creatively about how they can completely shield the user from the burden of backing up files, they assume that the user must be saddled with this task, and any design work merely tinkers around the edges of making it easy.

Wednesday, August 09, 2006

SC Johnson and Brand Extension

In February, I wrote about how to maintain focus and avoid brand extension by creating a new brand name. Now Laura Ries examines SC Johnson and its line of shaving care products.

SC Johnson's highly successful male-oriented brand of shave gels is Edge. Ries praises SC Johnson for opting for a separate brand, Skintimate, when it introduced a line of shave gels for women.

I am not sure whether introducing a separate brand was all that important in this case. What did "Edge" mean in the mind of the consumer? Would introducing "Edge for Women" have undermined the existing Edge brand? Sometimes line extension dilutes the brand, and we need to be cognizant of this fact. Even more undesirable, however, is undermining the original brand. I'm not sure if "Edge for Women" would have undermined the original meaning of "Edge" in the consumer's mind.

Ries writes that "Edge" originally meant "gel" in the consumer's mind. While the idea of a shave gel for women doesn't undermine this meaning, trying to extend the Edge brand into shaving cream does. So she recommends that SC Johnson, if it really wants to diverge from the gel category, should attempt to create a new brand name and a new category instead of extending the Edge brand. Seems like sound advice to me.

Tuesday, August 08, 2006


CNet News has a story about HopStop, a service that enables you to plan trips on mass transit from your cell phone:
Google Maps, Yahoo Maps, and even the old-school Mapquest are good at giving you driving directions. But they're pretty bad if you're walking, and they can't help you find your way via public transit. But a New York company, HopStop, can do this routing for you.
A similar service exists in Austin, Dallas, and Houston. Unlike HopStop, it's in stealth mode. Contact me if you're curious or want to be a beta user.

Monday, August 07, 2006

Focus and Bob FM

The apparent success of Austin's KBPA radio station raises some interesting questions about the principle of focus.

KBPA is one of many Bob FM stations around the US and Canada. They all play a wide variety of music from the past four decades. In fact, the Austin station proclaims, "We play anything." Most radio stations focus on a particular genre of music, such as country, hip hop, or classic rock. Along comes Bob and differentiates itself by playing anything.

Is Bob's product focused?

In one sense, it's clearly not focused. It spans the standard musical categories. Until recently, conventional wisdom said that they would be doomed because they had "no format".

But branding and focus are not just about established categories in an industry. Branding and focus are about creating new categories in the mind. If the mind can conceive it and differentiate it from other categories, then it can be a category. There is no reason to stick to established categories. In fact, you're best off creating a new one.

A caveat to keep in mind: focusing on a category shouldn't be your only concern. Focusing on a well-defined psychographic segment of the market is also important.

Sunday, August 06, 2006

Strategy and Product Management

The strategies you use to market your product include:
  • positioning
  • primary marketing media (word of mouth, PR, advertising)
  • approach to pricing
These stategic aspects of marketing contrast with tactics, the details of executing these strategies. In general your marcom team should be handling such tactical activities as coordinating events, planting of stories in the media, and designing brochures. But who should be performing the strategic activities? Are you an executive making strategic decisions based solely on your industry experience or gut feel? If so, consider involving your product manager or a product management firm to provide a solid foundation for your decisions.

Sound strategic marketing decisions are based on:
Don't be fooled by tactical marketing companies that masquerade as marketing strategy firms.

Saturday, August 05, 2006

Forgiveness and Macs

Late this week, a number of news stories mentioned a security flaw in Apple Macbook computers. I yawned as I read the headlines, but then I came across this one.

It contains these delicious quotes:

[T]he presenters said they ultimately decided to run the demo against a Mac due to what Maynor called the "Mac user base aura of smugness on security."

"We're not picking specifically on Macs here, but if you watch those 'Get a Mac' commercials enough, it eventually makes you want to stab one of those users in the eye with a lit cigarette or something," Maynor said.
No matter how hard I laughed, I still oppose violence and believe in forgiveness.

UPDATE: On the other hand, there's more to the story.

Friday, August 04, 2006

What is Consensus?

People often balk at the notion of consensus-based processes and decision-making. In my opinion, what the naysayers usually fail to realize is:
  • Consensus does not require that every person participate in every decision. Often consensus means agreeing to trust a single person to make a decision.
  • Consensus doesn't always have to apply to a decision. Sometimes it's enough to gain consensus for a process to come to the decision.
  • Consensus doesn't always require agreement. Sometimes it's enough for a participant to merely go along with a decision with the understanding that the group will learn from the consequences.
Above all, consensus requires creativity and leadership.

Thursday, August 03, 2006

Rice vs. Ries

Jennifer Rice and Laura Ries have a respectful but lively debate going on about focus and brand extension. Also note Scott Miller's insightful comments.

Wednesday, August 02, 2006

Amazon's Lack of Focus, Revisited

Early this year, I questioned the wisdom of Amazon's expanding its brand scope from online book shopping to online "everything" shopping. I pointed out that Al Ries and Laura Ries had all but predicted dire consequences for Amazon, but that trends in the stock price didn't look too bad at that time.

Well, late last week the Washington Post told us that:
It was the sixth consecutive quarter the company showed a decline in profit, sending the company's stock price down 22 percent Wednesday in Nasdaq trading.
Indeed, the one year stock chart for Amazon doesn't look good at all:

The article also tells us that, instead of narrowing its focus, Amazon is entering the grocery and movie businesses.

Amazon has a great name and built a great brand when it stood for "online books". Now I fear the warnings of Ries and Ries are coming true.

Tuesday, August 01, 2006

Do Products Create Needs?

Kathy Sierra writes:
The world never needed the iPod until Apple created it. Now, look how many of us could not live without it.
She refers to products creating a need where there wasn't one before. I prefer to characterize such products as exposing a need or a dormant problem.