“Re: Help with Macrobyte's Future”

Don makes a good point here. Failing to effectively price one's services and products have killed more than one company.

There's an old saying "the only one afraid of the price is the salesman."

The hassle here is that the customers aren't going to educate themselves on this sort of stuff. Someone's going to have to sell them on the idea. This is an incredibly tricky process. One that I daresay has been really unbalanced by vendor behavior. Seth's asked me to "be civil" here so I'll leave it at that.

What's needed is a good old-fashioned sales effort. Someone's got to package the solution and go sell it. Otherwise it's just a consulting effort. Granted, the consulting effort can be lucrative but it too has it's own sales cycle.

Perhaps it's best to look at having a liberal evaluation edition that defines clear limits on what can and can't be done with the code. If anyone's going to take the time to steal the code there's little you could ever do to stop them. So for the rest of the customers it's got to be something they can get their head around at a reasonably low point of entry. Evals with realistic time and data limitations are probably the best hope for building mindshare.

But you're still going to have to sell it. It will never just jump off the shelves. It won't even drag it's lazy ass out off the UPS truck and out of the box. Someone's going to have to pound the ground, press the flesh, and make those sales. This concept seems to be completely lost on the dot.bomb people.

Make an eval package. Make it genuinely work and be installable by mere mortals (or even IT guys). Give serious consideration to how the most likely first contact is going to view this process. If that's the infamous "IT department" then pay close heed to what they perceive as their important issues.

Look at how badly many of the existing programs treat their install process. Is it any wonder they're installed with all sorts of default security or other important settings? The effort of just getting them running was so complicated that the users just gave up once the rickety beast looked like it was working.

Next take serious stock of what the customer's maintenance of it is going to be like. Make sure there's a good understanding of the disaster recovery scenarios. Document and actually test them. If you're going to push something out the door, you'd better be sure of how it's going to behave in the field.

If you're treating this like a consulting project then a lot of these steps seem less important. After all, the more it breaks the more you can charge for support, right? The truth is somewhere closer to the customers just jumping ship.

Ah, I could go on. The point is there's a lot of really hard work that needs to be done in the sales area. Decide whether that's what you want to do. Without it this has all been just a really cool technical exercise.

-Bill Kearney