Friday, September 30, 2005

Pleading Ignorance

One of a product manager's most effective approaches to understanding the market is pleading ignorance.

When a product manager conducts an interview at a customer site, his purpose is not to sell the product or tell how it will benefit the customer. The purpose is to understand the customer's situation and problems, irrespective of whether the product solves them.

Consequently, there is no reason for the product manager to flaunt his knowledge of the market. In fact, claiming to know a lot about the market will tend to:

  1. Make the customer feel her ideas and perspectives aren't very important, thereby demotivating her during the interview.
  2. Cause the customer to omit information under the premise that the product manager knows it all anyway.
  3. Set expectations high, thereby increasing the chances the product manager will disappoint the customer.
Pleading ignorance, on the other hand, actually gives the product manager more credibility. It suggests that the product manager listens to the customer without prejudice and that therefore his conclusions, when he does draw them, are more reliable.

When you're learning, plead ignorance, and do it confidently.

Thursday, September 29, 2005

What is an Iteration?

Cote included among his recent del.icio.us links an article by Alistair Cockburn on iterative development.

The crux of the issue Cockburn raises is that "[d]anger grows when the results of [an] iteration are not directly linked to delivering the product to the end user."

To realize the benefits of iterative development, your iteration cannot simply be a development time period that culminates in testing and refinement of the plan for continuing development of the product. An iteration must result in a working release of the product to an end user. I have made this point in the past:

"With iterations, you perform the steps to yield a working version of the product for review."
That is, the tests you run shouldn't just validate that isolated features or pieces of the product work, but that the end-to-end processes users perform are working.

Why is it so important for iterations to yield a working, releasable product? One reason I've mentioned:

"Implementing the product and demonstrating it to prospective customers almost always results in the discovery of new requirements or the recognition of errors in the original requirements."
Another reason is that it prevents product developers from getting side-tracked. A developer might, for example, get bogged down implementing a particular feature. What's important, however, is not the feature itself, but what requirement it was intended to satisfy. If the developer is focused on satisfying the requirement instead of implementing the feature, she may (acting with "agility") simply choose to ditch the feature and satisfy the requirement by different means.

Wednesday, September 28, 2005

Buyer Tension

Many technology companies attempt to sell their products to two different kinds of buyers. For example, I once worked for a company that sold their products to both IT and managers of semiconductor factories.

Unfortunately, you undermine your marketing efforts when buyer tension exists. Buyer tension is when the messaging that resonates positively with one type of buyer antagonizes another type of buyer.

In the case of the company I mentioned above, the messages that were effective in marketing and selling to factory managers antagonized IT personnel. The reason was that, within the customer's organization, the IT personnel were currently providing their own custom solution to the factory manager. The most compelling message for the factory manager was to replace the custom solutions the IT personnel were providing with an out-of-the-box, easy-to-configure solution.

Thus marketing and selling to the factory manager antagonized the IT personnel, because it threatened not only their custom solution, but in some cases their jobs. So the product marketers tried to straddle both IT personnel and factory managers with the positioning of the product, thereby pleasing no one. The product developers were particularly displeased, because the straddle muddled the requirements for the product.

When buyer tension exists, it's a good indication that you lack sufficient focus. You need to pick one type of buyer and orient your product and messaging around that type of buyer.

Tuesday, September 27, 2005

Kranz on Focus

Over on MarketingProfs.com, Jonathan Kranz has an article, "Before You Write: Your 10-Point Checklist". One among several noteworthy items on the "checklist":
"7. Focus on one thing. I recently worked with an engineering company that has many talents. They do design. They supervise construction. They serve as expert witnesses in litigation. In fact, they do so many things so well that it was hard to craft a coherent message that wouldn't confuse potential clients. In the end, we agreed on a common theme: They solve problems that stump other engineering firms. In doing so, we had to elevate some elements of the message,
such as 'problem-solving,' while subordinating others, like 'design.'

