Cauvin

Your marketing team can use Google to identify the best ways to reach the target market for you product. The users and buyers of your product have certain characteristics in common that place them in the target market. By searching for the right combinations of keywords in Google, a marketer can turn up discussion forums, blogs, Wikipedia entries, on-line periodicals, and other resources that might be useful in spreading the word about the product. If the target market for your product is college students from wealthy backgrounds who use lots of text messaging, how about searching Google for college student "text message" If that query returns too many irrelevant results, how about searching for fraternity student dodgeball ( Dodgeball is a text-messaging service. Students who use Dodgeball are likely to be heavy users of text messaging in general.) You get the idea. The right combination of keywords will return sites and forums that prospective customers of your product are

Requirements documents have several audiences, including: Users Buyers Product designers Product developers Product testers Product marketers Sales people Typically, users and buyers know little about the technologies that designers and developers will use to build the product. Designers and developers typically are not in the same industry as users and buyers and do not share the same profile. Users and buyers should be able to read a requirements document and validate that it captures the problems they are trying to solve. Designers and developers should be able to read the same document and grasp the market problems with which they likely have no first-hand familiarity. At the same time, the requirements should be specific and measurable enough to design and develop the product. In documenting and communicating the requirements for the product, your product manager thus has the challenging task of making the requirements understandable yet precise to very different audiences.

When I tell people about Guy Kawasaki's 10-20-30 Rule of PowerPoint , the reaction is often shock and disbelief. How can anyone possibly adhere to those guidelines, they ask? Effective marketing communication requires discipline. The temptation is always there to Describe features instead of benefits. Tout too many benefits. Put more on the brochure rather than less. Use different messages and themes in different communications. Appeal to everyone (i.e. no one) instead of a targeted market segment. The 10-20-30 Rule of PowerPoint is an example of a set of disciplinary guidelines . It counters the temptations of creators of presentations to create too many slides, make presentations too long, and put too much on each slide. Your product manager can play a constructive role in maintaining discipline in marketing communications. She can provide input to, and provide feedback on, the collateral prepared by marcom folks. She can also suggest disciplinary guidelines to counter the tempta

If you haven't already read Guy Kawasaki's advice about PowerPoint presentations, check it out . Kawasaki advises: [A] PowerPoint presentation should have ten slides, last no more than twenty minutes, and contain no font smaller than thirty points. Oratory - rather than wording on slides - dominates the most effective presentations. Kawasaki explains: The reason people use a small font is twofold: first, that they don’t know their material well enough; second, they think that more text is more convincing. Total bozosity. Force yourself to use no font smaller than thirty points. I guarantee it will make your presentations better because it requires you to find the most salient points and to know how to explain them well. If you find your product manager's presentations dry or unfocused, make her aware of the 10/20/30 Rule of PowerPoint. UPDATE: Seth Godin reminds us of his advice about PowerPoint presentations , which meshes well with Kawasaki's advice.

On his How to Be a Good Product Manager blog (which, I might add, is a great read and off to a roaring start), Jeff Lash advises against reliance on focus groups : While they have their place, focus groups are too often overused and misused. Executives are often enamored with focus groups . In most cases, however, your product manager should avoid them and employ other market research methods.

Seth Godin wrote : The danger is when you keep score of the wrong thing because it's easy or precise. The requirements for our products should be testable and measurable. When a prospective customer tells us the competitor's product is not secure enough and needs registration and log-in functionality, part of understanding what the prospective customer means is to determine how to measure security. Your product manager may opt for specifications that are less challenging to measure. Rather than specify security metrics, for example, she may instead punt and simply specify the product will include registration and log-in functionality as the prospective customer requested. But doing so doesn't capture the problem the prospective customer is really trying to solve. What does it mean for the product to be secure? What information is problematic for an unauthorized user to access? What functionality is dangerous for an unauthorized user to employ? What are the characteristics o

The folks at the Product Management View have posted the Flash video and audio of my recent webinar, "Understanding Requirements Concepts". In the presentation , I Walk through the requirements conceptual model I posted in November. Draw the line between requirements and design. Illuminate what a nonfunctional requirement is. Your comments are welcome.

At the height of all the iPhone hooplah, I decided to short Apple stock. Shorting a stock means selling it without owning it, and then buying it later to close out the position. The effect is that you make money as the stock goes down (instead of the usual way of making money as the stock goes up). I sold Apple stock short January 10th. I then placed a limit order to close out the position (i.e. buy the stock to "cover" the short) at 10% below the price at which I sold it. This morning, I received notification from TD Ameritrade that the limit order had gone through, so I made a quick 10% on my money. Apple is a great company with great products (though I am skeptical about how some of the iPhone marketing will play out ). Their success speaks for itself. However, smart investing (and trading) is not always a reflection on the company. No matter how valuable a company is, it is always possible for the stock market valuation to be higher than the fundamentals dictate. When hy

