Pragmatic Marketing Rule #4

This is the fourth in a series of posts on Practical Product Management Rules from Pragmatic Marketing.

Rule #4: In the absence of market facts, he who owns the compiler wins.

I've lived through this nightmare more than once and, all I can say is, even in the presence of market facts it's plenty easy for the guy with the compiler to win.

But when you're working with the developers, it is ALWAYS best to have the following:

• Win-Loss analysis: If 19 out of 20 times, you hear that a key factor in a loss was ease of use, your developers can, in fact, respond that "The customers don't know what they're talking about," "We're selling to the wrong people," and "Our sales folks don't know how to sell." But you will have market facts to support your argument that the UI needs work.
• Competitive info: The last thing you want to find yourself doing is playing competitive catch-up - especially when some of the features you're trying to catch up with are completely irrelevant. Yet it is always useful to know what you're up against. And if you can anticipate moves that your competition is going to make - through analysis of what they're saying publicly, who they're partnering with, where they're selling, etc. - so much the better.
• Market trends: What are the analysts saying about your industry - or the industry you sell into? What's being said about technology trends. No, you don't have to listen to every 'Gartner assigns a probability of 0.8 to universal adoption of touchscreens by 2010", but people do place significant weight on what the "theys" of the world say. So dig up whatever data you can find on SOA, SaaS, MDM - or whatever acronym you think your product needs to accommodate. (Years ago I worked for a software company that - for a lot of reasons not worth going into here - was wedded to OS/2. I remember bringing a copy of InfoWeek (I think) with a picture of OS/2 in a coffin with a lily on it on the cover into a development meeting. It definitely helped us move along on our decision to convert to NT.)
• Customer input: The customer is not always right, and sometimes they will ask for stupid things, or not so stupid things that are, in fact, one-offs that help them and only them. But your trusted customers - not your developers - are the ones actually using your product, so their ideas should be heard.
• Sales engineering and customer service input: Your sales engineers tend to know better than anyone else what the technical obstacles are to selling and implementing your product. You need a forum for capturing their ideas. Customer service folks tend to know better than anyone else what the technical obstacles are to ongoing, day-to-day success with your products. You need a forum for capturing their ideas.

When product management/product marketing start talking product with the developers, they need to be armed with the richest possible set of market facts they can find. The above are useful sources of those facts. It's then up to you to put them in a digestible, sensible format to present them to the developers.

There is still no guarantee that a really stubborn guy with a compiler with balk at product ideas that don't spring full blown from his own head. But if you've got the facts, ma'am, it's far more likely that resistance will fade away.