Cauvin

Here is an apocryphal story that seems to be making the rounds in e-mail: "Some guy bought a new fridge for his house. To get rid of his old fridge, he put it in his front yard and hung a sign on it saying: 'Free to good home. You want it, you take it'. For three days the fridge sat there without even one person looking twice at it. He eventually decided that people were too untrusting of this deal. It looked to good to be true, so he changed the sign to read: 'Fridge for sale $50'. The next day someone stole it." While the story may not actually be true, you can easily imagine it to be true. Price discounts communicate to your buyers that your product isn't worth buying at the regular price.

When your product manager is researching the market, she has a choice between using hypotheticals and actuals . When interviewing a prospective customer, a product manager who uses hypotheticals asks such questions as: Would you be willing to buy a product that does x, y, and z? If I were to offer you a product that does x, y, and z, how much would you be willing to pay for it? How often would you use a product that does x, y, and z? In contrast, a product manager who uses actuals: Asks what the prospective customer does currently instead of using the product. Determines how much the prospective customer spends to accomplish her goals without using the product. Puts actual product or demos into the prospective customer's hands and determines whether she uses it. Both hypotheticals and actuals are helpful. Hypotheticals are notoriously unreliable , however. To the extent possible, a product manager should favor actuals when researching the market.

The example below is for people with an analytical bent who are interested in understanding my definition of "requirement" : "A requirement states the least stringent condition that must hold to solve or avoid a problem that a prospective customer faces." Assume we are developing a temperature control system, and the problems that prospective customers face include: Prospective customers feel too cold or too hot in their homes. Prospective customers will feel frustrated if it takes more than one minute of their time per day to maintain a comfortable temperature. We would likely include in our requirements a Maintain Comfortable Temperature use case and attach an ease of use constraint to it. Here are two possible ease of use constraints: a. The system will be a thermostat with a dial to set the desired temperature, a switch that determines cooling or heating mode, and an on/off switch. b. For a user that fits profile 'x', it should take no longer one minut...

In his "how to save the world" blog, Dave Pollard wrote recently about innovation and the role of market research. Here are some interesting excerpts: "There are two opposing views on the role of the customer in innovation. One school holds that all innovations start with conversation, observation, and understanding of the customer (current or potential) with the goal of surfacing and then filling an unmet need. The other school says that customers don't know what they need, at least until they see it, and sometimes a need doesn't even exist until a solution is available to fill it." Note the reference to dormant problems in the last sentence. The truth is that most innovations are evolutionary, rather than revolutionary. That doesn't mean they are incremental -- they are discontinuous, making leaps in design, technology application and functionality, but do so in response to evolving customer needs. Read the whole piece; it's well worth it. Via S...

Recall that dormant problems are those 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. There is a flip-side to dormant problems. Sometimes your product introduces a new way of doing things to a customer, a way that transforms their experience by solving a dormant problem. A real estate agent might be accustomed to a certain way accessing information regarding home listings and bringing notes with her as she shows the homes to prospective buyers. Your product might enable her to access the information instantaneously from her cell phone or PDA. She may even be thrilled by the convenience. Once she's over the honeymoon period, she begins to notice all of the incremental improvements to the product that are possible. There may be some quirk in the user interfaces that annoys her. By opening her eyes to a new way of doing things, you've also opened her eyes to all sorts of ways things could be even b...

In his article , "Push-Me-Pull-You: Reconciling Maintenance And New Releases", Jacques Murphy gives us guidance on when to emphasize maintenance of existing functionality (e.g. bug fixes) versus new product features. I think his treatment of the issue misses the point. Many companies face this issue. Just about every product has bugs and seemingly marginal usability problems. Yet it can consume a lot of development resources to fix them. Meanwhile, the typical product also is in a marketplace which requires new functionality to compete effectively. If you are an executive at a company facing this issue, make sure you have a product manager who simply sidesteps it. The important issue for a product manager is not maintenance versus features, it's what the product enables the customer to do. Bugs prevent a product from meeting its requirements. Missing features prevent a product from satisfying its requirements. Focus on the requirements; ensure that product designe...

All this week I will be conducting some important ethnographic research into snowboarding. By experiencing it for myself, I hope to get insights into the problems and emotions that a "real" snowboarder faces. I arrived in Salt Lake City, Utah yesterday and am about to leave for the slopes and take my first round of lessons. Not having snowboarded before, I expect to spend a lot of time on my rear end and knees. But I will be wearing plenty of protective gear: wrist guards, knee and elbow pads, and a helmet.

I've mentioned in the past that it's foolish to test-market a product name by simply asking people whether they like it or think it's "good". The main reason is that most people are experts in whether a name - for them - is easy to spell, easy to pronounce, or has meaning for them. But they are not experts on the principles of naming and branding. One manifestation of this issue is the tendency of people to love successful brand names that they wouldn't have liked before they became household names. If you had asked someone whether the ideal name for a search engine would be "Google", he probably would have replied, "That's silly. How about Search.com instead?" If you had asked someone whether the ideal name for a discount shopping chain would be "Target", she probably would have replied, "That's boring. How about Shopper's Paradise?" With naming products and companies, hindsight is 20/20.

