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

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.

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


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.

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

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:

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.

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

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:
  • 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.

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

Friday, December 15, 2006


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.

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

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:

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

Monday, December 11, 2006

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.

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

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

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:

  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!

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

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.

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.

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.

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);
[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.

Wednesday, November 29, 2006

Color Simplicity and Laura Ries' Dirty Mind

Laura Ries has a funny and informative entry on her blog about brand names and colors. She maintains that colors can be powerful aspects of a brand, and that focus and simplicity in color schemes is generally better.

Tuesday, November 28, 2006

Let Your Brand Die

What do you do if you have a mature brand that is well-known and perceived positively, but the products that it stands for in the mind of the consumer are obsolete or no longer valuable? It's tempting to try to preserve the brand but attach it to a new product that isn't obsolete.

According to Al Ries and Laura Ries, however, you should let the brand drown and possibly launch a new brand and product.
If the tide is against you, the best strategy is to let your brand drown and launch a new brand to take advantage of the next wave. Smith-Corona should have launched a personal computer with a different brand name.
Smith-Corona was once a powerful brand in the typewriting business. The advent of personal computers and word processors made typewriters - and the Smith-Corona brand - obsolete. Trying to launch a Smith-Corona line of personal computers would have been pointless.

Monday, November 27, 2006

Sunday, November 26, 2006

Requirements Concepts

Confusion over product requirements terminology and concepts is pervasive. Companies are producing MRDs, PRDs, and SRSes without even understanding what "requirement" means. Despite this wasteful and unnecessary requirements document proliferation, companies are neglecting key nonfunctional requirements.

To help educate the product management and development community, I have put together a comprehensive model of concepts relating to requirements. To view or download the full-size conceptual model, click the image below:

(See my post on conceptual models if you have trouble understanding the diagram.)

A sampling of the terms that the conceptual model explicates:

  • functional requirement
  • nonfunctional requirement
  • attribute
  • constraint
  • metric
  • specification
  • condition
  • user
  • stakeholder
  • use case
You are free to distribute, copy, or print out the diagram, but please do not remove the copyright information on the bottom right.

Saturday, November 25, 2006

Free International Calls

With Future Phone, you can make international phone calls for free (or the cost of a call to Iowa). You simply:
  1. Dial a gateway access number (either 712-858-8883 or 712-945-1111).
  2. When the gateway answers, enter 011 then the country code and number you want to reach.
  3. Wait a few moments for your call to ring through and then enjoy your free call.
I've added Future Phone as a contact on my mobile phone.

Friday, November 24, 2006

Marketing Equals Margin

According to Wendy White, Motorola's director of global technology marketing and communications, Motorola has a healthy view of marketing.

She equates marketing with margin:
People here like to think of marketing as equal to margin—which comes from enabling brand premium and creating demand.
She also describes Motorola's attitudes towards marketing:
In many companies, it's easy for marketing to be seen as a service organization: Non-marketers are thinking, "We'll do the work; you make it pretty." At Motorola, we focus marketing on discovering what's important to the customer and then positioning our offerings based on those distinct needs. It has also helped that our new CEO comes from a high-tech marketing background and has further revitalized perceptions of marketing. Now, our marketing team seems like one unified function, compared to the more fragmented feeling we had earlier.
Via MarketingProfs.

Thursday, November 23, 2006

Asking Questions Sideways

Crafting a customer survey is not as straightforward as it seems. You shouldn't simply ask the questions you want answered, as I've mentioned. The most valuable information usually comes from analyzing the correlations among the answers to the survey, not from merely looking at the responses to individual questions.

Susan Abbott tells us about sideways questions:
If we really want to find the answer to this question, we are going to have to come at it sideways somehow. Most commercial survey research uses multivariate techniques to tease out these kinds of findings. Like connecting the strength of your agreement with attitudinal statements (e.g."it is important to belong to prestigious business organizations") with your stated likelihood of renewing your membership.

In qualitative research, we cook up exercises of various sorts, instead of just asking the literal question directly. [It's also because most of us really like to play with colored markers and Post-it notes, although that's just a corollary benefit.] Sometimes, we may just ask what you think others do, not what you yourself do.
She goes on to describe how to use the randomized response technique to obtain the answers to uncomfortable personal questions.

Wednesday, November 22, 2006

Irregular Reinforcement

Seth Godin reminds us that
Irregular reinforcement is a hugely powerful message sender.
Last year, I called it surprise rewards. If it's too expensive to surprise and delight every customers every time, surprise them randomly. Send one of them a remarkable gift for no reason at all.

The reason surprise rewards are so powerful stems from congruity theory (which also is the primary reason you shouldn't choose a descriptive name for your brand). Congruity theory states that encounters incongruent with expectations cause people to apply inordinate mental effort to resolve the incongruency.

Tuesday, November 21, 2006

Implicit = Nonfunctional?

One of the product development community's favorite bloggers (and mine, too), Johanna Rothman, recently wrote about a negative experience she had with a product:
Even though I managed to accomplish the tasks I needed, the time it took me to accomplish them and the foreign approach to the UI made me not happy. Implicit requirements are still requirements.
Is the time it takes to accomplish a task really an "implicit requirement"? I think not. It's one of the primary metrics we use to ensure usability, and hence a standard nonfunctional requirement.

I have little doubt that most product managers neglect this metric in their requirements documents. But that neglect isn't due to the requirement being "implicit". It's due to the general tendency of product managers to pay excessive attention to alleged functional requirements that are in fact functional designs, to the exclusion of nonfunctional requirements that drive them.

Monday, November 20, 2006

Peanut Butter and Focus

CNET News tells us about an internal company memo at Yahoo. A senior VP at the company warned in the memo that the company lacks focus:
"We want to do everything and be everything--to everyone. We've known this for years, talk about it incessantly, but do nothing to fundamentally address it. We are scared to be left out..."
The internal memo, dubbed "The Peanut Butter Manifesto", continued:
"I've heard our strategy described as spreading peanut butter across the myriad opportunities that continue to evolve in the online world. The result: a thin layer of investment spread across everything we do and thus we focus on nothing in particular. I hate peanut butter."
It takes tremendous discipline to maintain focus in your product and its marketing.

Sunday, November 19, 2006

Paul on SMEs

Paul at the Product Beautiful blog hits the nail on the head:
First, develop to your average user, not your subject matter experts. SME’s will feature pack your product with interesting features of dubious usefulness to the rest of the Market. Worse, they will mutate core features (armor and firepower) to the extreme, and you’ll end up with a scenario where you have important features that should solve user’s problems but are so bloated that they are unrecognizable or hard-to-use (Macros in MS Word, Adobe Download Manager, the HTML blink tag, etc). BTW, Engineering/Development are super-SME’s, so don’t let them define the product - ever!
SMEs are a valuable resource, but the primary source of requirements should be buyers and end users, as I have mentioned.

Saturday, November 18, 2006

Pat Buchanan and Ali G

Funny exchange from the Ali G show before the 2004 election:
ALI G: "Does you think that Saddam ever was able to make these weapons of mass destruction or whatever, or as they is called, BLTs?
Mr. PATRICK BUCHANAN: "The--was Saddam able to make them?"
ALI G: "Could he make BLTs?
"Mr. BUCHANAN: "Yes. At one time, he was using BLTs on the Kurds in the north. If he had anthrax, if he had mustard gas..."
ALI G: "Whatever he put in them."
Mr. BUCHANAN: "No. No, no. If he had mustard gas, no."
ALI G: "Let's say he didn't have mustard and the BLTs just was plain. Would you have been able to go in there then?"
Somehow Ali G tricked Pat Buchanan into referring to WMDs as BLT sandwiches.

Friday, November 17, 2006

Conceptual Models

One of the most useful tools for explicating the terminology of customers is a conceptual model. Conceptual models depict the concepts in the problem domain and their relationships.

At Cauvin, Inc., we compose conceptual models in the form of static structure diagrams. Conceptual models resemble glossaries (in that they define the words in the domain), but they are richer and more concise.

Here is an example of a conceptual model:

Conceptual models in this format contain the following elements:
  • Concepts. Each rectangular box depicts a concept.
  • Links. A line between two concepts shows that an association exists between them.
  • Association. The name of an association is shown on or next to a link between two concepts.
  • Multiplicities. Multiplicities show how many instances of the concepts participate in the association. An asterisk (*) means that an indefinite (potentially infinite) number of instances participates in the relationship.
  • Specialization. A specialization is a kind of association with a hollow triangle connecting the link to a concept. The concept on the triangle link is the general concept. The concept on the other end of the link is its specialization, which means it is a kind of the general concept.
The example diagram thus directly implies the following statements:
  • A product is sold in zero or more markets.
  • A market is divided into zero or more market segments.
  • A segmentation method is a method of segmenting a market.
  • Regional segmentation is a kind of segmentation method.
  • Regional segmentation segments a market by zero or more regions.
Building a conceptual model helps a product manager understand the language of the customer. The process often exposes inconsistencies or inefficiencies in the terminology that a product manager can eliminate by explicating the concepts as she composes and refines the diagram.

Thursday, November 16, 2006


Explication is the process of analyzing the usage of a word or phrase and formulating a logically consistent definition that clarifies its meaning. Product managers explicate the terminology of customers to settle on the most effective way of wording product requirements and communicating with customers.

Conventional wisdom dictates a product manager should communicate in the "language of the customer". Unfortunately, there is no such single language. Different customers use words in different ways and use different words to describe the same thing. A product manager must therefore navigate this terminological landscape and determine the best words to employ in requirements and customer communications. The product manager should explicate the various alternative terms and, after deciding on an operational meaning for each alternative, select the ones that she judges customers will most readily understand.

For example, imagine your company provides Internet data centers to customers. It focuses on customers looking for high availability in their web sites. A frequently-used word among customers is "server". Yet different customers mean different things when they use the word:
  • Customer A means "the program(s) that process incoming requests and reply with content".
  • Customer B means "the computer(s) that process incoming requests and reply with content".
  • Customer C means "the conceptual aggregate of load-balanced computers and programs processing incoming requests and replying with content."
In your product requirements, how should you define "server"? In the brochures you hand out at trade shows, how should you define "server"?

Explicating the term yields the answer. However, you can only explicate a term in relationship to other terms. In my next entry, I will describe a powerful explication tool that some product managers use to model these relationships.

Wednesday, November 15, 2006

Marissa Mayer on Quick Response Time

Google's Marissa Mayer told an audience at a Web 2.0 conference last week that quick response times are a critical - possibly the most important - contributor to usability. Response time is the amount of time it takes for a product to respond (provide useful results or feedback) to user requests. Slow response times lead to user frustration and less usage of your product.

For example:
In a survey on search, Google asked people how many results they would want by default; they responded that more is better, Mayer said. So the company conducted an experiment, providing some searchers with 30 default results. But it took, on average, a half-second longer to get those results than when the default was 10 results, she said. Out of frustration, people conducted fewer searches.

"This indicated extreme unhappiness," Mayer said. "It was clear that we weren't going to make this change."
A half-second increase in response time resulted in a large increase in frustration and consequent reduction in product usage.

The anecdote also supports the notion that giving customers what they say they want is not always a good idea. Sometimes, you can't know what people want until you observe what they actually do, and what they like, in a given situation.

Tuesday, November 14, 2006

Michael on UI Design and Requirements

Michael recently wrote on his blog:
Right after gathering and prioritizing high-level requirements, get to the User Interface (UI) design. Do this before you complete your MRD or PRD. Yes, before!
This suggestion supports one of the reasons for employing an agile approach to product management. You can't specify all the requirements up front; BUFR is inefficient and unrealistic. When you design a user interface, you "test" the initial stab at requirements and uncover additional usability requirements that nobody had considered.

I would go further than Michael and suggest that organizations produce a "releasable" iteration of the product; i.e. work not only through UI design, but also technical architecture, some detailed design, implementation, and testing. (In some cases, GUI mockups can be the output of the first iteration.) See this entry for more details.

Monday, November 13, 2006

Brandon on Leaders

Brandon writes about two different types of leaders:
  1. Motivational. Communicates vision and strategy, not detail oriented.
  2. Operational. Implement the processes and nuts-and-bolts decisions, detail oriented.
Brandon observes that most organizations are strong in one form of leadership but lacking in the other.

Sunday, November 12, 2006

Zune: The Name

CEO Steve Ballmer, commenting on the name of Microsoft's new media player line, Zune:
It means nothing; it's just a cool name.

Friday, November 10, 2006

Dumping the Mac Guy

Is Apple dumping "the Mac guy", Justin Long? Yes, according to Jackie:
Justin Long, the actor who plays the Mac in Apple's latest rather mean-spirited series of commercials, is no longer doing the ads.
And at the Strategic Name Development Product Naming blog, William Lozito tells us:
I wonder if Microsoft has grasped just what an incredible breakthrough this is for their brand name - Apple has had to register the fact that very few Apple people want to talk about, and it’s this: Apple users are irritating to the rest of us and even to other Mac users.
Looks like I and others are being vindicated.

Thursday, November 09, 2006

Four-Second Response Time

Akamai and JupiterResearch came out with a press release this week stating, among other things, that:
Four seconds is the maximum length of time an average online shopper will wait for a Web page to load before potentially abandoning a retail site.
Much of the time, web surfers do not find what they want when they are browsing. Consequently, they are loathe to tolerate slow response times and pages that require a lot of time and effort to figure out.

Keep your web pages simple - simple so they don't take too long to load, and simple so that users don't have to invest too much time figuring out what to do.

Wednesday, November 08, 2006


"CAPTCHA" stands for ""Completely Automated Public Turing test to tell Computers and Humans Apart". You've likely seen them; web sites use CAPTCHAs to verify that a visitor is human (rather than a computer).

Here is an example of a CAPTCHA:

CAPTCHAs are an attempt to prevent computer-generated spam and other hijinx. Unfortunately, they cause several problems of their own:

  1. They decrease usability by adding to the amount of time and effort it takes for users to accomplish their goals.
  2. Some are difficult for humans to read.
  3. Some computer programs are better able to read them than humans.
Avoid CAPTCHAs if you can find an alternate way of preventing spam.

Tuesday, November 07, 2006

What Women Want

In a recent New York Times article, "What Do Women Want? Just Ask", Mickey Meece contends that female shoppers are causing innovative changes in the marketplace. For example, a homebuilder that used to build cookie-cutter homes modified its strategy after listening to female customers:
The kitchens in the company’s homes, the women said, were all wrong. The pantries were tiny, and the sinks needed to overlook a window so kids in the backyard could be monitored. And the mudrooms! They shared space with laundry rooms, meaning that dirty floors might sit right beneath clean laundry. (“It’s called a mud/laundry room?” one incredulous woman asked.) After that, Shane Homes subjected designs to similar grillings — before they were built — and adapted them accordingly.
A change in the demographics and psychographics of home purchasers created a market opportunity. Shane Homes tapped into this market after conducting qualitative market research.

Monday, November 06, 2006

Field Trips and Career Days

Part of facilitating a successful product team is to have developers that buy into a market-driven vision for the product. Developers have a natural tendency to be motivated by cool technologies and features that may work against a product that solves real problems in the market. Company executives and the product manager can work together to overcome this tendency, but only by building consensus in the development team for a market-driven approach.

One way of fostering buy-in for a market-driven approach is field trips. On top of the normal prospect visits he should be making, let the product manager bring developers to customer sites to observe and experience use (or non-use) of the product in real life. Better yet, have career days in which each developer actually sits in for a customer and plays her role for the day. You will have to get permission from customers, of course, but you have two strong arguments to convince them:
  1. Your team, for free, will do your customers' work for them.
  2. It ultimately benefits the customer for your developers to understand the user experience.
Use the field trips to draw attention to the problems that the product is supposed to solve. Use them to gather new information that developers learn.

A product manager's role is to understand the market and communicate that understanding to the product team. To get buy-in from developers, it's not enough to throw market requirements documents at them. Field trips give developers the perspective they can get only from first-hand experience.

Sunday, November 05, 2006

Descriptive Trademarks

Every once in a while, I feel compelled to reiterate certain counterintuitive marketing principles. One of these principles is that generic or descriptive names make poor brand names.

In his latest blog entry on trademarks, Seth Godin states the truth starkly:
The best trademarks are 'fanciful', words like Yahoo! or Verizon. Next down the list are words that [are] a bit descriptive, like Woopie Cushion, Wikipedia or JetBlue. The worst kind of words are descriptive. Yes, you can trademark the brand American Motors, but don't expect it to be particularly valuable or long lasting.
Trademarks can be names, words, phrases, logos, symbols, designs, or images. Choose trademarks that are abstract, not descriptive. See this August blog entry for a summary of why abstract names are superior.

Saturday, November 04, 2006

Sticky Toffee Pudding Ice Cream

Haven't yet tried Haagen-Dazs Sticky Toffee Pudding Ice Cream? Go getcha some while you have a chance. Wikipedia says it will only be available until January 2007:
Sticky Toffee Pudding was the winning ice cream flavor in the 2005 Häagen-Dazs contest, submitted by Judiaann Woo. Sticky Toffee Pudding ice cream is slated to be produced from July 2006 to January 2007.
It's the best ice cream I've ever eaten. Better than Ben & Jerry's Half Baked. Better than Haagen-Dazs Triple Chocolate. This morning, I bought five pints of it from HEB.

Friday, November 03, 2006

Usability and Single Page Checkout

A company called Elastic Path Software has released a single page checkout technology. Most e-commerce sites lead online shoppers through a sequence of pages to complete a purchase. This framework supposedly uses AJAX to consolidate the sequence into one page.

I haven't seen a site that uses the technology, so I don't know if it really improves the user experience. But how would we measure the improvement in user experience? Are the standard usability metrics enough to capture any purported improvement?

Via Cote.

Thursday, November 02, 2006

Fix Your Product's Broken Windows

In a March 1982 Atlantic Monthly article titled "Broken Windows", James Q. Wilson and George L. Kelling advanced a theory that minor acts of vandalism, such as grafitti or breaking of windows, escalate and tend to increase the incidence of more serious crime. Prevent the small, cosmetic crimes, and the frequency of more serious crimes will decrease.

A similar concept applies to your products. You should focus your product on solving the key problems the customers in your target market face. However, you also need to prevent and fix the "broken windows" in your product. Perceptions of minor, cosmetic glitches in your product can mushroom into a lack of trust in its overall quality. As I've mentioned before, image should reinforce substance.

Wednesday, November 01, 2006


In Why Rebranding Often Fails, Galen De Young notes how challenging it can be to change your brand. He enumerates five reasons for rebranding failure:
  • Lack of true change.
  • Making too big a leap.
  • Lack of Internal alignment.
  • Failure of the CEO to champion rebranding
  • Failure to clarify positioning
Rebranding is usually a bad idea unless your existing brand is too muddled or broad. You're usually better off renarrowing your brand or creating a new brand instead of changing an old one.

Tuesday, October 31, 2006

What is a Brand?

A brand is a set of associations imprinted in the mind of a customer. A brand associates things like names, logos, slogans, and colors with your product and with perceived attributes of your product. These associations can make a brand powerful; as you create a brand, your customers learn to expect certain benefits or attributes from your company or product. The associations also make your company or product more memorable.

Marketers attempt to develop and maximize brand equity, the value of the brand to the company. Strong brands translate into easier sales; sales people build on the existing awareness and perceptions of the product in their pitches instead of attempting, from scratch, to convince customers of the product's benefits.

Monday, October 30, 2006

Sam Decker on "Nevangelists"

Sam Decker writes about "nevangelists". Nevangelists have had a negative experience with your product or company, but after the fact you've somehow surprised and delighted them to the extent that they now have a positive view of it.

One of Sam's interesting hypotheses is that people who complain to you have demonstrated they are vocal, so they would make the best evangelists if you can convert them.

Sunday, October 29, 2006


Last month's Nielsen-NetRatings show that Snapvine.com was the most popular site for teens. Apparently, teens consider MySpace to be so last year. After browsing around the Snapvine site (without signing up for the service or downloading the application), I still can't figure out what it is. It has something to do with listening to, and receiving, voice messages and incorporating them into social networking sites.

I know what problem MySpace solves. What about Snapvine?

Saturday, October 28, 2006


My major in college was philosophy. Ever since I was a kid, I've studied, argued, and thought about philosophical issues. I still find philosophy interesting, but most of my opinions about philosophical issues have solidified, so I don't spend as much time on it.

My interest has shifted to sociology. According to Wikipedia:
Sociology is the study of the social lives of humans, groups, and societies, sometimes defined as the study of social interactions. It is a relatively new academic discipline that evolved in the early 19th century. It concerns itself with the social rules and processes that bind and separate people not only as individuals, but as members of associations, groups, and institutions.
Philosophical ideas are important, but social interactions largely determine happiness and can be extremely powerful forces for change. People with a high emotional intelligence quotient (EQ) have natural instincts and intuitions about sociology. Analytical types, such as I, have to study it to understand basic realities about human relations.

Friday, October 27, 2006

Work to Rule

On page 117 of Peopleware: Productive Projects and Teams, Demarco and Lister tell us about an interesting concept:
In Australia, where striking uses up nearly as much labor time as working, there is a charming form of strike called work to rule. Rather than walk off the job, workers open up a fat book of procedures and announce, "Until you give us what we're asking for, we're going to work exactly to the rule." When the air traffic controllers do this, for instance, they can only land one plane every seven minutes. If doctors were to do it, an appendectomy would take a week. Introduction of a Methodology opens up the possiblility of work-to-rule actions in still more parts of the economy. People might actually do exactly what the Methodology says, and the work would grind nearly to a halt.
Another term for this concept, apparently coined by Ken Orr, is "malicious compliance".

Don't get so caught up in processes and rules that you forget about getting real work done.

Thursday, October 26, 2006

Performance and Usability Requirements

For most products, performance requirements are subsumed by usability requirements.

With most products, users want to achieve functional goals within a certain amount of time. The amount of time it takes to achieve a functional goal is typically one measure of usability. Finer-grained response times can also impact usability, however. If a user clicks a button and nothing happens for ten seconds, the user may get frustrated and will almost certainly wonder what is happening.

So your product manager shouldn't necessarily include performance requirements per se, but should almost certainly include a full suite of usability requirements that include performance metrics.

The exceptions are those products that don't have much of a user interface component. Some products deliver functionality by themselves, largely without user intervention or interaction. The speed with which they deliver such functionality is a matter of performance but not usability.

Wednesday, October 25, 2006

Performance Benchmarks

Kirk Pepperdine has some things to say about performance benchmarks. He notes that:
  • performance is a key part of usability
  • developers and testers often neglect performance requirements or treat them as an afterthought
  • functionally complete demos create a bad impression if they perform slowly
In a future entry, I'll argue that performance requirements are really subsumed by usability requirements.

Tuesday, October 24, 2006

Steve Jobs and Usability

Apple products are reputed primarily for two things:
  • ease of use
  • aesthetics
A Forbes article gives us a glimpse into how Apple has achieved ease of use in its products. Apparently, CEO Steve Jobs insisted that products be usable. Judging by the following quote from an Apple engineer, he did so by insisting on usability requirements without dictating design details:

Steve would be horribly offended [if] he couldn’t get to the song he wanted in less than three pushes of a button.

Design is important. But don't lose sight of the real usability requirements for your product. The real usability requirements are metrics, not functional specifications or UI layouts.

Monday, October 23, 2006

Rationality and Product Preference

About a year ago, for fun, I went to grocery stores and bought as many different kinds of cola soft drinks as I could find, including:

  • Coke
  • Pepsi
  • HEB Original Cola
  • Safeway Select Cola
  • RC Cola
I then proceeded to administer blind taste tests to guests whenever I had people over to my loft. The results were interesting, mainly because what people thought was their favorite cola differed greatly from their actual preference.

Safeway Select Cola performed best overall. Unfortunately, I can no longer find it at the Randall's stores where I originally bought it.

I administered this test to only a few people (about six, if I recall correctly), so take the results with a grain of salt. But chalk this anecdote up as another example of how customers have all sorts of prejudices that interfere with knowing what they really like.

Sunday, October 22, 2006

Product Management and Testing

Product management glues a team together by facilitating a shared understanding of the market and what the product should do. Yet in some organizations product management is detached from testers. Just as product managers shouldn't write MRDs and throw them over the wall to product developers, they shouldn't throw them over the wall to product testers.

Product testers can play an important role in helping to formulate the requirements for a product. While testers may not have a lot of contact with customers, they have keen grasp of whether a requirement is testable, both in principle and in practice. Furthermore, testers are an audience for requirements documentation, as they develop system and acceptance tests from them. A product manager can use testers to help formulate the requirements in a clear and meaningful manner.

Saturday, October 21, 2006

Breaking Rules

A few years ago, the parking lot of my gym was full, so members were struggling to find a place to park. As I parked across the street in a large lot in the same shopping center, I noticed a member parking on the side of the street near the gym. There was a no-parking sign with arrows pointing in both directions, indicating that it was illegal to park there. What was strking about this experience, though, was the fact that the person chose to park right under the sign.

We all break rules. Sometimes breaking the rules is justified, sometimes it's not. I plead guilty to both. But I've noticed that there are certain people who flagrantly violate rules and seem surprised - even outraged - when they are punished for it.

Friday, October 20, 2006

Passwords Revisited

Looks like yet another study has vindicated my peeve about passwords:
A study released on Tuesday by global research firms Nucleus Research and KnowledgeStorm found companies' attempts to tighten IT security by regularly changing passwords and making them more complex by adding numbers as well as letters had no impact on security.

Staff still had a tendency to jot down passwords either on a piece of paper or in a text file on a PC or mobile device.
Read more here.

Thursday, October 19, 2006

Scott on Business Rules, Requirements, and Design

Scott Sehlhorst has a "juicy" entry about the relationship among business rules, requirements, and design. He portrays the relationship as analogous to an onion. As you peel the onion, he contends, requirements lie out on the outside, followed by business rules, followed by design.

In discussing these relationships, Scott raises a number of thought-provoking issues and points, many of which I've addressed (as has Scott) in previous blog entries. I don't entirely agree with his main point about about requirements and business rules. I think the relationship is a bit more complex, as I mentioned here.

Wednesday, October 18, 2006

SMEs and Documentation Specialists

Yesterday, I wrote that product managers should not rely on SMEs as their primary source for requirements. I will now go further and state that, to the extent that a company hires a product manager or business analyst to interact primarily with SMEs, the role names "product manager" and "business analyst" are misnomers.

I see this problem often in companies. They believe they already know the requirements (often confused with design); they are just looking for someone to document them so that developers can get to work. They call the person who does this documenting a "product manager" or "business analyst", but this person in fact has only a small - and very tactical - subset of the responsibilities that these roles entail.

In my opinion, this problem is largely responsible for the misconception that SMEs are primary sources for requirements.

Tuesday, October 17, 2006

SMEs: Not the Primary Source for Requirements

 In April, I wrote about subject matter experts (SMEs) and whether product managers should elicit requirements from them. Reading the entry now, I realize I was not clear enough in the point I was trying to make.

Flatly stated, product managers generally should not rely on SMEs for requirements. Eliciting requirements means identifying the problems that prospective and existing customers face. The primary way to identify these problems is to interview and observe the prospective and existing customers themselves, not supposed experts in the industry or domain.

Product managers should turn to SMEs to gain an in-depth understanding of the concepts in the domain and fill in some blanks that customers miss. But SMEs are not the primary source for identifying requirements.

Consider a bank developing a software product to help its customers balance their checkbooks. The way to gather requirements for the product is to interview and observe the people who balance their checkbooks, not a banking representative who is an expert in accounting. To be sure, an accounting expert might help the product manager with terminology and concepts, but that in no way means she understands the typical user experience. In fact, her perceptions are likely tainted by her expertise.

Now, end users may not be the only stakeholders who determine the requirements. Some of the bank's employees may indeed be important "customers" of sorts. But they are unlikely to be SMEs.

A product manager's role is to be a messenger for the market, not a messenger for domain or industry experts.

Monday, October 16, 2006

"Laptop" of the Future, Revisited

A couple of updates to my recent entry about the merging of mobile phone and laptop computer technology:
  1. Coincidentally, CNET News has a story about smartphone-maker Symbian's executives predicting the death of the laptop. One of the execs said, ""[I]n five years' time you'll wonder why you need a PC at all." They predict smartphone technology will render traditional laptop computers obsolete. But you heard it here first (to my knowledge, anyway).
  2. In a comment, Brandon noted convergence issues. I have written in the past that marketing guru Al Ries believes product categories tend to diverge rather than converge. In my reply to Brandon's comment, I draw attention to a distinction I have made: convergence of product categories versus convergence of technology.
It will be interesting to see what actually happens five, ten years from now.

Sunday, October 15, 2006

Rolling Stones: Are They Worth It?

The Rolling Stones are set to play in Austin October 22nd. I have been a huge Rolling Stones fan for over twenty years. Yet I won't be seeing them play unless I luck into some free VIP tickets. The ticket expense, fighting crowds, hassles getting overpriced food and drink, and waiting in line to use the restroom don't appeal to me. The cost/benefit analysis just doesn't work for me.

Many consumers don't apply such cold cost/benefit analyses to their purchasing decisions, however. After every Austin City Limits Music Festival (an annual musical event here in Austin), friends tell me they will never go to it again. But then the next year they change their minds and go.

Don't assume your customers will have a rational basis for their purchasing decisions. It depends on the nature of your product and the psychology of your target market.

Saturday, October 14, 2006

Selfishness and the Human Brain

The issue of what gives humans and other animals their moral compass is fascinating. Is it the threat of reward and punishment? Is it empathy? To what extent does a fully-developed moral compass require intelligence?

Scientists are making some progress by locating parts of the brain that govern selfish versus selfless behavior.

Friday, October 13, 2006

"Laptop" of the Future

Being an avid user of laptop computers and "smartphones", I have come to the conclusion that the technologies will soon merge.

A "smartphone" is a mobile phone with PDA capabilities. Smartphones have become so advanced that they perform many of the same functions as laptop computers. Phones that run the Windows Mobile operating system, for example, run Microsoft Outlook, Internet Explorer, connect to wi-fi hotspots, play music and video, and run many other applications.

The only things that separate smartphones from laptop computers are
  • Screen size
  • Storage capacity
  • Keyboard
I predict the laptop computer of the future will be a mobile phone to which you can attach a portable but external high-resolution monitor and full QWERTY keyboard.

Thursday, October 12, 2006

Agile and Discipline

Some critics equate agile methods with "hacking". They allege that employing agile methods is really about writing code without requirements, without planning, and without design. Contrary to what these critics allege, true agile methods involve planning, requirements, and design.

What differs from waterfall methods is that agile organizations practice these activities just-in-time. I.e., they plan, but they try not to invest a great deal of time on details that are likely to change. Same with requirements and design. Consequently, they have to constantly revisit and flesh out the details as development progresses. With waterfall methods, you try to complete detailed planning, requirements, and design as if there is little or no risk of them changing.

When you employ agile methods, there are constant temptations to lengthen iterations, put off getting feedback from users, put off revisiting requirements, and blow off writing tests first. Agile is not about hacking; in many ways it requires more discipline than waterfall.

Wednesday, October 11, 2006

Incentives and Viral Marketing

Eric Kintz writes about the dynamics of viral marketing, which he defines as focusing "on leveraging existing social networks by encouraging customers to share product information with their friends."

The observation that stood out to me was:
The probability of viral infection decreases with repeated interaction Providing excessive incentives for customers to recommend actually weakens the credibility of those links. The probability of purchasing a product increases with the number of recommendations received, but quickly saturates to a constant and relatively low probability.
The strength of viral marketing is its credibility. Traditional advertising has lost its credibility. But if you beat people over the head with viral marketing - begging or badgering people to spread the word about your product - it loses credibility, too.

You can help foster word of mouth in two ways:
  1. Create communication channels such as online forums, blogs, etc.
  2. Incorporate symbolic focus in the key messages you use to market your product.
The most credible word of mouth stems from natural excitement of customers, not badgering. Facilitate it instead of forcing it.

Tuesday, October 10, 2006

Atomic Physics Determines the Location of Your Store

Opening up a locally-based enterprise (LBE)? Read here about how a computational physicist uses atomic physics to determine the optimal location for a store.

Monday, October 09, 2006

Features are Proxies

Last week, I bought a digital audio player (MP3 player). I run around Town Lake here in Austin about once per week and like to listen to music while I run. I made sure I bought a digital audio player with USB 2.0 connectivity.

Do I really need USB 2.0? Actually, no. What I really want is to shorten the amount of time it takes for me to transfer files from my PC to the player.

Features are proxies for the things users really care about. Instead of dictating what features should be in your product, product managers should focus on what users really care about. However, they must also take into consideration that consumers use features to simplify their product comparisons and buying decisions.

Sunday, October 08, 2006

Seagate and their Dual-Brand Strategy

In the business of computer hard drives, Seagate recently acquired competitor Maxtor. Maxtor drives are lower-priced than Seagate drives. Rather than bring Maxtor drives under the Seagate brand umbrella, Seagate chose to maintain a dual-brand strategy.

It would have been a mistake to apply the Seagate brand name to Maxtor drives. "Seagate" stands for "speed" in the mind of the consumer. "Maxtor" stands for "capacity on the cheap". People who buy Seagates want high performance drives. People who buy Maxtor drives do so because they want lots of disk space for a low price.

If Seagate were to have combined the brands, the combined brand would have had no focus, and no clear meaning in the mind of the consumer. It would have thereby undermined their ability to sell the higher-priced Seagate models.