End of Year Hiatus

I am taking a vacation from blogging for the rest of the week. Look for posting to resume at the turn of the new year.

Six Principles of Stickiness

Chip and Dan Heath have written a book, Made to Stick. In it, they explore the importance of "stickiness". An idea is "sticky" if it tends to stick in the minds of people exposed to it. But the stickiness is not just a property of the idea itself, but of the presentation of the idea.

According to the Heath brothers, the six principles of stickiness are:

• Simplicity. Strip your idea down to its core and relentlessly prioritize.
• Unexpectedness. Violate people's expectations; be counterintuitive.
• Concreteness. Express your idea in terms of concrete actions or sensory information, not jargon.
• Credibility. Enable people to test, at least mentally, the idea for themselves.
• Emotions. Tap into gut feelings.
• Stories. Enable people to rehearse a situation or associate your idea with a story and retell it.

Your brand is an idea in the mind of the consumer. Make it stick.

Panasonic Attacks Its Own Products?

A story in today's New York Times describes how Panasonic is praising plasma technology and criticizing LCD technology. Though Panasonic is the leader in plasma TVs, it also sells LCD TVs. The screen sizes of the LCD TVs Panasonic sells are smaller than those its competitors sell, and Panasonic rather conveniently insists that it's mainly the larger LCD TVs that are problematic. Still, it's interesting to see a company criticizing a technology it uses in some of its products.

Cheesepodding

A Yahoo story tells us about some interesting new terms:

• ego-surfing
• crackberry
• google-stalking
• cyberchondria
• photolurking
• wikipediholism
• cheesepodding

I have to say that my favorite is "cheesepodding". Check out the article for the definitions.

The Time-Boxing Rule

In a recent entry on the Managing Product Development blog, Johanna Rothman wrote about time-boxing and just how strict teams should be about adhering to the prescribed duration of an iteration. Her inclination, which I share, is that a team should generally adhere strictly to iteration time-boxes.

I wrote the following comment:

In my opinion, an organization that can't handle this sort of problem doesn't really know agile. Agile is all about discipline and constant adjustments. One of the main reasons for time-boxes is to force us to think creatively, on the fly, about how to meet them.

We should expect to fail to meet our original objectives in some iterations. When we can't meet those objectives, we change the objectives such that they are (1) achievable within the time-box and (2) yield something "releasable". Inability to make this sort of adjustment indicates a failure of imagination.

That said, I think a healthy, experienced agile team can adjust time-boxes slightly. But the scenario you describe sounds much more like a failure of discipline and creativity than a candidate for slipping the time-box.

But my comment wasted a lot of words to state what Asher Sterkin crystallized in a later comment:

In my experience timeboxing (as any other good practices: sport, diet, etc.) follows the simple rule: "who wants to do it finds a way, who doesn't want finds an excuse."

Thank you, Asher.

On So-Called "Business Requirements"

Over on the Requirements Defined blog, Dan notes that a prudent product manager reviews requirements with various stakeholders and team members early and often:

At all stages in the process, there should be time devoted to validating the requirement with the relevant team members. When a review and approval step is skipped, the requirement and the dependencies for that requirement are placed at risk.

Yet, in his entry, Dan unintentionally provides a good example of how confusion over an alleged distinction between "business" requirements and more "detailed" requirements can result in overlooking the real requirements altogether.

Let's examine all the alleged "levels" of requirements:

By requirements I mean everything from high-level business needs (e.g. stakeholder requests, business requirements, vision and problem statements) to the most granular requirements (aka shall statements, functional and supplementary requirements and the like).

The point of Dan's overall entry is well taken, and I'm sure that he had no intention of getting sucked into yet another semantic debate about the definition of "requirement". But I see substantive problems with the following statement:

Does a tester have to review a stakeholder request like “Business wants to provide upsell and cross-sell opportunities based on items browsed/purchased on the website.” Probably not, but the business does. They need to validate the functional features that will execute this requirement.

Requirements should, in principle, be testable. The stakeholder request is far too vague to be testable. Your product manager's job should be to engage the stakeholder in a dialog that brings out precisely what "upselling" and "cross-selling" are, why they are important, and how to measure them. Merely "providing the opportunities" is useless if the opportunities don't translate into measurable sales, or at least measurable clicks or page visitations.

Worrying about "validating the functional features" is relatively unimportant when the success metrics are in place. A significant cause of problems in many organizations is a tendency to go from vague stakeholder requests to features or low-level functional specifications. Neither stakeholder requests nor low-level functions are requirements. Only when organizations recognize this fact are they likely to identify the real, measurable, solution-independent requirements.

Lesson: Launch a Second Brand

Will Laura Ries ever stop blogging about brand extension? I hope not. As often as she blogs about it (to the exclusion of just about any other topic), the tendency of companies to pollute their brands with extensions isn't going to stop any time soon.