Steve Johnson writes : "Marketing should strategically define the key steps of the sales cycle, and the tools that support each step, giving sales people a roadmap to move clients from leads to close and beyond. Working closely with sales management, we can identify the necessary tools and techniques. Then sales people and their sales engineers can customize these materials for each deal, if it's even necessary; marketing should never create one-time use materials for a single client." If you are a CEO or other executive and aren't sure about the line between sales and marketing, keep Steve's observation in mind. Marketing has more of a strategic role in the sales process; sales people make individual sales. That said, it may be worthwhile for your product manager to "test", by going on one or two sales calls, the sales process he prescribes.

According to this article in eWeek, Brandchannel.com's most influential brands of 2005 were: Apple Google Starbucks Target Lance Armstrong Note that all five brands have names that are not descriptive of the product .

Want to laugh? Watch this video .

Some of my readers may recall a point I made a few weeks ago: "You may also be intrigued if the product is somewhat 'unavailable' to you, wondering if it must be so good that the company doesn't even need to make it readily available." In an article this week on MarketingProfs.com, "Marketing Challenge: Let's Give 'Em Something to Talk About", Meryl K. Evans and Hank Stroll wrote: "An excellent example of limiting the product is when Google got many people craving a Gmail account. When the company launched Gmail beta, it limited accounts to invitation only. Soon, people auctioned off the accounts." Interestingly, I used the same example: Gmail. You're more likely to generate powerful word of mouth by creating the perception that your customers are an exclusive club instead of begging everyone to use your product.

I have four comments on Seilevel's presentation I attended last night: First, Jerry Aubin effectively argued that requirements management is vital to the success of a software project. Clearly, one of the main problems with product development is a failure to understand what to build. Second, Jerry implied that good requirements management requires a great deal of formality. He seemed to contrast formality with agile methods. I don't entirely agree that agile methods are informal. While it's true that proponents of agile methods point out disadvantages of formality, they also tout a structured, test-driven, disciplined, and iterative approach to product development. The bottom line is that agile methods can be every bit as formal as other methods, but just in a different way. Third, Joe Shideler insightfully pointed out that using "models" to elicit and document requirements helps to ensure completeness and accuracy. When you impose structure on specifications, y...

This evening I attended a presentation, "Beyond the System Shall - A Journey from Good to Great Requirements", by Jerry Aubin and Joe Shideler from Seilevel . I had a chance to meet some of the folks I've been debating on various requirements issues. Tomorrow I will offer my comments on their presentation.

Laura Ries just blogged about focus at Starbucks: "Starbucks is a powerful brand. But Starbucks is going to annoy people by cluttering the store with stuff. They need to focus on the coffee, the essence of the brand. Otherwise they will end up like McDonald’s. McDonald’s used to be a hamburger joint. But after years of expanding the menu and junking up the place, the food quality and restaurant quality has suffered enormously. When you take your eye off the ball of what your brand stands for things can deteriorate." Happy Valentine's Day, Laura! :-)

I've mentioned the importance of maintaining focus in your product and marketing efforts. But what if you have a great idea for a new product? Should you dispense with it just because it might cause you to lose focus? For example, what if you own a successful high-end Italian restaurant called "Filomarino". You recognize a market for a fast-food Italian restaurant. You might be tempted to extend the brand and create a new restaurant called "Filomarino Express". That name might give the fast-food restaurant an immediate boost, but it will also cause the Filomarino brand to lose its focus. Diners who associated the Filomarino name with sophistication or quality will be forced to re-evaluate what "Filomarino" means to them. The high-end restaurant will likely suffer as a result. Fortunately, you can create a new brand for the fast-food restaurant, even if it is has the same owner and executive chef. You will have to start the branding effort from scratc...

Here are the IEEE definitions of "requirement": 1. a condition or capability needed by a user to solve a problem or achieve an objective 2. a condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard,specification, or other formally imposed document 3. a documented representation of a condition or capability as in (1) or (2) Contrast them with my definition . Interestingly, IEEE's first definition is nearly identical to mine, except that mine states the condition must be the least stringent one needed to solve a problem. It seems you could categorize all sorts of design and implementation details as requirements without this qualification. Meanwhile, the discussion about requirements semantics continues and has spread to the Tyner Blain blog.

A couple of years ago, I came across on article about the scientific basis behind emotions and feelings. I read the article with interest but didn't really know what to make of it. Here was the sentence that stuck in my mind: "In other words, feelings do not cause bodily symptoms but are caused by them: we do not tremble because we feel afraid; we feel afraid because we tremble." Things clicked when I went for a ten mile run one day. I had awaken feeling as stressed as I've ever felt in my life, but after running ten miles, I no longer felt any stress whatsoever. I felt relaxed and content. I recalled the sentence from the article, and it suddenly made sense. All of the underlying causes of my stress were still there, but the physical sensations of stress were gone, and thus the stress itself was gone. Of course, the stress came back a few hours later, but only after I had learned from the experience.

