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

Snapvine

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

Sociology

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.

Saturday, October 07, 2006

"Blood in the Streets" Investment Approach

This week, I bought a couple of natural gas stocks.

Natural gas prices had fallen from around $15 per MMTU late last year to under $4.5 per MMTU. Some large hedge funds had bet that natural gas prices would rise instead of fall. These hedge funds recently got into a lot of trouble and collapsed, causing them to have to "unwind" their positions.

The "unwinding" meant the hedge funds were forced to liquidate their natural gas investments. Consequently, natural gas prices fell even lower, creating a distortion - a lower price than ordinary supply and demand factors would dictate. So I took advantage of the situation and bought natural gas stocks.

This approach to investing is my favorite. It's not enough to look at the investment itself; you have to determine whether its price is out of line with supply and demand fundamentals. The stock of the fastest-growing, most profitable company in the world is a poor investment if its price already reflects these expectations. One classic approach is to look for "blood in the streets"; i.e. when everyone is panicking, creating a distortion.

Friday, October 06, 2006

Meeting Tips from Marissa Mayer

Carmine Gallo recently interviewed Marissa Mayer, Google's vice-president of search products about how to run effective meetings. Mayer offered six tips:

  1. Set a firm agenda.
  2. Assign a note-taker.
  3. Carve out micro-meetings.
  4. Hold office hours.
  5. Discourage politics, use data.
  6. Stick to the clock.
Read the article for details.

I suggest a few more guidelines for facilitators:
  • Start meetings on time, no matter what.
  • For problem-solving meetings, follow a process.
  • Repeat what participants say in your own words.
  • Maintain a list of deferred items.
  • Meet one-on-one with key meeting participants in advance to begin to forge consensus.
In future entries, I will elaborate on some of these guidelines.

Thursday, October 05, 2006

Wednesday, October 04, 2006

The Power of One-to-One

A few months ago, I received a text message from my friend Laura. I hadn't heard from her in a while, so I was actually pretty stoked. When I read the text message, however, excitement turned to disappointment. It was apparent that she had sent a "mass text message", i.e. a message addressed to multiple people in her phone's address book. The gist of her text message was to try to get people to go to an event she was promoting. It didn't work on me.

It might have worked had she personalized the message, even if I knew she was trying to promote the event to me. PR tends to be much more effective when it's one-to-one.

Tuesday, October 03, 2006

Buying for the Story

A friend of mine recently bought a plasma TV. Funny thing is, he seems to enjoy talking about the TV more than he does watching it. He talks about how it has the best picture, the most advanced technology, and features that no other TV has. When he describes these things, it doesn't seem that he really derives any value from them while he's using the TV. But he does seem to get a great deal of satisfaction from telling the story.

Which segment of your market buys for the story?

Monday, October 02, 2006

Buying What You Don't Understand

How many times have you come across a product or service that interested you, but you couldn't figure out exactly what to buy? Sometimes companies, in their effort to ensure their products appeal to enough people, offer so many options that no one can figure out what they should buy without investing a lot of time sorting out the complexity.

I recently encountered this problem with an Internet service provider. They offer different bandwidth levels, static or dynamic IP addresses, wired or wireless service, installations on multiple computers, and an "early adopter" option. It was confusing for me to evaluate these options and determine how much they would cost. A friend of mine who received a mailer from them expressed the same confusion.

When marketing or selling your product, complexity is a turn-off for your audience. It makes it difficult for them to buy. Accordingly, I recommend:
  1. Try to minimize the number of packages or options you offer.
  2. Present whatever options you offer in the most straightfoward and simple way possible.
If you have any hesitation in minimizing the number of options, recall the importance of focus, and how much discipline it requires.

Sunday, October 01, 2006

Product Management versus Business Analysis

In a comment on a recent entry, Scott Sehlhorst raised the issue of how product management differs from business analysis:
I think a good way to frame the question is by contrasting product managers as strategic while business analysts are tactical. To clarify, I reword the statement: Product managers focus on multiple customers in a market. A business analyst focuses on multiple operations within a single customer.
My original point was not to suggest that business analysis is necessarily tactical. On the contrary - business analysis can be tactical or strategic; it depends on the activities performed. The full business analyst role includes strategic functions, such as identifying business problems to solve and possibly even suggesting solutions. Companies, however, have a tendency to hire business analysts to perform only a narrow part of the full suite of responsibilities: documenting business processes. In such situations, "business analyst" is almost a misnomer; "documentation specialist" might better describe this very tactical role.

Though the responsibilities differ, product managers and BAs can both have strategic roles. The terminology that best captures the difference between the product manager and BA, in my opinion, is external versus internal. A company hires a product manager to analyze processes and problems outside the company. A company hires a BA to analyze processes and problems inside the company.