HOWTO Go About Marketing to Developers?

byrnereese asks: "My company has finally realized that one of the keys to our success will be to create a strong developer program (IBM's Developer Works, and Palm's PalmSource come to mind as examples). It just so happens that I have been appointed to lead this program. Now I have a lot of my own ideas, but I wanted to ask a large developer community directly the one question I know I am going to have to articulate a coherent answer to at some point: 'What is the most effective way to market a toolset, or development platform, to a developer in order to encourage them to build products using your product, without turning them off at the same time?'"

Comments

Make it friendly

[nate1138]

Just focus on the advantages you have over your competition. Unlike many markets, yours isn't full of people that can't tie their shoes. These are the folks building the products and systems people depend on. Many of them are even responsible for making decisions about large technology puchases for their own companies. So basically, don't lie to them, don't overcommit, and simply show why your option is best. Also, having reasonable terms of use is helpful. Nobody I know likes to be told how to use a product that they just paid for.

Don't push, Design, Describe & Publish

[lprimak]

The subject says it all. Don't push your thing onto developers. Just publish it. If it's any good, people will use it. Sourceforge.net is one place to do it. Design your tool in an OO and component-oriented way, so people can mix-and-match your tool with others they are used to. The biggest mistake you can make is to develop a monolithic "infrastructure" that can't be used interchangably with other pieces and is required for all further development. Noone is going to use that. Publish small components, each of which do a single job really, really well, and then integrate them in a component-oriented fashion. Good Luck!

Free T-Shirts and useless toys to sit on your desk

[iforgotmyfirstlogon]

Well, that's what most companies seem to think...

- Freed

Don't lock them in

[Myshkin]

One of the most important things that I look at is how locked in to a particular product will I be if I use it extensivelly. This means:

1) If there are standards, support them.
2) If there are file formats, document them.
3) If there are APIs, expose them.
4) If you discontinue support, open source the code.
5) If the company goes belly up, open source everything.

Re:Don't lock them in

[2Bits]

2) If there are file formats, document them.
3) If there are APIs, expose them.


This is especially important. Good documentation is the best you can offer to developpers. Ok, most of them won't read, but eventually they will, and they expect good docs to be available, when they need it.

Also, publish examples, a lot of examples, and nice examples too. Publish advanced tricks to do things with your tools. The worst thing I hate about some vendors is, they try to keep everything secret, and hope that you will pay $3K for a 2-day introduction /concept training, then another $3K for first level training, another $3K for second level training, and so on.

As soon as I find out this, I don't use their products, period.

Last, and not the least, make your knowledge database searchable on the web, and accessible to everyone, including people who have not paid for the license (yet).

i don't think it's possible

[cballowe]

I pick my tools based on what works, not based on the marketing. I listen to other developers, check news groups and web commentary, and eventually pick the right tool for the job.

The better the tool, the faster word will spread but it's gotta be a significantly better tool for its intended purpose than what developers are already comfortable with otherwise they'll have no reason to switch. Picking up a new tool requires a temporary drop in productivity - the only way to offset this is to have it be much easier to work with in the long run.

Free is good, not not required.

[haplo21112]

Honestly if you want me to use your tools:
1. Good! no Excellent documentation is a must, if I can't figure out at least the basics of how to use the product in about 5 minutes...I don't have time for it...I'll move on to the next guy or just use what I already have...
a.) Lots of code examples, and documnent everything, assume nothing...
2. Stright forward use.
3. have people that have a clue ready to answer my questions if I am still lost.

Relevance, Integration, Samples

[brio-dude]

Relevance

Show how your product solves problems that developers face when implementing their solutions. Describe how the product works in terms of how a developer sees it. At the same time, describe how it works in terms of the business benefit it provides since the developers will probably influence their manager to purchase the product. Perhaps issue an evaluation guide for developers, and one for their managers.

Integration

Show how your product integrates with programming languages, dev tools, and platforms. Focusing on productivity gains, for example, that result from using the product can help developers and their managers make more informed choices - it also gives your product a tangible result (cost savings) that just about anyone can appreciate.

Samples

Provide lots and lots of samples - Samples for really simple things and samples of complete, working systems. A lot of a developers' product's success lies in its samples since the samples can be easily modified and integrated into an application, or in some cases, used as the basis of a new application.

Tried and true method of brainwashing developers

[guttentag]

1. Lock the developers in a large auditorium.
2. Hire a fat, bald man to charge onto the stage and chant "DEVELOPERS, DEVELOPERS, DEVELOPERS" nonstop for 20 minutes, or until one of the following occurs:
   • he collapses from exhaustion
   • the pulsing vein in this temple bursts
3. Introduce your product/service/ideology.