Industry Experience: How Important Is It?

In the latest Pragmatic Market BlogFest, Steve Johnson wrote about the importance of domain expertise. Steve's two main points are:

1. Developers need to understand the domain and not merely code to specs.
2. Product managers need to understand technology

I can't disagree with Steve on these points. However, more interesting to me is:

How important is it that a product manager have prior knowledge and experience in the domain?

I have written on this topic in the past. In fact, it was one of the first entries in this blog. Below are some more thoughts.

Should a company hire a product manager with years of experience in, and knowledge of, the industry? How about a capable and experienced product manager with little or no prior domain knowledge?

The key to understanding the importance of domain knowledge lies in recognizing a product manager's most important skill: learning about the market.

Thoroughly understanding a market necessarily entails being intimately familiar with the user and buyer experience, and therefore requires grasping the domain in which they operate. So yes, domain knowledge is fundamentally important.

But "learning" means acquiring knowledge, not having it already. A product manager who is knowledgeable about an industry solely as a result of lengthy prior experience is much less capable - and much less valuable - than a product manager who can quickly master a market and domain.

After all, markets change. New competitors enter the landscape, and user and buyer psychographics evolve. Don't you want a product manager who knows how to keep abreast of, or anticipate, these changes rather than relying on the way things used to be?

Thus we see that prior domain experience, while helpful, can be a crutch. An insistence on prior industry knowledge amounts to a concession that product managers are not capable of performing their primary learning function.

If you're an executive looking to hire a product manager, I recommend de-emphasizing domain experience and focusing on the skills that enable market mastery:

• Interviewing prospective and existing customers.
• Identifying and quantifying the problems that customers face.
• Analyzing the competition and their positioning.
• Framing survey questions and interpreting survey results.
• Observing customers in their native environments.

A product manager performs many other important duties, but the point is that domain knowledge is no substitute for these skills for achieving market mastery.

The Big Brands Do It, Why Can't We?

Good marketing often contradicts intuitions and instincts. Those wishing to cling to their intuitions find solace in the fact that big companies are just as likely to make mistakes as little ones.

Kimberly-Clark, a huge company and umbrella brand, chose "Huggies" as the name of a line of diapers. "Huggies" is a descriptive name in that it implies in a not-so-subtle way that it is comfortable and effective. (Similarly, Procter and Gamble sells the "Pampers" line of diapers.) Yet descriptive names generally don't make good brand names.

I can hear it now: "If Kimberly-Clark's marketing department decided on a descriptive name, why shouldn't we?"

I should point out that, aside from its descriptiveness, "Huggies" is actually a pretty good name. It is easy to pronounce, easy to spell, and slightly shocking - all attributes that foster brand recall and recognition. Plenty of products succeed despite a descriptive name.

But let's put to rest the idea that big, successful companies don't make marketing mistakes. Fortunately, Laura Ries debunks this notion on a regular basis. In her latest blog entry, she tears into seven successful companies for recent marketing decisions they've made.

eHealthInsurance.com

A few days ago, I received in U.S. Mail a notice from UniCare that the premiums on my health insurance were going up. Given that my health plan covers little and now is going to cost more than twice as much as it did four years ago, I decided to research other options.

I originally signed up for my health insurance plan through eHealthInsurance.com, a helpful service that enabled me to browse and compare numerous plans from a number of different providers. At the site, you can specify various plan features (deductible, co-pay, etc.), view a list of plans that satisfy those parameters, and compare the plan details.

It's a great concept. Unfortunately, it has nonetheless frustrated me. The reason is that the service focuses on the features of health insurance plans rather than addressing real-world scenarios.

This morning, I went to eHealthInsurance.com to research alternatives to my existing plan. I brought up various plans but scratched my head when trying to determine what they would and wouldn't cover. So I called their customer service to speak to a health insurance "agent".

The agent immediately asked me what I wanted in a plan. I told her that I don't know and suggested we walk through various scenarios and see which plans best covered them.

1. I get into a car wreck, suffer massive internal injuries, and go to the hospital for surgery.
2. I get a minor cut on my leg and go to a minor emergency center for stitches.
3. I go to the doctor for a routine check-up.
4. I go to the doctor to get a prostate exam (leaving aside the fact that the one prostate exam I've received was the most unpleasant experience in my entire life).

The agent's response? "I don't have time to go through all that. Just tell me what you want," she replied. "Do you want a co-pay?"

At this point, I told her I was frustrated. She was assuming I was an expert on health insurance concepts. All I know is that there are various types of scenarios. Some plans address them well, and others don't. Co-pays, deductibles, co-insurance, and out-of-pocket limits mean nothing to me except insofar as they affect the bottom line in these types of scenarios.

Though she initially refused to walk through the scenarios with me, she effectively did by the end of the conversation. I felt educated enough to compare plans and make a decision. Despite the fact I was still seething with frustration, I thanked her for her patience.

What product management lessons does this experience teach? I'll examine some of them in a future entry.