Cauvin

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

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.

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

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.

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.

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: The team understands the requirements. The requirements are testable (subject to the certain practical limitations ). 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.

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

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

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

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

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

Kathy Sierra sure is defensive about being an "iPod sheep".

Here are some guidelines for designing and choosing a logo: The logo should be abstract (a " blank slate ") and bear little or no resemblance to the product or product name. The attributes (e.g. colors) of the logo should be consistent with the rest of your branding effort. The logo should be such that it is possible to size it to fit on your marketing material, company documents, and product. The logo should be unique and identifiable to someone who has seen it multiple times. 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.

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.

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.

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

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.

Grant McCracken blogged in late July about an amusing, and definitely not passive , means of going to the market to understand it. Read his anecodote .

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

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

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

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.

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?

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

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

As I've mentioned before , I live in downtown Austin . I own a loft on the tenth floor of the Plaza Lofts . Here is the view from my balcony at sunset.

Offering price discounts on your product? You need to visit the Brand Autopsy Discount Detox Center .

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

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

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 10blogs tag area at Technorati.

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

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