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?
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


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.

Friday, April 20, 2007

Milestones Must Be Deliverables

Johanna Rothman recently wrote:
I taught a workshop about transitioning to Agile earlier this week. One of the things that's difficult for many project managers to recognize is that milestones must be deliverables--otherwise, it's too hard to know when something is done.

One of the participants had a slightly puzzled look on his face when I said that, so I'm not now thinking that another way to think about milestones is to call them handoffs. If everyone has the idea that their milestone is really a handoff to someone else in the project, you're more likely to get to "done" for a milestone.
Many early practitioners of agile methods are confused by the concept of an iteration, because it almost seems like an arbitrary increment in a project. At any point in a project, we can take a snapshot of everything and call it the end of an iteration. Johanna points out, succinctly, that iterations should be oriented around deliverables.

The most valuable deliverables will in general be those that exercise risks - usually requirements or architectural risks. If your team can deliver a fledgling version of the product to testers and prospective customers, you can determine how much progress the team is making in addressing these risks.

Thursday, April 19, 2007

What is Competitive Analysis?

What is competitive analysis?

You might think the following activities qualify as competitive analysis:

  1. Creating a matrix of features that shows how your product performs against competitors'.
  2. Comparing your product's market share, gross sales, etc. against those of your competitors.
These activities can indeed be part of competitive analysis, but they neglect the most important factor. Competitive analysis should primarily be about analysis of customer psychography and perceptions. Don't just compare your product to other products, determine what differs between your customers and those of competing products.

What are the problems your customers are trying to solve, and what are the problems competitors' customers are trying to solve? Document personas not just for the customers of your product, but for competitors' products.

How do people perceive your product versus others? With what single word do they associate your product (i.e. what is your brand)? Compare this word to the words that your competitors "own" in the minds of customers. What do existing and prospective customers perceive as your product's biggest strengths and weaknesses? What do they perceive as your competitors' biggest strengths and weaknesses?

This sort of competitive analysis is what should drive the positioning of your product, which largely determines the relative priority of product requirements and the strategies for marketing and selling your product.

Wednesday, April 18, 2007


In Marketing Warfare, Al Ries and Jack Trout wrote:
To play the game well, you first have to learn the rules, or principles, of the game.
The problem with marketing today is not just the lack of rules. The biggest problem of all is the failure to realize that one ought to have rules in the first place.

To rectify that problem, marketing people must start to systematically examine the history of marketing and formulate the strategic principles that govern the outcome of corporate battles. Nothing today is as important as strategy.
Good marketing doesn't come just from understanding and applying sound principles of marketing. It doesn't even come just from understanding your market. Good marketing requires both market understanding and principles.

Tuesday, April 17, 2007

Commuting's Dormant Problems

A recent article by Nick Paumgarten in the New Yorker magazine examines the psychology of commuters (those who travel long distances to work each day). Commuting is a revealing example of how:

  1. People are not always aware of the problems they face in their day-to-day lives.
  2. People are sometimes unable to judge rationally how valuable it is to solve the problems they face.
Paumgarten observes:

A commute is a distillation of a life’s main ingredients, a product of fundamental values and choices. And time is the vital currency: how much of it you spend—and how you spend it—reveals a great deal about how much you think it is worth.
The root of a product manager's responsibilities is to understand problems in the marketplace. The behavior of commuters shows that researching these problems is not always straightfoward, however. For example:
“Drive until you qualify” is a phrase that real-estate agents use to describe a central tenet of the commuting life: you travel away from the workplace until you reach an exit where you can afford to buy a house that meets your standards. The size of the wallet determines that of the mortgage, and therefore the length of the commute.
Yet according to Robert Putnam, a Harvard political scientist:
There’s a simple rule of thumb: Every ten minutes of commuting results in ten per cent fewer social connections. Commuting is connected to social isolation, which causes unhappiness.
The commuting paradox reflects the notion that many people, who are supposedly rational (according to classical economic theory, at least), commute even though it makes them miserable. They are not, in the final accounting, adequately compensated.
Road-building doesn’t much help. Atlanta is a showcase for a phenomenon called “induced traffic”: the more highway lanes you build, the more traffic you get. People find it agreeable to move farther away, and, as others join them, they find it less agreeable (or affordable), and so they move farther still. The lanes fill up.
The article is chock full of profiles of actual commuters and accounts of actual commute experiences. If your product manager is not generating this sort of information, he is not likely to thoroughly understand his market. The article further illustrates the complexity of interpreting quantitative and qualitative information and understanding market problems.

