Tuesday, December 26, 2006
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.
Monday, December 25, 2006
Six Principles of Stickiness
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.
Sunday, December 24, 2006
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.
Saturday, December 23, 2006
Cheesepodding
Friday, December 22, 2006
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:
But my comment wasted a lot of words to state what Asher Sterkin crystallized in a later comment:
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.
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.
Thursday, December 21, 2006
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:
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:
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.
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.
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.
Wednesday, December 20, 2006
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:
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.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.
A second brand allows a company to expand while still protecting the integrity of its core brand.
Tuesday, December 19, 2006
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.
Monday, December 18, 2006
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:
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.

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.
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.
Sunday, December 17, 2006
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.
Saturday, December 16, 2006
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."
"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 AmendmentGuess before doing a Google search :-)
b. Nadine Strossen, ACLU President
c. Al Gore, former U.S. Senator
d. William Brennan, former U.S. Supreme Court justice
Friday, December 15, 2006
Customizability

Thursday, December 14, 2006
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".
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".
Wednesday, December 13, 2006
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:
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.
[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.
Tuesday, December 12, 2006
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.
It's a case study in the importance of maintaining focus and consistency.
Monday, December 11, 2006
Constraint-Based Use Case Versions

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)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.
Maintain Comfortable Temperature (medium usability)
Maintain Comfortable Temperature (high usability)
Sunday, December 10, 2006
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:
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.

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)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.
Purchase Items (cash, receipt)
Purchase Items (cash and check, receipt)
Purchase Items (cash, check, credit, receipt)
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.
Saturday, December 09, 2006
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.
Friday, December 08, 2006
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.
Thursday, December 07, 2006
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.
Wednesday, December 06, 2006
Categories: Roundup
Here is a roundup of my series on the concept of categories in marketing strategy:
- Categories: Introduction - Defines what a categoy is and why it is so important in marketing.
- Categories: Naming - Describes the advantages of, and guidelines for. naming a category.
- Categories: Expansion - Describes how expanding a category can be more important than increasing market share.
Tuesday, December 05, 2006
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:
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:
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.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.
Monday, December 04, 2006
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.
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.
Sunday, December 03, 2006
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.

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.
Saturday, December 02, 2006
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.
Via Austinist.
Friday, December 01, 2006
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);
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.
[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.
But even in cases where brand strength is less important, clear and consistent positioning still matters.
Subscribe to:
Posts
(
Atom
)