Saturday, September 30, 2006

Kinsley on Newspapers

A column by Michael Kinsley recently appeared in Time in which he predicts the demise of newspapers:
Newspapers on paper are on the way out. Whether newspaper companies are on the way out too depends. Some of them are going to find the answers. And some are going to fritter away the years quarreling about staff cuts.
This prediction isn't original, but I haven't seen any other journalist express it so starkly.

Friday, September 29, 2006

Business Analysis: Strategic or Tactical?

Does your company employ business analysts? If so, to what extent is their role strategic versus tactical?

According to Wikipedia:
A business analyst (BA) is responsible for analyzing the business needs of their clients and stakeholders to help identify business problems and propose solutions.
A common activity of business analysts is to document business processes. Business needs typically stem from inefficiencies and problems in these processes. To the extent that your business analysts solely document the processes - as opposed to eliciting and researching them, identifying the inefficiencies and problems within them, and proposing solutions - your BAs have a very tactical role.

There is nothing wrong with such a role, as long as the people performing the more strategic functions are qualified to do so. Be careful about relying on subject matter experts (SMEs). Being experts in a domain doesn't by itself qualify them to analyze business processes and problems.

Thursday, September 28, 2006

How Not to Generate Positive Word of Mouth

Rayfes writes about a case study in how not to generate positive word of mouth for your business:

Stopped by Champion's Sports Bar for lunch today. Hadn't been so figured it would be good to try.

First impression is that it was yet another chain in Austin which isn't surprising since it's in some Mariott derivative hotel by the convention center.

Bartender messed up my order and another guy sitting at the bar. That's ok, it happens and he offered the other guy a free mystery beer.

