Slashdot Mirror
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?'"
is to use beer and naked chicks.
Yep.
Other than that... having a *good* toolset would help.
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.
Where's my lobbyist? Right here.
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!
Lenny Primak PP-ASEL-IA,Heli
Well, that's what most companies seem to think...
- Freed
"Coffee should be black as hell, strong as death, and sweet as love." -Turkish Proverb
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.
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.
email marketing. It works, and developers really appreciate the convenience of receiving email marketing.
Realizing the necessity is a great first start. Building a community of users is critical. Without knowing what your product or target audience is, I'd suggest making a strong developers release available for free - you can require registration for activiation, however. Next post as many good, *useful* examples of using your product for people to download. This combined with good documentation and tech support will build a loyal customer base which is worth an enourmous amount of money to a company. Some examples of good communities I've seen are the old Team Borland (circa 1990) where both Borland employees and capable users provided online advice/assistance for their products. The TeamB volunteers received free products/support and each year were actually flown out to the developers conference for free. Another good example in the embedded field is the AVRfreaks ( http://www.avrfreaks.net ) which is a support community for the ATMel AVR embedded processors. I don't know if the site is company sponsored or not but the resources there are great and there's obviously a lot of user-community participation. People looking to decide on whether to use an AVR chip or someone elses will feel a lot more secure choosing AVR thanx to the content of this site and multiple examples of real world usage of their products here. Its a competitive advantage you won't find listed in a checkbox in a trade rag review (perhaps they should) but real-world developers appreciate this more than most things a company actually pays for (like expensive ad-slick campaigns) - it shows they can actually get things done with your product and avoids vapor-promises.
Good luck!
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.
Power Corrupts,Absolute Power Corrupts Absolutely, leaving one person(group)in charge is absolutely corrupt.
- Your web site should contain actual technical information, not just so-called "white papers" extolling your virtues. Put your full manuals online for potential buyers to read.
- Don't bother sending nontechnical salespeople. We don't speak the same language and just annoy each other.
- Have a fully functional demo version for developers to try free.
- Give out a few free copies to prominent developers for review.
...just make ads that disparage lawyers, Apple Computer, the government, Star Wars: Episode 1, and forego proper grammar and spelling.
:P
Luv, Bill
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.
IntegrationShow 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.
SamplesProvide 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.
You have developers in-house.
.NET advertising?), no amount of advertising can sway developers. We're not teenage girls and you're not selling shoes.
Let them connect with developers outside the company.
(via blogs, mailing list, forums)
Don't censor them.
No email.
A very good online help system (wiki maybe) with feedback.
Good documentation. Document everything, including bugs, including stuff you're not sure about.
Work with O'Reilly to have one of your devs write a book on your system.
Involve outside developers in the design process, taking their feedback. Check out the gaming industry's record on that.
Make a complete toolkit available for free for "training and development"
Don't advertise in magazines. It's useless (see how far MS got with
Make your company web site HTML4 or XHTML compliant, with accessibility in mind. Make it easy to navigate. Make it fast (limit dynamic pages please). Keep links forever. Don't go rearranging subdirectories every five days. Developers like good links (http://www.company.com/support/article001.html) and developers use Bookmarks (or Favorites ATCMB).
Oh, and no registration on your web site. There will be no teenage girls or corporate executives in the API Reference section in your site. I don't want to give you my name, email, address, phone and sexual preference just to download a zip file.
If you want to mail something out, then rethink that. Developers live on the net. If it's not on the net, we don't want it. (Sun sent me cubicle stuff once. I now trash all mail from them immediately, without looking at it.)
Oh, and the documentation should be in:
HTML downloadable.
HTML browsable.
PDF for printing. (make sure the margins are wide enough to hole punch the paper)
"Piter, too, is dead."
Shhhhh! Man!
It's true that t-shirts and toys don't sell didley-squat, but don't tell everyone.
Without those free t-shirts I might have to do laundry once in a while.
And without the toys on my desk I might have to do work!
So mums the word.
Sweat
It breaks my pluginses, my precious!
Also, publish examples, a lot of examples, and nice examples too
How about this, to distinguish yourself from every other tool vendor: publish examples that don't have bloody big bugs in them that cause you to lose a days work trying to track them down!
This means when you update the API, you should update the examples so that they work, they use the recommended API, and they are following general good coding practice. Don't fob off writing examples onto someone who
</rant>