“John vanDyk Responded”

John vanDyk posted his thoughts on the issues Macrobyte is facing.

First, John said:

The fundamental issue is that support comes at a high developer cost. Seth, you will not be able to keep coding and support users. There must be a mechanism in place for that. If that mechanism involves support contracts, that just means there's money involved. It doesn't change the fundamental reality that when you're doing support, you're not coding.

Yes, this is a given, though it's something I may not think about enough.

What I perhaps didn't make clear is that I want to get back to a team of seven developers, or six developers and a full-time support person.

Also, developer-support would be a lot like sales-support, as a few of the developers that I've spoken to have said that they would like to be resellers/vars.

Support contracts with production installations would be, or will be, one of the revenue streams. If they're priced correctly, they'll a way to support additional staff (see above).

John's second point:

Charge what the software's worth. Don't give it away for less than it's worth if you intend to make a living at it or are trying to saturate a market

Unfortunately, the worth/cost/value of a product is determined by market forces, not by the company that makes or sells the product.

How much can we charge for production licenses to Conversant, without crossing the hard-sell barrier? As soon as that's done, the time involved with each sale goes through the roof.

John's second point:

Marketing. You hate it. I hate it. But it has to happen. Conversant is not currently the talk of the net. It needs to be! You've got a killer application there. Roll it out right.

Blech. Next point. ;-)

No, seriously... I meant what I said about not having a marketing budget. It's just not going to happen, at least in the short term. Something needs to bootstrap Conversant's success, and that first little thread of success is going to have to come from developer adoption.

Okay, last point:

Do PDF documentation (time spent on documentation saves user support issues -- not because they'll read it before contacting you, but because you can zip back an e-mail saying See section 3.1.4. rather than explaining to them what a Resource is)

That's a very good idea. There are other ways to accomplish the same thing. For example, we could deliver a radio-based set of HTML docs for the developers. Then we could just refer to the docs on their own machine, by URL.

PDF might be a better idea.

Of course, this has nothing to do with the pricing issue, but I apprecaite the thought he put into it. Thanks, John