Steve Johnson
sjohnson@pragmaticmarketing.com

In my seminars I often quote my rule that "he who owns the compiler wins." It's a reminder that product managers lack the political power to make developers do anything. Instead product management must persuade developers to build what the market will buy.

How do we persuade when we cannot mandate? Answer: use market data.

The primary role of product management is to know the market, knowing potential customers and their problems better than anyone else. We do this by observing them in the workplace, by interviewing them over coffee at a trade show, by following up after product evaluations. Then we tally the problems we've discovered and report the numbers to our developers.

Developers desire market information in the form of data, not the anecdotes that are so commonly reported from sales and marketing people. It's hard to define a product when the feature list changes from day to day based on who we talked to yesterday. Instead, aggregated market facts show developers the issues facing our customers in a form that developers understand.

Ask any consumer marketer: she will tell you chapter and verse about her market segment including what they eat, how many kids they have, what TV shows they watch, how much schooling they have, and the amount of their house payment. Yet the typical product manager in high-tech knows too much about their product's internals and not nearly enough about the market the product serves.

How do we get there?

Make a personal goal to contact at least three prospects or customers each month. I recommend that you contact an existing customer, a recent evaluator, and a qualified non-buyer.

Existing customers are great! They love to show off and will be glad to host the product manager for an all day session. Years ago I visited a customer and was astounded that they did not use the coolest part of the product yet loved a feature that we in the company thought was stupid. I spent all day with them, and since there was still more to see, stayed over and spent a second day onsite. Visiting customers quickly became my favorite thing to do each month. Everyone agreed that it was important, so no one hassled me about the time away from the office. And I had the opportunity to hear good things about my product. How often does that happen? We hear all about the product's inadequacies against the competition, how we lost a deal because our price is too high, our feature set too lean, our architecture is over-engineered. Yet customers like the product and are using it in production every day to solve business problems. They may have some ideas for features and will usually have a complaint or two about the company, but once these issues are out of the way, they are delighted to show you what they've accomplished.

Recent evaluators give great insight into what we're doing right and wrong in the selling process. Win/Loss analysis is probably the easiest of all activities to perform with the greatest power to persuade. Win/Loss analysis unfortunately usually suffers from politics. The sales channel frequently fears Win/Loss analysis will uncover flaws in the sales people rather than the sales process. Give them assurance that you won't embarrass the sales people but are trying to understand how to create a better product and a better set of sales tools. One company has formalized Win/Loss analysis like this: on every deal conclusion, win or loss, the sales administrator automatically reports the basic deal information to the marketing administrator who assigns an onsite visit to the appropriate product manager. Many companies that have implemented win/loss analysis are finding many more process problems than product problems. And strangely, the recent evaluator will almost always take an appointment with a product manager, but only after ensuring that the sales team will not be involved in the follow-up. Imagine the power to persuade that comes from a statement like "72% of last quarter's losses are because we don't solve this problem."

What about the rest of the market? The qualified non-shoppers? The prospective customers? The "losers"? If leadership in a market is 30%, the means that 70% of the market is not our customer. Wonder why? Find out by visiting them. Maybe the 70% doesn't know about your product and you just need a different communications strategy. Maybe the 70% needs a minor revision to the product for a better industry fit. Maybe the 70% believes your product is over-engineered for their needs (and maybe it is). Product management should know the market well enough to understand how qualified prospects are able to live without our technology.

Yogi Berra said, "You can observe a lot just by watching." And that's the trick of product management: find a representative of your market to watch. Watch for activities that they do over and over again that your product could address in a next release or in a new product. Understand their level of technical sophistication so developers can write a product interface that works for regular people instead of the (very few) power users. Identify the features that are never used so we can slim them down or eliminate them.

Bring market facts to developers and watch your credibility change. You know something they do not know; you know the market. Your company has plenty of product experts but who is the market expert? The correct answer should be "me."

Otherwise, in the absence of market data, "he who owns the compiler wins."