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
There's nothing worse than seeing a new technology, sdk, ide, or ... and when you install the evaluation the first thing you have to do is become and expert with the new tech.
Most successful technologies have made it really easy to download and start trying it out. If I can hook your application into mine in a couple of hours, I'll give it a try -- if it takes two days I won't.
Provide lots of examples and make sure your equivalent of hello world can be up and running in a few minutes work.
This doesn't mean target idiots, I don't need my mom to be able to install and run in 20 minutes but don't make me read the manual to learn that I have to move some directory into my jdk1.3 directory, edit the classpath, copy a jar file into some other directory and then ...
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.
1. No lock-in. Make it easy to switch between tools from rivals, to prove that you care about the developer and want them to try it.
2. Non-crippled evaluation - No time limits, no nags, none of that. If someone sends me software thats crippled, I let them know thats what I think of their software! (Its crippled).
3. Downloadable, or overnight shipping - Dont put artificial limits between me liking the idea of trying it and getting to try it.
4. Unbiased, widespread public reviews of the software. Dont buy reviews. Just hand it out, let em try it and write about it. Stand on the value of the product.
5. Open-source. I prefer open-source software. I *DEEPLY* prefer free(dom) software, but I know thats rare in the commercial sector. At least let me know that the source is well formatted, well designed, and open to contributions from outside your company by opening the source.
6. Standards-compliant. I dont care WHAT the product is, there are standards it should follow. Html editor? You betcha. Perl IDE? Absolutely. Follow standards, and shout about it!
7. Price - Make the price compatible with a developer budget. In other words, super cheap to use at home, and fairly pricey for commercial use. Get me hooked on a product at home, I *will* tell my boss I have to do it to get work done.
8. Freebies - shameful but true, companies that send me cool freebies do get a little bit extra attention, or at least get a look. I'm NOT talking about magazines. Think toys. Think polo (business) shirts. Think posters.
9. "The spokesman effect" - Ensure that your company has good spokesmen. Whether in sales, in service, on the phone, or even corporate spokemen.
10. BABES - I love booth babes.
GPL'd web-based tradewars themed space game
Many of us developers cannot stand it when we see something like, "Our new tool X allows one to use the new Foo paradigm to its fullest. Everybody knows that Foo increases productivity and does the dishes, so we introduced X to help you tap into the benefits of Foo".
It would be less irrating to see, "Our new tool X helps one get the best out of the Foo paradigm. If your shop is into Foo, then we invite you to look at X."
Brochures alone are not going to work well on true geeks. We have to see the details. We want to see the API's, code examples, time-limit demos, etc. Vague bragging will just make us click elsewhere because there are too many fluff artists already floating around. If we want fluff, then there are already places to get the fluffiest of fluff.
Table-ized A.I.
Free T-Shirts and useless toys to sit on your desk
:-P
You mean they are handing out Windows XP?
Table-ized A.I.
Keep customers informed about your product. Allow customers to inform each other. Give customers space and tools to work together. Give customers (indirect) access to developers and vice-versa.
Document everything you can. What you don't explicitly document provide good search tools for (those user-forums quickly build up lots of valuable information.) Code samples, vendors, release notes, manual corrections - get it all out there.
Let folks know your product development roadmap. If it changes let them know that too. Make it clear when & where you're willing to collaborate on development. Makes sure prices & licenses are fair and reasonable.
Make technical support a priority. Hire good competent folks. Give them good tools. Make it possible for issues to move from tier to tier of support easily and efficiently. Never leave a customer stranded. Only collect customer information once in a call (we're in technology admit - how hard is it to hand off a customer record?!)
Finally, watch out for "spin" or "expectations management". Don't treat customers like idiots but consider them as partners (and not like Microsoft considers it's "partners".) Teat folks well and they'll remember it; screw 'em and you'll pay, if not now eventually (look at CA.)
Developer specific? Get lots of code samples out: Real ones, useful ones, ones that show off your product. Don't have ridiculous requirements. Give folks a really low-cost way of checking out your product before committing.
I don't read ACs: If a post isn't worth so much as a nom de plume to its author then I wont bother either.
In different words, as a developer, I view "developer programs" with great suspicion. I don't want to be hooked to some company's product. If you deliver a good implementation of a public standard, I may recommend licensing it for our products. If it's some proprietary tool or non-standard API, forget it.
They are also quite open with the specs, Palm provides/helps with free tools (GCC) to compile. This helps the student/hobbiest not feel guilty about spending hundreds for development tools that they haven't used as much as they thought they would.
Looking for any old 8-bit Heathkit/Zenith software/hardware - http://heathkit.garlanger.com
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."
Nobody wants to pay $500 just to find out whether or not something works. If you want the maximum number of developers developing for your platform: 1) Give the SDK away for free or at cost of media.IBM killed OS/2 by charging $2500 for the SDK. Developer relations is NOT a profit center. 2) Support the developers. Give them a forum for questions, emails with tips, etc. Don't charge $3000/year for developer support (MSDN) like Micro$soft does. And don't charge $200/hour to people trying to report a bug like Novell. 3) Make sure the product works before you ship it. If they find problems with the preview release, they're not even going to bother looking at the production release.
"Freedom means freedom for everybody" -- Dick Cheney
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!
Don't forget that he has to be able to dance in front of the crowd!
GMD
watch this
1. Avoid strong ideological statements in your marketing ("We believe OSS is the wave of the future", "Free software forever"). I don't care about your politics, I want to know technical details about what your software does and how it will benefit me.
2. Be realistic in your marketing jargon - if it will improve produtivity, don't beat me about the head and shoulders with it, just say so and provide concrete reasons why.
3. Copious examples.
4. Reasonable price - I'll pay for something if I don't feel like I'm getting ripped off for something that is only used occasionally.
5. Multi-platform is nice (if possible), with equal levels of support.
6. Good technical documentation - consider having a third-party writer for this. The third-party books are usually much better than the company documentation for real world use.
7. Printed documentation. It's always a good idea to kill a few trees for our convenience. It shows you love us. (Seriously, a detailed reference manual is a good thing).
8. Download on purchase, and ship a CD later.
9. Good illustrations (if necessary). Sometimes a picture does say a thousand words, especially if it clears up a really wierd conceptual knot.
There's probably more, but that's all for now. Thanks for asking.
To celebrate the occasion of my 1000th post, I will post no more forever on Slashdot. Goodbye.
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.
4. ???
5. Profit!
I doubt, therefore I may be.
Not to mention they provide great drivers for both Windows and Linux. There is a CVS repository you can download other great stuff from. They support open standards such as OpenGL (we won't mention the whole Cg fiasco...I mean nothing).
Now compare that to the competition.
Disclaimer: I do not work for nVidia, nor own any stock.
Well,
....
above this thread is the thread about the new wireless option for the Zaurus.
When the Zaurus came out I was keen to get one as fast and soon as possible.
The price was not that high and they offred a developers discount and free training for the development environgment and/or OS.
However: they put me imediatly on a "hey he is german, lets forward him to our german department contact list".
Unfortunatly the german version of the Zaurus is about 30% more expensive, came at least 3 month later into the developers program and I lost intererst.
Most disappointing: they did not even let me buy the american version.
We do not deliver to europe
Sorry folks, no one can get here why american products cost us more than we would pay if we buy them on our own and pay the taxes at customs.
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Here's a message a friend of mine wrote a few years back, which I saved. Enjoy.
-Rick
From anonymous Wed Apr 26 00:27:55 1995
Subject: MKS
Date: Wed, 26 Apr 1995 00:36:08 -0500 (CDT)
Postmaster@mks.com,
I do not know the names of the people in your company to whom this note should be addressed, but I can describe them.
* There are 1 or 2 first class, original UNIX programmers who created all the products you actually make money on.
* They no longer are in the mainstream of the company. Perhaps they left. Perhaps they are now consultants. Certainly they can be described as UNIX bigots.
* They are completely pissed off, arrogant, and upset about the current move to the "Source Integrity" product. They feel your current customer base will be disappointed by the Windows orientation, the terrible documentation presented in the "test drive", and the overall poor quality of the product.
* They feel that you should have remained compatible with the GNU "cvs" product, offering a simple, fully functional, easy to use command line interface.
Now I will describe the people who realize they are just foolish UNIX programmers who do not understand the movement to fully complaint MicroSoft technology.
* They are slick, fast talking gentlemen, who have never worked for a small prosperous company.
* They have never produced a product that made money, development, startup and market costs included.
* They do not understand your current products, or the customers who buy them They feel you are serving an odd niche, one soon to disappear in the overwhelming rush of total Microsoft dominance in the market.
* They have identified another, larger, more significant market of Microsoft programmers who will want to buy their products. They perceive these programmers care primarily that the look and feel of these products match Visual C++, and suit a more professional data processing image than the renagade programmer of the past.
* They do not understand the real requirements of the product. They are assisted by a few slightly-better-than-mediocre Microsoft programmers who want to bear Bill Gates children.
* They are proud of their shiny new offering. They don't fully understand why anyone would want it, but they think the term "sandbox" is one of its best features.
* They wear nice clothes, they are charming, and they always go home by 6 pm. They work out in the gym. They use Microsoft email.
Here is my message to the good guys (first category)
I really need cvs for my project. I really do. I talked with your blithering salesperson on the phone, and he told me to try out the test drive. I was enthusiastic. I tried it. Within 15 minutes, I was so mad I could spit. It ruined my entire evening.
I really need that product. I was depending on you guys to have it. And now I am screwed.
My cats use the sandbox. I don't. It smells bad.
Your company survives on its image. Your image is being destroyed.
Your RCS product is destroyed.
These fools destoy your entire company if you let them.
They will claim you are in a declining market. They will cut back promoting the stuff that continues to sell, claiming it must finance new products. The new products will be ill conceived. Because they do not understand the customer, and they do not have your support, they will attempt to discredit you. They will bring in Microsoft lovers they claim are experts.
Together, they and their experts, like the blind leading the blind will lead your company to the abyss. When their products fail, they will claim it was insufficient development funds or promotion funds that killed it, even though they spent far more money on this trash than you ever spent on the products that succeeded. They will cut back your products even further to finance the madness.
In the end, when it is clear to them that the company is faltering, they will leave, shiny resumes in hand, claiming success for the products they tried to kill. They will never accept blame for the ill-conceived products they tried to create.
They see only image. They cannot create value for it is not within them. They are made of hype, and hype is all they can create.
And when your company is gone, they will move on to destroy another company. They will never accept responsiblity. They will never accept consequences. They will polish resumes instead. They will have lunch.
I have been there. I have watched these idiots destroy my company, as they are destroying yours. If you still have the power to fire them, fire them. If you can't, its too late to fix the problem. Quit and never look back. Your company was destoryed by terrorists. Be grateful you survived. Tomorrow is another day.
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>