This winnowing process may be painful—we all prefer to say as many good things about ourselves as we can—but it's absolutely necessary. Messages that are too broad disintegrate like powdery snowballs and never reach their targets. But a focused message is like a rifle shot—powerful because it is precise."
Many product managers and marketing gurus say that focus is important. In fact, one of Al Ries's 22 Immutable Laws of Marketing is the Law of Focus. The reason we keep on harping on it after all these years is that, unfortunately, there is an almost irresistable desire for companies to broaden their message.

Monday, September 26, 2005

Survey Brevity

Imagine someone sends you an e-mail asking you to complete a survey. What is the biggest deterrent to your agreeing to fill it out?

Most likely, the biggest deterrent is the anticipated investment of time. If you feel that filling out the survey would take just a couple of minutes, you'll be much more likely to do it than if you think it will take ten minutes. Right?

Some market researchers offer incentives for people to fill out surveys. The incentive might be a coupon or entry in a drawing for a valuable prize. For many potential respondents, incentives do not overcome the deterrence of the anticipated investment of time. Moreover, if a survey is too long, some respondents will begin answering candidly but will eventually start to answer randomly to get through it as quickly as possible.

Not only are many surveys too long, but some survey solicitations don't tell potential respondents how long the survey is. If you want to minimize reluctance to complete your surveys, keep them short (no more than a dozen questions in many cases) and tell potential respondents how many questions are in the survey.

Sunday, September 25, 2005

Bonnemann on Agile Product Development

Tim Bonnemann writes about agile product development:
"Agility is about paying attention and reacting. You can’t not make mistakes. What you can do is figure out you made a mistake quickly and react accordingly."
The inevitable mistakes and oversights occur not just with product design and implementation, but with product requirements, marketing messages, and pricing. Thus product managers, not just developers, must participate in the agile process.

Saturday, September 24, 2005

Farmer's Market

Besides the view and the availability of free (prepared) food and beverages, another reason I like living in downtown Austin is the Farmer's Market.

Saturday mornings between February and December, local farmers and other vendors assemble at Republic Square Park (4th and Guadalupe) and sell a variety of fruits, vegetables, meats, and eggs. Due to the climate of the area, the selection isn't large, but I buy the tomatoes and peppers on a regular basis when they are in season.

Best of all, it's one block from my loft.

Friday, September 23, 2005

Example of a Nonfunctional Requirement

I described yesterday what a constraint is. I also promised to give an example of a nonfunctional requirement. Below is an example from a recent market requirements document I composed for a client. I have edited it slightly to avoid disclosing confidential information.

A driver should be able to plan (in advance, by making a reservation) with a certain degree of confidence that a vehicle will be available when she needs it. Therefore, for advance reservations, it is desirable to maximize the probability that a vehicle will be available for reservation at the time the driver wishes to make the reservation.

For a given number of hours of advance notice x, the following formula yields the minimum percentage probability y that a vehicle should be available for reservation:

y = 100 - 1 / (.048 * 1.039x)

The constraint is on a "Use Vehicle" use case. I won't burden you with the details of how I derived the formula, but suffice it to say it involved balancing the interests of the customer with practical realities. It also assumes certain population, demographic, and psychographic profiles described elsewhere in the market study I provided.

Thursday, September 22, 2005

What is a "Constraint"?

Whether you're a company executive or a product engineer, your product manager may at some point deliver (hopefully not in a BUFR manner) you a market requirements document (MRD). The MRD will typically include functional and nonfunctional requirements that the product must satisfy.

The nonfunctional requirements comprise the constraints on your product that ensure it will solve or avoid prospect problems. The nonfunctional requirements will typically express the constraints as conditions or measurements that must hold as the user uses your product.

In my next entry, I will give an example of a nonfunctional requirement.

Wednesday, September 21, 2005

Ottinger on Requirements

