views:

259

answers:

6

My company sells developer tools. As a developer myself, it is hard not to assume that what is important to me is important to many other developers:

  1. In our case, the thing we lack the most is time. So, I'm willing to spend money on things like Microsoft Team Foundation Server which integrates well with Visual Studio and handles various aspects of managing a software project in an integrated fashion. And InstallShield Professional, which seems overpriced until I think about how much time it saves me. We arguably spend too much on the latest and greatest computers and monitors. I even built computers for two of us from gaming parts - at one year old they are still faster than a top of the line Dell Precision which we purchased recently (I was too busy to build one at the time).

  2. I care a lot about performance and efficiency, so I am happy to spend money on tools which help us to build a faster and smaller product.

  3. I am satisfied with the tools we use with one exception - support. It is amazing to how bad the support can be from some very successful companies.

  4. I prefer a terse, to the point technical book (K&R C is a great example of what I mean by this) or article to a wordy one.

So, all of this probably comes across in our product and company:

  1. We are not embarrassed to charge for our software. We are not the most expensive option, but we are certainly not the least expensive.

  2. We spend a lot of time on the performance of a feature before we release it. We spent 27 months on V1 of our product - and it did little more than read, write and calculate.

  3. To make sure that our customers (who are developers) get good support, our developers (including me) take turns providing phone and email support.

  4. We don't spend time on wordy doc. We have short Welcome / Getting Started / Tutorial sections in our help, but we spend most of our documentation efforts writing terse API reference material and creating samples which address the questions asked most frequently by our customers.

For each of these subjects, we could arguably do something smarter:

  1. We could have a less expensive limited version (fewer features and / or less support) or even a free "Express" version with appropriate limitations.

  2. We could do more features and spend less time honing each of them.

  3. We could hire a less experienced and less expensive person to do first line support.

  4. We could spend more time writing wordy documentation or hire a full time documentation person next instead of another developer.

What is important to you?

+2  A: 

Regardless of how much they cost or how much support they have or whether they're commercial or open source I'm only interested in how well they work. That's why something like Prince XML is worth the 4 grand for a server license. It's simply so much better than anything else at turning HTML into a PDF.

It's also why I prefer Oracle to any other database. Oracle is simply way better than anything else.

+3  A: 

Not being locked in...

If I have to make any investment in using your tool for the project (e.g., testing plans in a certain format, repository structures, special annotations or proprocessor macros, etc.), I want to know that I can move to another vendor's solution and reuse some of my investment.

Even if your tool is the best now, it might not be as well supported in two years... Offer me at least ways to export everything project related to some common format.

For example, if you have a project management system, I want some option of migrating my repository to CVS/SVN. I may lose some stuff (get me a way to create a paper record!) but I want the core of what is portable to be portable.

Uri
Are you talking doable? Or doable with no work? Our file format is identical to a defacto industry standard and our API is close - but switching would not come without work.
Joe Erickson
It's a cost balance. There is naturally some work, but it shouldn't be prohibitive. In other words, I shouldn't be stuck with your solution when there is something functionality superior because I would have to completely rewrite (not just change a few calls) to use your approach.
Uri
For example, if you sell a component that has a certain API that requires some crazy patterns that would be very different than any other eventual vendors, that could be a problem.
Uri
I've looked at the code samples for your controls and they seem sensible, so maybe this is not an issue. But I don't know what your competition looks like.
Uri
+1  A: 

Regarding support for the tool. Nobody is going to read a detailed manual. But everyone is going to look (at some point) through a good knowledge base. Make sure there's a good FAQ, and make sure that knowledge base is there. I'd personally sacrifice having an answer written nicely, for an answer that is correct and that I can easily find.

As for support, while I applaud having developers do the support, I am not sure how useful that is unless "they eat their own dogfood" regularly. Besides, better talking to somebody whose job and willingness is to answer questions, than a developer for whom you're a nuisance.

Uri
+7  A: 

If you want to get your software out there you should:

  • Have a fully-featured demo;
  • Be upfront about pricing. As soon as your website says "Contact us for pricing" I've lost interest;
  • Be sufficiently cheap that it can be bought without getting approval from the CEO. Look at Jira. Relatively cheap, insanely successful;
  • Be the best. Eclipse and Netbeans are free and packed with features but when it comes to Java I'll happily pay ~$600 per license for Intellij because it is (imho) way better;
  • Be justified in cost terms versus the competition. If you're doing a source control tool, how well does it compare to Subversion and relevant plugins (VisualSVN is cheap, TortoiseSVN is free);
  • Make me more productive and not get in my way (Rational tools get in my way). Another example of this is where software refuses to work because it can't find a license server to talk to. Paranoia about piracy will kill you;
  • Be designed to help programmers and not designed to be sold to companies (there's a difference).
  • Be responsive in support and feature requests; and
  • Have a relatively quick product release cycle. If I'm waiting 2-3 years fo ra major release, sorry I've lost interest and you've lost ground to the competition.
cletus
+1  A: 
  • It has to be really easy to use. I don't want to spend as much time learning your tool as I could implementing my own solution. There has to be a win there.
  • It has to work in production

That's it, two things. It has to be understandable and work. Simple.

Stephane Grenier
+2  A: 

Community.

If there isn't a good developer community the tool will wither and die.

Fortyrunner