Monday, April 16, 2007

Dodgeball Founders Quit Google

The founders of the Dodgeball text messaging service have quit Google. Google acquired the service a couple of years ago. Co-founder Dennis Crowley wrote on his blog:

It's no real secret that Google wasn't supporting dodgeball the way we expected. The whole experience was incredibly frustrating for us - especially as we couldn't convince them that dodgeball was worth engineering resources, leaving us to watch as other startups got to innovate in the mobile + social space. And while it was a tough decision (and really disappointing) to walk away from dodgeball, I'm actually looking forward to getting to work on other projects again.
I wonder what the future holds for the service.

Friday, April 13, 2007

Origin of Various Company Names

James at the Forty blog tells us where various company names come from. A few highlights:
Adobe: from the name of the river Adobe Creek that ran behind the houses of founders John Warnock and Chuck Geschke.

Canon: Originally (1933) Precision Optical Instruments Laboratory the new name (1935) derived from the name of the company’s first camera, the Kwannon, in turn named after the Japanese name of the Buddhist bodhisattva of mercy.

Nokia: started as a wood-pulp mill, the company expanded into producing rubber products in the Finnish city of Nokia. The company later adopted the city’s name.
Note how most of the names of the established companies in James' list are either proper names, are derived from facts about the founders, or are derived from acronyms.

Thursday, April 12, 2007

Upgrading Java

Sun recently released Java 6.0. As a current user of Java 5.0 (Dadnab is written primarily in Java), I've looked into upgrading to the new version. So far, I haven't done so, because I don't know how.

Before, it was mostly a matter of including jar files in the class path when compiling or running the Java program. Now I don't even know if those jar files exist in the new version.

This situation is striking. I have studied Sun's Java site and forums. I have downloaded new Java software and read the documentation. Perhaps I've missed something, but I really have no idea how to make my currently operational Java programs use the new version.

Did anyone specify upgradability requirements for Java 6.0? Did anyone test against them, having a sample of representative Java 5.0 users (not Sun employees) sit down and attempt to upgrade to the new version? I doubt it. They've ended up with a product and associated set of documentation that is unusable for some experienced Java programmers because they can't upgrade to it.

Can anyone help me? Dadnab currently uses the Java SDK and Java EE. What do I download, and what do I install, to simply upgrade to the new versions (so I can take advantage of some of the new functionality, such as generics)?

Wednesday, April 11, 2007

Easter Eggs

Want to get people talking about your product? One way to get people talking is to include "Easter eggs" in your product. An Easter egg is a hidden feature that surprises and delights, but isn't necessarily useful or consistent with the core purpose of the product.

When someone discovers an Easter egg, they are likely to spread word about it to their friends. "Hey, look what I found."

An Easter egg that my friend Sonia recently passed along is in Google Maps:
  1. Go to
  2. Click 'Maps'.
  3. Click 'Get Directions'.
  4. Enter 'New York, New York' to 'Paris, France'.
  5. Read line #23.
Sometimes developers include Easter eggs as a private joke, unbeknownst to you or your product manager. In other cases, Easter eggs are a deliberate means of generating word of mouth.

Tuesday, April 10, 2007

More on Affirmative Buying

Yesterday, I referenced and elaborated on Seth Godin's allusion to affirmative buying. Affirmative buying refers to the compelling reasons that customers buy a product, as opposed to the objections that non-customers voice as reasons for not buying it.

The notion of affirmative buying relates to the principle of focus. There is a constant temptation to broaden the appeal of a product to expand the size of its potential market. But broadening the appeal of a product typically entails making it less appealing to the most avid customers. The weaknesses of the product that limit its appeal to a broad market typically come hand-in-hand with the strengths that maximize its appeal to a focused market.

As an exercise, ask your product manager to present a plan to narrow the appeal of the product. In other words, ask her to consider the feature that appeals most to customers who are already the most excited about the product and turns off all other customers and non-customers. Have her present a plan for accentuating this feature and introducing new features that have similar appeal (and non-appeal).

Perhaps executing this plan would be disastrous for your product. But the exercise is worth performing just to explore what the focus of your product currently is and what currently motivates your customers. And there's a possibility that implementing the plan might just make the product so much more appealing to its base that they spread the word about it and increase the size of the customer base.