Later the guy wanted to watch something other than what was playing. There are 3 customers at the bar and 5 tvs. It's Thursday afternoon and not much is going on. The bartender tells him that he's not allowed to change any of the tvs. Customer asks for the manager. Manager doesn't come for 10 minutes. He says that he can't put anything other than sports on (even if it's muted) since they are a "sports bar."

At which point I decide I am not going to come back to a place with overpriced food that won't take care of their customers.

Guess they can join the list with Iron Cactus and a few other places that are too good for their own customers.

It's when you have a only a few customers that you have a great opportunity to go the extra mile to make them happy. Don't blow it.

Wednesday, September 27, 2006

Quote of the Day from Steve Johnson

"Product design is a skill! Hardware is designed by an industrial designer. Why isn't software?"

More here.

Tuesday, September 26, 2006

Marketing Metrics

Roy Young relates a story about Poland and metrics:

In the 1970s, the Polish government set out to make its furniture industry more competitive in the global economy. To that end, the government rewarded furniture factories based on the total weight of their products manufactured. As a result, the citizens of Poland now have the world's heaviest furniture
What you measure and reward is generally what you improve. So Young suggests we, as marketers, concentrate on metrics that are directly relevant to the bottom line (cash flow, revenue). He lays out a procedure for mapping marketing activities to outcomes and metrics.

A pitfall of this approach is that marketers can't control the bottom line. Imagine, for example, all the company's sales reps quit. Revenue will drop no matter what the marketers do. Should they be held accountable?

Monday, September 25, 2006


Hesh Reinfeld has a humorous (hopefully) piece on about supposedly harmless ways marketers can lie.

Sunday, September 24, 2006

Seth Stevenson on Advertising

In Slate, Seth Stevenson purportedly asks whether advertising really works. In actuality, he writes about which forms of advertising are most effective. He doesn't ever address the fundamental question of whether advertising has lost credibility and PR has supplanted it as a more effective marketing tool (at least for new brands).

Stevenson mostly reports the findings in the book What Sticks, by Rex Briggs and Greg Stuart.

Saturday, September 23, 2006

City Confidential

One of my guilty pleasures is the TV show City Confidential. It appears on A&E.

Each episode, the narrator profiles a U.S. city while at the same time describing a mysterious or brutal crime that occurred in the city. The show is both suspenseful and humorous. Its tongue-in-cheek attitude reminds me of mob shows like The Sopranos.

One episode on Philadelphia focused on the "sausage king", a guy who made and sold sausage but got in trouble with inspectors. So he shot all of them. The narrator said something like, "When the sausage king shot them, he shot them in cold blood - as cold as a frozen kielbasa."

Friday, September 22, 2006

Flip-Flops and Surprise Rewards

John Moore wrote about a company, Reef, that sells flip-flops with a surprise reward. Wearers of the flip-flops are surprised to learn that the bottom of the flip-flops contains an unadvertised bottle opener. It has become Reef's top-selling shoe.

Thursday, September 21, 2006

Qualitative Methods Decision Tree

Susan Abbott has a blog entry about qualitative methods of market research. The entry includes a "decision tree" that shows and categorizes different qualitative methods. One method that seems to be absent from the tree is ethnography, about which she has written in the past.

Wednesday, September 20, 2006

Are Requirements for Web Applications Obsolete?

In a comment on the Requirements Defined blog, curious jim wrote:
How much is useful for defining requirements for web apps development? Simulation or prototyping seems the efficient approach. Software by iRise and Simunication allows build of real simulations of web apps to identify requirements (the latter even hosts online build) so much of the discussion seems a bit dated for this sector.
Asking whether it is useful to define requirements for web app development is equivalent to asking,
Is it useful to understand the problem a web application is supposed to solve?
A requirement is a statement of the least stringent conditions that must hold to solve or avoid a prospect problem. As such, it is nothing more than a logical transposition of a problem statement.

Does the fact that a product or system is a web application mean that understanding the problem it solves is "dated" and not useful? Curious, indeed.

Tuesday, September 19, 2006

Language and Usability

In commenting on a recent blog entry, Kevin Brennan gave an example of a requirement:

"the user interface will be available in English, French, and Spanish"

Kevin's point was to illustrate how some requirements are testable but not quantifiable, since "quantifiable" implies numeric measurement. I understand and agree with his point. "English", "French", and "Spanish" are not numbers :-)

However, I wanted to digress a bit and further evaluate his example of a requirement. His example strikes me more as a design decision than a requirement.

Why would a stakeholder want the user interface to be available in any of those languages? What problem does it solve to make the user interface available in those languages? The problem it solves is making sure that the target market is able to use the product. Presumably, the target market includes a substantial number of English-, French-, and Spanish-speaking people.

The real requirement is to make the product usable by these people. Usability requirements typically include profiles of various types of users. Instead of specifying that the user interface must be available in various languages, the requirements should simply include language-speaking characteristics in the user profiles. The product must satisfy the usability requirements for these users.

Monday, September 18, 2006

Requirements Confusion

Over on Seilevel's Requirements Defined message board, Joy Beatty wrote about her recent experience at a requirements conference:

I heard some new ideas about NFRs [nonfunctional requirements] - One was that the distinguisher is that FRs [functional requirements] are quantifiable and NFRs are not. I'm not sure that I think any requirement is not quantifiable if you try hard enough to make it so.

A further explained response was that using “testable” as a distinguisher, meant that the requirement can be tested by execution of the system (FR = function or performance) vs something you might test about the environment of the system (NFR = maintainability).
In my opinion, these anecdotes only underscore just how misunderstood requirements are. People at a requirements conference were saying these things? Wow.

As I've mentioned, a nonfunctional requirement is just as testable and quantifiable as a functional requirement.

Functional requirements state what the system should do. The system either does it or doesn't do it. So sure, functional requirements are testable.

Nonfunctional requirements are simply metrics that we attach to functional requirements. While the system is doing whatever it's supposed to be doing, we can measure things like throughput (performance), how long it takes for a typical user to accomplish her goals (usability), the percentage of time the system is available to deliver any particular functionality (availability), etc. These nonfunctional requirements are by their very nature testable (at least in principle) and quantifiable.

Sunday, September 17, 2006

Sam Decker on Marketing Credibility

Sam Decker has a good post about the lack of credibility in advertising and the importance of word of mouth.

Saturday, September 16, 2006

Craig's List

Back in the old days, I used to have great success selling used items on the newsgroup. Recently, I advertised a futon and a TV stand there and had no success.

When I posted the items on Craig's List, I was bombarded with offers and had trouble keeping track of them. Apparently, Craig's List has taken over and made the forsale newsgroups obsolete.

Friday, September 15, 2006

Rebranding versus Renarrowing

In November of last year, I cited an article by Al Ries in which he noted that advertising agencies and market strategy companies automatically want to rebrand your products and company to justify your having hired them.

One way to tell whether the agency gives you good advice is to assess whether they recommend narrowing the scope of your brand. By far the most pervasive problem with brands is that they are not sufficiently focused. Therefore, chances are your agency should be recommending that you narrow your message. The effort should be a renarrowing effort, not a rebranding effort.

Thursday, September 14, 2006

Problem Statements

Over on the Requirements Defined blog, Joe writes:
A clear problem statement is, in many cases, just as important as the requirements themselves.
I agree completely that clear problem statements are of utmost importance in product management. However, I don't think Joe shares my view that problem statements are requirements, or at least are logical transpositions thereof.

If the problem is
It takes more than five seconds for a user to make a reservation.
Then the requirement is
The total amount of time it takes for a user to make a reservation shall not exceed five seconds.
Joe goes on to explore how you can further analyze and decompose problem statements:
For example, a company may know that their overall processing time for orders is too long. They may not, however, understand all of the individual problem statements that add up to that company-wide issue. Breaking this problem down into individual subcomponents for analysis and definition requires the exact same skill set used in solution analysis.
Again, I agree that problem decomposition is an essential product management activity. Where Joe and I seem to disagree here is over whether "subproblems" serve as the foundation for requirements - or for design.

Typically, customers do not care about "subproblems" except insofar as they contribute to the larger problem they want to solve. "Subproblems" contain assumptions about the way the product or organization currently operates. A new product will often dispense with at least some of these assumptions. Therefore, which "subproblems" you choose to address is a matter of design.

Part of a product manager's role is to find the right place to fit into, or even transform, customers' processes. In this sense, a product manager engages in some of what we might call "business process design". However, the product manager should always strive to select the highest-level problem to solve, to the extent feasible.

Wednesday, September 13, 2006

Computer Screen Size, Revisited

Late last year, I wrote that laptop screen size is not itself a requirement, but that the real requirements are on usability and productivity when using the computer. A large screen size is one of the most effective ways of enhancing such usability and productivity. I have always favored laptops with large screen sizes for this reason.

Now, Apple has the results of a study comparing productivity when using its 30-inch external monitor versus using a smaller 17-inch monitor. Among the major conclusions:
  • Computer displays are a widely overlooked productivity factor of the personal computer, and they can contribute significantly to productivity, efficiency, and overall throughput.
  • Productivity and efficiency gains documented in these productivity measures are present in not only digital imaging and design applications, but also in office applications as well as in personal productivity of the computing environment.
  • A larger display area often results in new productivity strategies that make best use of the display in ways that one cannot easily imagine when working on a smaller display.
What is significant about these findings? The main significance is in its exposing how the emphasis on faster processors is misplaced. Instead of just worrying about feature specs, your product manager should be focusing on what really impacts users.

Tuesday, September 12, 2006

Mike Lunt on "Selling" to the Development Team

My friend, Mike Lunt, writes:

There are many jobs that a product manager may do, and while most focus the vast majority of their time gathering requirements and selling the products to the sales team, I contend that another equally important role is necessary. This role involves selling the engineering team on the value the new features or changes in the product will have for the customer (and ultimately the success of the group). In other words, for a product to be successful, the engineering team must be motivated to implement the product manager’s feedback. Many projects have failed or been plagued by engineering feature creep because the team did not have confidence in the information stream coming from the product manager(s).
A product manager's responsibility is to help the entire product team fully understand and appreciate the needs of the customer. This responsibility underscores the product manager's facilitative role. The most effective product managers facilitate not just customers, but sales, marcom, and developers.

Mike goes on to propose some ways that a product manager can use objective data to persuade developers. While objective data is helpful, I think fundamental facilitation techniques - active listening, the Socratic method, etc. - are what's most important.

Monday, September 11, 2006

Requirements for Product Upgrades

A common mistake when specifying the requirements for a product upgrade is to detail each of the incremental enhancements developers should implement. While such a specification is important, it does not constitute requirements and bypasses an essential prerequisite.

Imagine you have a mature software product that is popular in the marketplace but has a key weakness: customers have difficulty using it the first time. A competitor has included a wizard-based user interface to overcome this problem. Wikipedia defines "wizard" as follows:
A wizard is an interactive computer program which acts as an interface to lead a user through a complex task, using step-by-step dialogs.
So you have a pretty straightforward solution to the problem, and you can document this solution by simply specifying what the wizard will do. But it's not a product manager's job to do so. This activity is a design activity, not a requirements activity.

A product manager should document the problem being solved, not the solution to that problem. In this case, the problem is that it takes too long for a customer to use the product for the first time. The requirement, accordingly, should be a learnability constraint. That constraint should already be included as a requirement for the existing product; the upgrade merely tightens the constraint (specifies a smaller amount of time to use the product the first time).

Often, a product upgrade does not add new requirements. Rather, it simply tightens existing nonfunctional requirements. If you find your product manager specifying a lot of new requirements for a product upgrade, she probably is shirking her responsibilities.

Sunday, September 10, 2006

Is Apple's iPod a Parity Product?

A story in The Observer has bad news about Apple's iPod:
The iPod, the digital music player beloved of everyone from Coldplay's Chris Martin to President George Bush, is in danger of losing its sheen. Sales are declining at an unprecedented rate. Industry experts talk of a 'backlash' and of the iPod 'wilting away before our eyes'.
Has the iPod turned into a parity product?

Saturday, September 09, 2006

The Epidemic of Flakiness

As I've grown older, I've noticed a disturbing trend. It used to be that, when I sent an e-mail or left a voice mail for someone, I could usually count on a response. Now I no longer expect a response unless it's a very close friend or member of the family. Most of the time, when I leave a message for an aquaintance, I do not receive a response.

Hand-in-hand with this trend is the tendency of people to commit to actions and then not follow through. I have had acquaintances assure me repeatedly they would attend certain events, only to be no-shows without any prior notice.

These trends may be a result of the fact that people are simply more accessible these days. Or maybe I just have chosen acquaintances that are a lot more flaky. Either way, it frustrates me.

Friday, September 08, 2006

Windows Chicken?

Naming an international brand isn't easy:
"Vista," in Latvian means "fowl." Yes, that's right. People are awaiting the release of Windows
Chicken." The word "vista" is also used as a slang term meaning "frumpy," when referring to a dumpy woman, according to
a story from Agence France-Presse.

Thursday, September 07, 2006

Segmenting the Gaming Market

A Parks Associates survey breaks the gaming market into six segments:
  • Power gamers (11%)
  • Social gamers (13%)
  • Leisure gamers (14%)
  • Dormant gamers (26%)
  • Incidental gamers (12%)
  • Occasional gamers (24%)
Details here.

Wednesday, September 06, 2006

Tuesday, September 05, 2006

Symbolic Focus

Determining the key messages to use to market your product is already a challenge. (See my article, "How to Formulate Marketing Messages".) Once you've decided what messages to use, you have to figure out how to instill them in the mind of the customer.

To instill messages in the mind of the customer, you must present them credibly. Merely telling the customer that your product is the highest quality or easiest to use, for example, isn't credible. To make your message credible, you can employ symbolic focus.

Using symbolic focus means picking a very specific feature or attribute of your product that is concrete and is undeniably present in your product but in no one else's. By itself, it may be of little or no value to most customers. But it exemplifies or is symbolic of the larger message you are trying to drive home.

When you employ symbolic focus, your claim is credible, because it is unique and not vague. As a bonus, if the feature is remarkable in some way, it will generate word of mouth. When you do communicate the larger message, it will be more credible.

Monday, September 04, 2006

Laura Ries on Folgers

Big, successful brands know how to do marketing, right? Wrong! They are just as likely as small companies to succumb to the natural tendency to assume marketing is common sense. Laura Ries turns her lens on Folger's.

Sunday, September 03, 2006


When you receive a letter in the mail, are you more likely to consider it junk if:
a. The envelope is plain and merely has the sender's address and your address.
b. The envelope is "busy" and has words such as "Important information. Open immediately!"
I don't know about you, but the plainer the envelope, the less likely I am to consider it junk.

Saturday, September 02, 2006

Roger's Rules for Evites

If you ever send out Evites, I have several suggestions of how you can host a successful event:
  1. Don't charge a cover. This suggestion is related to the free food and beverages theory.
  2. Don't do a charity event. If you think that adding a charity element to the event will enhance the appeal, think again. (The exception, of course, is when the whole purpose of the event is charity.)
  3. Don't make the guest list private. People are generally what make the event. If you make the guest list private, you're effectively making it so that people don't know if the event will be any good.
  4. Don't hype. By hyping I mean sending a lot of reminders or including language like "everyone is going to be there!" When you hype an event too much, you're either implying that the event isn't all that appealing on its own merits or that the people you're inviting aren't special.

You can usually recruit a handful of people to help supply food and beverages and let everyone else freeload.

Friday, September 01, 2006

Essence versus Implementation

One way to ensure you capture the real requirements for a product, according to Robertson and Robertson, is to "separate the essence of the problem from its implementation". They give the following example:
[W]hen you approach an automated teller machine, what is the essential piece of business that you wish to conduct? 'Withdraw money from your bank account' would be a logical answer. The things that you have to do like insert a plastic card, enter a PIN, and so on are to do with the technology that the bank chooses to use. The essense is that you access your account and withdraw money from it.
Then ask yourself, for example, why you might design the system to have a PIN. The answer points to another essential problem to solve: unauthorized access to funds. The PIN isn't the requirement; security is.