Saturday, December 22, 2007

The Ultimate in Requirements Traceability: DBA

Requirements traceability refers to the ease of tracking the relationship of artifacts to product requirements throughout the development process. One form of requirements traceability involves slavishly documenting each design decision and precisely which requirement(s) it addresses. There's got to be a better way. And there is.

If your team isn't communicating well and your process is broken, you are likely to have some of the following problems:
  1. Features that are "neat" but don't address requirements.
  2. Designs that don't address requirements.
  3. Difficulty adjusting to changing requirements, priorities, and scoping.
  4. QA that doesn't know what to test.
For this reason, some managers are enamored with the concept of requirements traceability. An untrusting manager tries to impose some heavyweight processes to ensure these problems don't occur. Usually, the process usually involves some huge, complicated spreadsheet with all sorts of links between various items in artifacts.

Instead, why not nudge the team into adopting a few simple, lightweight practices?

Realize that test-driven development (TDD) goes a long way towards establishing a de facto requirements traceability. Encourage your team to "document" its requirements and interaction design decisions as test cases.

But you'll want to test frequently. Use demonstration-based agile (DBA), in which the team delivers a demo and submits things to QA for testing on a weekly basis.

Let's examine the effects of adopting these practices.

First, if design and implementation decisions conflict with the requirements, it will show when the tests fail.

Second, when requirements change, the test cases change, and any other changes that must happen will happen, otherwise the tests will fail.

Third, the weekly demos will ensure that product manager is able to trace or track adherence to the requirements.

Finally, and most importantly, your team will communicate frequently, which will likely improve the quality and efficiency of its output.

Rather than imposing requirements traceability in a heavyweight manner, use DBA.

Tuesday, December 18, 2007

A Problem Understood is a Problem Half Solved

In a Q&A over at Functioning Form, Tom Chi gave us this nugget:
Usually when a group of smart people is at an impasse for a long time, it is because the problem is poorly framed, not because their solutions are not good. Unfortunately, it is par for the course in the tech industry to try to bowl headlong into solving things even before we know what the problem is, or the criteria for success. Defining a problem is also an extremely creative activity. If you are falling back to the same lame problem statements and measures of success, then you aren’t really trying. And there are a ton of reasons to try. The most important is that a well defined-and exciting problem (and its associated constraints) is the catalyst that makes design go. By not drawing a clear and compelling problem, you are cheating your team out of an incredible unifying and driving energy.

Tuesday, December 11, 2007

More Is Not Always Better in Surveys

Having trouble getting responses to your survey?

In a MarketingProfs.com article, Dean Wiltse tells us seven rules for achieving higher online survey response rates. One of the rules is:
Rule #4: More is not always better

Many organizations believe the more questions they ask, the more measurable the results will be. However, the reality is the exact opposite. The more questions asked, the less focused and thoughtful survey responses are and the more survey takers rush to exit.

Instead of asking every possible question under the sun, survey designers should keep the survey focused and to the point.

Survey administrators should bear in mind that to get a solid response rate the number of questions should not exceed 30.
I'm even more radical. I recommend limiting the number of questions to 12 in most cases.

Saturday, November 10, 2007

Demonstration-Based Agile (DBA)

Adopting agile development processes means adopting key practices, usually some combination of the following:
  1. Develop in short iterations.
  2. Release frequently.
  3. Write tests first.
  4. Communicate frequently.
Organizations moving towards agile product development typically face major hurdles as many people are entrenched in old waterfall thinking. How can you most effectively move towards agile in such an environment?

Forget about Scrum, XP, and all the buzz words. Let me introduce a new buzz word.

Start with demonstration-based agile (DBA) on a small scale. With demonstration-based agile, you insist on only one thing:

Regular Demos. The development staff demos the product to the product manager and other members of the team at the end of every week (or some other short period).
It's a lot easier for a team to agree to regular demos than it is to short iterations or frequent releases. Yet regular demos aren't much different. The team must iterate on developing the product and must have something to "release" (as a demo) frequently. Regular demos also stimulate frequent communication. Finally, the team sort of plans "tests" by defining in advance what to expect from each demo.

Some curmudgeons may resist the idea of regular demos, but for many the concept is easier to swallow than all of the agile practices that fall out of it.

Tuesday, November 06, 2007

Positioning Cough Syrup

Positioning your cough syrup can be like positioning mouthwash.

Last year, I cited the example of Listerine as a product that highlights the weakness within its strength. It tastes bad, but the bad taste instills confidence that it kills germs.

Now John Moore at Brand Autopsy tells us about Buckley's Cough Mixture employing a similar positioning strategy.

Monday, November 05, 2007

Effect of Fees on Your Brand

Sometimes fees above and beyond the base price of your product are a lucrative part of your business. For example, late fees, though they purportedly are exceptional and merely for recouping revenue that would otherwise be lost, are in fact a major cash cow for video rental stores.

From a narrow economic point of view, such fees are good for your business. After all, business is about making money, and the fees bring in revenue.

But the long-term impact of such fees is hard to measure and may be negative. Fees affect the long-term perceptions of your product and company. They affect the equity of your brand.

For details, see this post by Roger Dooley on the Neuromarketing blog.

Wednesday, October 17, 2007

Presenting at the SMP Conference

I will be presenting at the Software Marketing Perspectives Conference and Expo Tuesday, October 23rd.

