In classic marketing classes, a lot of decisions are quantitatively driven or at least backed. If you’ve had that training and go into classic consumer marketing, you probably feel right at home.

However, in my experience, enterprise software marketing rarely has similar quantitative data available. This is particularly true in immature segments where you are creating the market. But it is even true in segments that are followed by industry analysts.

I’ve worked in some organizations where we commissioned our own research. But even there, the best data came from focus groups rather than statistical analysis.

So, if you don’t have statistical or analytical data to work with, how do you get enough information to make good decisions? I believe that most often it comes from the ability to synthesize a number of often anecdotal bits of information into a cohesive whole. This is really the art of software product management and marketing.

Where does this information come from?

Customer themselves: This is the big one. We all go out and talk to our customers. Sometimes one to one, sometimes in bigger sessions. These interactions are good for a couple of types of input:

• Major pain points for the customer. If they are all “whining” about the same thing, it should certainly be on the list
• Topical issues. Like everyone else, customers will tend to feed you the top of mind stuff first. This can be a good trend indicator. But, be careful with this information as it might be old news by the time you do anything with it.
• Innovative customers. If you have a few customers who clearly ‘get’ your product, work with them. These are the folks who might just give you the next great idea or at least the raw material for it.

Sales force: The sales team is often quite vocal about the topic of the day and very aware of things that are impacting competitiveness. However, they also tend to be even more short term focused than the customers. Be particularly wary of:

• Only listening to the most vocal reps. The ones that seek you out may or may not be your best source. They may be the ones who are least successful at selling what you have and simply looking for excuses. The ones who know how to ‘sell around’ deficiencies or competitors’ positioning are often the best and they are too busy to come to you.
• Getting sucked into “last customer syndrome”. This is where the answers you get are driven by whomever they talked to last. Part of your job is to extract more relevant trending information rather than just taking the one data point.

Make sure to include the Sales Engineers in your discussions with the field. Very often, they know more about the competitive situation than anyone because they were asked directly by customers to explain this or that and how it compares to ‘brand x’. 

Even more importantly, they know all the things they do in their demo setups to ‘work around’ the product. They may be making sales with demoware that should be in the product and you never know about it if you don’t ask.

Support: You should be getting feedback from support not just on bug escalations but on things like ‘top ten’ lists of what customers call about, which they could do, have trouble with, etc. It’s easy to get bogged down in the mechanics of processing and prioritizing escalations. But, while important, it isn’t where the future lies. When your support team can tell you about how they just got the 20th call from customers trying to do “x” that they thought the product should do but doesn’t, that isn’t a hint, it’s a club to the head if you listen.

Professional Services: Sadly, this is one of the most obvious in concept for enterprise software companies and in my experience almost never well executed. Your PS team is out there working closely with customers every day. Generally working on two kinds of things: 1) Deployments 2) Customizations. Might it be good to know what challenges they are having with the first, and what interesting ideas customers have for the second? Duck, that club is swinging at your head again.

Unfortunately, most of the time this information never crosses the organizational gap. PS folks are billed by the hour and aren’t incented to spend time talking to you. Your engineering team will most likely have no interest in looking at the ‘hack’ work that the PS team has done for ideas.

Fixing this is hard. But you can do your best. Work with the PS team management to identify top issues lists during deployments. Figure out how much time or customer satisfaction are being squandered. Create a process for at least tracking and sharing the summary of customization products. Maybe even make a PM/Dev review part of the process for bigger ones.

Industry analysts: If you have them, this is obviously a great source. The good ones will bring you new ideas synthesized from their conversations with multiple customers. But be careful. If you pull too much and don’t end up doing it, it is worse than when you let a customer think you’ll have a new feature by year end because the analysts have communication leverage.

Build a good relationship with the analysts that cover your space. They should be treated as your friend, even if you need to keep them at arms length sometimes. Once you have reasonably well baked ideas, they can be great validation points as long as you understand their personal interests and biases. No point in pitching your great new app for Market A to the analyst who just published a piece on how Market A is a waste of time. (BTW, do have a good argument to yourself and your management about why it isn’t?). By the same token, if you heard them say that a “42 inch Widget” would be the best thing if only someone built it and you have finally come to the same conclusion, they are great people to see if the “Super WonderWidget” hits the mark.

Engineers: Last but not least, is your own engineering team. If you’ve got a good team, they should have domain knowledge themselves on what would be interesting to customers. Make a point to take them along on the customer visits so they can be part of the ‘brain trust’ that really understands what makes sense. By the same token, this lets them build features better the first time. They’ll really understand how customers want to look at things and you’ll go through fewer design revisions.

However, do be careful about the balance of power issues. PM and Dev should be great partners but you are still responsible for driving the product direction. You don’t want to let things go down the slippery slope to uncontrolled releases that are driven by the engineering team’s desires rather than market needs. At the end of the day, all of these inputs need to by synthesized into a cohesive roadmap and product plan by you.