Send to Printer

marketing

The New Marketing Battle Cry

January 5, 2010 7:48:58.509

I'm starting to see that marketing is a lot like teaching - periodically, new fads sweep through the field, and a lot of people get swept up in the new idea - whether what they were doing before worked or not. Take this David Meerman Scott Video from Eloqua Experience, for instance, where the catch phrase is "No one cares about your product".

From this, the take away is that you should promote something other than your product - success stories (real or imagined), problems your product solves (channeling the late 90's "solution, not software" thing), and so on. There's something to that; people do want to hear more about the problems you can solve than about a dry list of features and functions.

But.... a lot depends on what kind of product you are promoting, too. Take development tools in general, and, for me, Smalltalk in particular. Back in the early and mid 90's, there was a lot of top down selling happening in this field - I remember being involved in plenty of "bake offs", where I'd go in as a Smalltalk SE (sales engineer) and do a competitive demo against a guy promoting a competing product (typically some 4GL toolset). That simply doesn't happen anymore; tools in this segment move bottom up now. Developers read blogs, news sources reporting on the IT sector, and they talk to friends about what they use/see. When something catches their eye, they download it, and - so long as the installation and getting started process doesn't immediately disqualify it, they might try and build something small.

That process right there is where product marketing plays a role in the development environment space. It's correct that developers, like everyone else, want to know what problem your product solves, but for them, the problems in question are development ones. If your tool is aimed at a particular niche - Ruby on Rails and Web Velocity are specifically web development things, for instance - you aren't going to promote the building of Windows client side customer care apps. So what kind of information is the developer looking for as he/she evaluates the tool? Yes, the boring old "features and functions" stuff. Spiffed up for the modern era, that means simple tutorial pages and short videos rather than large piles of doc, but still: the developer is interested in the basics.

None of that contradicts the basics of David's thesis, but it does mean that you can't just take the glib 30,000 foot view and decree that "features and fuctions" is of no interest to anyone. It all depends on who the audience is. For instance, let's say that the developer evaluating your tools likes what he sees, and decides "hey, I'd like to get me some of that". At that point, they'll go talk to a manager about using the tool. That conversation won't revolve around low level details; the manager will mostly assume that his staff has done that work for him. The manager will go on a hunt for other information:

  • Does anyone else use this stuff (answer: success stories)
  • What does it cost (answer: information on the website)

The roadblocks at the management level can be political, of course - you could have an IT manager who has decided that "this shop uses technology X, period", where X is usually some safe sounding mainstream thing. Barring that, all the roadblocks are back at the vendor end: can the manager find the information he's looking for? If not, you lost a prospect very early in the process.

In summary, you need to take what David's saying and apply it to the field you're in. What information your target audience wants and needs from you depends on who that target audience is. You simply can't apply a blanket rule.

Technorati Tags: ,

posted by James Robertson

 Share Tweet This