Slashdot Mirror

← Back to Stories (view on slashdot.org)

HOWTO Go About Marketing to Developers?

Posted by Cliff on from the where-traditional-marketing-strategies-fail dept.

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?'"

24 of 267 comments (clear)

  1. FREE, As in Beer. by mass · · Score: 2, Insightful

    FREE, As in Beer, as in give it away. Charge for support, instead...

    1. Re:FREE, As in Beer. by Zurk · · Score: 2, Insightful

      Palm did the exact same thing initially -- they gave away the OS (ROM dump of several versions of debug OS), devtools, emulator etc etc.
      They still do if you sign the NDA and fax it to em.
      They sold the hardware with the non debug OS.

      do the same. give away a DEBUG version of your tools which cant be used in production and SELL the complete non debug production version.
      just dont make the debug version an eval or time limited. let it print gobs of debug messages and make it bleeding edge.

      That'll be $400 for my consulting fee. Thanks. ;)

    2. Re:FREE, As in Beer. by Anonymous Coward · · Score: 2, Insightful

      Charging for support only works if your documentation sucks. And if your documentation sucks, they'll pay for something else. People will pay for documentation, but they'll pay Tim O'reilly, not you.

      If you really want developer mindshare make it so that they don't need to pay for support. This is even more important than free beer, and is the real draw of open source software.

    3. Re:FREE, As in Beer. by i0lanthe · · Score: 2, Insightful

      Doesn't have to be FREE, just provide a nice discount, both Palm and Sony has developer programs that provide nice discounts for the products.

      hmmm. The goal of Palm and Sony is to sell hardware (PDAs); as such it makes good sense to give away development tools, emulators, etc., and (when convenient) to provide limited discounts on some models of the hardware for registered developers. Poof! Lots of third party software, lots of reasons for non-developers to buy PalmOS instead of a competitor's product.

      Fundamentally this kind of "free stuff" is about making your real product more attractive to its target audience.

      If the development toolset is the real product, then you can't give it away and survive; you can't even discount it to developers (because your whole market is developers so that would be "everybody"); instead, probably take the crack-dealer approach, "first hit is free, you're hooked now, you pay".

      If instead the development toolset's relationship to the product is "effortlessly [from your perspective] causes the creation of things that make the product itself worth buying", then yeah, cast your bread upon the waters and get it back 1024-fold or whatever... don't necessarily make everything free but make enough of it free (or make enough of the specs open that other people create free/cheap tools) so that the most shoestring-budget developers truly only "need" to buy your actual product, your PDA-or-whatever (and if you have different interchangable gradations, from "minimalist free toolset" to "all-singing all-dancing commercial toolset", you can work the crack-dealer angle back into it after all... here the comparison to PalmOS development tools definitely breaks down because it requires actual effort to move a project's codebase from the gcc-based tools to the commercial tools, so it becomes hard to justify moving in either direction.) And if developers are only a tiny fraction of your real product's real audience, sure, you can probably afford to give developers some discount on the product itself, after you've finished thinking about how cheap you can make the tools.

      --
      "The Crystal Wind is the Storm, and the Storm is Data, and the Data is Life"
  2. Make it friendly by nate1138 · · Score: 5, Insightful

    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.
    1. Re:Make it friendly by jrj102 · · Score: 2, Insightful
      Unlike many markets, yours isn't full of people that can't tie their shoes.
      Sadly, this has not been MY experience. I have met some seriously stupid developers. I don't mean "can't write a decent algo" stupid... I mean "what's the number for 911" stupid. I always thought that the mindset required to be a programmer/developer would act as an intellectual filter of sorts... but alas, that idealism was based on the assumption that everyone in the industry would be at least marginally productive, which is often not the case. Now... Getting back on the thread... I hate to admit it, but nobody seems to have licked this as well as Microsoft. The OSS projects I've worked on did not have very good developer documentation because documentation is not fun. Even companies like Macromedia (I do a lot of ColdFusion work) don't do a good job of supporting developers. However, Microsoft's MSDN is an excellent resource when I'm writing code for people on the dark side. I hate to admit it, but their developer support is one of the few areas where I have to give them some credit. --- jrjones@criticaldomain.net
      --
      jrjBlog
  3. Don't lock them in by Myshkin · · Score: 5, Insightful

    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.

  4. i don't think it's possible by cballowe · · Score: 5, Insightful

    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.

  5. Marketing to developers... by scherrey · · Score: 4, Insightful

    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!

  6. Free is good, not not required. by haplo21112 · · Score: 5, Insightful

    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.
  7. Treat them like developers by maiden_taiwan · · Score: 4, Insightful
    - Your product should use industry-standard vocabulary instead of inventing your own jargon for everything. This way developers can understand what your product does and compare it to others.

    - 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.

    1. Re:Treat them like developers by Amazing+Quantum+Man · · Score: 4, Insightful

      Have a fully functional demo version for developers to try free.

      Do NOT require an email/snailmail or phone number for this. We don't want marketing BS cluttering up our phones/mailboxes. If we like it, you'll hear from us. Otherwise, be prepared to have a lot of downloads from

      Name: J. Random Developer
      Title: Linux God
      Email: bite.my.shiny@metal.ass.dude
      SnailMail: 123 Any Street, Anytown, AK, 99999
      Phone: 900-FOR-SEXX

      --
      Fascism starts when the efficiency of the government becomes more important than the rights of the people.
  8. I really don't like IBM's Developer Works by ChaoticChaos · · Score: 2, Insightful

    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!

  9. Make it easy to get started ... by Titusdot+Groan · · Score: 3, Insightful

    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 ...

  10. No bullshit and hype by Tablizer · · Score: 3, Insightful

    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.
  11. Create a Dog Food Factory by Neumann · · Score: 2, Insightful

    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)

  12. Honesty, integrity, reliability by maggard · · Score: 3, Insightful
    Be honest about what your product can do. Be honest about what it can't. Be honest about any bugs or misfeatures in your product.

    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.
  13. promise the sky by g4dget · · Score: 3, Insightful
    Just do what Microsoft and everybody else is doing: promise the sky, make it flashy, and make some simple programs really easy. By the time your customers figure out that they are hooked on another complex, proprietary library/system that really doesn't work any better than anything else, you have them already hooked.

    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.

  14. My Personal Rules by johnbr · · Score: 2, Insightful
    I got a lot of calls from a lot of vendors for tools and platforms. Here's where they caught my interest:


    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.

  15. How to create a developer community? by chris_mahan · · Score: 4, Insightful

    You have developers in-house.

    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 .NET advertising?), no amount of advertising can sway developers. We're not teenage girls and you're not selling shoes.

    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."

  16. Either free or free samples by El · · Score: 3, Insightful

    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

  17. Re:Free T-Shirts and useless toys to sit on your d by M.C.+Hampster · · Score: 1, Insightful

    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.
  18. Key items to do by Animats · · Score: 3, Insightful
    • Be utterly honest about your product's weaknesses. It's better that developers hear it from you than find it out the hard way. It reduces the risk from a development manager point of view.
    • Provide a public bug report and tracking system. Reported bugs should be logged in and customers should be able to monitor their status.
    • Reported bugs must be fixed or fully documented as restrictions. No hidden bugs.
    • Import project files from competing products. This is a no-brainer.
    • Offer a full one-year warranty. Satisfaction guaranteed or your money back. A few percent of the customers will return the product. Ask them why. It's a cheap way to find out what you did wrong.
    • Offer reasonable feature combinations. Microsoft is notorious for offering development tools in price tiers, with the higher tiers having about 95% of stuff nobody wants, but 5% you have to have. Don't do that; you don't have a monopoly.
    • Study Metrowerks. Metrowerks made it as a tool vendor. Find out why.
    • Study Symantec. Symantec blew it as a tool vendor. Find out why.
  19. Example code by pommiekiwifruit · · Score: 4, Insightful

    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

    • (a) doesn't know the api and
    • (b) couldn't code their way out of a paper bag anyway.

    </rant>