Thursday, May 31, 2007

On the bigger screen, people completed the tasks at least 10 percent more quickly - and some as much as 44 percent more quickly. They were also more likely to remember the seven-digit number, which showed that the multitasking was clearly less taxing on their brains. Some of the volunteers were so enthralled with the huge screen that they begged to take it home. In two decades of research, Czerwinski had never seen a single tweak to a computer system so significantly improve a user's productivity.

Wednesday, May 30, 2007

Now Wiegers has a good piece on the distinction between requirements and design. Or rather he attempts to sidestep the interminable semantic debate and focus on some important consequences of failing to understand the "why" behind product specifications.

In my view, the summary passage in the piece is:

When it comes to requirements specification and design, the essential issue is not one of what versus how. It’s a question of distinguishing the real customer need from just one possible description of how a clever developer might satisfy that need. Incorporating a solution idea into a requirement imposes a design constraint. The requested solution describes one way to satisfy some requirement but perhaps not the only way, the best way, or even a good way. Focusing on solutions masks the underlying requirement. This can make it difficult for a developer to understand what the customer is really trying to do, making it hard for him to devise the most appropriate approach to meet that expectation.

Actually, I think the "real customer need" is the what, and a "possible description of how a clever developer might satisfy that need" is the how, so the what versus how distinction makes perfect sense. Setting aside this quibble over terminology, however, Wiegers hits the nail on the head about focusing on underlying needs rather than dictating solutions to developers.
Wiegers elaborates:

The requirements analyst needs to detect when a requirement imposes unnecessary constraints on designers. This should lead to a discussion with the customer representatives about the underlying need that led to the customer proposing that specific solution. It’s important to respect the customer’s input. Don’t summarily dismiss the customer’s solution idea; important information is hiding in there somewhere. Use that input as a starting point to drill down to a deeper understanding of what the customer is really trying to accomplish. It’s possible that the customer’s solution idea will be appropriate, but don’t let the customer—or any other stakeholder—paint the development team into a constraint corner prematurely.

He then gives real-life examples (drawn from actual requirements documents). Here is one:

"A master power button shall be installed on the front panel." Further discussion might surface an explanation of why this precise design approach is necessary. Perhaps it’s required for compatibility with an existing product, or maybe it will conform to a pertinent standard or safety requirement. Or it could be an unstated ease-of-use requirement. If so, it would be good to know about any related usability requirements that could influence this, and possibly other, functionality or design issues.

In other words, customers don't care about "power buttons" per se. They care about compatibility, compliance, safety, and ease of use. If a requirements analyst fails to document these nonfunctional requirements in measurable terms, the product may end up with a "power button" but still end up being incompatible, not compliant, unsafe, and difficult to use.

Friday, May 25, 2007

Laura Ries has three recommendations for Lenovo, the largest personal computer maker in China and a spin-off of IBM's ThinkPad line.

Focus the product line on notebooks and discontinue desktops.

Change the company name to ThinkPad.

Focus on battery life as the company's key differentiator.

While I question the wisdom of the second recommendation, I wholeheartedly agree with Ries' other recommendations. This sort of gutsy strategic thinking about positioning (sacrificing a portion of the market to enhance focus) is precisely what is lacking in many companies today.

Thursday, May 24, 2007

Meritline recently sent me an e-mail asking me to fill out a survey. The e-mail stated that Meritline would send me a desktop organizer for free as a reward. I chose not fill out the survey.The irony is that I might well have decided to fill out the survey had they not offered any sort of reward. I thought, "I don't want a desktop organizer, so why should I bother filling out the survey?" Had they not offered a reward, I might have thought, "If this survey is short, I'd be happy to answer questions to help improve Meritline's services."

Survey incentives not only pale in comparison to the deterrent effect of a long survey, but they can actually make some potential respondents less likely to complete the survey.

Furthermore, isn't Meritline biasing their sample in favor of people who want a desktop organizer?

Monday, May 21, 2007

Has the government done any product management on its currency product?

Since 1971, the U.S. government has made several attempts to ween its citizens off of paper currency (dollar bills) and onto coins. In many other developed countries, similar denominations of currency have been coins, not paper. Supposedly, the similarity of dollar coins to quarters has been one reason that dollar coins have not gained popular acceptance.

If the government were to gather requirements for a currency product, what would they be? What would the use cases be? What would the attributes and constraints attached to these use cases be?

Some of the use cases might be:

Pay for Goods

Carry Money

Withdraw Money

Deposit Money

Some of the attributes might be:

Fit (Does it fit comfortably in pockets/wallets/purses?)

Weight (Does carrying a lot of it around weigh you down?)

Durability (How well does it withstand the elements and time?)

Identifiability (How easy is it to distinguish relative to other currency?)

I am personally sensitive to the fit and weight of currency. I don't like the feel of a lot of change in my pockets, and I can't stuff a lot of coins in my wallet.

Friday, May 18, 2007

It's a trend. Glide is now Crest Glide. Cottonelle is now Kleenex Cottonelle. SpinBrush is now Crest SpinBrush. And so it goes.