In her latest entry, she gives several examples of brand extension failures. She starts by setting her sights on the new eBay Express extension, and she links to a Wall Street Journal article noting that it "isn't selling well". Then she moves on to Volvo convertibles and others.

She concludes with a constructive suggestion:

A better strategy is to launch a second brand. As Toyota did with Lexus. As Sony did the PlayStation. As Apple did with iPod. As MTV did with VH1.

A second brand allows a company to expand while still protecting the integrity of its core brand.

If you're an executive considering changing your focus to expand into new markets, consider the liabilities of brand extension and the possibility of launching a new brand instead.

Quote of the Day

"A commodity is only a commodity if you treat it as one." Seth Godin tells us that sometimes company values distinguish a product from its competitors.

Backwards Compatibility Requirements

When your company upgrades a product, you and your product manager may concern yourselves with backwards compatibility.

Backwards compatibility refers to the extent to which the upgraded product works with existing ways of using the product. The upgrade may introduce new features and new ways of interacting with the product. But if a user can interact with the new version in the exact same manner and achieve the exact same results as with the old version, then it is fully backwards compatible.

However, backwards compatibility is not an end in itself. It avoids the following problems associated with existing users' lack of familiarity:

• Relearning/retraining. To use a product that isn't backwards compatible efficiently, a user may undergo a punitive learning curve to get up to speed.
• Mistakes. A user unfamiliar with the new interface may be more likely to make mistakes while using the product, causing possible physical, psychological, or monetary damage.
• Fear of upgrading. Even if upgrading would be worth it from a cost/benefit perspective, users may be reluctant to buy or use the new version.

Your product manager should generally avoid making backwards compability a requirement. Instead, the requirements should include measurable constraints on the learning curve and the probability of destructive mistakes. The testing team should create and execute tests that ensure the upgrade meets these constraints before release.

Some degree of backwards compatibility will likely be a part of satisfying these requirements, but designers may find superior ways of satisfying them. For example, a designer may conceive of a new user interface that is so much simpler that it's easier to learn the new way of using the product than it is to use it the old way.

Armed with metrics showing that the learning curve and risk of destructive mistakes are minimal, your sales team has a powerful way of overcoming the fear of upgrading, regardless of whether the upgrade is backwards compatible.

Positioning Exercises

One way to determine whether you need market research and strategy help is to go through a positioning exercise. Follow the steps I outline in my series on positioning. If you find yourself having trouble answering any of the questions, or even if you have trouble justifying your answers to a disinterested party, you likely need to understand your market better or reconsider the principles of marketing, which are often counterintuitive.

First Amendment Quiz

Who argued that the appointment of congressional chaplains, a tradition that continues to this day, is a violation of the First Amendment to the U.S. Constitution:

"Is the appointment of chaplains to the two houses of Congress consistent with the Constitution, and with the pure principle of religious freedom? In . . . strictness the answer on both points must be in the negative."

a. James Madison, framer of the First Amendment
b. Nadine Strossen, ACLU President
c. Al Gore, former U.S. Senator
d. William Brennan, former U.S. Supreme Court justice

Guess before doing a Google search :-)

Customizability

Beware of "customizability" as a key attribute of your product. While it can be a very important and powerful attribute, it can also be a sign that your product doesn't address a focused set of problems in the marketplace. If you can't point to three or fewer compelling problems in the marketplace that would be enough to drive customers to buy your product, you might be tempted to make your product "customizable" so that it addresses any need a customer might have. Instead, either gain a better understanding of your customers, or strongly consider the possibility that your product just doesn't have a good value proposition.

Google's Category Confusion

In my last entry, I wrote about Donald Norman's contention that Google is more "complex" than Yahoo, and that users like complexity. While I mostly disagree with Norman, I think his arguments raise some interesting questions about categories and some challenges for Google.

The crux of the issues is whether Google is a web search engine or a portal. Yahoo is a portal. Its primary business is as a central starting point to provide access to various content and services. As such, its front page is "busy" and contains many links in addition to a search engine.

As a search engine, Google is the market leader and a powerful brand. But Google is not the market leader as a portal.

Portals and search engines are different categories of products. Google as a brand can't be as successful straddling both categories as it can by focusing its brand on one category. To be most successful in search, it needs to keep the clean, search-oriented look of its front page. To be most successful as a portal, it would have to clutter its front page with links and addtional services.

Google does offer various services that don't fall squarely into the search category. Gmail, though it provides excellent search capabilities, is an e-mail client. Google Calendar is an impressive on-line application, but it's more of an organization tool than a search tool.

Some of these services are diluting Google's brand. They by no means cause people to view Google negatively, but they do have an effect on the extent to which people equate "Google" with "search".

Donald Norman on Simplicity

Donald Norman recently wrote an odd column singing the praises of complexity. He challenges the conventional "do one thing and do it well" wisdom:

