Cauvin

A friend of mine works for a successful B2B service company that dominates in the automobile market. Their technology and business model need not be specific to the automobile industry, so they are planning to extend into other vertical markets. I am worried they will encounter two major challenges: Dilution of their brand. Market understanding. As the company extends into new vertical markets, they should probably create a new brands for each vertical market. But I doubt they will. If they don't, they will dilute what is now a powerful brand in the automotive industry. While I don't doubt the company's technology and business model is relatively independent of their vertical market, a company that pays little attention to the special needs of a market will inevitably suffer. I hope the company will conduct some solid market research and be prepared to make changes and additions to their technology infrastructure to adjust to the research findings.

Free wi-fi network goes live in downtown Austin.

I've been debating colleagues recently about the difference between product requirements and product design. One of my favorite examples is whether having a user log into a software application is a requirement or design. I contend that, in most cases, it is design. The true requirement is a constraint on the likelihood that an unauthorized user will view sensitive information or damage something. When you capture the true requirement, you free designers to come up with an innovative or revolutionary way of satisfying it. Often, my colleagues will reply that, in the real world, log-in is an integral part of security, and that the possibility of other security solutions is some sort of theoretical pie-in-the-sky. So I was delighted to come across a recent wired.com story : "Researchers at Carleton University in Ottawa, Canada, are exploring the possibility of a biometric security device that will use a person's thoughts to authenticate her or his identity." They cal

You can apply marketing principles to selling your house. My parents are planning to sell their house soon. When I asked them about it, they pessimistically noted that the property is near a fairly busy road, so people inside the house can sometimes hear traffic noise. Remember one of the ways to position your product : find the strength within your biggest weakness. So I proceeded to point out to my parents that they have possible optimistic messages to highlight when they sell their house: Convenient access to the retail on the busy road. Being located within walking distance of an elementary school. How about the following elevator speech: "If you don't want to be close to Bee Caves Road, this isn't the house for you. But if you want your children to be able to walk one block to get to school, if you want quick access to the vast majority of shopping in the Westlake area, then you might qualify to live in our neighborhood." A perfect example of embracing your w

Good tips from Guy Kawasaki on writing executive summaries . One tidbit: "This means your executive summary should be about two pages, maybe three. Some people say it should be one page. They’re wrong. (The only reason investors ask for one page summaries is that they are usually so bad the investors just want the suffering to be over sooner.) Most investors find that there is not enough information in one page to understand and evaluate a company." He also describes exactly what should - and shouldn't - go in an executive summary.

Monsieur Godin writes in his inimitable way about focus and why so many companies resist it: "I asked, 'Are there any writers in your field who you hate because they get paid way too much compared to your perception of the effort they put in and the talent they have?' 'Sure,' he said, feeling a little sheepish about being annoyed by their success. 'And how do they get those gigs?'" Focus often means embracing hatred of your product . If you're not turning someone off with the way you positition your product, you're probably not focusing sufficiently.

Karl Wiegers, author of several books on product requirements, says his favorite definition of requirement is: "Requirements are…a specification of what should be implemented. They are descriptions of how the system should behave, or of a system property or attribute. They may be a constraint on the development process of the system." This unfortunate definition comes from Ian Sommerville and Pete Sawyer. Frequent readers of this blog know that I find this definition to be overly broad. After all "a specification of what should be implemented" could include a detailed design specification with UML class and collaboration diagrams. Wieger's favorite definition thus fails to provide any meaningful distinction between requirements and design. A proper definition of requirement must clearly distinguish between requirements and design.

In his "Understanding Market Psychology and the Halo Effect" article in Advertising Age, Al Ries discusses how you can market your products by focusing on one particular thing and leveraging the "halo effect". The halo effect can manifest itself in at least two ways: Customer perceptions of a single product influence their perceptions of your company or all of its products. Customer perceptions of a single product benefit influence their perceptions of other benefits of the same product. Ries cites the Apple iPod and Motorola Razr as examples.

Today I played in a kickball tournament. Inspired by the movie "Dodgeball", we invented an organization called the American Kickball Association of America (AKAA) and named our team "Old School". Unfortunately, we lost in the first round, so we don't get to advance to the Las Vegas finals that ESPN 8 ("The Ocho") is televising.

In a recent MarketingProfs article , Dan Herman argues that you should not position or differentiate your product based on its core benefits. His reasoning is that the competition - almost by definition - shares or can imitate the same core benefits.

Some companies form customer advisory boards (CABs). Prospective and existing customers comprise these boards and provide input and feedback on one or more products the company is developing or offering. Surely it's good to communicate with customers to understand their situations, problems, and suggestions. But is a CAB a good way to do so? Yes, but not for the reason you might think. In general, you're much better off conducting one-on-one interviews with prospective and existing customers than convening meetings of a CAB. The group setting of a customer advisory board has many of the same drawbacks as focus groups . Above all, CABs are almost certainly not qualified to make decisions on which features to include or how to market your product. Board members are customers, not requirements analysts, design experts, or market strategists. CABs are more useful for outbound marketing purposes . Forming a CAB is a great way of generating some word of mouth and PR for your produ