My seminar will be "A Template-Based Approach to Positioning". Here is the description of the session:
Product positioning is the process of defining your target market and shaping the perceptions they have of your product. Positioning largely determines which product requirements to tackle and how to market your product effectively. Prospect problems, distinctive competence, and competitive analysis should drive positioning. Yet how should these factors combine to determine your product's positioning? We will discuss positioning principles and fill out a positioning template for a sample product.
The event will take place at:
Hyatt Regency Austin on Town Lake
208 Barton Springs
Austin, Texas, 78704
See the full line-up of sessions and presenters here. Register here.

Friday, October 12, 2007

The Differentiation Test

Laura Ries tells us:
The mission of a slogan is not just to define your brand, but more importantly to differentiate it from other brands.

One way to test the differentiation factor is to reverse the slogan and pin it on the brand’s major competitor. Does it make sense? Could it define another brand? If not, then the slogan is just plain puffery that is likely to be ignored.
Read Laura's entire post. It's a great lesson on positioning with many concrete examples.

Tuesday, September 25, 2007

Industry Experience: How Important Is It?

In the latest Pragmatic Market BlogFest, Steve Johnson wrote about the importance of domain expertise. Steve's two main points are:
  1. Developers need to understand the domain and not merely code to specs.
  2. Product managers need to understand technology
I can't disagree with Steve on these points. However, more interesting to me is:
How important is it that a product manager have prior knowledge and experience in the domain?
I have written on this topic in the past. In fact, it was one of the first entries in this blog. Below are some more thoughts.

Should a company hire a product manager with years of experience in, and knowledge of, the industry? How about a capable and experienced product manager with little or no prior domain knowledge?

The key to understanding the importance of domain knowledge lies in recognizing a product manager's most important skill: learning about the market.

Thoroughly understanding a market necessarily entails being intimately familiar with the user and buyer experience, and therefore requires grasping the domain in which they operate. So yes, domain knowledge is fundamentally important.

But "learning" means acquiring knowledge, not having it already. A product manager who is knowledgeable about an industry solely as a result of lengthy prior experience is much less capable - and much less valuable - than a product manager who can quickly master a market and domain.

After all, markets change. New competitors enter the landscape, and user and buyer psychographics evolve. Don't you want a product manager who knows how to keep abreast of, or anticipate, these changes rather than relying on the way things used to be?

Thus we see that prior domain experience, while helpful, can be a crutch. An insistence on prior industry knowledge amounts to a concession that product managers are not capable of performing their primary learning function.

If you're an executive looking to hire a product manager, I recommend de-emphasizing domain experience and focusing on the skills that enable market mastery:
  • Interviewing prospective and existing customers.
  • Identifying and quantifying the problems that customers face.
  • Analyzing the competition and their positioning.
  • Framing survey questions and interpreting survey results.
  • Observing customers in their native environments.
A product manager performs many other important duties, but the point is that domain knowledge is no substitute for these skills for achieving market mastery.

Friday, September 14, 2007

The Big Brands Do It, Why Can't We?

Good marketing often contradicts intuitions and instincts. Those wishing to cling to their intuitions find solace in the fact that big companies are just as likely to make mistakes as little ones.

Kimberly-Clark, a huge company and umbrella brand, chose "Huggies" as the name of a line of diapers. "Huggies" is a descriptive name in that it implies in a not-so-subtle way that it is comfortable and effective. (Similarly, Procter and Gamble sells the "Pampers" line of diapers.) Yet descriptive names generally don't make good brand names.

I can hear it now: "If Kimberly-Clark's marketing department decided on a descriptive name, why shouldn't we?"

I should point out that, aside from its descriptiveness, "Huggies" is actually a pretty good name. It is easy to pronounce, easy to spell, and slightly shocking - all attributes that foster brand recall and recognition. Plenty of products succeed despite a descriptive name.

But let's put to rest the idea that big, successful companies don't make marketing mistakes. Fortunately, Laura Ries debunks this notion on a regular basis. In her latest blog entry, she tears into seven successful companies for recent marketing decisions they've made.

Wednesday, September 05, 2007

eHealthInsurance.com

A few days ago, I received in U.S. Mail a notice from UniCare that the premiums on my health insurance were going up. Given that my health plan covers little and now is going to cost more than twice as much as it did four years ago, I decided to research other options.

I originally signed up for my health insurance plan through eHealthInsurance.com, a helpful service that enabled me to browse and compare numerous plans from a number of different providers. At the site, you can specify various plan features (deductible, co-pay, etc.), view a list of plans that satisfy those parameters, and compare the plan details.

It's a great concept. Unfortunately, it has nonetheless frustrated me. The reason is that the service focuses on the features of health insurance plans rather than addressing real-world scenarios.

This morning, I went to eHealthInsurance.com to research alternatives to my existing plan. I brought up various plans but scratched my head when trying to determine what they would and wouldn't cover. So I called their customer service to speak to a health insurance "agent".