Tim Ottinger writes about requirements in his blog. He mentions the danger of "paper-heavy methodocracy", which is roughly equivalent to BUFR. He also notes (about software requirements in particular) that "a requirement is architecture, language, library, and format agnostic", reflecting the larger truth that requirements should not prescribe any particular design or solution.

I wonder if he agrees with my definition of "requirement"?

Tuesday, September 20, 2005

BUFR

If you are an executive at a software company, your development team may be familiar with agile or iterative software development.

At first, its advocates lamented "big up-front design" (BUFD). Software organizations that try to design the product up front in excrutiating detail waste a lot of effort, as implementing and testing the software uncovers many unforeseen problems. Agile development attempts to exercise the architecture (high-level design) and expose these problems early. It typically does so by "releasing" the software early for testing. It thereby attacks architectural risks early in the development process and defers the design details.

More recently, advocates of agile development have realized that a more serious problem than architectural risk is requirements risk. You never know all of the requirements until you release the product. If your organization engages in "big up-front requirements" (BUFR), you tend to waste even more time than with BUFD. You're better off attacking requirements risks early in the process - again, by "releasing" the software early for testing and feedback - after having defined the key requirements but having deferred the details.

Since market problems and needs should drive the requirements for a product, the product manager must work collaboratively with the development team to iterate on the requirements. A product manager who engages in BUFR and then throws the requirements over the wall to developers subjects the entire product development effort to risk - requirements risk.

UPDATE: Some people refer to BUFD and BUFR as 'BDUF' ("big design up front") and 'BRUF' ("big requirements up front"), respectively.

Monday, September 19, 2005

Lean Manufacturing

The terms "agile development" and "iterative development" originated in the real of software products and projects. Do the same concepts apply to the development of other products?

I've mentioned previously that hardware products can benefit from agile development methods. Another domain in which the concepts apply is manufacturing.

Lean manufacturing seeks continual improvement. Just as with other forms of agile development, it embraces the assumption that it is impossible to predict up front what the final product will be. There are simply too many variables and too many uncertainties, so you implement a solution and iteratively refine it.

A product manager has to work within this process of continual improvement to ensure the product meets the market requirements in a manner that's cost effective and realistic.

Sunday, September 18, 2005

Product Management and Sales: The One-Two Punch

Instead of having a product manager go on a sales call, you can use the following effective approach to an important sale:

  1. Product manager meets with prospective customer. Pleads complete ignorance.
    Just asks questions. Afterwards, reports customer's special situation to sales
    person.
  2. Sales person meets with prospective customer. Uses SPIN Selling
    techniques. Tailors the message based on what the product manager reported.
The reason this approach can be so effective is that the product manager "disarms" the prospect by making clear she is just gaining an understanding of the prospect's situation and problems, and does not plan to sell the prospect anything. But then the sales person has the benefit of having a thorough understanding of the prospect's situation before the sales call.

Saturday, September 17, 2005

Big Bend National Park

If you like primitive camping and can stand desert climate, you might want to try visiting Big Bend National Park. I've camped there several times.

My first visit was a four-day, three-night camping adventure. With my buddies, Jim and Bobby, I spent the first two nights high in the mountains and the third night in a random spot in the desert. My fondest memory of the trip was playing the card game "War" in the desert while drinking warmed cognac as the sun set.

I have a multimedia slide show of a more recent visit here. Many of the "slides" are video clips, so you may have to wait a minute for some of them to load.

Friday, September 16, 2005

Surprise Rewards

Seth Godin writes about an unusual but effective promotional idea: surprise rewards.

The typical promotion advertises rewards and often tells the customer what they must do to receive them. For example, airlines offer frequent flyer miles. Credit cards offer cash back.

But what about rewards that come as a complete surprise to the customer? Everyone likes a pleasant surprise. When the customer purchases your product, how about giving it to them for free every once in a while? Or how about randomly giving them a voucher towards any future purchase? By doing so, you create powerful word of mouth for your product.