Over on Tyner Blain , Scott states : "There is nothing that prevents a waterfall project from reviewing estimates throughout the course of the project." Recall that agile processes use iteration and frequent releases to adjust to changing requirements and other discoveries during product development. Waterfall processes, on the other hand, schedule along a critical path that culminates in a single release. While Scott endorses agile practices, he does not believe they lead to improved estimation. I don't agree with Scott on this last point. Here's why. Reliable estimates hinge upon a holistic understanding of requirements, design, implementation, and testing. With waterfall, you certainly can review and adjust estimates halfway through the process, but you will not be able to incorporate the full feedback effects. For example, you could be halfway through requirements and design and re-estimate the project, but you wouldn't have the benefit of the discoveries

Tim Harford has an article in Slate about "Confusion Pricing". Cell phone and other companies offer pricing plans that are so complicated it's difficult to tell what is or isn't a good deal. Two key points from the article: "They are good at judging which calling plan will cost least, and good at switching if their initial guess is wrong." "The whole experience suggests that confusion pricing is not really about trying to entangle every customer in an impenetrable web of complex offers. Instead, it's a very simple screening device to spot customers with money to burn. If you don't care enough about your phone bill to ask Katie for a spot of advice, then you can obviously afford to pay a little more." In other words, insofar as "confusion pricing" has any merit, it's that it segments the market into two different types of customers: price-sensitive customers versus those willing to pay more more money. However, it's po

Just an idea: to understand the perceptions of adults, interview their children. Children tend to parrot their parents' views in a simple and concise manner. Listening to children talk about politics gave me this idea, but perhaps it applies equally to product marketing.

Amid the rush to match competitor features one for one, keep in mind the following passage from Gause and Weinberg's Exploring Requirements : For instance, suppose you are building a new car, and the competitive analysis says that the other cars in this class all have gold monograms on the steering wheel. When the marketing people try to make "gold monogram on steering wheel" into a requirement, ask, "What function does it serve?" Most commonly, you'll get the reply, "It doesn't serve any functions. It's just there to match the competitors." "In that case," you say, "the function is 'match the competitor's.' And just what is it about the competitor's we're trying to match?" "Their pizzazz! Their sales appeal!" "Great. So we can say that the function we want is 'match the competitor's sales appeal.'" "Sure, but how are we going to do that?" "Possi

The Waiter Rule: "A person who is nice to you but rude to the waiter, or to others, is not a nice person." More here .

Steve Johnson touches on using an ethnographic approach to assessing usability: "Watch what they do, not what they say they do! They repeatedly solve their problems in a roundabout way instead of the direct way—because the direct way requires a deeper understanding of how the product works or how the data is stored."

I've mentioned before that your web site should have a call to action . I also gave some simple examples of actions. Today, while running around Town Lake here in downtown Austin, I brainstormed some new possibilities: Quiz . Quiz your visitors about the product or service you provide and grade them on their performance. For example, if you sell a service, grade your visitors on how well they could perform the service themselves (without your help). Audit . Assess your visitors' situations based on a short form they fill out. Give them a free assessment that shows how much they need your product or service to improve their situation. ROI calculator . Based on a form they fill out, show your visitors the probable impact of your product or service on their ROI. Derivative product . Let your visitors use a product developed using the product or service that you offer. Some attributes to consider when deciding on a call to action for your web site: Modest commitment . The action

Yesterday , I described what business processes and rules are. If your company sells its products to other businesses, it is generally important to understand the processes and rules of these business customers. Such an understanding enables you to make your marketing messages and sales processes relevant to your target market. It also enables you to understand the requirements your product must satisfy to be valuable to your customers. But what is the relationship between business rules and requirements? Recently, Joy Beatty raised this question on Seilevel's Software Requirements Message Board. Below is a transcription of my reply. It seems that business rules and requirements have at least two relationships. The business rules sometimes represent the context in which we specify the requirements. I.e., the existing rules of a customer organization influence or drive the requirements. In other cases, the requirements drive business rule design. I.e., designers specify

Sometimes we sell a product to businesses that improves their efficiency. Improved efficiency can help the business achieve: Increased production or sales volume. Lower production and operational costs. There is a discipline called "business process improvement" (BPI) dedicated to the subject of improving operational efficiency. Companies like Dell spend a great deal of time on BPI projects to determine how they can make different aspects of their business more efficient. Key concepts in BPI include business processes and business rules . Business processes are the steps a business executes to achieve their objectives. Accepting and processing orders, doing payroll, and hiring and firing employees are all examples of business processes. Business rules are rules the company follows as it executes its business processes. An example is a pricing rule that states the minimum price or margin a sales person is allowed to negotiate with a customer. You can also view the steps wi

