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?'"
FREE, As in Beer, as in give it away. Charge for support, instead...
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
1. Advertise it on slashdot 2. Call the thing "IT" 3. Tell us NOTHING about "IT" 4. Plant the idea of "IT" in the media 5. Start widespread media speculation that "IT" is the answer to everything
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.
First off: getting on the front page of /. is a good start.
Second, though it may not be popular around here: don't release the toolkit under the GPL. I'm assuming you'll want corporate developers building add-on's and whatnot for you, and Corporate America is terrified of the GPL.
The BSD license takes out the scary bits, but probably isn't a good choice either: my strong suspicion is that most corporate legal departments aren't savvy enough to note the difference, and would likely recommend steering clear of any such 'viral license' (as defined by Microsoft FUD)
nothing gets my attention like freebies. Even if it is cubicle trash, it will get me long enough to look at your product. That is what counts. Email is a NO NO, the spam content going thru the roof ensures that I delete ANYTHING I don't recognize immediately and if I have to take the time to filter it personally I am gonna be annoyed.
errr....umm...*whooosh* *whoosh* Is this thing on ?
I would suggest being very open and helpful to developers, they are more likely to stay with you if they are happy and want to do more.
Community is a good way to expand pr - have some forums and let the developers make their voice heard,
you will be greatly rewarded...
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.
This is the tool I swear by, and would actually pay some money if required.
IBM released this 40 million dollar project for free, and I believe it got to market just by a word of mouth mostly, and being free. This IDE does the job right, now other Java IDE comes even close. It is fast, great interface, and people behind it really listened to all the IDE complaints and tried fixing most of them.
http://dtum.livejournal.com
Just hire super models for your sales team.
"...but I wanted to ask a large developer community directly..."
So are you asking us to help you locate a devloper community?
Second would be producting a GPL'd version and retaining the copyrights so it can be reused in non-open-source sales. Also selling non-GPL'd source code could be a nice side line.
M0571y H@rml355.
I'm twenty times more likely to like something when they give away an SDK for some type of use, along with lots of example code. It's a good-faith effort. Even when I'm prepared to buy the stuff or whatever for work, I like when it looks like a company is trying that hard to curry favour with developers, isn't asking you to buy something just to see how it works, and so on. Free examples, free dev tools, like Apple, Palm, handspring, IBM...even X10.com.
NOT like all the companies that make cable boxes, Microsoft, nintendo, sega, Sony...
Seriously. Nobody is a bigger pain than a developer (I say this as a developer). If you do, count on considerable support costs up front.
Roving Web-Teleoperated Robot
email marketing. It works, and developers really appreciate the convenience of receiving email marketing.
Exactly how much do believe in what your company is doing? The most effective way to market a toolset is atleast not to introduce your company as a collection of morons who do not realize anything.
Find the dumbest high ranking pile of crap you can find, show him a shiney brochure.
He will slobber all over his checkbook, won't be able to pay you fast enough!
It's all about the shiney brochure people!
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.
Really, the biggest thing I need to know is of its existence. Then get a limited piece into my hands. I know many people have a development edition for free, only charging for deployed versions.
For the developer program itself, give me good info that keeps me coming back to the website. Have source code showing examples of less-used features. Have a support database with the most common errors using the tools. Give me a chance on finding the answer myself.
Marketing to TV viewers or AOL lusers is a totally different beast than marketing to developers. Save the bullshit and fluff for the morons who will believe it. You can't bullshit a bunch of developers. If your product sucks they will know it! If it has problems -- admit it or else you risk a public humiliation. Let the developers come up with their own uses for your product! Don't lock the developers into your way of doing something (remember the CueCat ???).
If you sell a good product or a real value-added service than you will suceed. But, developers can root-out bullshit a mile away!
- 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
Easy: Developers listen to developers. If you can find a way to pitch such that the message is backed up by some normal run-of-the-mill geeks, I think thats one key. There's no advertising like word of mouth, so messages should play off word of mouth and basically a demonstrated base of support from the developer community.
Specs and competative differentiators were ruined long ago by the hyperbole in IT advertising, so those kinds of angles arn't usually so compelling to developers. We like what other developers like, so if you can play off that, that'd be a plus.
Also, I think developers often look at new products as inventions or software that was just sitting around waiting for somebody to invent them. Companies that act like they are technical gods are a turn off for me; much better to have a company that sells its ability to interact and co-operate with the development world rather than a company that acts like developers should worship them for discovering the 'holy grail' of whatever technology you are selling. We can see past superficial bull, so just act like the girl next door that knows shes nothing all that special, but that she wants to play and have some fun with *us*, and we'll be all over you.
"Old man yells at systemd"
They might have a "portal" for developers, but the stuff I need isn't there. Want to make "friends" with developers? How about full (NOT SANITIZED!) Q&A database from the programmers and one that is searchable. Also make it easy for the programmers to enter a new issue. Everything else is secondary!
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 ...
Add functionality and features, but NEVER make it difficult or tedious for the developer to get to the raw code. If your IDE allows you to stick Widget X on the screen, give the developer a very concise, direct way to mess with the true source code of Widget X. That's the biggest gripe I hear when it comes to those super-helpful IDE's.
.... um, i lost you after "0110100001101001".
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
There are many good suggestions in previous posts such as well documented API's, source code, examples, good help files, good support, direct contact with your developers, servers to use (such as the strong arm servers compaq opens to developers to write for that processor/platform)
.Net applications. That article shed some light on Mono and cast aside the FUD that propogates when you have a void of information. If people don't know your position on the advantages of your platform then they will assume things.
One suggestion - I've noticed that platform creators like to write about their sdks in trade magazines, on websites, and newsgroups about the details of their sdks and why developers should use them. One good example is Miguel De Icaza and the Mono project. He wrote in detail about it in Dr Dobbs about the technical merits of using the Mono framework on Linux to run
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.
A) Make sure the toolset is really, really good. Developers I know only respect quality - it doesn't matter if a tool is free, if it's flawed in any way people won't like using it, even if mandated by management. This will cost you a lot future sales :)
B) Charge a reasonable price, and make licenses as flexible as possible (i.e., floating licenses).
C) Back to being good - quality support is a must!
I was recently told by a support person "your code is wrong" and got a man-page quote as a reply for something that was clearly a bug in the tool. Needless to say, I will never recommend that product to anyone again - especially because it has a very high price!
If you are Microsoft you are able to 1) omit any and all simple, clear, one-feature examples from any docs of classes in your framework, 2) give really complicated examples showing several features all at once off in some corner which is not hyperlinked to any of the class docs, 3) circularly hyperlink stuff without any complete explanations so your users will go mad, and 4) omit any explanation of what a class is used for in the Overview heading.
A dorito-scented CD in a Pamela Anderson shaped box.
If your bitterest enemies are people who hack the heads off civilians, then I would say you're doing something right.
- Make it easy to find out about your toolset. If at all appropriate, make it easy to download and try out. Provide some good WORKING samples.
- Answer the phone/email. Developers won't call unless there's no other way to solve the problem. We know that phone and email support often sucks, but some times there's no other choice. At least respond.
- When we do need assistance, don't have support personnel treat us like complete idiots. Don't get me wrong, many of us are, but we all think we're geniuses and disabusing us of that notion is bad marketing.
What's a sig?
In 1995 A Microsoft Evengelist said that the Microsoft vision is one PC per person. Of course, when asked how many people had more than one PC, about 90% raised their hands.When asked how many had more than than one PC with them, only a few raised their hands.
Fight Spammers!
1) take a marketing course from Pragmatic Marketing
2) subscribe to newsletters from www.softwaresuccess.com
Free T-Shirts and useless toys to sit on your desk
:-P
You mean they are handing out Windows XP?
Table-ized A.I.
All of these ideas come from your developers using the tools to do development themselves. If you dont like your tools, why will anyone else?
so here are some things that bug me about current sites:
1) REAL WORLD applications built by using your development tools (these should be done internally by your best engineers).
2) The complete API which include:
- the name
- the input parameters (lists of all possible values (if reasonable))
- the output
- when to use this, when NOT to use this.
- a link (or links) to where the api is used in the real application(s) from above.
3) A forum where people can show off the programs they created using your tools.
4) A regular set of columns describing solutions to challenges that the users of your tools are experiencing. (If you eat your own dog food, these should be pretty self-evident, but feedback from your users will go a long way as well)
A good product sells itself, unless ofcourse microsoft has a competing product ...
me
We need more information about your product. Is your product aimed directly at developers (i.e. Kylix), or at the mass market (i.e. Palm). I gather by reading between the lines, it may be mass-market. If it's a mass-market product, you want developers to develop third-party add-ons (aftermarket products). The main way to do this is to show them the money. How many units are you planning to ship in the first 6/12/24 months? Are you going to allow developers to co-market to your customer base? How much will the product cost? This drives how much one can charge for add-ons (never more that the product). All the neat development tools in the world won't draw developers unless you can show them how to make money by writing for your platform. Similarly, if the market is huge, developers will be willing to put up with less-than-optimal tools just to get a piece of the pie. You might also want to consider a forum for third-party developers to learn if somebody's already working on an idea similar to theirs. Of course you should treat your developers to the next release of the platform software well in advance of general availability so they can get their products working with it. Oracle charges a nominal fee to be part of their developer's network to cover the cost of quarterly software updates.
Create good documentation, written by the least technical person you have to hand who can actually understand how to use the thing. The techies who wrote it always assume too much when they document things - get someone else to write the docs.
Include lots of example code. Write a few samples which use your tool/API/whatever to solve non-trivial problems, and include them, with a detailed step-by-step commentary of what they're up to.
Once you've written all this documentation, give it good indexes, and make it freely available on the web. Particularly, make it very easy indeed to find a good, detailed, description of what your product does, and the examples.
Whatever you publish, simply be honest about it. Unlike business folks, knowledgeable developers (who usually drive tech decisions) are good enough to dissern between hype and fact.
Also be willing to listen to the community. Sometimes you will not like what you hear, and you have to put your "open mind" hat and listen for real to such comments and see if maybe you are wrong and what they suggest makes sense.
Another very important issue is support. Who or how will the product/service/technology that you propose be supported? Be very clear about it. Are you in it for the long run or just until you can sell your stock. Will it be a community-supported project, and if yes, what are you doing to get support?
I'd also recommend you publish as much data about the project as you can, but keep it simple and provide tons of examples. Remember that when a developer can easily understand what something is about, he/she is more likely to give it a try. And if upon giving it a try he/she finds out how easy it is to work with it, your chances of having one more developer on you side increase substantially.
Finally, provide as many resources in the form of URLs, sample code, tutorials, white papers, newsgroups, email addresses, etc as you can provide. There's nothing more frustrating that working for several hours and then being dead stuck without any resources to help you out on your problem.
Get a near-monopoly on desktop operating systems, expand into developer tools, and push the competition virually out of the marketplace by making people think they have to use your product. :-)
The same technique works well with web browsers and word processors.
#define sig "Every social system runs on the people's belief in it."
What seems to always work fastest is this:
1) Give away stuff. Free books, free CD's, whatever it takes to get your product out.
2) Make the product affordable. If the competition is selling for $29.95, sell yours for $19.95.
3) Market it to the wrong crowd. Upper management always likes to think they're making some great technical decision, even if they don't know what the hell they're talking about. Look at how many businesses are using Windows servers, because the bosses told their techs that it's what is better.
I've seen countless decisions passed down towards me, which were the direct result of the boss getting some flashy flyer or reading in a magazine about some great product. That's why Microsoft keeps putting out those glossy ads about %99.99999999999 uptime.. The boss will see that, and remember your server going down once for any reason (including power outages), and tell you to switch.
Serious? Seriousness is well above my pay grade.
1. Inflate their egos - adopt the attitude that anyone with any intelligence at all MUST be a developer and anyone in any other profession must be there because they're not smart enough to program.
2. Pander to their fears and insecurities. Project an image that says that you and your product are THE next big thing. Their own fear of obsolescence will drive them to you like lemmings being herded by Disney execs.
3. Lie to their faces, with sincerity and conviction. Tell them that chicks REALLY DO prefer smart guys over football jocks, and your product will prove it.
Bottom line - developers are human (barely) and can be influenced and swayed with pretty trinkets like any other group. Good Luck!
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.
Those work well...if you have a good product.
Strange women lying in ponds distributing swords is no basis for a system of government.
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.
"My company has finally realized that one of he keys to our success will be to create a strong developer program
....
You mean, as a developer you're going to jump into the already overcrowed field selling developer tools to developers. Sheeeeeeeite, like we don't already have easy ones like ASP and Visual Basic, free ones like Perl and PHP,
How about developer tools for business users, who outnumber programmers by, oh, at least 100 to 1, mebbe 1000 to 1. Bigger market, bunky, and completely without any competition at the moment.
Nobody ever replaced dBase or Paradox, unless you count that execrable Access and FileMakerPro. Gawd, the money to be made selling a web enabled version of dBase.
1) I could see viable, useful products/applications/software built from them.
I can't stress this too much. People are always trying to sell me a platform with nothing on it, and keep getting upset/annoyed that I don't "see the potential". Well, color me jade, but I've seen too many "next big things" turn out to fizzle, so I refuse to be first. *Except* when I know the company really well, and they're interesting in having me help them make the product better.
2) Don't be "buzzword" laden
As other people have referenced, I hate the fancy "new buzzword of the week" systems that try to make the product seem new and exciting. All they accomplish is to make me feel annoyed and uncomfortable.
3) 'Is this for you'?
It would be nice if you had a section on your website that asked a set of germane, intelligent questions about my problems and challenges. At the end it should spit out a rough estimate as to whether this platform/toolset will help me. DO NOT MAKE IT ALWAYS ANSWER YES. WE CAN SEE THROUGH THAT.
4) Long trial period.
I like to kick the tires, and I hate having 30 day evaluations. Given everything else in my day, how am I supposed to figure out if this product is useful or not (especially if you called me) in 30 days. Most especially with your first few potential customers, give them a lot of handholding and patience. Let them get used to having it before you ask them to pay for it.
5) Put up open discussion forums
I think the Cluetrain Manifesto hit it right on the head here - if I can see raw, unadulterated commentary from the rest of the world, I will feel better that if I like the product, I haven't been snookered.
Really - the only way to get my attention is to give me free product, then leave me alone. Assuming the product is a new piece of hardware, UNIX-like operating system (that runs on our environments), or relational database, if you give it to me free as a developer I'll add it to our supported platforms whether we have customers demanding it yet or not, just so I can learn about it. New products need application support to get customers.
On the other hand, if you try to push it further than that, by continuing to stuff marketing material at me, or worse, spamming me (and a pre-existing relationship is not a license to spam - in fact its evidence that you had the opportunity to seek permission), I'll take it off the list.
The difference is that the first (free product) shows you're willing do what it takes to ensure wide support for the product. The second (intrusive push-marketing without genuine consent) shows that you have no idea how to do it, and have no respect for the recipient's time.
This is particularly true of email - while some people might think their time is worth the $0.00 it costs you to send them a spam, the people whose decisions matter value their time much more highly than that, and spamming them is an insult that will have the opposite effect to the one you hoped.
The day of the Uber IDE is upon us. The big players in this new framework market are obviously VS .Net and the excellent Eclipse framework & the extenibility of these (Eclipse in particular) makes them perfect for the potential toolset maker.
They are quickly becoming ubiquitious in the industry. Developers are much more likely to use a tool that seamlessly integrates with a platform they are already familiar and productive with.
They are rich in functionality that would be hard and expensive to duplicate in a roll your own situation. Much more time and development energy could be spent on the actual tools rather on the UI and other necessary periphery required as much of that is already present and easily utilized.
A case in point is RIMs Develeopent Environment for J2ME. THey have developed their own IDE for writing applications for their J2ME offerring that no developer in their right mind would want to use (slow and not too pretty!). Their time would have been much better spent in making tools that plug nicely into something that resembles an enterprise IDE, rather than waste their enrgies on unnecessary wheel reinvention and poorly at that!
../../
.NET.
You got to have drug dealer mentality, sort of life M$. First you give away free samples then you concoct cockamamie story about how your product will revolutionize the world as we see it. This should get the attention IT managers. Once you have enough clients hooked, you role out a new license plan, again, sort of like M$. You must also have a catchy name, you know, something like
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."
Nothing gets me more excited than a free t-shirt.
Then I get to retire one of my current ones (the one with the most holes goes!)
That means that working tools need to be free, and there can't be any NDAs to sign. I have to be able to see my Hello program running, without paying anyone or making any promises.
Palm is an outstanding example. The only thing I didn't like was that I had to sign up to download ROMs for the emulator, but I had already seen my program run on a real unit by then, so it was ok, since I was past the initial hook.
Online browsable or downloadable APIs for free, are good. Being able to use existing tools that everyone has sitting around, like gcc, is good.
Header files and fundamental link libraries, must be free. Don't even think for a second, of treating them as a revenue source. Every dollar you make was at the cost of ten (number pulled from ass) programmers saying, "Screw it, too much effort."
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
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
NO SECRECY!
Developers like to figure out how things work. Then we like to brag about it.
Make sure enough of the API is open. The more the merrier. And make sure that no legal restrictions hamper our tinkering. If anything, support forums that encourage discovery and tinkering related to your developers' program.
You can break every other rule, but if you break the NO SECRECY rule your developers' program will always be second rate.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
I tried the demonstration edition of the Blitz Basic 2D programming language, which allows you full access to all of the features except compile-to-executable, and now I'm hooked. Some of the things that hooked me: 1: Free download of operational software. I'm able to develop using the demo, if I want to distribute, I have to purchase. 2: Active support. The programmer behind BlitzBasic 2D is constantly at work on the project, making it better, and he listens to and replies to feature-requests. If there was a bug, he actually worked at fixing it, and sometimes patches or fixes were up within a week or two of reporting them. That is awesome. 3: If I want to buy Blitz Basic 2D, it is not too expensive (~50USD). 4: A great user forum. Of course, nothing makes a great user forum but users, but if you make an "official forum", they will come. Things not to do: 1: Break the software. Blitz Basic 3D is limited to 30 uses. I never even downloaded that program, for that reason only. 2: Give customers shoddy or no support. I develop in a language called Visual Dataflex that has the worst documentation of any development system I've worked with (a lot!). It really ticks me off. 3: Lock up the forums. Blitz 2Ds forums were open to developers who had not purchased the software for quite a while, but were limited to only registered users after about 8 months. That was *almost* enough to make me quit Blitz altogether (if weren't such a good product by itself, I would have).
my sig was dubm so i took it out.
I've worked in many companies and seen these types of developer marketing initiatives fail because the marketing group was too distant from the very developers engineering the product. Make sure to take time to relate to the people actually building the product, for they've got the most insight and experience with how to use it, and what you can do with it.
Make sure to spend ample time with your company's engineers at Harrington's, Attitude's, and other local bars, to not only pick their brains, but to build with them a strong repoir so if you ever need to count on them for a solution or a fix or a quick HOW-TO guide, they'll be there for you. You may also want to improve your SSX Tricky skills and contribute to the white board every so often.
Dr. Evil
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!
Let's face it, developers are there to use whatever toolset management wants them to, and to shut up whinging. If they don't like it, they can go work elsewhere.
If you provide decent free tools or documentation (like HOWTO's or samples) for developers to easily get started you are more likely to get people to take a look at what your product can do and try out different things. Once they have started and are interested then they will be looking for more advanced materials and resources. You also get the advantage of having more developers familiar with your product(s)
IMVHO, if you're marketing to developers, i'd suggest approaching it with a B2B service mindset. in the eyes of your customers, you're there to help them make their job easier - and like a consultant, you should emphasize how your product can let them be successful in their job. which makes for peculiar constraints.
:)
- their business depends on the performance of your product. the more they know about it, and the more familiar they are with it, the more likely they will be to evaluate it fairly. also, trust is worth its weight in gold.
- developers are likely to do a thorough comparison of your product with your competition. make sure to provide enough data points to convince then that your product is the best fit for their needs.
- developers like to try before they buy, especially with something as idiosyncratically personal as development tools. give opportunity to test the product's performance in a real-world situation. (vmware's excellent 30-day license comes to mind).
- pamper your developers. do all the things you (as a developer) like in a piece of infrastructure, and that rarely appear in low-quality (or open source) products. easy to use tools, clean and powerful APIs, great debugging and tuning facilities, extensive documentation with examples all go a long way towards convincing somebody to pay extra for a particular product.
as i'm sure you recognize, customer relations are extremely important to anyone in a b2b situation. microsoft is especially good at this, and worth studying in great detail. they pamper but also respect their developers, teach them how to use their system, and go to great lengths to show them how they can make their lives easier by using their products. because in the end, your customers will look to you as someone who makes it possible for them to do their job. and that's the basis of a good business relationship.
My other car is a cons.
Don't forget that he has to be able to dance in front of the crowd!
GMD
watch this
One thing I look for is a mature API - I want to know that if you upgrade your tools, I don't have to choose between an old unsupported version or a complete rewrite. It means putting a lot of thought into future directions when you write your initial API. It will of course change when you add more stuff in the future, but if I see something that completely changes its APIs between two minor releases, chances are I'll find something else.
I should be able to determine what your product is, and why I need it within 5 minutes of being on your website. Don't tell me what it's going to do -for- me, tell me what it really does, and I'd wager the person to best provide the verbage for something like that is going to be a tech that help develop it. Don't tell me it's going to increase my productivity by 50%, or provide a scalable architecture for me to build my applications on... tell me how it's built. I'll know whether or not it's right for me.
Clipper (compiled dBase for the drooling masturbators) ran about $800, the tools to go with it were another $2000, toss in a couple magazines, we're talking real cash flow for a publisher. PdoxDos was just as expensive, nobody hesitated spending for these tools.
I'd like to get my hands on the old mailing lists for all those tools, at least 25% of the addresses would have to still be good.
Why do all the publishers boycott the end-user developer market. Hell, we got money, that's the market Microsoft goes after, they don't do too shabby. Do you think we use Visual Basic because we like it?
Do what everyone else does, market to their bosses, to VPs, purchasing depts, etc. The developers don't have purchasing authority anyway; you don't have to convince them unless you're giving your tool away, and if you're giving your tool away you aren't likely to make money at it anyway.
is competition good, or is duplication of effort bad?
If you have just been appointed to lead this project, as you say, I would have thought the more important question would be: how should I design the toolkit so that it will be the most effective? (that is, easy to install, easy to get started, flexible, powerful, etc....) What are common problems other people have had with embedded system devkits?
1) Make it easy to install.. I want to get it install and running in under 15 min.
2) document everything.. provide good examples from the basic Hello world to the most advanced.
3) Do NOT EMAIL me about it. My inbox is sacred.
Don't force people to "register" or "join" some "community" to access your stuff. Otherwise they will feel that instead of offering something valuable to them, you're just trying to mine them for personal data in endless web forms. (In which they are going to lie enyway).
Did I mention that I have never read an article on nytimes.com (free reg req, blahblah)?
I'm not convinced until I see it running thus the fast path to a purchase is an easy to set up demo. Specifically that means a simple download and online registry.
Furthermore, your licensing needs to be simple and work. At a previous employer we never got the license server for Purify to work on our newish 64-bit platform though Purify itself worked fine. I've seen contracts cancelled over inflexible and broken license servers.
yours, DJ
He wants to make some money, you large bearded idiot.
1 - Make it cheap. $99 will get you a lot of customers, Free will get you a lot of customers. There will be a lot of overlap in those customers, but a lot less than you think. Almost every developer will be able to afford $99, it is enough that it can come out of a workers weekly allowance without too much trouble, yet it is not too cheap that someone will drop it if it is too hard to use. If you really want to sell it for more, make a $99 version that has a lot of the features (not all, but enough to show it is a worthwile tool). I cannot get the boss to buy a $3k tool, it takes 6 months of paperwork to do so. I can and have opened my wallet and charged $99 tools, many became shelfware, but it was low enough that I did not feel screwed shelling out my bucks.
2 - Lots of code samples. MSDN and IBM DeveloperWorks are like that. Maybe the code has lousy comments, but enough that someone can look at it and see a use that you may not have. Lots of MSDN samples get used for prototypes in my shop.
3 - Good web access. Nothing worse that trying to look up API_call_839901232434 and being unable to find it. Or taking half an hour to find it.
4 - Leave out the booth babes. We want to write code. If we wanted to fantasize about booth babes, we would be looking somewhere else.
5 - Leave out the content free marketing. MS should do that. Instead of showing what I can make with your development tools, they show me some guy with his feet up on a table, or some orange page with buzzwords.
6 - Why should I use your tool rather than another one? Answers please. Logical ones, not the crap marketing departments love to put together.
7 - Consistant help files. MSDN loses here. I keep the MSDN library disks going back to 1994. Much gets omitted intentionally from the documentation when they want you to use some new api call that exists only in WinXP rather than some decent version that was there in Win32 for the last 7 years.
8 - Licensing games. Sure you can make some nitziffic licensing scheme that guarantees that every installation is a paid installation, but you forget developers tend to have 3-8 machines at any given time. Several at work, several at home, and 1 or more being built at any given time. Don't play license cop. If folks are going to pay, let them. If folks want to use one copy for several machines, don't stop them. If you try to stop them, you will lose. You want evengelists for your tool, not folks in straightjackets.
9 - T-shirts and toys. Forget them. When I get them, I toss them. I won't wear a t-shirt, and my life is too cluttered for tchotchkies.
Don't lie about its capabilities and sell a buggy .0 release, and then charge for the bugfixes. Borlund hosed me years ago, I don't give a rat's ass how good their stuff is, it'll never get used in my shop. Ever.
Valve enabled the ability for the end-users to make their own mod(ification)s to the product Half-Life.
It was free, and now the most popular game on-line is one of those mods.
So make it free and be nice to those that take the effort to make the community. Things can happen as Counter-Strike shows.
Are you from Microsoft?
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.
First, make your tools compatible with Emacs. :)
Seriously, I don't use most 3rd party tools because they don't let me use my favorite text editor. By combining a bad text editor with development tools and making it hard to use an external editor (most IDEs), you're going to alienate many developers. Development tools need to integrate into my workflow easily and not get in the way. My editor is a big part of my workflow, don't make me change it. The only exception is for tools that are just too useful. I'll suffer a bit, but the payoff needs to be large.
TogetherSoft is the only development tool company I can think of that really succeeds here. I've use Together for Java, C++ and Python development and always coded in Emacs. Everything in the model updates as you expect it to.
Development tools also need to be easy to use. And by this I don't mean saying they're easy to use in the marketing packet. Do some usability studies and make sure they're easy to use! If I have to spend more than an hour figuring out a new tool, odds are its not worth it. Of course, there are exceptions here for very useful tools (odds are yours does not fit this category).
Finally (and most importantly), tell the truth!!! If your marketing info makes a claim, it better be true. As soon as I hit the first false claim when trying out a tool, I stop using it. It's not worth my time to figure out what is fluff and what is real.
Get these right and you won't need clever marketing to get to me.
-Chris
Ads on slashdot, I hear they are cheap now, if you want a significant developer base to see them, this might not be a bad way, I occasionally click on them.
Degaussing scares the bad magnetism out of the monitor and fills it with good karma.
Forget IDE's. make can't run the IDE and neither can cron. The tool must have a fully functional command line interface!
Also the tool should be fully functional on a UNIX and/or linux platform. NT and 2000 have crippled shells, so production work with third party vendor tools on NT or 2000 boxes is painful.
Give on-site tutorials using Crayola "Washable Whiteboard Markers". You (and they) will soon find that the marks made by these markers do not wash off of whiteboards, even with industrial strength graffitti remover. Your presentation will become permanent advertising right next to the developers' desks. - Dr. "Crayola can bite my shiny metal ass" Evil
Make your products the best choice for the developers, and document that fact, provide good searchable knowledge base access, examples, etc. But your selling needs to focus on the management, who will ultimately decide to go with your system, and force it down the (hopefully not reluctant) throats of the developers.
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.
are sample programs that don't install easily and aren't intuitively obvious (to me, not you) to use. If I can't install a demo version (because it has dependencies that I haven't installed) or if I have to read some opaque manual to figure things out, then I'll move on.
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.
Don't bullshit.
Don't spout vapor.
Don't lie.
Don't make shit up.
Just present your product, not the crap.
"A major one."
Usability testing is important - to make sure that a dumb mistake in any of your user experience doesn't lock people out. Very important, even for a developer program!
Places like Microsoft user test new developer resources and websites etc. You should, too.
would we answer that? who wants to increase the number of companies out there successful at marketing their products to us merely because they know how to market it to us? just point out the strengths of the product, and if that matches the needs of whoever you are peddling it to, they will buy it. if it doesn't meet enough needs, improve the product.
I can think of four things, partly already mentioned:
I'd almost argue that it's useful to provide the developers with a developer community and mailing list too. But that can backfire if you set it up and choose to ignore it.
----- obSig
The biggest thing you can do in the current age of blogs is get your lead developers out into the blog community. This lets people interested in your technology follow the changes minute by minute. Even better if your developers then subscribe to customer's blogs. This creates a great community. One that is especially noticeable on Google.
Your current product line still sucks. Think long-term. All products will become obsolete in time. The key is to create a better feedback loop between marketing your products and getting good comments for future improvements.
- Listen to developers.
- Make sure the developers have everything they need and more.
- Reduce the barriers between your own developers and them.
- Get your sales people into developments.
- Create trust.
Why market to developers? They don't make purchasing decisions. Market to managers. Most of them buy tools for whimsical reasons that you can't predict anyway.
Whatever you do, don't put that nasty M$ line that goes something like "You may not distribute any files created with this program." Whatever the wording was, it sounded like they were claiming the rights to MY creations.
I'd rather write in binary.
TodayTM BillyJoelTM GoogleTMd for StitchTMes due to WindowsTM while RollerbladeTMing with an AppleTM and a PopsicleTM
One thing that really annoys the hell out of me about Palm is just how damn difficult it is to get developer tools working. There are probably people at Palm who thing their developer platform is fantastic because they have free and commercial solutions. But the free solution is a pain to set up. I went to thie developer conference in Sydney last year (I live in Adelaide but was over there for another conference) and they gave out a CD of tools. "Great!" thought I. And it didn't have anything on it I needed.
There's this attitude that because you're working with developers, they'll wade thrugh the nasty murky stuff to get your product to work. No way. I don't have energy to screw around with that crap. When I'm trying out new products it's usually related to work, but something I do in my own time, and I'm there because I want to use the tool, not spend ages setting it up.
With Palm you have to download all sorts of things - prc tools, cygwin (if you're on Windows), the debugging kernel, and other things. This involves a hunt around the net and is a pain because they could just put together a straightforward developer package and save everyone the hassle.
Further, if cygwin is already installed you have to jump through hoops because the tool likes one sort of line ending but not another. Ugh!
Believe with me, my saplings.
This question is a simple marketing survey. Typically, however, marketing surveys that ask "What do you want?" don't actually get you relevant results. Lots of people THINK they want a bunch of particular things, but when presented with them in the final product those specific things often get totally ignored.
Here's a suggestion: Ask "What's pisses you off about certain developer programs? What things, upon noticing them, make you stop dead in your tracks and go somewhere else?"
Then do the opposite.
Once you've made sure you're not going to immediately turn people away, then start picking the best of the "core features" suggested in other posts here.
You're never going to please 100% of the people 100% of the time, but if you start by trying as hard as you can to not DISplease people you're already 50% of the way there.
-= Lunatic
Easy to uninstall. Whether or not I like the demo version, I'm going to want to get rid of it at some point. Test the uninstaller. If it leaves files behind, tell me where. Better yet, don't leave files behind. See installation comments re: InstallShield/RPM. Whatever you do, don't write a frag-grenade installer, make me clean up the mess, and then hope I'll be favorably disposed to your product.
Lose gracefully. If I don't like the product, make sure the sales rep doesn't keep calling back to try and "understand the problem".
A marriage is always made up of two people who are prepared to swear that only the other one snores.
Imprimis, it needs to be good. If it isn't good, and you aren't Microsoft, quit now and cut your losses.
Secundus, make it open source. If it isn't open source, and you aren't Microsoft, quit now and cut your losses.
If it's good, amd open source, and actually solves real problems better than what's already available (not exactly the same as being good), then your challenge is to figure out how to make enough monetary return. Otherwise, your only concern is how much of the VC money you can get away with before Microsoft embraces your revenue stream.
HAHAHAHAHAHAHA! You so funny! HAHAHAHAHAHAHA! You so original! You make me laugh! HAHAHAHAHAHAHAHA! You funny man! I like you jokes! HAHAHAHAHAHAHA! Wow...my sides are hurting with that funny, funny quip you just threw down on us like some clever maniacal funny man! You so funny! HAHAHAHAHAHAHAHAHA! Someone even modded you as funny to show how funny you really are to the rest of us! Quip, quip says you! Everyone! Over here! Look at the funny man! He made a funny about handing out Windows XP! Get it? handing...out...XP! HAHAHAHAHA! It's a reference to XP...yes, how it's a "useless toy". HAHAHAHAHA! Yes, I am not sure where this guy is from but boy is he funny! Who invited him to the party? We gotta have this guy over more often! Honey? Come down here a second and listen to this guy 'tell it like it is' in a really funny way. HAHAHAHAHAHAHAH! Toys and t-shirts, that's priceless. "Handing out Windows XP." Gold. Just pure gold. How do you do it? I mean, so many people post on Slashdot but then you see a funny gem like this. HAHAHAHAHAHAHA! Pure hilarity. When's the last time you actually used Windows XP and so wittily remarked about it? Had you not been using Win98 or ME then this wouldn't actually apply and hence your joke would 'have no teeth' as it were. But the brilliance of you tying in handing out toys with XP had me splitting my sides. HAHAHAHAHAHAHAHA! You funny man. So clever, so very very clever. I'll bet you were the funny man in high school too. Wow. You still got it!
Forget the whales - save the babies.
It partly depends on your business model. There is an enormous difference between, say:
/.-referential sig
1 - giving away a compiler and documenting the API for your handheld unit. You'll make your money on the hardware, and the development tools are part of your marketing. The more widely deployed, the better for you.
2 - the toolkit is supposed to generate revenue. Then you have to convince people of its quality and utility, but without disclosing so much that they don't need you anymore.
Obviously, 2 can be a tough position to be in, depending on the nature of the product.
Note the lack of a
Your favorite
If you want to develop something that will catch on fast... copy PHP's open source style. (php.net)
1. make it useful
2. make it modular
3. make it flexible
PHP is well suited for Object Oriented programming and structural programming.
PHP works on windows and unix
Make the documentation easy to understand
Provide many examples
AND REMEMBER TO HAVE FUN...
Open Source is fun...
Use short sentences...
Make sure it can at least say "Hello World"...
Free Web based FTP
You pointed out developerWorks, but missed the project that really mattered: Eclispe.
When IBM wanted to build a community around the Eclipse IDE, how did they do it? They Open Source'd it of course.
Of course, if your trying to sell a developer environment, than you need to demonstrate to me (someone who listens to no marketing stuff at all) why I will be so much more productive using your environment than Emacs that makes me dump all the time I've invested in Emacs.
You either need a super fast, super standards compliant compiler, or some AI in your editor that's so darn good that it thinks for me. Otherwise, I'm just fine with Emacs thank you.
int func(int a);
func((b += 3, b));
Well you're the last two at least, so its odds on you suck too.
HAND.
Think nothing is impossible? Try slamming a revolving door.
I think it's funny the number of people who say "don't bother marketing, I choose what's best".
/. users are above it (or just in denial), but chances are marketing does work on you, it's just too subtle for you to realise.
Maybe that's true for those posters, and maybe it's not. There is a belief amongst many of us that we are "immune" to marketing and use our superior intellects to make purchasing decisions. I used to think that way, till I studied marketing.
The thing is, I have worked in marketing departments at various times, including groups marketing to developers. You don't spend 6 and 7 digit marketing budgets without measuring the return on the marketing funds. And the marketing campaigns work - they wouldn't keep doing them if they didn't.
For example, I've seen one developer-focused campaign that saw users go from about 3000 to about 8000 in a few months, the only change was marketing, no product changes were made.
Maybe
Next time you are in the supermarket and you choose the toothpaste you have heard of instead of the cheaper brand you've never heard of, congratulations, you're a marketee!
Read reviews of shopping cart software
I can't believe you wasted your time typing all that shit up.
Think nothing is impossible? Try slamming a revolving door.
A product will practically market itself if it meets three criteria:
Assuming your product meets these, you only need to do two things:
Moderator hint: a comment is neither "Flamebait" nor "Troll" if it is true.
You so original!
Mod envy?
Narcotics give you the patience and stupidity to do many things it seems.
"Don't mess with him, he taunts the happy fun ball."
Then create some wanna-be certification scheme so half-assed morons who'd sign their checks "Fruit of the Loom" if their mother didn't stencil their name on their shorts could pretend to be a "Sisteem enGenear".
Then watch those same erstwhile geeks promote your product as much as they can because, even though they aren't smart enough to really do more than reboot the server, they are smart enough to realize that if folks demanded the same level of performance from their computer that they demand from their much-more complex automobile, they'd be back to asking "Do you want fries with that?"
Of course, along the way you piss off the real geeks.
When developing the software think about the process developers go through to get good code out the door. It will help you as well as us. We need documentation readily available, but not in the way.(Having things pop up while I am typing destroys my rhythm.)
If your toolset cuts out the pain and gets me to good code faster, better documented, more bug free; then we can all make more money than the guys using your competitors tools.
The push is in getting a definition of HOW different developers prefer to work. Modules can be a great blessing here.
Don't forget that you are also selling to non-developers. Upper management and/or companies paying the developer may mandate certain toolsets be used.
Get the software into my hands. Don't cripple it. Ideally, don't even put an expiry on it... make it freely available for evaluation and charge for the right to distribute it or use it outside of a development environment. The idea is to let me play with it, get used to using it and see what it can do (whatever it is).
Provide strong support. Microsoft does a really good job of this. The developer documentation for all their products is very good. High quality documentation can reduce the learning curve and make whatever product you're selling more useful more quickly. Make getting at the information easy.
Be truthful about your product. Explain its strong point. Explain its weak point. Explain why you desions for your trade off in your product. Be open and honists about any problems it has. Rember your selling a tool designed for particular jobs. Dont try to push it as a good for everything tool. Sell it for what it is attened to be.
Trust in your product is the most important part in advertising. Assuming that your are not Microsoft you dont have the resources to Bully people into using your product out of fear. Developers are people even most of guys on slashdot. The generally want to feel good about using the product and they want to know that they are using a product that they can trust and they know what it can do.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
The most important characteristic of development tools is that they don't last very long. Those of us who have been around for a while are very leery of closed environments, however convenient. Build your (e.g.) Java application in Magic Environment X, wait 4 months, and you are high and dry. Even if Magic Environment X comes from IBM or Oracle. The big players change strategy about as often as some people change their underwear, and for the same reasons. The smaller players die. Sure, I use things from the IBM site, but you won't catch me committing a development product to Visual Age, sticking me with a ton of proprietary metadata which will break next month. If I can't edit all of it in emacs (in a pinch), I look for some other way. So, if you'd like us to use your stuff, don't play the game of trying to lure us in and trap us. We've been fooled before. Au Contraire, make it really clear just how much effort we are committing in buying into your tool, and just how much trouble we might be in if we need to get back out. The lower those barriers, the likelier that we'll play.
Most development environments seem to be designed, tested, documented, and marketed by people who never think of trying out an application with more than four source files and 100 lines of code. They look cute in a demo, and are completely frustrating and unproductive for volume. In fact, usually they crash and burn. When they don't, they subject you to 'death by 100 dialog boxes.' Like, for example, a debugger which always pops up a query when a particular condition is detected, and no way to tell it to ignore the condition the first 100 times it occurs. Source control systems are particularly prone to this evil. They present very cute GUIs. Then you try to organize a merge of 100 files with them. One file at a time. Hours later ...
I'm not a great fan of Microsoft, but I have to say that, after all these years, Visual Studio very nearly manages to combine a convenient GUI with the gestures requires to productively work on a large scale. Various attempts at GUI-ified debuggers from Sun and HP never made it nearly as far.
All of which adds up to: if you build something that us really useful to pros, pros will use it. Regardless of the volume of attractive nuisance you put on the web or on tradeshows.
Developers are annoying. They Do Stuff. They don't just stick with the superficial, obvious, ways of using your product. When they do, they get into trouble. Things break. Or they get confused. And they call support. And when I call support for a product for a developer, I expect to communicate with a person who has a clue. All too often, I find myself attempting to explain programming 101 to some reverse-telemarketer trained to look for my issue on a list and compensated for making me go away as soon as possible. Of course, best is if your product has really been tested in the corners, and just works. Next to that, your only hope is if the first line support people have the qualifications that consumer software companies reserve for third-line -- if they have them at all. That means people with the training and experience to have actually used your stuff. In other words, your developers. Make your developers work the support line in rotation, and watch your bug-counts drop as they get personal experience in the value of fixing it before they ship it.
You have a blonde in a plaid skirt and kneesocks get between my legs and suck me until I shoot all over her face, I'll tell my fucking boss to buy your shit with his money. That's marketing pal.
This is kind of like the pot calling the kettle black since you ripped off your post from Stewie's tyrade on Family Guy. But it was funny. :)
-Sokie
------
Where are the slash-groupies? I distinctly remember being promised slash-groupies!
One of the best developer resource sites I have ever used is www.php.net for the main fact that information is organized and easily accesible. The documentation and comments are well maintained.
You'll need a shiny brochure for me to show mr. boss, kind of like the bright shiny objects I throw to get him to chase after so I can get back to work. The blonde can give me a brochure after pleasuring me. Yep, a nice brochure with screenshots and buzzwords, just make up anything. It won't matter because I'll still be using Emacs no matter what the dipshit boss buys. I swear to christ, I'd be rich if I had a share of any dogshit stock (Global Crossing, Enron, whatever) everytime my boss sneaks up behind my chair and makes some comment about me (or any other developer) using emacs and not the fucking IDEs he's wasted money on (and tried to shove down our throats in stupid "instruction" sessions). Oh well, enough about Emacs and how it rules, don't forget the glossy brochures. And the blowjobs.
It's probably a fill-in template. Couldn't you tell? Not everyone is as fucked up as you, my dear boy.
Ever heard of closing your tags? Please, stay away from xml you script kiddie.
Let me le tyou know about Espial's experience from a devloper who uses Espial tools..
Espial wanted to get into the mobile dev market having develoeprs use their light gui toolkit, testing tools, and other tools..
What they did is started a developers website knwon as devicetop.com with year coding contests fro prizes in cash, developer boards to echange ideas and code, an application showcase board, and etc.
Whil ethe market is in a current slump Espial has managed to snare top honors with tis innovative java courses in mobile programming(some say better than Sun's own)..
Not only that they have snared some pretty big CE clients using their tools like Sony by using this approach..
By focussing on the developer they were able to sell their set box OS system which is where they make their money..
The important points:
-Make the tool set free
-set up developer boards and contests
-Make contest free to enter!
-Listen to developers
Don't Tread on OpenSource
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.
Developers are extremely fickle about their development environment (I am personally a die-hard vi user).
In order to get developers to use your product, you need to get them to use it and see why your product is better than what they've been using.
A good example of this is the bitkeeper program that Linus adopted for kernel C.F.
Unless you give us the chance to use your product without monetary commitment, we will never use it.
Probably. Im too braindead to think.
Think nothing is impossible? Try slamming a revolving door.
Good technical manuals: WebLogic is expensive, and I wouldn't use it for personal use, but they have great respect IMO for the developer. Their APIs are fully documented in clear, technical language, they have samples for everything useful, and many many FAQs. Their docs are also updated for new releases. I think good docs will make or break a product, unless it's so easy to use that command-line help is enough or it's "intuitive" (like WinZip on Windows)
Straightforward user interface:Even if you have the docs, the truth is I won't read them till I need them. I tend to install the thing and then browse around to see what I can do. If it's an editor, I start typing. If it's a drag and drop GUI builder, I start building. While there's something great about developing your own unique interface and way of looking at the world, at least allow for an "idiot's option" that gets me feeling productive; or, that the tool hasn't gotten in the way of what I'm doing. Kudos to tools like JEdit, for example, which I had up and running and compiling with in maybe an hour. Blahs to APIs like Xerces, which I can use, but which have an absolutely confusing API in some cases (how do you move an Element from one Document to another? where's the changeParent() call?)
Let the FAQs lead the way:A number of others posted that your should publish your knowledge base, but I'd also add that a good FAQ system is a good lead-in for developer interest in your newsgroups. Basically, it will draw people there even if the newsgroups are new. I suspect you'll also spend the early rollout manning the newsgroups yourself. Roll your answers into the FAQs; searching newsgroups is tedious work. The worst thing to find are newsgroups with many, many unanswered threads (like Sun's Java site) and scanty FAQs. JGuru has a very good set of FAQs.
Good luck! Let us all know when it's released.
p!yaya
"I honestly would vote libertarian if their candidates weren't usually total cooks."--slashdot poster
As always, the product should sell itself. If you build it, they will come.
Oh shit! I forgot to click "Post Anonymously"...
1. Lock the students in a large auditorium.
2. Get a big fat,bald, professor with a big beard to charge onto the stage and chant "YOUR ALL WRONG! WRONG! WRONG!" nonstop for 60 minutes, or until one of the following occurs:
- professor screams running out of the room, because students who refused to 'assimilate' were flashing laser pens at his ass
- students start throwing paper airplanes
3. Professor introduces "new paradigms"/"new technology"/"Windows is the future of computing"/"Paladium: Safe sex with software"/"UNIX is dead"
4. Use fancy laptop screen projectors with cheesy powerpoint sounds and animations to make your audience go "ooohh aaaaahhh". And finally...
5. Make sure they are all first year students, as their the most stupid and easiest to suckers to 'assimilate'.
6. Repeat steps 3 and 4 until perfect. Enjoy!
Dave Winer wrote a great article about this, in 1994. Everything holds true today.
Platform is Chinese Household
You're not building a "successful developer program," you're building a platform. The distinction is critical.If your technology doesn't benifit them and their orginazation goals no amount of anything will make them go forward. You sell your technology by convinving them of the value it will create for them or their end users. Once you convince them of the value, then convinve them that the costs are less then the benefit. If there is a enough of a postive spread between cost and benifit they will go ahead. Simple really, just remember the BASICS of what your doing selling.
You have to get a grass-roots word-of-mouth going, by starting with influential developers. Give away copies at tradeshows. Go to a user's group meeting, show your product, and give away a lot of copies (check out Software Development Forum if you're in the bay area). Try to get some prominent or way cool developers/products to use your tools.
Include a broad spread of working examples ranging from `hello world' level through simple demos and games to a few fully working applications. And dual BSD/GPL licence the lot of it.
A big draw for me is having somewhere to start, being able to pick up a working app, however small, and stretch it to fit. The dual licencing is needed to enable both proprietary and OSS development based on those examples. BSD to allow BSDish and proprietary stretching-to-fit and GPL to allow Free stretch-to-fits.
Also, set up a site with stuff like the PERL repository or PHP's PEAR system. Your users will expand your template base for free, benefiting everyone except (possibly) your competition.
Got time? Spend some of it coding or testing
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.
If the product just sucks, it will never end up being used. Period.
If the product is good, it will end up being used.
IBM Developerworks offers excellent information,
not just about their tools but about well,
everything. That's why I like them and read the articles.
However, I've used perhaps just one tool by them.
Their products, tools and such don't suck,
but they've (mostly) the wrong
language for me.
I am always surprised at the good tools/libraries/etc. that must have been used to build actual tools just in order to test them and would actually be really close to what I needed to do but instead I get a huge pile of documentation instead of a couple of WELL thought out non-trivial examples of code that would cover probably a vast majority of the uses for the library.
For example, maybe you have a library that parses some file format or datastream. You could just give me the library and a bunch of documentation or you could give me a makefile and a small app ( nontrivial please but not too complicated. I know that is asking for a lot but you do know the kinds of things that your target customer is really going to want to do don't you? ) that opens up a socket/file reads the data, parses it, does something with it like print out the various parts of it. This is probably all of the documentation that I need as most people only use a small fraction of the functionality of any given tool anyway. I know very few people that go through the documentation, you just don't have time. At most people grep the documentation for the little fragment that they need.
Resist documentation overload.
For advertising, skip the "it will make you more productive"
crap. Tell me why it will make me more productive. And I don't
mean "Enhanced User Interface" what the hell is that? Tell me EXACTLY why.
Make the identicale program free for home use. If someone is going to
pirate your software, it's gonna happen so skip the anti-piracy
annoyances and nags.
Do NOT make a "pro" "corporate" "enterprise" "home" etc version, X program
should be X program, the home users free copy should be able to do
everything the commercial versions do.
Make it free to redistribute (with license text etc.) even by OEM's but
not for profit, they have to give it as a freebie.
NO SPAM, and I mean postal, e-mail, banners, POP-UP's, or commercials during
the superbowl.
Now for the program itself, make sure it's modular and the api's to create modules
are open for home or commercial extension. Document everything, no internal secrets
of the api to give yourself the edge on plug-in's, put it all out there.
Documentation is important.
Did I mention no spam? I never want to recieve an email about a tech-conference. If
you do come up with a developer community, don't require registration, you can't have
my e-mail, name, or anything else about me. No you can't try to sell me your other products or even plug-in's for this one.
Another business model would be to license the toolset under GPL, and sell a different license to anyone who wishes to make a non-GPL product. This has the added benefit that anyone can start working on a project, and once they're done checking the feasability, then they approach you for licensing. While the company may lose some sales from that, (fewer unnecessary sales), they will have more user satisfaction.
This business model can be stretched to include distributing the API in a closed source way, but free (beer), if you license it properly.
I think the real issue is advertising the product. How do you get your name out?
If you can get on slashdot, that's good. Advertising on google seems to be pretty good too.
Don't forget: You're selling Software to Software Developers.
The customers you want are the ones you can't bullshit on about your product. So be honest and think of what these people want.
Some simpple yet crucial rules you have to follow because of that:
1.) Solid Documentation.
2.) Works as Advertised and honesty about features and non-features. And don't just describe that something isn't supported, describe why and give them the opportunity to request little extensions that deal with the issue - you'll have a community in no time. (see www.gentleware.de as an example)
3.) Close contact/friendship. You and your customers ARE IN THE SAME BUISNESS!!! Give them space to discuss current problems in the field with your developers and get a feeling for the needs of the market. (if only Macromedia would do that...)
4.)Be good and tackle the difficult stuff that needs "Wow!" solutions - with a speciallized but modular aproach. In other words: Give me the tool I'm gonna bug my boss about! Nobody wants the zillionth IDE. Rather a rocksolid extension to existing OSS IDEs (example that I just had the other day : a Database binding administration tool that updates all the tedious error handling code and that kinda stuff automatically. Borlands proprietary stuff is cruddy and, well, proprietary and Netbeans lacks it)
If you make these rules your vision you're in for a solid long-term deal with a supperb customer base.
Good luck and welcome to the buisness.
We suffer more in our imagination than in reality. - Seneca
I think a good start would be to get your product up on "Ask slashdot"...
People who do this well (outside the big names) are perforce - they make it really easy to find out about their software, try it, and get comfortable with it.
jcorporate.com (home of the expresso framework for java development) are also pretty good - they have a decent mailing list and provide as much documentation as they can (though it appears they need some help there...).
Good luck
It's all very well in practice, but it will never work in theory.
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>
Above all your own developers should be the kind that " are impatient and have hubris" they should be given horrific deadlines and given immature teams to finish projects of the kind where your tools should be used preferably at a client site or something before anything else in other words the authors should first be convinced of the plot before sitting down to write
The way I see it, developer programs serve a number of uses. You've got to look it from a number of angles:
(a). Early adapters: Need to know what the toolset can do - why should they use this? Whether this is through demos, releasing APIs or giving particular features free is a matter of choice and what you think will work best. The main thing is getting 'buy-in'.
(b). Current 'dumb to intermediate' users - Need to focus on particularities -> stuff users don't know how to do or weren't aware of a particular feature. The best way to do this is to have feedback channels - users describing things they use or your own developers describing particular feature subsets. What this channel again is a matter of choice - whether it be newsgroup, articles on the web site or magazine articles etc.
(c). Advanced users - You need these guys to champion the product toolset. Again, if they document experiences they have had(especially if you can a big name that fellow developers will respect) it will make to big difference to people using the product. Also can use these guys to suggest product enhancements etc. The big danger with these guys is that they are always likely to find something else..
In my experience, developer groups have always had the limitation that they have treated everybody the same rather than categorising users as above;
If you're going after Microsoft developers, make it integrate VERY cleanly with .net
Here's what I look for when evaluating tools:
:)
- Factsheets of functionality, both abbreviated and full technical detail. Nothing bothers me more than marketing documentation that leaves out important technical information. If I have to call up a salesperson to find out if it will work on platform (x) I won't call.
- Downloadable demo. Preferrably without requiring pages of personal information. Asking for personal info in exchange for demo software is a big turn off. If I like the product, I'll be in touch. I *always* fill out the registration/personal info pages with completely bogus information anyway. Please get rid of these things.
- Online documentation with the following:
Usage documentation w/ examples
API documentation w/ examples
- Case studies on how the product contributed to various solutions are helpful, so long as they are written in everyday english. I hate case studies that are full of buzzwords and glittering generalities that don't say a damn thing about what actually happened.
- Online community support system/knowledgebase, either via newsgroup, mailing list, webpage, etc. This basic level of support should be free. Charging extra for access to upper-tier experts is fine.
- For getting the word out, listings on freshmeat/sourceforge and other industry directories are a good start. Presence at trade shows helps. Trade magazine reviews help. Reputable third-party books help once you're that mature. Taking out ads on slashdot probably helps too
The general rule of thumb is to treat me as an educated consumer and provide truthful information resources so *I* can make that decision. If I feel like the marketing department is trying to hide the product behind buzzword literature so that I have to talk to a salesperson in order to find out anything meaningful, I'll won't be calling. I don't mind calling to ask specific questions or clarify a specific point, but all the basic information describing the product should be readily available.
1. Have several levels of your Developer Suite. Have cheapy "educational" versions for students, or personal use, and more pricy commercial versions for business who need more support. I don't necessairly support making it FREE, but make at least a compiler/linker etc available for free, and then resonably priced Suites. Reminds me of the Visual C++ Studio that I was able to buy for $180 or 200 because I was a student. I would make it cheaper than that, tho, because students are typically cheap :)
2. Have the ability to NOT rely on your Developer Suite to use the rest of your product. It is kind of old fashioned, I guess, but probably 85-90% of the work that I do at my job is using vi and a gcc-esque compiler.
3. Make sure that using your Developer Suite will not make the code produced in it obsolete elsewhere. Use ready-available, modular code for your add-ons, and make them available and usable for the people who decide not to use the Suite.
4. Good documentation, also available for free. Provide good, solid, documentation for several levels. I think the Ruby Documentation (or download)is a good example of this because it starts out very low level for a newbie or student, but the end is a close to exhaustive set of built in libraries and methods. Publish the book for those that want to have a hard copy, but also make it available to read online. 9 times out of 10, developers will want to have a hard copy that they can put sticky notes in and page marks, but the information should be there for free.
If it is quality, people will use it!
We're changing PLC's for one of our products because the manufacturer sent us a detailed spec of their latest offering. It did one little thing (can talk RS-232 at TTL voltage) better then our current controller and a slick ad would have glossed over that detail.
My biggest complaint with tools has been archaic licensing schemes. I detest Parralel Port Dongles used for licensing I already have 2 of them attached to my machine along with a parralel port ICE. To top that off every time the vendor I am using puts out a minor revision change to their tools it requires new license files.
Intellegent licensing is the only issue I can see upfront. Obviously if your API's suck I am not going want to continue to use your product but by then it I have already bought it.
Above all, do *not* make it free.
/." (yes, that's "slash dot").
1) Hire someone to decipher the spamblocks of all slashdotters in all topics you can find. Don't bother removing doubles. Mail them about your valuable tools, they WANT to hear about them. Keep the list up to date, and repeat the mailing twice per day for at least five weeks.
2) Post daily anouncements in all usenet newsgroups, and post pointers to your website on as many online discussion boards as you can find. Don't restrict yourself to discussions about developer-related subjects, developers read other topics too!
3) Do NOT make it free. Make it _very_ expensive, and make sure to charge enough for a runtime license. Cheap tools are worthless toys, the more it costs the more confidence people will have in your product.
4) Make it so difficult that nobody can use it without support. As everyone knows, all tools that are easy to use lack functionality. Charge $1000/year per user for online support (a private NNTP-server with peer support newsgroups is sufficient; but make sure someone moderates it to remove messages related to bugs in your software, as there aren't any and those trolls only undermine confidence.)
Offer phone support at $500 per minute, accessible between 09:00 and 09:30 (Taiwan time), and make sure no support staffer speaks English or has an education above grade school (as everyone knows, the higher the education, the more they tend to use language ordinary people don't understand).
5) Provide some documentation (you can make it an option that can be acquired by anyone who buys at least 15 licenses). Organize it as one (numbered) file per subject, and above all do NOT include links or references. A search engine, if you add one, should turn up as many results as possible. For example, every search containing both the letters I and P should turn up everything related to networking (hardware and software). *Every* subject should start with a disclaimer regarding its correctness, followed by the full license agreement.
6) At startup, your tools should remind the user of the licensing agreements. It's a good idea to make the user answer a question like "what is the seventh word of the third paragraph of page 12 of the license agreement" before the tool will present its command prompt. Also make sure the tools check the number of licenses a customer bought (online on your I486 server connected over a 64 kbit line) and does a portscan of the local network every 15 minutes, memorizing IP address matches of previous scans, to make sure no more than the registered number of licenses is installed. As soon as a violation is suspected, broadcast an UDP datagram that disables all running installations *before* doing "rm -rf
I find it interesting that in answer to the question "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?" All the answers revolve around the concept of providing a good product and service!
I mean, this is the new economy we are talking about. We don't need good products, just effective marketing campaigns. We don't need good support after the product is sold. We've already got our money after all.
How am I as a "Marketing Manager" going to work with all these wishes for quality production and support? I get my orders from above where they say "Here's what we made, now sell it." Who am I to tell the execs "My sources say I would sell more product if we could offer a product that is better than the competition. So can we make the following changes?"
Ok, so I'm a bit cynical about marketing, and the way so much shit gets put out in fancy boxes with testimonials from "Reviewers" who will stamp their name on anything for a small fee.
While the replies on this post have been very thoughtful, most of them seem to be geared toward how the company with the Product can make the product good enough to appeal. And that is certianly the first step in any offering. But I think that has to be taken for granted to answer the question at hand.
Assuming the product does have the quality and features developers would like to use, how does the company effectivly get the word out? If you had a toolset that you truly believed in, how would you transfer that belief to a developer and convince them to buy?
I did it because it was the valiant and courageous thing to do. And I was bored.
Oracle, for example, lets us developers download a version of their Database Server for use at home, so we can build up those development skills in Oracle PL/SQL at home and use them at work.
Offer a free version of your product, like Borland does for Kylix, that only can be used to create open sourced products, and for commercial use we have to buy that $500USD to $5000USD compiler and license. That way we can try out your language or tool, and if we like it we can buy the full version and get jiggy with it. Nothing like spending $500USD to $5000USD to get a language or tool that you do not like, and wished that you could have test drived it.
Offer free online help, even if limited, it helps out greatly. Create a newsgroup on it, make a forum, get TWIKI/WIKI to document stuff, whatever it takes to help us out. By helping us out, you are helping your company out as well.
I think this is an interesting question. The company I work for has for some time now been selling a product which, basically, rocks. The product is an a complete development language and design methodology complete with IDE that is second to none. I say this not as a 'marketing within a marketing discussion' opportunity (I personally get no extra money if they sell more products or not) but because the product is far superior to any other I've encountered. Unfortunately, however, it is still remarkable difficult to market because it is hard to convince programmers/developers to learn a new language even though the long term benefits (portability, reliability, time to market, etc.) of doing this are a great advantage. Most people are still using languages with roots in the 60s and 70s and things have come on a lot since then but the language fundamentals have not. How do you market something that, by nature of its superiority, implies the methods currently employed are, most likely, not the best. People don't want to be told they are doing things wrong (or at least not optimally), especially when they have been doing it that way for years.
Rake Free + Mac Poker: CardCrusade
Reading the responses to this question really makes me think what a bunch of aragont loud mouths we have here. It reminds me of when you ask your user base for new features for 2.0, "well, uh... I'd like this and that". They THINK they know what they want, but I bet what they want probably isn't a good idea, nor right for the product.
Slashdot people have no idea what marketing even means, I knew from the get-go they would say "leave us alone and make a good product, preferably for free and we'll use it". Ya right, how would they even know about it then? From "Crossing the Chasm" I would recommend you find a small niche of developers, like game dev's or embedded system dev's and market to them specifically, give them all the features they want and maybe some they don't even know they want, become and industry standard in that market segment, then move onto an adjacent market segment. In this example the game dev market would be a "beachhead" segment, where the troops would land, they you go ahead and invade the next town and so forth.
And forget 90% of what these people said, except the free demo thing, cuz I really dig that.
-Jon
this is my sig.
Hey, most of the t-shirts I wear I didn't have to pay for, it's convenient ;-)
And who can't use another Tuxedo penquin...
But seriously, what annoys me is when you have to fill out a 6-page form before you can get the software, and then it has important features disabled so you can't save what you do, or it works but anything you do in it will stop working after a few days. Given the hassle for what you get, I'll generally just ignore it.
Twenties Retirement
Didn't see any mention to Apple's ADC: IMHO seems to be an interesting model; it was quite helpful in my experience.