Become a software monopoly
So you want to be a software monopoly? Welcome to Software 101, the one module that skips all that tedious programming to tell you what you really need to know in order to dominate the market.
Don't be drawn into the fiction that creative thought, inventive design and implementation effort are required to create a marketable product. Any old piece of code you have lying around will do. Even code that someone else left lying around; for example, on their web site. After all, if someone needed to write it, chances are some other sucker needs to pay for it because they're not smart enough to write it themselves and too dumb to see that a hyperactive monkey could write it better.
Whether it actually works or not, or is even finished, is a moot point. There is still a market for untested, fragmentary software, otherwise many present day companies would never have made it this far. If you feel that your code really is in a total state of disrepair, consider marketing it as one of the following:
A healthy dose of marketing claptrap can do wonders here, making your unused Perl module seem like something so revolutionary that even you'd buy it. Let's hope those other saps do.
Be honest with yourself up front before attempting to become the Dostoyevsky of technical authoring: no customer ever reads manuals. Ever. Period. It's much too great a waste of their precious time, when they have software salesmen to entertain them and navel fluff to extract, and would detract from that childlike yet frighteningly intuitive aura of naïvety (i.e. fog of ignorance) they feel they possess.
Given these facts, you'd be much better advised to pay a design agency to come up with a really impressive colour cover while you print out random extracts from the online system manual (any system) until you have sufficient pages to discourage overly curious users of your product. Don't forget to index it; write an auto-indexing tool using rand() and flog that too. And get some screendumps of your product in there or, if it's not sufficiently photogenic, your rival's. To save the customer even more time, throw the completed manual in the bin or lose it.
All manuals suffer from the now widely recognised problem of `assumed knowledge'. Ostensibly, this is knowledge of the product you already possess but are unaware of, and thus unconsciously expect the user to have too. However, it can also apply to the often mistaken assumption that the user has any clue whatsoever. Because even if you reprinted verbatim everything that was ever published about the underlying platform, hardware, OS and supporting applications, you'd still be fielding support calls from people who have accidentally eaten the CD. (Some people can't even manage to open the box, but you needn't be concerned about them as they won't be able to find your support line number that way.)
Don't bother listing product limitations, disclaimers or implementation warnings in the manual. For one thing, marketing will force you to remove them because the truth often hurts. For another, as hinted above, no one reads them anyway. This is why customers buy, for example, backup software and insist it be able to catalogue web pages. This is amusing, but not nearly so much when the sales team forces you to implement the necessary functionality - bolted on like the head of Frankenstein's monster - to keep the sale. In addition, printing warnings about how not to use the software is tantamount to bribing the user to do such things and then complain when it doesn't work.
What the hell are you on about, it runs on your machine, doesn't it? Then why on earth would it fail to run like that all the time on any other machine? They're all identical, right? And if one feature works, the rest ought to because they're all in the same source file, yeah? Testing can soak up valuable time when you need to be out there flogging the thing to pay your bills, and it's boring. Besides, the customers are screaming for the new release and threatening to go elsewhere if they don't see it yesterday - despite not having staff available to do the upgrade for the next six months - so they might as well test it. Easier to fix any bugs then than recover a lost contract, c'est oui? Exactly.
Marketing literature should be akin to a vision statement, covering as it does features that you hope to implement one day. Poor, rushed design and coding can often be mitigated by spending more money on the marketing strategy. Indeed, you may find that a substandard programmer - who even finds binary confusing because of all the figures - can be a talented marketing executive in disguise.
Don't be misled into thinking that marketing ends in the production of a few glossy brochures featuring half-naked women with a tenuous connection to software. Apply your campaign to all aspects of your product, including technical documentation, online help, error messages and release notes, to form a unified message. This is most easily accomplished by removing all useful information, substituting instead vague and optimistic rumours about possible functionality. Remember that a slim, monosyllabic manual containing no hard detail can be an excellent pre-sales brochure; truly, this hides complexity from the user.
A highly effective way to promote your software in the technical marketplace lies in the publication of a "whitepaper". Presenting this as an authoritative and independent analysis of the problems your products claim to solve allows you to employ almost subliminal techniques in publicising them, whilst often affording the opportunity to rubbish your competitors in a dignified, legal fashion. Technical information can be limited to a few figures ripped from one of those system functions that produces lots of numbers, such as our old friend rand(). Put them into tables and label them something like "Sound to noise ratio of co-differentiated process execution"; you don't know what it means, neither do they.
Dealing with real, live, allegedly conscious customers is often the most frustrating part of becoming a software king. The toughest ones can be infuriatingly sceptical of your claims for the product you sell, asking awkward questions and demanding demonstrations of capabilities that you know it simply does not possess, regardless of the brochures. Worse, their scepticism, whilst admirable to a discerning engineer, is usually misplaced. They will often reject the credibility of key features in your product, simply because they have not come across them previously in their own small field of experience, while swallowing the much greater fiction that they actually need them at all (or that the product works).
This bizarre combination of perceptive interrogation and breathtaking gullibility is usually directed at technical staff rather than the generally ignorant sales representatives who are responsible for most of the B.S. Yes, that's right: the customer distrusts or denigrates the word of an honest and knowledgeable installation engineer yet never questions the claims of a person paid on commission for everything they can persuade the customer to purchase, simply because the latter affects to like them on a personal level.
Salesmen do not like customers, characterising all of them as either:
Customers are always eager to proceed with installation ASAP once they've had five sales meetings, visited three reference sites, considered your proposal for the lifetime of one parliament and managed to get the purchase order out of the door (minimum turnaround, six months). This can be frightening when you're busy trying to close similar deals with twelve other customers, of which you can only deliver on two.
Initially, you should issue a fifteen page pre-installation audit, requiring no less than the entire company history, a copy of the last financial report and the resumés of every person likely to come into contact with your product. Should they persist, skilful brinksmanship is the best way to buy time. When they ask how soon you can deliver and install the system, tell them you have someone arriving on-site within the hour: "Errr, we'll call back to confirm. <click>". This usually scares them off for at least a year. A really good software company will at this point bill them.
Customers are notoriously unable to handle bad news. In the words of Jack Nicholson in that Navy flick, "You want da truth?! You can't handle da truth!!" For this reason, do not ever admit fault or liability for the faulty operation of your software. In HappyLand, where the customer gambols and plays, software does not have bugs and does everything the salesman said it would, all the time, perfectly. Therefore, patches should be "feature updates", fixes should be "modifications" and outright disasters culminating in the loss of all the customer's financial data should be "someone else's fault", preferably the customer's.
Don't feel guilty about this. If they didn't hyperventilate and threaten all kinds of penalty clauses, lawsuits and media attention, not to mention your administrative staff - and one of them is pregnant and was only covering reception for the afternoon anyway - when you notified them that the latest OS release was incompatible with their version, you wouldn't have to hide the awful truth about the divide-by-zero error that silently corrupts the entire database.
That's not to say that all support calls are potential minefields of future litigation. Many of them are merely breathtakingly dumb. Again, it's the problem of assuming that the customer possesses the same knowledge you do (and doesn't think format is the generic repair utility). No matter how many times you insist that what the customer requires is so simple, they could do it themselves in five lines of script, they will frequently challenge you to prove it. This is simply because they are convinced that if you do it, it will somehow be:
Remember that you can usefully keep the support wolf away from the door by blaming problems on related factors, such as the OS, the hardware and the phases of the moon. Inform the customer that your support procedure strictly forbids further investigation until all external factors have been verified; with luck, the other vendors will have similar policies, and thus you can keep a support call tied up for months until someone gives in and accepts the blame to get rid of the customer. After all, this is what partnership and integration agreements are for. A talent for fast thinking is useful here, as it will enable you to quickly invent a plausible reason why the problem is likely to be someone else's.
Engineers sometimes like to publish lists of "known issues", "common solutions" and "frequently asked questions", in the vain hope of avoiding the most frequent calls. Stop them at all costs, as this kind of information can seriously corrode your marketing message. Besides, who reads it?
Matching your competitor's bull with a stampede of your own; Why you can never threaten enough resellers with sufficient violence; and Lock-in: How your customers' insecurities can make you very secure indeed.
This page is provided "as is" without warranty of any kind, either express or implied, including, but not limited to, the implied warranties of merchantibility, fitness for a particular purpose or non-infringement.
This page could include technical inaccuracies, typographical errors, half-truths or total lies. Big Bubbles reserves the right to deny any resemblance to real or imaginary organisations or companies.
In other words: revelation is in the eye of the beholder.