What does "Amazon.com" mean to you? Does it mean " Internet book store"? Or does it mean "online shopping"? Amazon.com started as a book store and built a very successful brand name. If you wanted to buy books online, chances are you went straight to Amazon. But then they decided to expand their business to include all kinds of merchandise. What did branding gurus Al Ries and Laura Ries predict? "Amazon.com means Internet bookstore. Not auctions, gifts, home-improvement products, toys, video games, electronics, software, DVDs, or videotapes . . . . Line extension is very popular in corporate America, almost as popular as stock options and corporate jets. Both feed the corporate ego. What is terribly confusing is the fact that line extension can work . . . in the short term. But almost never in the long term." Judging by a five year chart of Amazon's stock price, they haven't done too badly: But I still associate Amazon with books, and I...

Ironically, I've started a discussion on Seilevel's Requirements Defined message board about the definition of "requirement" . In that and other forums, semantic differences and confusions have arisen, and I thought it would be worthwhile to get on some common ground regarding just what a requirement is. You can participate in the discussion here (but you'll have to register): http://requirements.seilevel.com/messageboard/showthread.php?t=149 Hope you can contribute! UPDATE: You can find a comprehensive model of requirements concepts here .

Laura Ries gives the rundown on the advertising losers and champs on the Super Bowl.

I'm fortunate enough to have not only a friend who writes business plans, but another friend who was a commercial lender. Thus I have friends on both the author and audience side of business plans. I myself am no expert on business plans, but these friends have given me valuable insights into what they must include to be effective. My retired commercial lending friend recently suggested that one approach towards pitching a product to investors is to put together a simple, straw man business plan before spending too much time and effort fleshing it out. The idea is to put forth the basic value proposition and projections and use it to get feedback on how to refine it. Of course, you will need to do some market research to end up with a compelling and credible plan . To some extent, the nature of this market research may depend on feedback you get from presenting your straw man business plan, however. So how do the business plan and the market research fit in with each other, gi...

This quote from Henry Ford is famous, but I think it's worth elaborating on it: "If I'd asked my customers what they wanted, they'd have said a faster horse." The quote succinctly and powerfully makes the point that customer-centricity is not just about blindly delivering what customers say they want . In the end, regardless of what customers may ask you to do, they want you to solve their problems. A skilled product manager will help you get beyond customer requests, understand the core problems they face, and define what it means to solve them. Enthiosys 's Luke Hohmann makes a similar point.

The Running on Root blog touches on problems with overemphasis on features : "The temptation seems to be to get into a feature war with everyone else. Once you’ve exhausted all of the useful features you start to include numerous niche features and one-off customer requests. Dump these onto a product sheet in no particular order and you look just as good, if not better than all of your competitors. A lot of these features aren’t likely to matter very much to the people that use the software, so you need to get some marketing materials, product advocates, consultants, etc to push your product to the people that make the decisions (and don’t actually use the product). " Features are important, because they typically are easy to communicate. But don't lose sight of usability and the goals that users are trying to achieve with your product.

An interesting entry in Wikipedia about prescription and description, a topic I've covered in the past.

In eWeek, Andreas Pfeiffer writes about the problem of overemphasis on features rather than usability. Key grafs: "More features isn't better, it's worse. Feature overload is becoming a real issue." "Forget about the killer feature. Welcome to the age of the killer user experience. When technology achieves something desirable without being in your face, when it knows how to integrate itself into your wishes and desires without distracting from them, that's when technology lives up to its potential." Via Steve Johnson.

A few days ago, Random linked to a product roadmap for Firefox, a web browser. A product roadmap shows the expected changes to a product over time. Product roadmaps can have different audiences, and I believe the format of the roadmap should depend on the audience a product manager is trying to target. One common format for a roadmap shows features that the company plans to add to the product. Users and analysts are accustomed to thinking about products in terms of features, so to some extent this format is helpful and natural. However, particularly if the audience for the product roadmap is internal, it might be worthwhile to orient it around use cases rather than features. The high-level use cases for a product typically don't change much during its lifetime. Yet the constraints around these use cases do change; even if the use cases stay the same, you make the product easier to use, more secure, or more reliable. One way to format your product roadmap, therefore, is in terms o...

If you're a CEO courting investors, you probably find yourself presenting the business plan for your company or product frequently. Incorporating solid market research in the plan gives it credibility . However, the credibility of the written business plan sometimes has less impact than your credibility, and the credibility of other leaders in the company. So you might think that market research helps only marginally in closing the deal with investors. Perhaps you should instead just try to pad your Board of Directors and leadership positions with some industry experts. Think again. The most impressive presentation you can give to investors is one in which you demonstrate not only that you have a solid plan, but that you know how to address business realities. Rather than rely on industry experts - who can be helpful but can also be a crutch - how about becoming an expert yourself? If you just happen to have market research and strategy skills, you can use them to become an exper...