How to code as a marketer

If you’re on the Light Side in the hi-tech world, odds are pretty good that your primary “doing it” activity has something to do with coding.  If you’re not actually writing the code, you’re compiling it, or architecting it, or QA’ing it, or bug-fixing it, or triaging it… or managing a team that’s doing those things.  The code may be a pure language like Java or C, or some web-based API, or maybe some higher-level scripted language through an IDE so you don’t have to worry about the underlying code.

Well, marketers often have to “code” too, in a very subtle and hard to master programming language.  The difference is, their coding isn’t in C++, SQL queries, PHP, Perl, or Javascript… it’s “English.”

English, of course, has its own grammar and syntax.  Its own optimizations and subtleties.  Unlike Light Side coding, however, you don’t have to be a Dark Side marketer to learn how to write it and use it.  Nevertheless, just like any code monkey can write software to get the job done, it takes definitive skill to manipulate language just as you might write more elegant code.

Sometimes in a Light Sider’s career, he or she is asked to code in English… Unfortunately, this is often akin to asking a Dark Sider to do some programming with Visual Basic, or some web design work with Microsoft FrontPage.  Sure, you can probably come up with something functional.  But is it as effective and useful?

In Light Side programming, one often tries to minimize the number of lines while maximizing both functionality and readability.  A few crystal clear lines can achieve what several pages of complex code might not.  So it is with Dark Side programming.  In English, brevity and succinctness are imperatives to optimize the inherent value of your communications if you are to retain the waning interest level of your target audience.  Yes, I intentionally violated my own rule in that last sentence, which should have read: be clear and concise if you want people to get it.

It’s an unfortunate Light Side tendency to be as complete and accurate as possible in your descriptions.  “This product performs 37 functions as detailed in this documentation.”  That’s great for documentation.  Please, by all means, be thorough in your reference materials.  But how do you explain that to the guy who controls the budget for the engineer who’s going to buy your product?  He’s not going to read your documentation.  He needs the inside-flap-of-the-book-cover version.  Remember, it’s easy to write about everything and anything your product does.  The hardest thing isn’t knowing what to say.  It’s knowing what not to say.

Unfortunately, just as with real coding, the only way to really get better is through experience and practice.  Reading about it can help, but you really just have to roll up your sleeves.  “Code reviews” can help you pick up some tips from other Dark Side programmer peers  as well.   Look for future posts here (to be tagged “Force training”) that lead you through a few practice exercises on the subject.

There’s a slew of programs, or “marketing collateral,” that marketers must create with this mysterious English to accomplish the task of communicating the value of whatever it is they’re marketing.  Datasheets.  Customer-facing powerpoint presentations.  Whitepapers.  FAQs.  External and internal training documents.   Articles for industry trade magazines.  When I sit down to create one of those, in my head, I slip into a coding mentality.  What am I trying to accomplish, what’s the design and architecture, what are the constraints I’m operating under.  I’ll write pseudocode, in the form of an outline or a draft, before I go about implementing the actual ‘program.’  And along the way, I’m definitely looking to optimize.

Next up, I’ll tell you the framework that I prefer for creating any marketing material.  It revolves around a well-crafted positioning statement, which may be the single most important part of any marketing effort.