Thursday, September 15, 2005

Product Manager on Sales Calls?

Product managers sometimes get dragged into sales calls even though sales is not among their core responsibilities. Product managers, after all, are experts on the market, understand the product, help devise the sales process, and formulate the key messages. What better person to take on a sales call?

Sales people and product managers should work closely together so that the sales people are able to operate independently with customers. A product manager has not really fulfilled his full responsibilities if he hasn't communicated his understanding of the market with the rest of the organization.

One exception to this rule is that it may be beneficial for product managers to "test" the sales process and messaging by personally applying them with real customers.

Wednesday, September 14, 2005

Godin and Wehr Agree

Lisa Wehr writes in a MarketingProfs.com article:
"Landing page design should be clean; it should have easy-to-find buttons and a clear call to action."
You shouldn't just hope that visitors browse various pages in your web site. You should orient the site, particularly its landing page, around inducing them to do something. This advice echoes what Seth Godin recommends in Knock Knock.

Tuesday, September 13, 2005

Flaws in CPM

In my last entry, I wrote about critical path analysis. Fundamental to the concept is the analysis and documentation of dependencies among the tasks required to complete a project. The concept is important to executives and product teams, because it forms the basis for scheduling the development and release of the product.

The key flaw with using critical path method for scheduling is that planners (e.g. project managers) misuse it. Let's see what Wikipedia says about it:

"Originally, the critical path method considered only logical dependencies among terminal elements."
The problem arises when planners try to convert a critical path diagram (CPD) directly into a schedule by superimposing a timeline on the diagram. This kind of CPD may yield a best-case schedule, but projects of substance almost never progress accordingly.

First, you can't anticipate with any level of certainty the effort and time required to complete tasks. For example, how long will it take the user interface programmers to finish the UI for a software product? You can only make an educated guess.

Second, you can't easily and accurately model the collaboration among different members of the team. An effective product development effort requires a great deal of interaction among the product manager, developers, testers, and even marcom and sales. Tasks and roles tend to blend together much more than a CPD can convey.

Third, you can't anticipate the requirements discoveries that will take place. It might be that prospective customers say, "Oh yeah, I forgot to tell you about this other problem I have." Or it might be that a competitor releases a product that renders your product obsolete unless you significantly enhance it. These requirements discoveries will, in turn, render your CPD obsolete.

Fourth, you can't predict the logistical and architectural challenges that will arise. You may find a critical bug in the software tools you're using to develop the product. Or a subcontractor may suddenly go out of business.

Fifth, you can't predict the integration problems that will occur. You eventually have to integrate the deliverables resulting from the disparate tasks. It is difficult to anticipate how long it will take to integrate these pieces.

Understanding the anticipated dependencies using critical path analysis can be useful for identifying what went wrong. However, a CPD on a timeline does not allow for nimble adjustments. Nimble adjustments require an agile approach to scheduling.

Monday, September 12, 2005

Critical Path Method

During the course of my career, both in software development and product management, I have encountered many executives and project managers who think in terms of critical path.

With critical path analysis, you break a project down into tasks and show the dependencies among these tasks. You usually also size (show the amount of time it will take to complete) each task. You may also place all of the tasks on a timeline. The end result is a critical path diagram (CPD), which some project managers then treat as a schedule for the project.

The critical path method (CPM) of project management is antithetical to more agile, iterative methods. In a future entry, I will discuss some of the major flaws in CPM.

Sunday, September 11, 2005

What is Market Strategy?

It's important to formulate a market strategy and align your tactical marketing (advertising, PR, brochures, etc.) with it. Numerous firms claim to provide market strategy services, yet many of them fail to actually deliver strategy. But what is market strategy?