One way to market your product on the cheap is to include references to your product in Wikipedia articles. Anyone can edit Wikipedia articles. You simply visit the article you want to edit, click the 'Edit' button in the appropriate section of the article, and make your changes to the article. This tactic has the following benefits: Wikipedia, though anyone can edit its articles and provide false or insignificant information, is generally considered a credible source of information. Google usually ranks Wikipedia entries high in its search results. You get to choose articles that are relevant to your product. When you employ this tactic, you should strive to genuinely improve the article. If you don't, someone will probably remove your changes.

Looks like Scott Sehlhorst tagged me to list five things you might not know about me: In the year 2004, I watched more hours of 7th Heaven reruns than any other TV show. My favorite social drink is an Irish car bomb . I majored in philosophy in college and was a software engineer for eleven years before becoming a product manager. I use my car an average of about once per week, preferring to walk or ride the bus whenever practical. I am known as the "King of Evites " for the number of social invitations I receive and pass on to my friends. I now tag: Barbara Nelson Steve Johnson Laura Ries Paige Davis Stewart Rogers Now I should go back to sleep. I got up way too early.

In a recent debate over requirements terminology, one of the participants proposed that the line between the requirements and design of a product is the same as the distinction between the external and internal aspects of the product. I.e., the requirements specify the external behavior and attributes of the product, and designs specify internal details of the product. The idea is that, as long as you're treating the product as a "black blox" (not peeking inside to see how it works internally), you're in the realm of requirements and not design. This distinction has a great deal of initial intuitive appeal but leads to absurd conclusions with contradictions in terms. For example: P1. User interface designers produce specifications that describe only external aspects of the product. P2. If a specification describes only the external aspects of the product, it does not contain design. C. Therefore, the specifications that user interface designers produce do not contain