Consumers, however, will usually use one name instead of two. Nobody in their right mind would write Nescafé Taster's Choice on a shopping list. Or Crest Glide. Or Kleenex Cottonelle. It's just Taster's Choice, Glide and Cottonelle.

Furthermore, the most powerful brands are those that stand on their own, without corporate endorsements or master-brand hocus-pocus. If Nestlé bought Red Bull (an acquisition they should definitely consider), should the brand be re-badged as Nestlé Red Bull? I think not.

Also, beware:

Research can lead a company astray because consumers prefer the known to the unknown.

Before Dietrich Mateschitz launched Red Bull, he hired a market-research firm to test the concept. "People didn't believe the taste, the logo, the brand name," he said. "I'd never before experienced such a disaster." But he launched it anyway. And today Red Bull does $3.4 billion in worldwide sales.

Thursday, May 17, 2007

At one time, most people thought of agile development as shown on the left. Determine the requirements up front. Then iterate on the analysis, design, and implementation.

Slowly, people began to realize that BUFR is often a bigger risk than BUFD. The new model of agile development is shown on the right. Iterate on the entire process: requirements, analysis, design, implementation, and testing.

This depiction of the new model is still somewhat crude and incomplete. Testing really occurs throughout the process. And when market research and strategy appear in the iterative loop, it turns into agile product management.

Wednesday, May 16, 2007

Branding and positioning are highly relevant to "outbound" marketing and marketing communications. So you might wonder if:

They are relevant to the requirements for a product.

They are part of strategic product management.

I believe the answer is "yes" to both.

As your product manager is understanding the problems in the market, the distinctive competence of the company, and the competition, she should be formulating the positioning of the product using established positioning principles.

Branding strategy and positioning should in fact drive product requirements. Should your focus be on ease of use, customizability, or style? The answer to these sorts of positioning questions determine which problems you choose to solve and thus what the requirements for the product are. They also determine how to prioritize those requirements.

A strategic product manager is a product manager who sets the strategy for building and marketing the product but doesn't necessarily do a lot of tactical outbound marketing (e.g. writing white papers, creating brochures, etc.). Positioning in many respects is a less tactical activity than specifying product requirements, because it sets the vision for the product into which the requirements must fit.

People buy products with a singular purpose except when doing so creates a compelling problem. Mobile phones are an interesting case, because their users usually carry them everywhere. But some people also want to carry cameras, digital audio players, and computers everywhere, too. It would be a problem to carry all of these separate devices.

The convergence of these devices in a PDA phone thus solves a real problem for some people. The question is whether the seriousness of the problem outweighs the drawbacks of combining the devices into a single product.

Friday, May 11, 2007

Measuring results and basing employee evaluations and compensation on them is important. However, you risk killing their intrinsic motivation:

Intrinsic motivation is your own, natural desire to do things well. People usually start out with a lot of intrinsic motivation. They want to do a good job. They want to help people understand that it’s in their best interest to keep paying AOL $24 a month. They want to write less-buggy code. Extrinsic motivation is a motivation that comes from outside, like when you’re paid to achieve something specific.

Intrinsic motivation is much stronger than extrinsic motivation. People work much harder at things that they actually want to do. That’s not very controversial.

But when you offer people money to do things that they wanted to do, anyway, they suffer from something called the Overjustification Effect. “I must be writing bug-free code because I like the money I get for it,” they think, and the extrinsic motivation displaces the intrinsic motivation. Since extrinsic motivation is a much weaker effect, the net result is that you’ve actually reduced their desire to do a good job. When you stop paying the bonus, or when they decide they don’t care that much about the money, they no longer think that they care about bug free code.

You also risk having your employees focus too much on the metrics, to the exclusion of what really matters:

Another big problem with Econ 101 management is the tendency for people to find local maxima. They’ll find some way to optimize for the specific thing you’re paying them, without actually achieving the thing you really want.

When it comes to dealing with people, be careful with metrics and incentives.

Thursday, May 10, 2007

Purchase ItemsActor: PurchaserPrecondition: Purchaser types at least thirty words per minute and has a web navigation efficiency rating of at least 40.Postcondition: For the average Purchaser acting at full efficiency, the number of seconds elapsed is no more than 30 + 20 * n, where n is the number of items purchased.

The name of the use case represents a functional requirement. What does the product do, or enable the user to do? Purchase items.

What are we to make of the preconditions and postconditions? What relationship do they have to the requirements for the product? Answer: the preconditions and postconditions are the nonfunctional requirements attached to the functional requirement. Another way of expressing the nonfunctional requirement would be as an attribute and associated constraint:

Usability: For a Purchaser who types at least thirty words per minute and has a web navigation efficiency rating of at least 40, it shall take no longer than 30 + 20 * n minutes to purchase n items.

When you think about requirements in this manner, it becomes apparent that you shouldn't just treat the product as a black box, but also the use cases. The steps in use cases don't matter as long as your product fulfills the preconditions, postconditions, and invariants.

Wednesday, May 09, 2007