Monday, April 09, 2007

Affirmative Buying

Seth Godin recently wrote about stinky durian:

Durian is a fruit from Southeast Asia that can be charitably described as smelling like stale baby vomit.
How about a genetically engineered durian that is odorless? Would such a variety solve the "vomit odor problem" and therefore be a hit in the market for durian?

Non-durian eaters don't have a 'durian problem'. They aren't standing by, fruitless, impatiently waiting for Songpol Somsri to figure out how to make a stinkless one. Nope. They've got cantaloupes and kiwis and all manner of other fruits to keep them busy.

The feedback you get from non-consumers is rarely useful, because the objection they give is the reason they don't buy from you, not the thing that will cause them to affirmatively choose you.
If you spend all your time trying to address objections that buyers might have to your product, you end up with a product that offends no one but doesn't appeal to anyone, either. Focus more on the affirmative reasons customers buy your product, and be careful not to jeopardize the appeal of your product by watering it down.

Friday, April 06, 2007

Bad Ideas

Jeff Lash counsels product managers to embrace, or at least not discourage, bad ideas. Team members provide ideas and suggestions about how to develop, market, and sell products. A fundamental part of fostering innovation is to encourage the free flow of ideas, good or bad.

I would go so far as to add that your product manager should actively and intentionally be introducing bad ideas of his own. Doing so breaks the ice so that team members won't be afraid of introducing the first bad idea. It also puts team members in a counterintuitive state of mind, which is conducive to innovation.

Thursday, April 05, 2007

Small Annoyances

Usability guru Jakob Neilsen tells us about small annoyances in user interfaces that compound and cost you money.

Neilsen highlights the use of drop-down menus to select state abbreviations in e-commerce sites. This example resonated with me, because I have definitely been annoyed by such menus. Neilsen notes that Amazon offers users the ability to simply type the two-letter state abbreviations. Either way, Neilsen recommends web sites "validate that the ZIP code/postal code corresponds to the state, province, or other locality entered by the user".

The larger point is that your product manager should be framing the metrics to measure these annoyances, QA should be testing them, and your web designer should be minimizing them.

Wednesday, April 04, 2007

Why to Follow Guy Kawasaki's PowerPoint Rules

A story in Australia's Sunday Morning Herald tells us that using PowerPoint in presentations can reduce the audience's ability to follow and retain the information presented:
Pioneered at the University of NSW, the research shows the human brain processes and retains more information if it is digested in either its verbal or written form, but not both at the same time.
John Sweller, who developed the "cognitive load theory", clarifies:
It is effective to speak to a diagram, because it presents information in a different form. But it is not effective to speak the same words that are written, because it is putting too much load on the mind and decreases your ability to understand what is being presented.
Famed venture capitalist Guy Kawasaki has advised PowerPoint presenters to follow strict guidelines to make their presentations effective. These guidelines are primarily based on the premise that the visual aspects of a presentation should merely be cues or adjuncts to the oral component. Cognitive load theory provides a scientific rationale for Kawasaki's guidelines.

Tuesday, April 03, 2007

Researching for Test Cases

Part of the reason market research is important is to understand your prospective customers and to define and market your product accordingly. However, the testing of your product can also benefit from market research.

As I've expanded Dadnab to other areas (it is currently operational in Austin, Boston, Chicago, Dallas, Houston, Seattle, and the tri-state New York, New Jersey, and Connecticut area), I've used Google Maps extensively to come up with test cases. For each area, Dadnab has a suite of anywhere from 30 to 60 tests that I run periodically to ensure it is working properly.

Yet you don't improve what you don't measure. Occasionally, when I run into someone who lives in a covered area and ask them for locations to plug into Dadnab, Dadnab doesn't handle it well. So I now conduct on-going market research that polls prospective users for information about the trips they actually make. I then incorporate these trips into the suite of tests.

Monday, April 02, 2007

How to Choose Logo Colors

Al Ries and Laura Ries give us several pieces of advice about choosing colors for a brand logo:
  1. A brand should use a color that is the opposite of its major competitor's.
  2. Choosing a color that differentiates is more important than picking one that sets an intended mood or is descriptive.
  3. A single color is almost always the best color strategy for a brand.
For more information, see The 22 Immutable Laws of Branding.