The user-friendliness of your marketing communications sometimes reflects the user-friendliness of your products. Engadget had an amusing but significant (in my opinion) piece about complexity of the keynote speeches that Steve Jobs, Michael Dell, and Bill Gates gave at recent conferences. Here are the results: It would appear Dell and Gates are the nerds of the bunch, using 6.4% and 5.11% "hard words," respectively -- compared to Jobs' 2.9% -- and stringing together fancy sentences 16.5 words and 21.6 words long, while Jobs did it up children's book style at 10.5 words per sentence. Jobs also kept his lexical density (ratio of content to words) low, at 16.5% compared to 21.0% for Gates and 26.3% for Dell. Finally, the Gunning Fog Index (don't give us that look, we warned you going into this) which measures the average years of education needed to understand a text, rated Jobs' transcript at 5.5, Dell at 9.1 and Gates at a whoppin' 10.7. If you don't

Wow. Naseem Javed seems quite passionate about his aversion to the iPhone brand name.

I will be presenting a webinar on requirements concepts Wednesday, January 17th at 11 am CST. With the help of my requirements conceptual model , I will attempt to break through much of the confusion that plagues requirements terminology. You can register to receive an e-mail reminder of the webinar here .

In case you want to include the Dadnab demo in your blog, MySpace profile, or other web site, here is the code for the Dadnab widget : <center> <form action="http://demo.dadnab.com/enclosure.do" method="POST" target="_blank">   <select style="background-color: lightgoldenrodyellow" id="region" name="region" size="1">     <option selected value="Austin, TX: (512) 981-6221</option>     <option value="bay">San Francisco Bay Area: (415) 335-6221</option>     <option value="boston">Boston, MA: (857) 244-1622</option>     <option value="chicago">Chicago, IL: (312) 772-3622</option>     <option value="dallas">Dallas, TX: (469) 844-3622</option>     <option value="houston">Houston, TX: (832) 303-3622</option>     <option value="portland">Portland, OR: (503) 406-8622<

I have been working on my own venture for about year. In the middle of 2006, I began recruiting beta testers for the new service. The service is now out of beta. Dadnab enables riders of mass transit (bus, rail, etc.) to plan their trips using text messaging from their mobile phones. A rider sends a text message with her origin and destination, and Dadnab replies to the message with an itinerary telling which buses or trains to take, at which stops, and at what times. The service is currently available in Austin, Boston, Dallas, and Houston, with many more cities in the works. Below is a demo, in the form of a web widget , of the +Dadnab  service: Austin, TX: (512) 981-6221 San Francisco Bay Area: (415) 335-6221 Boston, MA: (857) 244-1622 Chicago, IL: (312) 772-3622 Dallas, TX: (469) 844-3622 Houston, TX: (832) 303-3622 Portland, OR: (503) 406-8622 Seattle, WA: (206) 659-6225 Southern California: (323) 863-6221 Tri-State NY/NJ/CT Area: (347) 497-3622 5th & lavaca to ba

As much of a fan of Apple's emphasis on design and the apparent merits of the iPhone as he is, Steve Johnson doesn't like the name "iPhone". I think it's too generic. Generic brand names are poor for reasons I've mentioned before. I'm not sure why Johnson doesn't like the name.

The introduction of Apple's iPhone brings up a number of marketing issues. Focus . Apple is marketing the iPhone by stating that it "combines three products". Is it a phone? Is it a digital media player? Or is it a device for accessing the Internet? A lack of focus often leads to product failure. Naming . Cisco is suing Apple over the name "iPhone". More importantly, the name is generic. Generic names usually make the worst brand names. Differentiation . Apple tried to "think different" in designing the phone. Did they succeed? The phone includes a "visual voice mail" feature in which you can view a list of your pending voice mails and select which one to hear. I don't know of any other phone with this feature. Most of the other hyped features (including touchscreen dialing) seem to be available in other phones. Brand extension . Apple changed its name from Apple Computer to Apple, Inc. The iPod is not a personal computer, yet it has been

CNBC aired a segment today reporting that studies show businesses with no formal business plan often do just as well as businesses that have business plans. A study out of Babson College . . . studied 116 businesses. They found no statistical difference over a set period of time of how well those businesses did by metrics such a revenue or profits . . . . Other studies back this up. The reporter summarized the advice of venture capitalists and the study's analysts as follows: If you are thinking about seeking capital from a venture capitalist, you should really think about doing a plan. But really think about sizing it down: five to ten pages. A lot of VCs tell me they want a PowerPoint presentation instead . . . . Keep it shorter rather than longer. Don't waste six month to a year doing it. Writing a business plan can be a good exercise, because it forces you to consider certain questions - such as the positioning of your product - that you might not otherwise consider. But le

Fox News has an interesting story about software product usability. The article quotes David Platt, author of the new book Why Software Sucks It touches on some familiar themes about the virtues of simplicity and the fact that users frequently don't know what they want. Via Slashdot.

It looks like my next mobile phone will be the Cingular 8525 . For about a year, I've been holding out for a phone that runs Windows Mobile 5.0 Pocket PC Edition, has built-in wi-fi, and has a good camera. I wasn't able to find one until Cingular released the 8525 late last year. Unfortunately, the price tag on the phone is a bit hefty ($400 through Cingular with a two-year contract), so I am going to try waiting until the price comes down before buying it.

Once again, Pragmatic Marketing's esteemed Steve Johnson hits the nail on the head. He cites an exchange between a vendor and a customer: Vendor: "Customers want claims paid in a timely and efficient manner." Customer: "I want my car fixed." Don't let your team lose sight of the underlying goals your customers are trying to achieve.

Toyota is known for continually improving their manufacturing processes. This article describes their philosophy and includes some illustrative examples. One quote from the article stood out for me: If you don't understand what you're trying to improve, how do you know that your suggestion is an improvement? Your product manager shouldn't just tell developers what to build. Specifying features is of limited utility - and may even be counterproductive - if your team doesn't understand how those features benefit customers. The product manager should specify what to improve and the metrics by which your team can judge that a feature (and the implementation thereof) actually benefits customers. Via Cote.

Laura Patterson has a MarketingProfs article on personas. She does a good job of enumerating the questions your product manager should answer when writing personas. She also explores the difference between personas and profiles .

As I mentioned in my last entry, there are two primary reasons that web widgets have become such a phenomenon: Blogs and social networking sites have turned ordinary web users into amateur HTML programmers. They facilitate viral marketing. Most blogging (e.g. Blogger) and social networking (e.g. MySpace) platforms provide a means of inserting HTML code in messages and profiles. As a result, people who never had any intention of developing ordinary web sites have learned some of the basics of HTML so they can do things like pepper their MySpace profiles with pictures and include YouTube videos in their blog entries. They don't compose complete web pages, but they do insert snippets of HTML code. Widgets facilitate viral marketing. If you provide a useful service on the web, you can make it available as a widget by posting HTML code that someone can copy and paste in their page. Your service then becomes directly accessible from their page. Since so many people now have basic HTML

Yesterday, I introduced the concept of web widgets. As chunks of HTML code, they don't seem particularly revolutionary at first glance. Yet they are revolutionizing the web. YouTube is perhaps the quintessential example of the success of widgets. When you visit a video at the YouTube web site, you'll find a chunk of HTML code that you can copy and then paste into your blog, MySpace page, or other web site. I've embedded a YouTube video below. (Beware of humorous political content. Ali G. interviews Patrick Buchanan and tricks him into confusing WMDs and BLTs.) The chunk of HTML code that I pasted into this blog entry to embed this video was: <embed src="http://www.youtube.com/v/blnduEgwBH0" width="425" height="350" type="application/x-shockwave-flash" wmode="transparent"></embed> There are two primary reasons that widgets have become such a phenomenon: Blogs and social networking sites have turned ordinary web us

What is a "web widget"? According to Wikipedia: A Web Widget is a portable chunk of code that can be installed and executed within any separate HTML-based web page by an end user without requiring additional compilation. Usually, web widgets are chunks of HTML code that you plug into a web page. Examples include: HTML code that displays a picture on your MySpace profile. HTML code that embeds a YouTube video in one of your blog entries. HTML code that embeds a portion of your calendar on your personal web site. You may question the significance of web widgets. The concept of chunks of reusable HTML code doesn't seem particularly revolutionary at first glance. However, for reasons that I'll explore in my next entry, widgets have become very important on the web.