Wednesday, August 31, 2005

Dormant Problems

Some problems that exist in the marketplace are dormant. Dormant problems are those problems of which your customers are not aware, and to which they will be oblivious until you present them with a new way of doing things.

Before the advent of e-mail, few people or companies considered written communication to be inefficient or a problem. Yet imagine a company like Dell scrapping the use of e-mail and going back to using paper notes and memos for their internal communications. Not only would it be inconvenient, it would have a devastating impact on their bottom line. It was not apparent just how inefficient written communication had been until we started using e-mail. Inefficient written communication, therefore, was a dormant problem.

Dormant problems are a challenge for a product manager to uncover, as well. Facilitation is one tool a product manager can use to uncover dormant problems. You also have to persistently ask, "Why?" Putting yourself in your customer's shoes, via an ethnographic study, is also helpful.

Sometimes the most effective way to uncover dormant problems, however, is to use these methods after releasing a prototype. That way, prospective customers have a chance to experience a new way of doing things, which helps them become aware of the problems they faced all along.

Tuesday, August 30, 2005

"Effective Product Managers Know Their Market" Manifesto

In her latest entry, Barbara Nelson recalls a "manifesto" that she and Steve Johnson wrote last year. It lists 23 things product managers must do to be active and facilitative (and therefore effective). It's right on point. I can't believe I missed it when they first published it.

Monday, August 29, 2005

Your Product Anchor

What single factor should anchor all of your product management efforts?

The pool of prospective customers, and the problems they face, should drive the definition and marketing of your product. However, the anchor for the entire effort is your company's distinctive competence. Your company's distinctive competence is what distinguishes it - and not just your company's products - from existing and potential competitors. It's what your company does or has that no other company has.

Your company's distinctive competence is generally the source of a sustainable competitive advantage. If your company is not uniquely qualified to develop or sell a product that solves problems customers face, then another company can enter the arena and produce or sell the same, or a superior, product.

When you're properly focusing on solving problems in the market, don't forget to ask yourself whether your company is uniquely qualified to solve them. Understand your company's distinctive competence.

Sunday, August 28, 2005

Pervasion

As I've mentioned, marketing experts have long warned against brand extension. You want your brand to stand for a single idea in the customer's mind. Focusing on no more than three key messages (or even just one) in your marketing campaign and can help you achieve this goal.

Your focused messages must pervade your entire product and marketing effort. Every piece of marketing collateral should communicate the message. Every press release should somehow refer to the message. You should be able to incorporate every seemingly insignificant choice of features in your product into your messaging story.

Saturday, August 27, 2005

Haagen-Dazs Triple Chocolate Ice Cream

A few weeks ago, I discovered something that has changed my life: Haagen-Dazs Triple Chocolate Ice Cream. Around the year 2000, I remember eating large quantities of Starbucks Double Shot Chocolate Ice Cream with Hazelnut Fudge. I was devastated when they discontinued the flavor, to the point that I called customer service. Now I have something to fill the void.

Friday, August 26, 2005

Test-Driven Development (TDD)

In a previous entry on agile product development, I mentioned that some companies that practice it employ "test-driven development" (TDD). With test-driven development, you plan and implement the tests for the product before you develop it.

The practice is most common in software development but works for all kinds of product development. One of the advantages of the practice is avoiding "drift". Drift is the tendency of product developers to lose sight of the requirements the product must satisfy. Collaboratively planning and implementing tests first ensures:
  1. The team understands the requirements.
  2. The requirements are testable (subject to the certain practical limitations).
  3. The team can apply the tests to the product continuously throughout development.
When you incorporate product management in the agile development of the product, you work closely with product testers to iterate on both the requirements and the tests.

Thursday, August 25, 2005

The Evils of Brand Extension

For years, marketing experts have cautioned against "brand extension". If you have an established product with a successful brand name, you might be tempted to "extend" it. There are two ways to extend your brand:
  1. Broaden the appeal of a single product by adding features to it. For example, if your product is a television, you might add a radio feature to it.
  2. Leverage the appeal of your existing brand name by attaching it to a new product. For example, you might produce a brand of bicycle called "The Ruckus". It's so successful that you decide to start a line of bicycle products: Ruckus Classic, Ruckus Sport, and Ruckus Supreme.