1. Security: a team of 10 hackers [profiled elsewhere] per hour attempting to access account holders' credit card information shall be successful no more than an average of once every five years.2. The system shall require users log in with a user name and password. On the third consecutive unsuccessful log-in attempt using a particular user name, the system will lock the corresponding account.

The first specification is a nonfunctional requirement. The second specification is a functional decomposition of that nonfunctional requirement.

All nonfunctional requirements can be decomposed into functional specifications.

In fact, when an interaction designer fleshes out (defines the particular steps in) a use case, she is functionally decomposing both functional and nonfunctional requirements. She is specifying functional steps that will satisfy the requirements.

Tuesday, May 08, 2007

Devoted Web 2.0 users of either gender, though usually under 30, who voraciously update personal Web pages, blogs and mashups to publicly express themselves. Likely to watch videos on an iPod or participate in a virtual world. Most social interaction takes place via instant messaging, texting and blogging via a high-speed Internet connection at home and work.

Connector (7 percent)

Mostly female thirtysomethings who have been online since the early 1990s and have a fully loaded cell phone or smart phone. They are happy to use the Internet, usually via Wi-Fi, from either device as a place to manage content and connect for work, community, family, hobby and entertainment interaction. They are twice as likely to blog or have a Web page than the average American.

Lackluster veteran (8 percent)

Been there, done that on the Internet since the mid-'90s and could care less about Web 2.0 or mobile media. Usually fortysomething men who have a laptop and a broadband connection. E-mail and cell phones are seen as essential for work for these users, and they surf the Web to find information, as well as e-mail to stay in touch with family and friends, but the interest ends there.

Productivity enhancer (8 percent)

These moderate users, likely to be fortysomethings of either gender with kids, have a positive view on what the Internet offers, in terms of getting their job done and learning new things. They like to use the Internet to stay in touch with family and friends, but you'll be hard-pressed to find them watching a Lost video clip on a cell phone or laptop.

Mobile Centric (10 percent)

Typically thirtysomething, you'll find these users' cell phones jam-packed with things like video clips and games. They, however, are less enthused about connecting via a computer and have been online only for a relatively short time, compared to other groups. Pew found this group to include a high share of African-Americans.

Connected but hassled (10 percent)

These users have invested in technology and connectivity but see it all as nothing more than modern "intrusive" necessities. Usually females in their late 40s, they are interested enough to invest in broadband accounts, cell phones and digital cameras, but they suffer from "information overload" and couldn't care less if they have lost access to the Web, e-mail or cell phone.

Inexperienced experimenter (8 percent)

Having the necessary technology and desire to join the party but unsure of what to do with it, these usually female fiftysomething users of above-average income are below average when it comes to using the Internet and cell phones. They probably have been online for only five years but have tried a little of everything, including posting a comment to a message board, downloading music or sharing photos via e-mail.

Light but satisfied (15 percent)

Also usually females in their mid-50s who went online in the last five years. They are satisfied with the technology they own and use but do so only occasionally and could easily do without it. While the majority have cell phones, they are feature-light and would not consider using one to replace a landline.

Indifferent (11 percent)

Mostly men in their 40s who do not have broadband, these annoyed users have cell phones and Web access but rarely connect. Their slow connections are "no doubt a barrier" to more actively using the Internet to pursue hobbies and share with others.

Off the network (15 percent)

People in this group, tending to be 65 or older, do not have a cell phone or Internet access. Some have computers or digital cameras.

Friday, May 04, 2007

Bob Corrigan recently described an interesting requirements elicitation technique. The basic idea is to observe while a third party participates in a discussion of a possible requirement or feature idea.

Wednesday, May 02, 2007

For what single idea does "Apple" stand in customers' minds? Here are some possibilities:

Stylish

Easy to Use

Design

It occurs to me that style and usability are both aspects of design, and that customers may perceive them synergistically. The ease of use seems to heighten perceptions of style, and aesthetics seem to strengthen perceptions of ease of use.

I haven't thought deeply about the issue, and I haven't researched it. So it may already be a known fact or may just be plain wrong.

Salespeople like to talk, and they need to make a sale. Combine this character trait and this need, and you get the typical unsuccessful sales interaction. The salesman talks and talks, while the customer is standing there with all sorts of questions. The salesman doesn't answer the questions the customer has. The salesman answers the questions he thinks the customer has.

Truth be told, he answers the questions he has answers for.

Not only does he fail to answer the customer's actual questions, but as he prattles on, he adds to the customer's concerns.

By the time his verbal spring winds down, the customer has decided that she doesn't want to buy anything from this salesperson or his company, or that the product or service isn't what she wanted anyway.

So she walks away. The salesperson doesn't understand why. Sometimes he finally starts asking questions as the customer is drawing away. But it's too late then, because the customer has already rejected the salesperson's pitch and is making her exit.

What he should have done is start with questions.

[I thought I came across this piece via Steve Johnson's blog, but I can't seem to track down the post so I can cite it.]

Subscribe To

About Me

I'm a downtown Austin dweller with a passion for food, football (playing it, not watching it), knowledge, nutrition, investing, and a low-car lifestyle. In my professional life, I empower teams to make smart product decisions by applying design thinking, lean startup methods, and timeless marketing principles.