Market strategy comprises many of the deliverables from product management, including:
  • Positioning and messaging. What differentiates your product from the competition? What are the key themes and messages to use in advertising and PR?
  • Prospect problems. What are the main problems your product will solve that prospective customers face?
  • Branding recommendations. What principles should govern the selection of a name or logo?
  • Market segmentation. Who is in your target market?
  • Communications analysis. What media should you use to reach your target market?
Some of these deliverables actually extend slightly beyond what some product manager may provide. For example, some product managers profile prospective customers and shed light on the type of media that will reach them, but do not actually recommend a media strategy. Regardless, strategy defines the high-level policies, enabling marcom to wage an effective campaign that implements the policies.

Saturday, September 10, 2005

Roger's Rule of Irrationality

The three topics of conversation in which people are the most irrational are religion, politics, and sports.

Friday, September 09, 2005

Laura Ries on Google

Laura Ries has some quotes that are gems in her latest entry about Google:

"Google is a branding success story . . . . The name alone is branding genius. Short, simple, unique, different."

"Google has its tentacles in way too many divergent businesses."

"I am very concerned for the Google brand and Google stock holders. No brand can stand for everything and dominate every market."
Indeed, "google" follows important naming principles. Notably, it was a "blank slate" with no resemblance to the product.

Time will tell whether Google's rumored and actual forays into divergent businesses will pan out for them.

Thursday, September 08, 2005

"Market Strategy" Companies

Are you considering a "market strategy" company to help with your product marketing efforts? Not all market strategy companies are created equal. Beware of three types of firms that masquerade as "market strategy" companies:
  1. The Marcom Helper. Some companies that claim to do market strategy don't mean "strategy" at all. Instead, they perform tactical work such as designing professional-looking web sites, composing pretty brochures, or organizing PR events. While tactics are important, even essential, they usually must implement the overall strategy to be effective. Does the firm understand your strategy and how to implement it?
  2. The Unprincipled Strategist. Marketing strategies usually won't work if they fail to satisfy certain marketing principles. Does the firm understand the principles of positioning and branding?
  3. The Uninformed Strategist. Determining the best strategies to guide your product marketing requires a thorough understanding of prospective buyers, the problems they face, and competing products. Does your firm perform the necessary research?

In short, a skilled product manager or product management firm should guide your product marketing strategy.

Wednesday, September 07, 2005

Processing Customer Requests

Your customer support department receives bug reports and feature requests from users. How should your company deal with these reports and requests?

Many product teams grow tired of dealing with the on-slaught of customers who think they know better than you what should go in your product, and which bugs are the highest priority to fix. And those who tire of the on-slaught have a point - customers often don't know better. However, you can learn with them if you follow up to uncover the root problems and the business contexts underlying the bug reports and feature requests. A product manager is ideally suited to perform this kind of follow-up.

As a result of the follow-up, the product manager and the customer may both conclude that the bug or feature is really irrelevant to the bigger picture. An innovative way to solve the customer's problem may come to light. Or the customer may discover a new way to use the product that achieves the same result as the feature she requested. Either way, customer support should not be a one-way valve for information.

Tuesday, September 06, 2005

Sales Process Definition

Part of what a product manager does is to help define the sales process for a product. Not only does she profile the prospective buyers of the product, but she gains an understanding of the key stakeholders who collaborate to make buying decisions.

A college student may consult with parents before buying a car, since in some cases the parents actually pay for it. In a business-to-business (B2B) sale, the decision to buy may require the collaboration of executive, technical, and user buyers.

How a salesperson most effectively can approach a sale depends on the potentially complex processes and interactions that customers use to make their buying decisions. A product manager who has researched these processes and interactions should work with the sales team to design the sales process that works best with them.

Monday, September 05, 2005

Obtaining Commitment

Let's look at what Neil Rackham wrote in SPIN Selling (page 33):

"Closing techniques may increase the chances of making a sale with low-priced products. With expensive products or services, they reduce the chances of making a sale."