The agent immediately asked me what I wanted in a plan. I told her that I don't know and suggested we walk through various scenarios and see which plans best covered them.
  1. I get into a car wreck, suffer massive internal injuries, and go to the hospital for surgery.
  2. I get a minor cut on my leg and go to a minor emergency center for stitches.
  3. I go to the doctor for a routine check-up.
  4. I go to the doctor to get a prostate exam (leaving aside the fact that the one prostate exam I've received was the most unpleasant experience in my entire life).
The agent's response? "I don't have time to go through all that. Just tell me what you want," she replied. "Do you want a co-pay?"

At this point, I told her I was frustrated. She was assuming I was an expert on health insurance concepts. All I know is that there are various types of scenarios. Some plans address them well, and others don't. Co-pays, deductibles, co-insurance, and out-of-pocket limits mean nothing to me except insofar as they affect the bottom line in these types of scenarios.

Though she initially refused to walk through the scenarios with me, she effectively did by the end of the conversation. I felt educated enough to compare plans and make a decision. Despite the fact I was still seething with frustration, I thanked her for her patience.

What product management lessons does this experience teach? I'll examine some of them in a future entry.

Tuesday, August 28, 2007

Trade Shows: Of What Value Are They?

The esteemed Steve Johnson recently wrote a provocative blog entry on the merits - or lack thereof - of demoing at trade shows. He implies that showing demos is usually not very effective:
Nobody retains information from a trade show--everyone is yelling to be heard. Perhaps you could be a little quieter and much more effective. Let's use the demo where it belongs, much later in the sales cycle.
And he contends that collecting information about prospects' situations and problems is often a better use of trade show time:
At your next event, try just asking people who come by the booth a few simple qualifying questions about their problem and its urgency to them. If they answer in the affirmative, scan their badge or take their card and invite them to enjoy the show. Meanwhile send a set of materials to them through the mail or better yet, have a sales person contact them the week after the show.
In my opinion, Steve's key point is that:
The best demo is customized to the customers, their problems, and within the context of how we can specifically solve their problems.
If you've read SPIN Selling, you know that your best chance of making a high-value sale is to use a facilitative process that starts with asking a lot of questions. Only after you've fully understand the individual prospect's situation and problems do you describe your solution in detail.

Regarding trade shows, however, the more important questions to me are:
  1. Why are you an exhibitor at the trade show at all?
  2. Who is attending the trade show, and why?
What goals are you trying to achieve as an exhibitor at the trade show? If you're trying to sell product, then Steve's advice is important to keep in mind. But maybe you're trying to affect media coverage? Or maybe you're trying to gather intelligence on the attendees and competition? I wonder, though: perhaps you can achieve this latter goal just as effectively without being an exhibitor (and just being an attendee)?

It matters who is attending the trade show. Is media attending the trade show? Are tech geeks with little or no buying authority attending the show? Are actual prospects attending the show? Perhaps you should attempt to segment the population of the trade show into various personas.

The bottom line is that the issue isn't as simple as whether you should demo at trade shows. You need to research the expected trade show population and shape your goals accordingly. In the end, you may decide that being an exhibitor isn't the best way of achieving those goals.

Monday, August 27, 2007

GSD&M's Idea City

GSD&M is changing its name to "GSD&M's Idea City". This move seems like a bad idea for at least three reasons:
  1. The new name is too long. The length of the name makes it less "speakable". A brand name that's easy to say is more likely to be remembered and more amenable to word of mouth.
  2. The new name is too descriptive. Descriptive brand names are less memorable and make differentiation in the mind of the customer harder.
  3. Any identity change is costly. Every bit of marketing and sales collateral has to be modified and redistributed.
But the threat of rebranding disease is constant and almost ubiquitous.

Friday, August 24, 2007

iPhone Convergence in Action

It's just one person's experience, but Amy Tiemann recently described her disappointment with the iPhone. Her conclusion:
It turns out that combining multiple functions into one device isn't always more convenient. For me, a Blackberry Pearl plus an iPod Nano seems to be the best combination. I need basic online access on my smart phone, but I don't browse a lot or compose a lot of e-mail on my Pearl. I either call back, answer e-mails from my desk, or if I am traveling, I have my laptop with me.
Recall that Laura Ries stubbornly predicted that the iPhone would fail (after some initial success) because it is a convergence device. The jury's still out, but Amy Tiemann's experience is an interesting data point.

Thursday, August 16, 2007

When the Market Changes, Should Your Brand Also Change?

Trends in the marketplace affect the appeal of your message and the profitability of your product. When the trends run counter to your marketing message, should you re-position your product?

Laura Ries says, "No." She discusses the Hellman's brand. Hellman's mayonnaise is full fat, so
What do you do when the world seems obsessed with dieting, fat and calories? When every product is promoting it is low-fat, fat-free, low-carb, high fiber or zero calorie? When everybody is on a diet, gobbling up calorie reduced manufacture foods yet still hungry, miserable and (at least in the U.S.) fat?
Most company executives and product managers would either modify the marketing message or come out with a "light" version of the product under the same brand.

What does Laura suggest?
Whatever your brand is, you have to deal with it. Pretending it isn't high fat isn't going to change what’s in the package. And promoting your “light” version just reinforces in the mind of consumers how “fattening” the regular version must be.

Like food, a brand is best when it is real, simple and focused. If opportunity strikes in another direction, companies should launch a new brand.
In other words, maintain brand focus.

Tuesday, July 31, 2007

How a Six-Month-Old Startup Got Bought by Google

Yes, this piece gives advice (based on an actual startup experience) about how to get bought by Google, but it's really just sound advice for any business:
  • Don't focus on getting acquired.
  • Instead, focus on the user.
  • Ignoring limitations lets you tackle problems from a different angle.
  • Don't be afraid to tackle the giants.
  • Pay attention to the details.
  • Have a really understanding spouse.
See the piece for details.

Wednesday, July 25, 2007

Buy a Problem

In my last entry, I described the Buy a Feature innovation game. One of the shortcomings of the approach is that it focuses on features instead of problems.

Unless they are product designers, your customers likely do not know how much a feature is worth to them. What they know - or at least what you can elicit from them - is what problems they currently face and how much those problems cost them.

Before your product designers decide what features to include, they need to know the product requirements. As I've mentioned, requirements are simply a manner of expressing, in measurable terms, the problems that customers want to solve and avoid.

So Buy a Feature can put the cart before the horse. Your team needs to understand the problems customers want solved, and how they prioritize them, before jumping into features. And once your team is considering various features, why do you need customers to prioritize them for you? Your team's job is to weigh the features in terms of how well they address the requirements (which have already been prioritized), not to engage customers in a separate effort of prioritizing features independently of the problems they solve.

Tuesday, July 24, 2007

Buying Features

One of Luke Hohmann's great innovation games is "Buy a Feature":
Create a list of potential features and provide each with a price. Just like for a real product, the price can be based on development costs, customer value, or something else. Although the price can be the actual cost you intend to charge for the feature, this is usually not required. Customers buy features that they want in the next release of your product using play money you give them. Make certain that some features are priced high enough that no one customer can buy them. Encourage customers to pool their money to buy especially important and/or expensive features. This will help motivate negotiations between customers as to which features are most important. This game works best with four to seven customers in a group, so that you can create more opportunities for customers to pool their money through negotiating.
A nice consequence of using this approach is that it gets customers away from the mentality that features come for free. They must prioritize and balance the value of features versus development costs.

If you haven't checked out Luke's book, Innovation Games, I definitely recommend it.

Nonetheless, in my next post, I will discuss an important limitation of this approach and propose a variation that addresses the limitation.

Monday, July 23, 2007

Monitor Your On-Line Presence

If you monitor mentions of your company or product on search engines, in on-line news, or in blogs, you may find yourself manually performing searches on an irregular basis. An easy way to monitor your on-line presence is to use Google Alerts:
  1. Go to the Google Alerts page.
  2. Sign into your Google account (if you don't have one, create one).
  3. Click the 'New Alert' button on the bottom right of the page.
  4. Type the search keywords you wish to monitor.
  5. Select whether to monitor news, blogs, web, groups, or comprehensive (all of them).
  6. Select how often you wish Google Alerts to perform its searches.
  7. Click the 'Create Alert' button.
Then you'll receive e-mail notifications when your on-line presence changes.

Tuesday, July 17, 2007

Your Product Will Be Buggy

No matter how thoroughly you test your product, no matter how many quality control measures you put into place, any new or significantly-enhanced product you release will be buggy.

Some good quality control measures include:
  1. Your product manager gathers realistic usage scenarios from prospective and existing customers.
  2. Your testing team maintains a suite of regression tests, adds to them as tricky new scenarios come to light, and runs the tests on a regular basis.
  3. Your developers maintain unit tests and run them on a regular basis.
  4. Your developers review each other's designs and code.
  5. You release beta versions of the product to customers.
Yet even with these measures in place, your product will almost certainly contain defects. Part of your release plan should be to put mechanisms in place to efficiently process defect reports, fix them promptly, and enable users to obtain the fixes as quickly and painlessly as possible.

Tuesday, July 03, 2007

iPhone: Distinctive and Inviting

My friend Tamara got an iPhone over the weekend, and I got a chance to play with it Sunday. After watching her use it, listening to her comments, and trying it for myself, I concluded that the iPhone is distinctive and inviting.

The iPhone is distinctive in the sense that I have never seen another phone that simultaneously is sleek, has a large and bright screen, and has a fingerable touch screen. My 8525 has a fairly large screen and a stylus touch screen, and it is more powerful, but it is by no means sleek. It looks clunky in comparison to an iPhone.

The iPhone is inviting in the sense that, while not necessarily easier to use than many other phones, the phone's user interface is innovative and stylish. You want to hold the phone and use it if just because it looks so "neat".

That said, aside from its distinctive and inviting look, I see little reason to buy an iPhone. And it still remains to be seen whether the iPhone will be a success in the long run.

Monday, July 02, 2007

Use Cases for Sales Enablement

The sales folks in your organization need to connect with customers by addressing their specific situations and problems. Arming sales with use cases and scenarios can help.

The idea is to document use cases and scenarios for all situations that a qualified lead might face. When a sales person is on the phone with a prospective customer, she then can not only tout benefits of the product, but she make those benefits tangible and clear by applying them to the prospect's situation.

Fleshed-out use cases and scenarios contain the following information that is critical to a sales person interacting with a prospect:
  1. Description of the functional goal of the user. The name of the use case/scenario should convey what the user wants to accomplish. An explanation of the context and the reasons is also helpful.
  2. User interactions with the product. The step-by-step description of how the user will interact with the product to achieve her functional goal.
  3. Preconditions and postconditions. Conditions that exist before and after the user has interacted with the product as described in the use case/scenario. Preconditions and postconditions indirectly capture the nonfunctional behavior (usability, performance, etc.) of the product.
But keep in mind that most of what your sales people should be doing is first asking questions to understand the customers' situation, problems, the implications of those problems, and the need/payoff associated with the problems. Only then can they identify the use cases and scenarios that are truly compelling to the prospect.

Laura Patterson has more on use cases for sales enablement here.

Thursday, June 28, 2007

Dadnab Media Coverage

A couple of weeks ago, I sent a press release to Austin media outlets announcing the launch of Dadnab. (The service has been operational for over a year, but for various reasons I had held off on announcing it to the traditional media.)

Two weeks later, stories or mentions of Dadnab have so far appeared in three publications:
  1. Austin Business Journal. A blurb appeared in the 6-22-2007 print edition.
  2. Austin Chronicle. The "Naked City" column dedicated a section on Dadnab in the 6-28-2007 print and on-line editions. Also, on 6-25-2007, an entry on Dadnab appeared in the "Chronic" blog.
  3. Daily Texan. Both the print and on-line editions of the 6-28-2007 University of Texas campus newspaper contain a full-blown article on Dadnab.
Properly-crafted press releases really do stimulate media coverage.

Tuesday, June 26, 2007

Seth Godin on Focus

Seth Godin points out one reason that focus is so important in marketing:
[Y]ou can learn much earlier in the process if you've gotten it right or not.
Because you're making more per sale, you can spend the time necessary to figure
out what really sells and modify your offering sooner in the process.
When you're all things to everyone, you're nothing to anyone.

Wednesday, June 20, 2007

Cognitive Dissonance

The power and pervasiveness of cognitive dissonance and the rationalization are phenomena that all marketers should understand. Read about them here.

Wednesday, June 13, 2007

Requirements Elicitation Research

Over on Seilevel's Requirements Defined blog, Joy Beatty wrote about some research into requirements gathering. The results of the research appeared in a paper, "Child's play: using techniques developed to elicit requirements from children with adults" (IEEE membership or subscription required). The research was mainly into eliciting requirements from children, but many of the same lessons apply to adults.

The main lesson from the paper seems to be that it is foolhardy to elicit requirements from children or from adults by simply asking them what they want. Placing them in realistic scenarios and focusing first on what they are trying to achieve - rather than how to achieve it - is the key to successful requirements elicitation.

Tuesday, June 12, 2007

Project Comparison: Agile and Waterfall

Chris Woodill wrote about two software projects that his organization is working on. One project is using agile methods. The other project is using a waterfall process.

Chris compared and contrasted the results so far.

Friday, June 08, 2007

Lessons from Apple

The Economist has an article about Apple and business lessons to learn from it. According to the article, the lessons are:
  1. Incorporate outside innovations. Not all innovative ideas have to come from within your own company.
  2. Design from the perspective of users, not from the perspective of a technologist. Usability is key.
  3. Be willing to ignore what the market says it wants today. Sometimes, concentrating on prospective instead of existing customers is the best policy.
  4. Fail wisely. Expect some of your products to fail and to learn from those failures.

More on "failing wisely":

The fourth lesson from Apple is to “fail wisely”. The Macintosh was born from the wreckage of the Lisa, an earlier product that flopped; the iPhone is a response to the failure of Apple's original music phone, produced in conjunction with Motorola. Both times, Apple learned from its mistakes and tried again. Its recent computers have been based on technology developed at NeXT, a company Mr Jobs set up in the 1980s that appeared to have failed and was then acquired by Apple. The wider lesson is not to stigmatise failure but to tolerate it and learn from it.
Will the iPhone ultimately be a success, or failure from which Apple learns? Time will tell.

Thursday, June 07, 2007

Seth Godin: Against Meaningful Logos

The best logos and brand names have little or no preconceived meaning and little or no relation to your product. So it's good to see Seth Godin come out so unambiguously against "meaningful" logos:
If you're given the task of finding a logo for an organization, your first task should be to try to get someone else to do it. If you fail at that, find an abstract image that is clean and simple and carries very little meaning--until your brand adds that meaning. It's not a popularity contest. Or a job for a committee. It's not something where you should run it by a focus group. It's just a placeholder, a label waiting to earn some meaning.
If you find yourself or your team evaluating the quality of a logo in terms of what it conveys about your product - instead of it conveying little or nothing at all - you're on the wrong track.

Tuesday, June 05, 2007

Reference Cards

If your marcom team is thinking of creating a brochure, stop and think about its purpose and context.
  • Where are you going to make it available to prospective customers?
  • Do you expect or want them to read it as soon as they pick it up?
  • Do you expect or want them to take it home or to work with them?
  • Do you want customers to hand them out to their colleagues/friends?
  • Do you want customers to keep them on hand for reference?
Depending on the answers to these questions, you might consider information or reference cards instead of a brochure. If you distribute durable cards the size of a standard business card (3.5" x 2"), customers are more likely to:
  • Take it home or to work.
  • Hand them out to their colleagues and friends.
  • Keep them in their purses or wallets for reference.
Sometimes a brochure is the way to go, but it depends.

Monday, June 04, 2007

Ayn Rand and Taxation

Ayn Rand is a hero of libertarians and other advocates of limited government. Many of her fans complain about progressive taxation and favor a flat tax. A progressive tax system is one in which the tax rate is higher for larger incomes, profit, or sales cost. A flat tax system is one in which the tax rate is the same for all incomes, profit, or sales cost.

Most proponents of flat taxation argue that having the wealthy contribute a disproportionate share of their income towards the government's expenses is unfair and wrong. They may even quote Ayn Rand as part of their argument.

I don't want to argue for or against a flat tax here. But I do want to dispense with the notion that Ayn Rand opposed the wealthy contributing a disproportionate share of their wealth or income to the legitimate operations of government.

The money quote is from Ayn Rand's The Virtue of Selfishness:
It is in their own interests that the men of greater ability have to pay for the maintenance of armed forces, for the protection of their country against invasion; their expenses are not increased by the fact that a marginal part of the population is unable to contribute to these costs. Economically, that marginal group is nonexistent as far as the costs of war are concerned. The same is true of the costs of maintaining a police force: it is in their own interests that the abler men have to pay for the apprehension of criminals, regardless of whether the specific victim of a given crime is rich or poor.
Almost sounds like class warfare rhetoric, doesn't it?

A couple of subtleties and qualifications:

First, recognize that Rand believes the government's only proper role is defense, enforcement of contracts, and law enforcement. Rand's opinions on the funding of government therefore cover only those expenses.

Second, Rand did propose a flat tax of sorts but it was voluntary:
[T]he cost of . . . voluntary [my emphasis] government financing would be automatically proportionate to the scale of an individual's economic activity.
Rand pointed out that most of the poor, since they have little at stake, would likely not contribute at all. So what may have appeared to be advocacy of a flat tax in fact more closely resembles progressive taxation in its effect.

A pure disciple of Ayn Rand therefore must therefore favor not only a minimal role for government, but a progressive system of funding it.

Friday, June 01, 2007

Positioning Statements - Courtesy of Wal-Mart and GSD&M

A leaked Wal-Mart competitive analysis (prepared by GSD&M) gives some nice positioning statements:
  • Best Buy = Electronics, because they provide information and knowledge to help you make an informed decision.
  • Kohl's = Apparel, because they provide a wide selection of brand-name apparel for any occasion, any style and any budget in a stylish environment that inspires browsing.
  • Bed Bath & Beyond = Home Decor, because they have great displays that provide ideas on how to pull looks together.
  • Walgreens = Quick Prescriptions, because you get them quickly and efficiently so you can get back in bed.
Details here. Via Brand Autopsy.

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

Monday, April 30, 2007

More on iPhone Predictions

I noted in March that Laura Ries predicted the iPhone will flop. Her reason is that she believes it is a convergence device.

In a comment, my friend Brandon boldly disagreed with Ries and predicted that the iPhone will be a huge success. Now Seth Godin has joined the fray with his prediction:
My take is quite different. I think the iPhone is going to sell 2 million units in 2007 and more in 2008. There, I said it.
Meanwhile, Laura Ries stands by her prediction that the iPhone will not be successful.

I respect the willingness of Laura, Brandon, and Seth to go on the record with their predictions. I don't yet have a prediction. I see the success of the iPhone hinging upon what Jack Trout and the elder Ries (Al Ries) call "the battle for the mind".

Is the iPhone really a convergence of product categories, or is it merely a convergence of technologies? Whether it is a convergence of product categories depends on how Apple will market it, and how consumers will eventually perceive it. If consumers perceive it as a phone with iPod functionality, then Laura Ries may be proved right. If consumers perceive it as an new kind of device and are able to assign it an entirely new category, then it could be an astounding success.

Friday, April 27, 2007

"How Are You Doing?" Questions

When you are facilitating a meeting, it's a good idea to periodically ask "How are you doing?" questions.

Some meeting participants have a lot to say but keep quiet, because they don't feel "safe". All of the participants who are vocal may agree on something, making those who disagree reluctant to share their contrary opinions.

One of a meeting facilitator's responsibilities is to make all participants feel safe. How about asking:
What's up, Paul? Do you have any thoughts to contribute?
or
It seems we have a lot of agreement that . . . . How about some contrary opinions? What do you think, Jane? How about you, Justin?
Monitor the participation and body language of the meeting attendees. Proactively solicit contributions from those who aren't participating or who look like they have something to say.

Thursday, April 26, 2007

Disastrous

Oh, Laura, thanks for your thoughts about descriptive names:

One of the most tempting and logical but ultimately disastrous naming strategies is using a generic descriptive name. While you think you are giving your brand an advantage by describing exactly who you are and what you do. You aren’t able to build a powerful brand. Generic names are filed in the mind in the lowercase. To have power, brands need to be filed in the uppercase.
An example?

Seattle’s Best Coffee, might tell people that you have a high-end coffee shop from the Pacific Northwest. But when I ask people what Seattle’s best coffee is the answer is always the same: Starbucks.
The best way to come up with a good brand name, in my opinion, is to sit in front of a computer typing candidate names into Google. Find ones that have close to zero search results.

Wednesday, April 25, 2007

Brand Resonance

Seth Godin recently advanced the following definition of "brand":
[Prediction of what to expect] times [emotional power of that expectation]
I have previously defined "brand" as
A set of associations imprinted in the mind of a customer.
Either way, a brand exists in the mind of the customer.

And Daniel Sitter elaborates:
[Godin] also suggests that focus is also an important factor for companies to remember when marketing their brand. If a company has diversified into many industries, their brand often becomes diluted, forcing confusion into the mind of the consumer, and a confused mind does not buy. Furthermore, reading between the lines reveals that the tendency towards offering various brand extensions may also tend to cloud the branding efforts of a company, leading to poor consumer recognition. The solution... keep it simple, maintaining a brand focus.
In other words, brand focus not only makes it easier to set customer expectations, but also helps maximize the emotional power of those expectations.

Tuesday, April 24, 2007

Paper Wallet

Instructables tells us how to make a durable wallet from a 8.5 x 11 sheet of a paper and a piece of tape.

Monday, April 23, 2007

Transcript of "Understanding Requirements Concepts" Webinar

Below is the transcript of the "Understanding Requirements Concepts" webinar I presented in January. You can also find it, along with links to the video and audio, here.

Roger Cauvin: All right; thank you. Again, I’m Roger Cauvin with Cauvin, Inc. It’s a product management and research firm in Austin, Texas.

Today as Suzannah mentioned, we’re talking about requirements concepts. The purpose of the presentation is going to be to clarify the concepts and terminology related to requirements.

I’m going to do three things. First, I’m going to show how existing requirements terminology is actually contradictory. Second, I am going to show how confusion leads to product development failures, and third, I am going to clarify the concepts to remove the contradictions.

I recently participated in an on-line debate about requirements terminology, and in that debate one of the other participants drew a distinction between external and internal aspects of products.

The idea is that the line between requirements and design can be drawn in the same way as between external and internal aspects of a product. So a requirement would specify the external behavior of the product, and the design specifies the internal details.

That sounds like a great distinction and a great way of drawing that line between requirements and design. Unfortunately it leads to contradictions.

What does a UI designer do? A UI designer specifies only the external aspects of the product when that UI designer produces a user interface spec. Well, if it’s only the external aspects of the product, then you would think they would be requirements. But then we’re led to the conclusion that UI designers do not design user interfaces. Which is a contradiction in terms.

Another example is FRSs, which are called "functional requirement specifications". We’ll talk a little bit later about what functional requirements are vs nonfunctional requirements but for now, you would think that a functional requirement specification would contain functional requirements and not contain nonfunctional requirements.

When I talk to colleagues who actually produce these documents, they insist that their functional requirement specifications include nonfunctional requirements. So we’re led to the conclusion – the contradictory conclusion again – that functional requirement specifications contain nonfunctional requirements.

You may be asking, well, this is all semantics. Why does this matter? Does this have any impact on how we do our requirements, and whether it impacts our product development processes, and whether we have successful products?

I argue that it does. Just about any problem solving expert that you talk to will say that the most neglected and the most important part of the problem solving process is first understanding and defining the problems you are trying to solve clearly.

When we fail to understand the distinction between requirements and design, we are essentially failing to understand the distinction between the problem and the solution and we therefore end up, very often, failing to clearly understand and define the problem. That leads to product failure.

Toyota understands this. Toyota is renowned for their process improvement practices. I recently read an article about Toyota’s process improvement practices, and in that article Toyota executive said the quote that is on the screen right now. That quote essentially says that one of the keys to Toyota’s process improvement successes has been their emphasis on first trying to understand clearly the problems they are trying to solve and what they are trying to improve, before jumping into possible solutions and ideas about how to achieve that.

I am going to introduce you now to the conceptual model which you see on your screen. A conceptual model depicts concepts and the associations among those concepts. The rectangles you see represent the concepts, and the lines you see between them represent the associations among those concepts.

Above each line or associated with each line, is a text description as well as what’s called multiplicity. Let’s look at product and problem.

A product solves or avoids problems. The multiplicities are the 1 and the asterisk you see. The asterisk means "any number of"; it could be zero to infinity. So we read that as, "one product solves or avoids any number of problems".

If you look under the stakeholder concept, you see a hollow triangle. The hollow triangle on the end of an association link depicts specialization; it is a special kind of association.

The way you read this is "an internal stakeholder is a kind of stakeholder". A user is a kind of stakeholder. A buyer is a kind of stakeholder. So what I’d like you to take away from this slide in the end, is the emphasis on solving problems.

Some of you may be familiar with Pragmatic Marketing – with whom I have no affiliation – but I respect what they teach and what they preach a lot – which is they talk about product managers’ primary responsibility being identifying problems in the market. If a product doesn’t solve or avoid problems in the market, then it’s probably not going to be a success in the market.

This diagram shows that product solves or avoids problems that stakeholders face.

That brings us to the definition of requirement. The definition of requirement is it specifies the least stringent conditions that must hold to solve or avoid a problem that a prospective customer or other stakeholder faces.

The requirements are [integrally] linked to problems. Requirements are all about defining what it means; defining the conditions that must exist before we would say that the problem has been solved.

That brings to mind an article I recently read by Steve Johnson of Pragmatic Marketing, in which he stated flatly "the requirement is the problem".

What that meant was a statement of a problem, and a statement of the conditions that must exist for us to say the problem is not there, is the requirement.

There are two types of requirements. Functional requirements and nonfunctional requirements. A functional requirement specifies what the system or the product will do or enable it to do. So it specifies a function. An example would be – let’s say our product is a car. A functional requirement for the car, would be that it enables users to travel from their origin to their destination.

Associated with that functional goal, that function, are sequences of interaction that may occur between the user and the product in order to achieve that goal. That’s what the use case is.

What’s important to recognize, though, is that a use case – it’s really the end goal of the use case – of the top level use cases of a product – that represent the functional requirements. The individual steps within the use case are a form of interaction design. They can also be functions but they are not functional requirements. They are design functions.

That brings us to nonfunctional requirements. You may ask, well, it seems like the steps in a use case really are important because the user is interacting with the system. They are the ones who are actually carrying out those steps.

In a sense, that’s true. But what they are trying to accomplish is things like not just the functional goal, but they’re trying to do it within – let’s take the car example – where they are traveling from origin to destination. When they are dong that, they want to make sure they are doing it fast enough; that it’s easy enough for them – those kinds of things.

Those are the nonfunctional requirements. Things like usability, speed, reliability, comfort, fuel efficiency—all of those things are attributes. If you look in the diagram, attributes characterize functions. So in the context of traveling from your origin to your destination, you want it to be fast, reliable, comfortable, etc.

When you do that, though, in order to make that a requirement, it has to be measurable. So you have to have metrics associated with each attribute.

A metric, for example, might be, for the fuel efficiency attribute, miles per gallon. It’s the way you measure fuel efficiency. Then you place constraints on that metric. So you specify that the product should get at least 50 mpg, let’s say. And there’s your nonfunctional requirement.

Another question that may be entering your mind - or may have entered your mind long ago - is wow, this is a very high level conceptualization of requirements. So high level that developers would not know what to build if they were given a thorough and comprehensive requirements document, using this conception of requirements.

You’d be right. Requirements aren’t enough to dump in the lap of a developer and expect them to be able to code from it. Design specifications are important too.

The lesson here is that a specification is not synonymous with requirement. There are two types of specifications; design specifications and requirements specifications. Requirements specifications are very important because they are all about that problem-, that all important problem-solving activity which is defining the problem you are trying to solve.

Design specifications are important too, though. Those include things like user interface specifications, use cases, the fleshed out steps in the use cases and things like that. They are definitely essential; they’re just not requirements.

Finally, here is the entire conceptual model. It may be a little small for some of you to read. I’d urge you to visit the entry on my blog where you can view a larger version of the model or print it out for your own purposes.

This screen is a combination of the other screens that I showed you. With that, I guess I’ll turn it over to Suzannah.

Questions and Answers

Q: How does viewing requirements this way fit in with Agile Software Development?

A: It fits in well but the thing to recognize, is that when you – one of the premises behind Agile – is that it’s almost impossible to fully understand all of the problems you are trying to solve before you actually start implementing your product.

In the context of an Agile product management and development environment, what you do is you develop an initial set of solutions for your requirements. But don’t try to be 100% about it because you never can be until you move into design, do some design and implementation, and get some feedback from your customers. That will typically shed light on some problems. Some problems will come to light that you hadn’t recognized before.

Q: What is the difference between acceptance tests and requirements?

A: Acceptance tests and requirements are [integrally] related. An acceptance test, however, is something that is practical to implement. Sometimes the problem that a customer wants solved is not readily, in practice, testable. It always should be, in principle, testable. It always should be something you can measure but in practice, sometimes that measurement is hard to make.

For example, let’s say the customer wants the car to last 7 years. In order to directly test that requirement, which is something we have to fulfill – it is something important to fulfill – we can’t just ignore it because it’s not easy to test – in order to test that directly, we would have to wait 7 years.

We would have to devise an acceptance test which would take 7 years for us to find the results.

So instead what we do is devise acceptance tests that approximate or give us a good idea or simulate the requirement we are trying to test.

Q: What are the key steps to coach and educate traditional business owners and product managers, to trust and think Agile on storycards instead of requirement documents?

A: I would say the first thing to do is to get buy-in for the notion that traditional Waterfall requirements documentation, where you assume you are going to get all the requirements right up front and throw them over the wall to the designers and the developers – doesn’t work.

One way to do it, is to gather the evidence and present the evidence about how that doesn’t work. And get buy-in for the notion that it doesn’t work. I think that’s the main prerequisite to getting them to think that maybe there is another way. Maybe you can use a little bit more Agile requirements documentation, such as storycards.

But I don’t know. I’m not personally endorsing the idea of storycards. But I do endorse the notion of an Agile approach to requirements which means that you don’t try to produce 100% of detail and accuracy up front and assume that it’s going to hold for the rest of the project.

Q: You mentioned you have to have metrics for your nonfunctional requirements but many times nonfunctional requirements are qualitative in nature. What are your feelings about this?

A: I guess an example would be good there – I’ve encountered an example before and used one before when trying to explain this, and that might be – a metric tends to imply a number.

Of course, sometimes an attribute is not measured in terms of a number. Sometimes it could be a color – a range of colors— of languages or something like that. That’s fine; I’m including that in the notion of a metric.

Q: If a customer says they want a button to be blue, is that a requirement?

A: It could be, but in all likelihood it’s not. Our responsibility as product managers is to ask "why". If the customer says they want the button to be blue, we need to understand why they want it to be blue. We can’t just say okay, we’ll make the button blue. We’re really shirking our responsibilities to understand what lies beneath that.

What we might find out, for example, is that they wanted it to be blue because that’s the traditional color scheme they are used to, where maybe blue buttons are okay buttons and red buttons are their cancel buttons – and they are afraid if you change that scheme on them, that they’re going to press the wrong button and possibly lose data, possibly result in the death of somebody – or other negative consequences.

We need to understand what that is. Once we do that, we can formulate it in terms of a nonfunctional requirement, like safety, and put metrics around it – like the likelihood that a user with a certain profile is going to lose data, cause death or whatever they are trying to avoid.

Thank you very much, Roger, for the extremely insightful presentation.