Thursday, May 31, 2007

Big Screen Productivity, Yet Again

Another study showing that bigger computer screens increase productivity:
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.
Big screens are convenient, not just a luxury.

Wednesday, May 30, 2007

Wiegers on the Requirements/Design Distinction

Karl Wiegers and I have disagreed in the past on requirements terminology.

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.

Tuesday, May 29, 2007

Kevin Brennan on Strategic Thinking

Kevin Brennan explains how we can't rely on customers, unfacilitated, to tell us their problems and what it would take to solve them. A strategic thinker needs to be involved.

The summary quote:
A genuinely effective business analyst is someone who can understand business needs well enough to propose better solutions than the business people can develop on their own.
Well stated.

Monday, May 28, 2007

Toyota to Focus on Hybrids

Toyota's hybrid vehicles have been a huge success. Now it appears that Toyota is planning to focus completely on the hybrid market.

Friday, May 25, 2007

Strategic Advice for Lenovo

Laura Ries has three recommendations for Lenovo, the largest personal computer maker in China and a spin-off of IBM's ThinkPad line.
  1. Focus the product line on notebooks and discontinue desktops.
  2. Change the company name to ThinkPad.
  3. 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

Survey Incentive

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?

Wednesday, May 23, 2007

Alyssa Dver on Great Product Managers

Alyssa Dver tells us what distinguishes a great product manager from a good one. Great product managers:

1. Know their product but also know their own limits.
2. Listen first.
3. Ask why, not what.
4. Are decisive.
5. Are responsive.
6. Communicate frequently, concretely, and concisely.
7. Manage passion.

For details, read the rest of Dver's piece.

Tuesday, May 22, 2007

Not an SUV

Want to differentiate your brand? Sometimes it's as easy as being the opposite.


I just heard a BMW ad on the radio saying that BMW doesn't make SUVs. And BMW's ad for the X3 portrays it simply as "Not an SUV."

Monday, May 21, 2007

Dollar Coins

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

Are Two Brands Better Than One?

Are two brands better than one? Al Ries says no:
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.
A good market research firm likely will test the concept with qualitative research and indirect questions rather than focus groups.

Thursday, May 17, 2007

Agile Development


Is your company doing true agile development?

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

Is Positioning Strategic?

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

  1. They are relevant to the requirements for a product.
  2. 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.

Tuesday, May 15, 2007

When Convergence Can Work

Al Ries and Laura Ries post a new video each month on their Ries Report web site. This month's video is about the iPhone and convergence.

In the video, Al Ries echoes his daughter's prediction that the iPhone will flop (after some initial success), saying it

  • Will not dominate the market.
  • Will not have a big market.
  • Will not be a success.
  • Will not make money for Apple.
One important nugget that stuck out was his statement that:

Convergence can work where convenience is a major issue.
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.

Monday, May 14, 2007

Weinberg on Healthy Negotiation

Want to see some contrasting examples of healthy and unhealthy negotiation? Check out Gerald Weinberg's piece from last year.

Friday, May 11, 2007

Intrinsic versus Extrinsic Motivation

My friend Chris H. recently sent me a link to this Joel Spolsky piece.

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

Use Case as a Black Box

Consider the following use case:
Purchase Items
Actor: Purchaser
Precondition: 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

Requirements and Functional Decomposition

What is the difference between these two specifications?

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

Revisiting the Technology Adoption Curve


[Graph from CNET]

A recent Pew research study categorized adults' "evolving relationships to cyberspace" as:

Omnivore (8 percent)

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.


More on the study here and here.

Monday, May 07, 2007

Cingular 8525 Received

Over the weekend, I finally received my Cingular 8525 (a.k.a. HTC Hermes) mobile phone. Here are some observations:
  1. Navigating the phone with the touch screen is fast and easy. (The exception is the camera; I am still learning its touch screen interface.)
  2. The touch screen dialing is convenient and straightforward now that I'm getting over my expectation of a separate numeric keypad.
  3. Synchronizing contact, calendar, e-mail, and tasks with Outlook took me a long time to get working properly, almost exclusively due to problems with Microsoft's ActiveSync software.
  4. The SMS synchronization software I installed works beautifully. Now copies of all of the text messages I send and receive automatically are stored in Outlook on my computer.
  5. The speakerphone is clear and sufficiently loud.
  6. The slide-out QWERTY keyboard is very handy for typing out text messages, e-mails, and Word/Excel documents.
  7. Wi-fi initially seemed to work well, but now it seems flaky, and configuring it is a bit confusing.
Overall, I'm very happy with my purchase.

Friday, May 04, 2007

Requirements Elicitation Technique

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.

Thursday, May 03, 2007

Four Keys of Great Managers

In First, Break All the Rules, Marcus Buckingham and Curt Coffman tell us the four keys of great managers:
  1. Select a person based on talent, not so much for experience, intelligence, and determination.
  2. Set expectations by defining the right outcomes, not by defining the right steps.
  3. Motivate the person by focusing on strengths, not by helping to overcome weaknesses.
  4. Develop the person by helping him find the right fit, not by helping him get promoted.
Somewhat counterintuitive, but based on some sound premises and research. I recommend the book.

Wednesday, May 02, 2007

Style and Usability

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.

Tuesday, May 01, 2007

Ask Then Tell

As I've mentioned, SPIN Selling describes a sales process based on questioning and listening rather than telling. Many of the lessons apply to product management as well.

Now, Kristin Zhivago shares:
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.]