[P]eople want the features. [S]implicity is a myth whose time has past [sic], if it ever existed.

In a related article about Google, Norman wrote:

Why are Yahoo! and MSN such complex-looking places? Because their systems are easier to use [than Google's].

Yes, I did a double-take when I read that statement, too. Visiting the Yahoo home page to perform a web search takes longer than visiting the Google home page to perform a web search, if just because of the time it takes for a browser to load the Yahoo home page.

Yet Norman's claim is actually that Google is more complex for users who are trying to do something other than search. He has a point. If Jane goes to the Google home page to check her Gmail account, she probably has to go through more time and effort than Joe trying to get to his Yahoo Mail account from the Yahoo home page. The reason is that Google's home page is so sparse that it's not obvious how to get to Gmail from it. Yahoo, on the other hand, has a potpourri of links on its home page, including to its mail service.

But the obvious point that Norman seems to miss is that Google has a more popular, more profitable, and more beloved search engine than Yahoo. Simplicity is winning the search engine battle. Norman's example of Google and Yahoo undermines his own criticism of simplicity.

Nonetheless, underlying Norman's observations about Google are some important lessons about categories and some genuine challenges that Google faces. I will describe some of these lessons and challenges in my next entry.

Ries on Acura and Lexus

Al Ries examines the Acura and Lexus brands in this YouTube video.





It's a case study in the importance of maintaining focus and consistency.

Constraint-Based Use Case Versions

As I mentioned yesterday, when you divide a use case into versions and distribute them among iterations, you can divide them along feature lines or requirements lines. When you divide use cases into versions along requirements lines, you relax certain constraints (nonfunctional requirements metrics) that are attached to the use case. Your team implements the most relaxed version in the first iteration. The team then implements progressively more stringent constraints in each succeeding iteration, culminating in a final iteration in which they implement the original, unrelaxed constraint.

Imagine a use case for your product is to maintain a comfortable temperature. Some of the associated nonfunctional requirements are usability constraints limiting the amount of time and effort it takes for a user to achieve this goal. Yet it could be that the functionality - not the usability - is the most challenging and risky requirement for developers to implement.

To enable the developers to implement a version of the use case in the first iteration, you can relax the usability constraints so they can focus on the functionality. As they iterate, the developers progressively incorporate the more stringent constraints:

Maintain Comfortable Temperature (low usability)
Maintain Comfortable Temperature (medium usability)
Maintain Comfortable Temperature (high usability)

Keep in mind that the purpose of iterating is to accommodate change. You should expect the use case versions in the iteration plan to change as you learn from early iterations. Sometimes these changes will be as simple as tweaking the stringency of the constraints. In other cases, you may have to take the more serious step of relaxing other constraints or deferring the implementation of use case versions further in the iteration cycle.

Use Case Versions

Last year, I touched on the concept of use case versions. A use case version is a use case with simplifying assumptions attached to it. Use case versions help with incremental delivery, scheduling, and product roadmaps.

Use case versions help with incremental delivery by enabling shorter iterations and releases. With incremental delivery, you should be iterating on the development of the product and "releasing" the product for testing and feedback after each iteration. But often a use case is far too complex to implement within a single iteration time-box. In such situations, you can implement a succession of simplified versions of the use case instead.

For example, imagine your organization is implementing an e-commerce web site. One of the highest-level use cases (perhaps even the only use case at the requirements level) is Purchase Items. You've attached various nonfunctional requirements to this use case regarding usability, payment flexibility, etc. It's unlikely that your developers will be able to deliver a fully tested implementation of the use case that satisfies all of these requirements in a single two week iteration.

What to do? Throw up your hands and extend the length of the iteration? No need. Instead, divide the use case into versions:

Purchase Items (cash only, no receipt)
Purchase Items (cash, receipt)
Purchase Items (cash and check, receipt)
Purchase Items (cash, check, credit, receipt)

Now your developers can realistically implement each version of the use case within the two-week time-box. Furthermore, they can deliver concrete, end-to-end user value at the end of each iteration.

Note that the simplying assumptions in this example were feature assumptions. It is a feature of the system to support credit payments. It is a feature of the system to support receipts. Such features represent design choices to satisfy the nonfunctional requirements. Scheduling the incremental delivery of a system is not a requirements activity.

You can, however, divide use cases into versions along nonfunctional requirements lines. To do so, you loosen the constraints (rather than features) on the first iteration and attach progressively more stringent constraints in succeeding iterations. My next entry will explore a specific example of constraint-based use case versions.

Equal Protection Clause

The equal protection clause is part of the 14th Amendment to the U.S. Constitution. It states:

All persons born or naturalized in the United States, and subject to the jurisdiction thereof, are citizens of the United States and of the State wherein they reside. No State shall make or enforce any law which shall abridge the privileges or immunities of citizens of the United States; nor shall any State deprive any person of life, liberty, or property, without due process of law; nor deny to any person within its jurisdiction the equal protection of the laws.

Some interesting facts about it:

• It was passed in the "rump" Congress after the Civil War. The "rump" Congress excluded representatives of the Southern states.
• The Radical Republicans pushed it through Congress.
• Ratification by Southern states was a condition of their reacceptance into the Union.
• The framer of the clause, John Bingham, expressly intended for the clause to apply all preceding amendments - some of which had previously applied only at the national level - to the states.

The equal protection clause was therefore a radical concept. People can differ about whether the circumstances surrounding its passage were fair or legitimate. To truly adhere to the original understanding and purpose of the clause, however, a judge should apply it broadly and boldly.

Igor Naming Guide

Check out the Igor naming guide. It seems that more naming and branding companies are learning the ugly truth about descriptive brand names.

Design Is Your Box

We all know that "thinking outside the box" fosters innovation. Design is the box. Thinking outside the box means understanding the problems you want to solve without design constraints. Requirements help you understand the goals that lie outside the box. Requirements foster innovation.

Categories: Roundup

Here is a roundup of my series on the concept of categories in marketing strategy:

1. Categories: Introduction - Defines what a categoy is and why it is so important in marketing.
2. Categories: Naming - Describes the advantages of, and guidelines for. naming a category.
3. Categories: Expansion - Describes how expanding a category can be more important than increasing market share.

Hope you enjoyed the series!

Categories: Expansion

If you're the leader or first in a category, you should strive to expand it. Rather than try to increase your market share, increase the size of the pie. As the market leader, you generally will benefit
proportionately more than your competitors (especially if you don't have any yet).

As Al Ries and Laura Ries wrote in The 22 Immutable Laws of Branding:

When you're the first, you can preempt the category. You are the only brand associated with the concept. You have a powerful publicity platform. You need to put your branding dollars behind the concept itself, so the concept with take off, pulling the brand with it.

What happens when competition appears, as it inevitably does? Most category leaders just can't wait to shift into brand-building mode. That's a mistake. Leaders should continue to promote the category, to increase the size of the pie rather than their slice of the pie.

Try to create a new category with a product that is so focused it has no share in a pre-existing market. Then market the category so that your product benefits.

Categories: Naming

If you manage to create a new category and be the first in it, you have a chance to name the category. You can introduce the category name in your marketing literature and PR campaigns.

The guidelines for choosing a category name differ from the guidelines for choosing a brand name. While descriptive brand names are a bad idea, a category name is by nature descriptive.

"Xerox" was a powerful brand name that dominated the "copier" category. The brand name was a blank slate, not descriptive of anything [at least to the average person; see the comments], especially of the product. The category name, on the other hand, was a straightforward description of the product's function.

The main guideline in choosing a category name is to ensure it clearly conveys that the product(s) in it differ significantly from products in existing categories. Such a category name aids in the marketing of your product, as it makes it easier to position it versus the competition.

Categories: Introduction

Products typically fall into categories. Hertz is in the rental car category. Toyota is in the car category. Symantec is in the security software category. Xerox is in the copier category. Categories, at least to the extent they are relevant, exist inside in the minds of consumers.

The most powerful position for your brand to occupy is to be synonymous with a category. If your brand is synonymous with a category, it means that people automatically think of your product when they think of the category, and vice versa. They don't think about the competition.

If possible, you should strive to create a new category and have the first and only product in it. Remember, though, categories exist in the mind. So you have to create your new category in the mind.

Stay tuned for more on categories and how your marketing can affect them.

Chuy's, an Austin Original, Sold

It's the end of an era. The owners of my favorite Tex-Mex restaurant, Chuy's, have sold to a "private equity group". The original owners will still sit on the board of directors, but I wonder if the unique character of the restaurants will deteriorate over time.

Via Austinist.

When Is a Brand Important?

When is a brand important? Are there industries or business models in which the strength of a brand doesn't matter very much? Geoffrey Moore argues that branding isn't as important for businesses selling complex products to other businesses (B2B);

[W]hile [brand value] has extraordinary relevance to B2C volume operations enterprises, it has virtually no relevance to B2B complex systems enterprises.

The importance of brand strength hinges on the nature of the buying process.

With high-dollar custom services, the most effective sales approach usually is to facilitate a dialog with the customer to come to a mutual understanding their situation, problems, the implications of those problems, and the associated needs and payoffs. In such cases, the demonstrated understanding of the needs of the particular customer is often much more important than brand perceptions.

On the other side of the spectrum are products that address well-understood problems. The sales process for those products is more focused on demonstrating an ability to deliver the solution. A strong brand greases the wheels by tapping into preconceived notions of quality and credibility.

But even in cases where brand strength is less important, clear and consistent positioning still matters.