Wednesday, August 31, 2005
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
Monday, August 29, 2005
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
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
Friday, August 26, 2005
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.
Thursday, August 25, 2005
- 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.
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
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.
Tuesday, August 23, 2005
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
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
"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.
Saturday, August 20, 2005
Friday, August 19, 2005
- 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.
Thursday, August 18, 2005
Wednesday, August 17, 2005
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
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
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
Friday, August 12, 2005
MarketingProfs.com has a good article about how you should orient your corporate web site:
"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
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
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
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
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?"
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
"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
Friday, August 05, 2005
Thursday, August 04, 2005
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
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
Pragmatic Marketing's product management weblog
Seth Godin's Blog
Creating Passionate Users
The Origin of Brands Blog
Managing Product Development
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.
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
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