Why technical marketing is important for programmers

Most programmers I know hate marketing. Their dislike stems from two root causes: the fact that they aren’t naturally good at it, and their misconception of what technical marketing actually is. “Naturally” is the keyword here, given that technical marketing takes a certain sort of conscious effort and is a skill (a social one) that can be learned, just like programming.

I fully understand that most programmers prefer to focus on coding, and coding alone. But being good at marketing is a valuable skill, whether you are the last code monkey on a project or the CTO of an emerging multimillion dollar company.

Technical marketing is not about spamming, selling out, deceiving or spreading FUD regarding your competition, whoever they may be. Technical marketing is about promoting a given product or technology by clearly illustrating its advantages to a technical audience. This audience might consist of your boss at work, who you’re trying to convince to let you use a certain technology or programming language; it could be potential investors for your startup, users of your open source project, or technically-minded customers that you’re selling your product to.

The underlying product has to be good, regardless of how you promote it. Yet just being good is not enough on its own. Many virtually unknown products are good. The way you present your product can make the difference between success and indifference, an unwanted slug-paced growth and the birth of a phenomenon.

Ruby on Rails’ story is a proverbial example of technical marketing done right – and it all started with a convincing screencast by David Heinemeier Hansson. David’s demo was not the most amazing technical demonstration of all time, but it was effective at conveying the potential benefits that could derive from the adoption of this new framework. That’s what got people interested enough to want to take a second look at it. The framework actually being good, did the rest.

Keep in mind that I’m mostly talking about marketing as a mindset, as opposed to a series of actions taken once you’ve released your product. The features you decide to include, the UI, the user experience you ultimately provide, the documentation, the logo, the name, the domain url you choose, are all affected by the way you think about the marketing and promotion of your product, before you ship it.

Take Ruby 1.9 for example, which has clearly improved over its 1.8 predecessor. When asked the question, “Why hasn’t the Ruby community switched to Ruby 1.9 yet?”, most Ruby programmers would tell you it’s due to the fact that many gems and plugins do not work yet. Some may even argue that most hosting providers have not yet extended their support to cover Ruby 1.9. True as these points may be, they are only side effects and not the real cause. From a marketing perspective, using version number 1.9 was a huge mistake.

Arbitrary and meaningless as version numbers can be, when you slap a version number on a piece of software, you are making a statement about it. For example, there’s a commonly held perception that anything below version 1.0 is considered as being in the experimental stage, it’s a moving target (and API), and something you’ll most likely want to avoid in production. A 1.0 release is worth considering, but it still doesn’t convey a sense of trust. This take on version number is ultimately silly, right? Well, that’s because humans by their very nature are silly at times. People often make emotionally guided decisions, not necessarily rational ones.

1.9 was a terrible choice for several reasons. Within the Ruby community (and it’s not the only one that operates like this) odd numbered releases are considered to be development releases. For a very long time, the plan was to have 1.9 be a development release, while work was underway on Ruby 2.0. This may have taken too long though as the plan was altered. Ruby 1.9, with all its drastic changes, is now the stable, official version. The decision to go this route caused confusion for many people and failed to convey the importance and newness of this release.

If Matz manages to release a 2.0 version within the next two years, I can guarantee you that people would rather jump directly to 2.0 (from 1.8) than pass through the gates of 1.9 – even if all he’s done is add a couple of new/improved features. All you have to do is call it 2.0, and people will run, not walk, towards the possibility of dropping Ruby 1.8.x faster than yesterday’s newspaper.

In my opinion, the right thing to do would have been to call this release 2.0, get most of the community to switch to YARV and the language’s new features, and then incrementally develop and bake-in additional features for the next version. Ruby is no longer the project that only a few people cared about back in the 90s; it’s now a major player in the programming language arena. As such it’s understandable if things don’t take ten years to move from one version to another. And keep in mind, this is just a arbitrary version number we’re talking about here.

Calling your open source forum “Beast” may not be the smartest idea either. People who go searching for it, will suddenly realize that they’ve stumbled upon another kind of beast forum entirely, one of the sort that is illegal in many of the 50 states. Similarly, obscure names that are hard to pronounce and communicate will usually end up damaging the growth of your project. As so does having a complicated installation procedure, a getting started guide that makes a lot of assumptions, a crowded and ugly looking site, and so forth.

There are countless other aspects to consider that can improve the appeal and the perceived value of one’s product/project/company. Small adjustments to the way we think about projects and the way we showcase them, can have a huge impact on their success. It’s worth genuinely caring about these details and embracing the possibilities that begin to open up when you make decisions with marketing in the forefront of your mind.