If you're not careful, extending your brand in either of these ways can destroy your profitability. The reason is that you may "pollute" your brand.

A brand represents an idea in the customer's mind. If you add features to your product that don't relate to the original, core purpose of the product, you run the risk of confusing the established idea in the customer's mind. When you create or extend a line of products, you make it difficult to maintain a single, coherent meaning for the brand name.

If you "pollute" your brand, it will be a less powerful force for driving your prospective customers to buy your products.

Laura Ries has a recent entry about brand extension on her Origin of Brands blog.

Wednesday, August 24, 2005

Approaches to Iterating

Recall that we at Cauvin, Inc. specialize in agile product management. Most agile methods incorporate iterations. With iterations, you develop and "release" the product many times before the final release to customers. In each time-boxed iteration, you refine the requirements, design, implementation, and tests for that "release" of the product. (I'll explore in a future entry how some agile methodologies plan the tests for the product before they design and implement.)

Yet sometimes it's not immediately obvious how to divide a product development effort into iterations. Here are some approaches that we use with our clients:
  • Verbal Description - Flesh out use cases and verbally walk through the customer experience with prospective customers.
  • Mock-Up - Compose a Powerpoint presentation or other user interface and use it to demonstrate the user experience to prospective customers.
  • Simulation - Create a simulated environment for testing your product and demonstrate your product working in that environment.
  • Use Cases per Iteration - Implement just a subset of the product's use cases and demonstrate them to prospective customers.
  • Use Case Versions per Iteration - Implement simplified versions of the use cases your product will ultimately satisfy. Demonstrate these working versions to prospective customers.
No matter which approaches you use to divide your product development effort into iterations, try to confront uncertainties and risks (in requirements and design) in early iterations.

Tuesday, August 23, 2005

Hardware versus Software

Some hardware producers believe that, while agile methods are important for developing software products, they do not apply to hardware products. In my view, agile methods benefit development of all types of products.

As I mentioned in a previous entry, the benefit of agile development is that you build into your process an efficient means of dealing with mistakes and discoveries that inevitably transpire. You discover requirements you hadn't considered. You find inadequacies in the design. You want to make these discoveries as early as possible in the development process. Iterating on the product development tends to minimize the amount of time it takes to discover problems and inadequacies and recover from them.

Why might agile processes not work for hardware development? In some cases, the cost of a hardware development iteration is much higher than that of a software development iteration. In software, your development staff simply updates code in each iteration. Code costs nothing but the time to write it. The equipment in hardware, on the other hand, costs money above and beyond the time to fabricate and piece it together. If you iterate too much, these costs will add up and exceed the savings you derive from discovering, and adjusting to, mistakes earlier in development.

The cost of iterating clearly does impact the wisdom of using agile methods. However, only in extreme cases does it ever render agile methods inferior to waterfall methods. Furthermore, organizations with no experience with agile methods tend to overlook the many creative ways they can iterate at a low cost. This myopia tends to bias them against agile methods.

Monday, August 22, 2005

Hiring a Product Manager

You're looking to hire a product manager, either on a full-time basis or as a consultant. You cringe as you think of all the resumes you're going to have to process. You decide to include in the requirements for the position that the applicant "must have ten years of experience in the industry".

Smart decision? Probably not.

Remember, the most important skill a product manager possesses is facilitation. People with facilitation skills are so rare that, by restricting applicants to those with a wealth of industry experience, you may have reduced your pool of qualified candidates to zero.

Furthermore, facilitation skills lessen the importance of industry experience. Facilitation is what effective product managers use to gain an understanding of the market for products. Industry experience only brings a true understanding of the market when the proper analytical and facilitation skills accompany it. And a skilled facilitator can gain a more thorough and unbiased understanding of the market in a short time than an experienced industry insider lacking such skill ever can.

Sunday, August 21, 2005

Product Management Case Study

Random has a blog entry about Blogger's integration with Microsoft Word. Blogger conducted some ethnographic research by visiting the Democratic National Convention to see political bloggers in action. They noticed bloggers at the convention composing entries in Word and attempting to transpose them to their blogs.

Random writes:

"I am sure there were many requests to add Word integration to blogger but is that really the solution? Did they adequately address the true customer need? Personally, I think what the Blogger users are saying is the current blogger editing tools are not very good. I doubt the Word bloggers use more than 1% of Word's features when editing a blog post. I would also guess there are numerous Word formatting quirks that will trip up the Blogger integration. My take is the Blogger team missed out on a great opportunity to really address the true customer need: a better Blogger editor."

With his analysis of this case study, Random affirms the fact that product management requires much more than just listening to customers. You have to take an active and facilitative approach to researching your market.

p.s. Random also mentions Flock. I'll be curious to check it out if I receive an invitation.

Friday, August 19, 2005

Why Pay for a Logo?

Here are some guidelines for designing and choosing a logo:
  1. The logo should be abstract (a "blank slate") and bear little or no resemblance to the product or product name.
  2. The attributes (e.g. colors) of the logo should be consistent with the rest of your branding effort.
  3. The logo should be such that it is possible to size it to fit on your marketing material, company documents, and product.
  4. The logo should be unique and identifiable to someone who has seen it multiple times.
  5. The logo should be easy to reproduce electronically (e.g. on a web page) and in print.

Given these guidelines, it makes little sense to pay a branding/advertising firm exhorbitant amounts of money to produce the logo. You just need someone creative who knows how to use simple drawing software on a computer.

Thursday, August 18, 2005

Requirements and Specifications

In a July entry, I wrote that product design is not part of a product manager's role. A product manager specifies the requirements, but not the design, for a product. In one of his comments, Steve Johnson included a link to an excellent article he wrote about the distinction between requirements and specifications. Whether you are a product manager or a company executive trying to understand the proper roles within the product team, it's well worth the read.

Wednesday, August 17, 2005

Ethnography

In her latest entry on the Customer Experience Crossroads blog, Susan Abbott writes about ethnography. Ethnographic market research differs from such typical methods as conducting surveys, focus groups, and one-on-one interviews. With these other methods, you don't study the prospective users and buyers of your product in their natural environment.

When you employ ethnographic research methods, you observe (and sometimes interact with) your subjects in their natural environment. In a previous entry, I linked to an interesting example of ethnographic market research.

Tuesday, August 16, 2005

Importance of Qualitative Research

In yesterday's entry, I briefly described the difference between quantitative and qualitative research. Since qualitative research tends to be less "scientific", you might consider it less valuable than quantitative research. You would be mistaken.

Imagine you're writing a business plan and including a section on the size of the market for your product (i.e. the estimated number of people who likely or potentially will buy it). The size of the market is a numeric quantity, so shouldn't you focus on quantitative research to determine it?

While quantitative research is necessary for sizing the market, you must segment the market before you can size it. I.e., you must divide the population into groups who are more or less likely to buy your product.

Segmenting the market requires a psychographic study. You can't just guess about the demographic characteristics that would make a buyer more or less likely to buy. You need an in-depth understanding of the situations and problems that different kinds of prospective buyers face. You segment the market along these psychographic lines. Then you determine how many people exist within each segment.

Using psychography to segment the market therefore requires qualitative research. This qualitative research is a prerequisite to the quantitative research into the size of each market segment.

Don't underestimate the importance of qualitative research!

Monday, August 15, 2005

Qualitative versus Quantitative Research

There are two types of market research: quantitative and qualitative.

Quantitative research yields information about the number of people who fit certain criteria. An example of quantitative research is conducting a survey to determine the percentage of people who have bought a competitor's product.

Qualitative research, on the other hand, yields non-numeric information, such as an account of a particular customer's situation and problems. A product manager might determine the customer's situation and problems by conducting a one-on-one interview. Since it is not directly quantifiable, the information from qualitative research is not always "scientific".

In an upcoming entry, I will examine why both types of research are important.

Sunday, August 14, 2005

Saturday, August 13, 2005

Roger's Theory of Bias

Accusations of bias usually indicate more of a bias on the part of the accuser than of the accused.

Friday, August 12, 2005

Get Straight to the Point

MarketingProfs.com has a good article about how you should orient your corporate web site:

Excerpt:

"The Web is not a great place to win hearts and minds. It is not a great place to convince people to do something they did not come to the Web already intending to do. Traditional marketing techniques, such as brand name repetition and the use of images to communicate brand attributes, don't work as well on the Web.

What works well on the Web is a useful Web site that wastes no time and gets straight to the point."

Thursday, August 11, 2005

Focus Groups

Previously, I wrote that effective product managers actively go to the market to obtain information rather than relying on industry experience, feedback from support calls, or feedback from sales. Many executives don't seem to appreciate the value of go-to-market approaches, with one exception: focus groups.

Due to media attention to the concept of focus groups - whether in the context of product marketing or politics - much of the population is familiar with the notion. So the first idea that may pop into your head as an executive when you need market feedback is to conduct a focus group. Unfortunately, focus groups, while sometimes a useful tool, are often not a particularly effective active means of gaining an understanding your market.

The main problem with focus groups is that they don't give the facilitator the opportunity to probe deeply into the customers' situations and problems. Not all customers have the same perspective and background, so you would have to probe each customer individually to understand them. A focus group is not the appropriate setting for probing each individual's personal situation.

Focus groups are still helpful, particularly when one-on-one interviews precede them. Focus groups aid you in gaining an understanding of the surface, gut reactions of your customers. They also may yield insights about the effect of customer interaction on their propensity to buy.

Use focus groups judiciously, and don't use them to the exclusion of other techniques. More on this subject in Susan Abbott's Customer Experience Crossroads blog.

Wednesday, August 10, 2005

Passive versus Active Product Management

Many company executives believe they can understand the market for their products by passive means. For example, an executive may believe the following sources of information are sufficient for understanding the market:

1. Observations she made during her experience in the industry.
2. Suggestions and feedback from existing customers during support calls.
3. Feedback from sales about what prospective customers want.

These sources of information are all helpful but not sufficient. They are all passive ways of gathering information about the market for a product. You will never fully understand the market for your products without actively pursuing and facilitating interaction with your customers.

A product manager goes to the market, conducting one-on-interviews and surveying prospective customers. In a future entry, I'll mention another active approach with which executives seem to have the most familiarity, but which is usually the least informative.

Tuesday, August 09, 2005

Venture Capitalists as a Target Market

At many startup companies, the CEO consumes much of his time trying to secure funding from investors, often venture capitalists. The CEO is essentially trying to sell venture capitalists a share in the company. Therefore the product is the company, and the venture capitalist is the buyer.

Has any product manager researched this market? Conducted one-on-one interviews with prospective investors? Identified the top three problems that prospective investors face? Segmented and sized the market of venture capitalists?

Monday, August 08, 2005

360 Degree Audit: Framing the Questions

If you use a 360 degree audit to evaluate a product manager's performance, you survey the development, marcom, and sales teams to determine how effectively and convincingly the product manager has communicated an understanding of the market to them. What questions should you include in such a survey?

Whether you are a CEO, CMO, or VP of marketing conducting the evaluation, you should not ask the following question in a survey of these teams:
  • "How well do you think the product manager is doing her job?"
As we've noted in the context of conducting surveys of customers, the questions you want answered often aren't the questions you should include in a survey.

Here's a stab at some questions that might yield more reliable feedback. In parentheses after each question, I've specified for which department the question is appropriate.
  • "How well do you understand the problems that prospective customers of the product face?" (all departments)
  • "How well do you understand the different kinds of buyers of the product?" (sales, marcom)
  • "How well do you understand the product requirements, i.e. the criteria the product must satisfy to overcome the key problems the product is supposed to solve?" (development)
  • "How well do you understand the key themes and messages to use in PR and advertising for the product?" (marcom)

I'm sure you can improve the wording of these questions. I'm also sure that several more questions would yield informative results. The point is that these kinds of questions keep the "tactical expectations" problem from poisoning the performance evaluation.

Sunday, August 07, 2005

360 Degree Audit: Tactical Expectations

Commenting on my proposal for evaluating a product manager's performance, Steve Johnson points out that:

"A 360 degree audit is a good idea but don't forget that sales, marcom, and development are often expecting tactical product support rather than market information. I'm not sure I want them determining my income so subjectively. "

I like Steve's "360 degree audit" term to describe my proposal. The proposal is to evaluate a product manager's performance by surveying the development, marcom, and sales teams to determine how well he has imparted an understanding of the market to them.

Steve rightly points out that these teams often expect tactical help (e.g. a white paper on the product's benefits) from product managers more than market information (e.g. buyer profiles). Of course, many of us have Steve and Barbara to thank for educating the product management community about this tendency of companies to pressure product managers into a more tactical role.

As with all surveys, the key is to frame the questions so that you get useful information. In a future entry, I will discuss how you can structure the survey of these departments to avoid the "tactical expectations" problem.

Saturday, August 06, 2005

Thursday, August 04, 2005

When to Stop Asking, "Why?"

In my article, "How to Guarantee Product Failure", I mention that a common mistake in requirements gathering is to not ask, "Why?" Prospective and existing customers often make "feature requests" and suggestions about what your product should do. If you're an executive in the company, you might conclude that you should take their advice if enough of them clamor for the same feature.

A product manager's job is to probe further into the customers' underlying concerns. Features are not requirements; they are solutions. Whenever a customer requests a feature, ask which problem this feature would help them solve. After the customer tells you a problem, ask why it's a problem. Continue asking why until you fully understand the root problem and its implications.

But when do you stop asking, "Why?" How do you know when you've fully understood the root problem? One guideline is to stop when you've reached the customer's core needs (e.g. health, sex, safety, social acceptance). Your product may address one or more problems that block satisfaction of them, but it will never fully address the core need. You know you've probed deeply enough when you reach the core.

Wednesday, August 03, 2005

Framing Survey Questions

You're a CEO or VP of marketing wanting to research the market for your product. You know the questions you want answered. Why not whip up a quick survey using a free on-line tool such as SurveyMonkey.com?

The main problem with this approach is that the questions you want answered frequently aren't the questions you should include in a survey.

For example, what if you want to know how much prospective customers are willing to pay for your product? You could just ask them, "How much would you be willing to pay for a product that does blah blah," and provide them a blank to fill in. You will not get reliable results.

A skilled product manager would formulate the questions differently:

1. Ask negative pricing questions. How much does it cost for the prospective customer not to use your product?

2. Ask a conjoint analysis question. If a customer has to choose among several different pricing/feature packages, which one would he choose?

Pricing is one of many examples of questions you may want answered, but that you must formulate indirectly in a survey to get meaningful results.

Another important factor to consider when drafting a survey: you can typically draw the most important conclusions not from the direct responses to each question in the survey, but from uncovering correlations between the responses to different questions.

Tuesday, August 02, 2005

Ten Blogs

Here are ten blogs I read:

Pragmatic Marketing's product management weblog
Seth Godin's Blog
Decker Marketing
Creating Passionate Users
The Origin of Brands Blog
Managing Product Development

Random Blog
Drunk And Retired
Andrew Sullivan's Daily Dish
Talking Points Memo

To see how to add your list of blogs, visit the tag area at Technorati.

Product Management Deliverables

The reports that we put together at Cauvin, Inc. serve as an example of the deliverables a product manager produces. As I've mentioned in previous posts, we use an iterative approach to producing our documents. In fact, we begin delivering reports to clients the first week. The reports consist mostly of templates. Feedback the client gives us on these templates enables us to modify the documents to suit the client's needs. We incrementally flesh out these documents until the project ends.

Here is the set of documents we typically deliver to a client:

buyer profiles - profiles the different kinds of buyers in the market
market segments and sizing - divides the market into segments and estimates the size of each segment
market requirements - details the problems in the market and requirements the product must satisfy
positioning and messaging - messages and themes to use in advertising and PR
naming - what to name the product and/or company
pricing - how much to charge for the product
competitors - analysis of the product's competition
prospect interview notes - notes from one-on-one interviews with prospective customers of the product
survey report - results of survey(s) of prospective customers
key findings - significant observations and conclusions from market study (interviews and surveys)

Armed with this information, clients are able to plan and strategize their product development and marketing.

Monday, August 01, 2005

Use Case Granularity

Craig Larman weighs in on how granular use cases should be:

"A common error in identifying use cases is to represent individual steps, operations, or transactions as use cases. For example, in [a] point-of-sale terminal domain, one may (inappropriately) define a use case called 'Printing the Receipt' when in fact the printing operation is merely a step in the much larger use case process, 'Buy Items'.

A use case is a relatively large end-to-end process description that typically includes many steps or transactions; it is not normally an individual step or activity in a process.

It is possible to break down activities or portions of a use case into sub-use cases (called 'abstract use cases') - even down to individual steps - but this is not the norm . . . ."

- Craig Larman's Applying UML and Patterns, page 53