Unless you're selling a very low-priced product, don't try to "close the deal" with a first-time visitor to your web site. Instead, close a small deal - a "deal" that costs the "buyer" little or nothing. That deal is a mere stepping stone towards the purchase of your product. Rackham calls this stepping stone an "advance".

Rackham wrote mostly about sales calls, but the same principles apply to web site design. You want to obtain some sort of commitment from the visitor, but you shouldn't expect it to be the placing of an order. Rackham's advice reinforces the notion that your web site should have a call to action, and that it should be realistic.

Sunday, September 04, 2005

A Call to Action?

What is your company web site's call to action?

In general, your company's web site shouldn't just look pretty or provide information. When a prospective customer visits it, it should drive them to act. "Sure," you say, "our web site provides information that stimulates a visitor to buy our products." Really? A visitor is going to read a little about your company and its products and buy, right then and there?

You're usually better off having a more modest, intermediate goal for your web site. You need a realistic call to action. Possibilities include:

1. Downloading a demo.
2. Requesting some specific information about the product.
3. Inviting someone else to buy the product.
4. Signing up for a trial version of the product.
5. Signing up for a free "consultation".

You should focus your web site on getting the visitor to perform the action you choose. Make sure it's obvious what the action is, and that it is easy to perform.

Saturday, September 03, 2005

Will SMS Applications Thrive?

Short Message Service (SMS) text messaging is now standard on mobile phones. (Multimedia Message Service, or MMS, is an enhanced messaging service that adds the ability to attach pictures and sounds to the messages you transmit.) It is widely used. But will it survive in anything resembling its current form?

I am a big fan of Google SMS. I was at Academy buying shoes on a Sunday evening and decided to go to Oshman's in the hope they would have a better selection. Would Oshman's be open on a Sunday evening? How could I obtain their phone number so I could call them? If I used my mobile phone's directory assistance service, it would cost me $1.25. I ended up using Google SMS to determine Oshman's phone number.

I wrote 'oshmans austin texas' in a text message and sent it to 46645 (GOOGL on most phones). Within seconds, I had received a text message back from Google SMS with the address and phone number of Oshman's. Very convenient! Yahoo has a similar service.

I can imagine many useful applications of this sort. There are many situations where we are on the go, need some information, but don't have access to it without calling someone to have them look it up. But I know of only two such services: Google SMS and Yahoo's similar service. And I don't know anyone else who has ever used them. Why haven't SMS applications taken off?

Friday, September 02, 2005

Knock Knock

Artistic ability and creativity play a large part in designing an effective web site. However, certain marketing principles apply as well. If you don't adhere to these principles, your company's web site may fail regardless of how artistic, creative, or slick it is. Seth Godin describes some of the principles in his free eBook, "Knock Knock". Some of them will surprise you.

We've mirrored a copy of the eBook on the Cauvin, Inc. web site.

Thursday, September 01, 2005

My Brain's Companion

For almost seven years, I owned a Motorola Startac mobile phone. Friends snickered about it being an "antique". It being my first mobile phone, I was thrilled with it until it stopped working after I dropped it on the ground too many times. During the years I owned the phone, many new models of mobile phones were coming out, but I didn't see any compelling reason to buy them. When my Startac finally died, I was left with little choice but to buy a new phone. I bought a Motorola mpx200.

It was only after I bought and used the Motorola mpx200 that I realized the seriousness of the problems I faced all those years without it. The mpx200, like many other phones (but not the Startac), has a calendar and will keep it synchronized with the calendar in Microsoft Outlook. It also has e-mail and will synchronize messages with Outlook. Using these features changed my life. The mpx200 is like an adjunct to my brain.

The problem I had for all those years was a memory and scheduling problem. I could not keep track of appointments and social events, because there was simply too much information that I either (a) needed while I was not at my computer or (b) discovered while not at my computer. But I didn't realize just how serious a problem the memory and scheduling was until I used the mpx200 and was able to see how different my life could be with my brain's "companion".