Seth Godin writes about the value of your organization learning through trial and error: "People mistakenly believe that one way to successfully avoid error is to avoid trial." Your organization will make mistakes not just in developing a product, but in defining its requirements and in marketing it. Product management and development should use agile methods that build the notion of trial and error right into the process.

Dennis Forbes posted a lot of interesting data on domain names. He followed up with some more shortly thereafter. Via Seth Godin.

This Maureen Dowd article appeared in the New York Times in late 2005. In it, Dowd gave her account of what "modern girls" do in dating. I found the following passage to be quite disturbing: "After Googling and Bikramming to get ready for a first dinner date, a modern girl will end the evening with the Offering, an insincere bid to help pay the check. 'They make like they are heading into their bag after a meal, but it is a dodge,' Marc Santora, a 30-year-old Metro reporter for The Times, says. 'They know you will stop them before a credit card can be drawn. If you don't, they hold it against you.' One of my girlfriends, a TV producer in New York, told me much the same thing: 'If you offer, and they accept, then it's over.'" This state of affairs seems to be the worst of both worlds. Not only is does it revert to a prefeminist notion of gender roles, it smacks of dishonesty to me.

As a followup to yesterday's entry about the word-of-mouth (WOM) roundtable, I thought I'd highlight an interesting tidbit in the discussion. Steve Rubel (I think) outlines a four-step process for developing a WOM marketing program: Find an existing community of users of your product. That community may exist on the Internet (as a group on Myspace or as a newsgroup) or may be a club. Determine what are they saying about your product. What's the "vibe"? Engage them in dialog. Enable them to shape or "co-create" the product and its marketing. Empower them to do things they might not be able to do on their own. As with all marketing programs, it's important to research the market and have your key messages and strategies in place.

Remember how Jack Trout tried to poke a hole in all of the hype surrounding the use of word-of-mouth (WOM) in marketing? He talks with three WOM advocates in this roundtable discussion . The advocates effectively make their case, but I still consider valid Trout's underlying point about WOM being just another tool in the marketing toolbox.

As mentioned in yesterday's entry , the duration it takes for a user to complete a functional task is an important metric in usability requirements. However, there are really two types of duration: Engagement duration - the amount of time the user is actively attending to the task. Total duration - the total amount of time it takes for the task to complete. Consider, for example, disk defragmenting software. A user performs miminal configuration and initiates the defragmenting process. The amount of time the user is engaged in these activities might just be a few seconds. But the total amount of time it takes to achieve the user's goal - defragmenting the disk - could take hours. You might argue that the total duration doesn't so much measure ease of use as it does performance or productivity. Either way, it is a separate concept from engagement duration.

Usability requirements are the metrics by which we judge that a product is easy enough to use. As I mentioned before ( here and here ), an ease of use requirement might specify: Profile . A typical user’s prerequisite skills and experience. Effort . A limit on the number of user gestures (keystrokes, mouse clicks, etc.) it should take to accomplish a functional task. Duration . A limit on the amount of time that it will take a typical user to perform the functional task. Reading this post on the different skill levels of users, I realized I hadn't specified that product managers should generally apply this pattern to a range of users. User skill levels range on a continuum from novice to expert, and experience levels range from beginner to seasoned. Ideally, the product manager addresses ease of use for the full continuum of skill and experience levels, but such metrics may not be realistic to formulate. It may suffice to specify metrics for a finite set of user levels, e

"America Online" no longer exists. The company has officially changed its name to "AOL", which is what everyone called it anyway. "America Online" was a poor choice of a brand name for several reasons, including: It's too long. It's too generic . Abbreviations aren't the best brand names, either, but at least they tend to be short and less descriptive of the product or company. AOL follows a long line of companies with long, generic names that never "took" in the marketplace: IBM - International Business Machines FedEx - Federal Express AMD - Advanced Micro Devices GM - General Motors I'm not sure which of these companies have officially ditched their original, long names, but most people refer to them by their abbreviated names. All of these companies have at one time experienced great success. But this success came in spite of, not because of, their long, generic brand names.

"SME" is short for "subject matter expert". Requirements analysts and product managers often speak of interviewing SMEs. Should product managers interview SMEs? Probably. It depends on the "subject matter". Is the subject matter the situation and problems that prospective customers face? To document the requirements for a product, product managers need to understand this subject matter. Prospective customers are experts on their situations and problems. They may also be experts in the domain in which they work. It is essential that product managers interview them. However, prospective customers are not necessarily experts in the technologies that are part of solving those problems. Unless your product manager delves into product design (as opposed to pure requirements), such expertise is helpful to a product manager but not essential.

Tonight I went to the "soft opening" of Ruggles in Austin. (Actually, the restaurant is located in West Lake Hills.) I met one of the owners last night, and he invited me to the opening. A "soft opening" precedes the public opening and is by invitation only. Ruggles has three locations in Houston. I went to the first location about fifteen years ago and thought the food and atmosphere were great. Tonight's experience was about the same. The food and service were great. I just wish the restaurant were located downtown. The public opening of Ruggles is taking place Monday.